Mujina Dev Call #2

Mujina Firmware
1
1 Like
Mujina Dev Call
2

I remember we had 2 people recording, maybe we can have the raw recording and/or the summary here?

1 Like
3

Definitely. I hopped on an airplane almost right after our call for the Telehash and Texas Energy and Mining Summit, but we’re done this afternoon, and I should get to it tonight.

1 Like
4

Generated by AI from the meeting recording.

Mujina Dev Call #2—2026-05-18 1700 UTC

Attendees: Ryan (host), Johnny9, Gary, Jayr, Skot, Tyler, David. Referenced but absent: Jeff (author of the YAML config PR), Schnitzel.

Summary

Meeting format

  • Adopt Gary’s suggested flow: walk GitHub discussions first, then issues, then PRs. Share screen when there’s something specific to refer to.
  • Cap calls at 1h30 (David’s suggestion; these run on a weekday).

Config file and persistence design

Triggered by Jeff’s open YAML config PR. Ryan flagged that this needs a design conversation before more code lands.

  • Most changes made via the API should persist across restarts—in practice “config, by definition, is something you persist” (Johnny9). Skot’s NVM-overheat example: derated settings have to survive a power cycle so the box doesn’t come back up at its old unsafe state.
  • Two layers proposed:
    • User-managed config: hand-edited, comments, ordering preserved, never clobbered by the daemon.
    • Process-managed config: machine-readable, lives at a default location, freely rewritten by the daemon. The cascade/merge layer that overrides defaults.
  • Schema must distinguish defaults from user overrides so software updates can move defaults without trampling user values (Johnny9).
  • Hardware config and application config feel like different things (Gary, Skot). Hardware config (which boards, which I2C devices, which fans) is mostly static and schematic-level; application config (pools, API, log levels) is the runtime-mutable stuff.
  • Dynamic discovery wherever possible (USB hotplug, board EEPROMs, AMLogic control-board self-detect, S19 hashboard layout); static config only for the genuinely non-discoverable (fan presence, I2C addresses, power-supply wiring).
  • Jayr’s per-device case: two nominally identical Bitaxes, one runs hot. Want a way to fingerprint a specific device and override its config without touching the driver defaults.
  • Open question Ryan flagged: when a user passes an explicit startup config file via a CLI flag, where do API-driven changes get persisted? Gary floated an explicit “export current config” command rather than auto-writing.

Hardware-in-the-loop testing and safety

  • Ryan wants integration tests on real hardware soon—already hesitant to make some changes for fear of breaking functionality.
  • Open-source-friendly self-hosted runners are awkward: random PRs shouldn’t be able to flash arbitrary firmware onto someone’s house hardware.
  • Johnny9: start simple—a GitHub workflow gated on maintainer approval before it runs on hardware. Forces end-to-end tests to get written; infrastructure can grow later.
  • David described his employer’s lab setup: many duplicates per miner model, Jenkins-managed scripts, perpetual perf/efficiency tests focused on releases. Hardware failures during normal QA are rare; happen mostly when modifying auto-tuning or sleep logic.
  • Direction settled on: a standardized downloadable test suite anyone with hardware can run and publish results from (Skot’s framing). Defer a central orchestrator until clearly needed.
  • Skot cautioned against an “official Mujina lab” carrying centralized responsibility for validating safety across all devices.
  • Bitaxes are the safe starter target (“better to melt one of those” than a 3kW S21).
  • Jayr suggested a ProtonDB-style community reporting site for hardware compatibility once the project supports more miners.

Community ports and the “vibe-coded” workflow

  • Tyler started a forum thread for tips/tricks on porting Mujina to other miners—meant for non-developers driving experiments via AI agents (Schnitzel, Skot’s S19 work).
  • Skot wants a “hacker kit” / getting-started guide covering the pre-Mujina problems too: removing proprietary firmware, getting around Secure Boot, loading arbitrary software onto control boards.
  • Two distinct problems to keep separate in docs: (1) get arbitrary software running on the control board, (2) add Mujina support for that board.
  • Ryan’s framing: this is perhaps a new open-source workflow for 2026—vibe-coded prototypes do research, then maintainers turn those vibes into production-quality merges. Skot’s corollary: keep Mujina modular so prototypes can drop in without rewriting the core.
  • Any porting docs must lead with safety warnings (fire, hardware destruction).

Bitaxe Bonanza USB identification

Johnny9 is finishing the Intel-ASIC PR and needs to distinguish Bitaxe from Bitaxe Bonanza on the wire.

  • VID/PID allocation isn’t really under the project’s control—the string descriptors are.
  • Skot: key on hardware version number, the way ESP miner does (601 / 602 … 1002 for Bonanza).
  • Both agreed bitaxe-raw on Bitaxe vs. on Ember One are different enough to stay separate firmwares.
  • The Bitaxe naming inside Mujina currently assumes Gamma and is too narrow; needs to get more specific.
  • Decision: change the USB product string to encode the hardware version (e.g., “Bitaxe 1002”) for Bonanza, then iterate.

Adjacent

  • David’s company released their internal firmware orchestration / miner-management app as open source on their GitHub. They plan to add native Mujina support in the next few weeks—it’ll pull hash rate, uptime, temps, etc. via the Mujina API.

Action items

  • Ryan—write up the config design in a GitHub discussion and leave concrete feedback on Jeff’s YAML config PR, so the next round has something specific to argue around.
  • Ryan—file a “good first issue” for porting USB hot-plug discovery to Windows (works on Linux and macOS today).
  • Ryan—create open, contributor-friendly issues as they come to mind; don’t batch.
  • Ryan / everyone—treat safety warnings as the lede of any porting / on-other-hardware documentation.
  • Skot—post porting tips and tricks to Tyler’s forum thread.
  • Johnny9—update the Bitaxe Bonanza PR to set the USB product string to the hardware version (e.g., “Bitaxe 1002”), then move it out of draft.
  • Open—start drafting a standardized downloadable test suite anyone with hardware can run and publish results from; tests live in the Mujina source repo (Johnny9 / Skot direction).

Full transcript:

dev-call-2.clean.txt (65.1 KB)

2 Likes
5

Quick follow-up: one of my action items was to write up my vision of the config design specifics so we’d have something concrete to review instead of hashing it out in the abstract.

That’s done. It grew into a full set of requirements for Mujina’s configuration system and REST API, written up as MIP-0001 (the first Mujina Improvement Proposal, a new lightweight design-doc convention in the spirit of Bitcoin’s BIPs and Nostr’s NIPs).

There’s a short intro thread on GitHub Discussions:

And the MIP itself is open as a pull request, which is where review and comments should happen:

I’d really value everyone’s feedback! Please read it and poke holes; comments, suggestions, and patches welcome on the PR.

2 Likes