# Mujina Dev Call #2 --- 2026-05-22

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


## 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 damaging boards.
- 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 M64 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 a new open-source workflow for 2026 ---
  vibe-coded prototypes do the 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 Bitaxe 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).


## Transcript

Ryan: Recording is on okay oh now I now I see the I do get a a red thing up at
the top it says it's being recorded so All right, well, as I said last time,
the format of these meeting and agenda of these meetings is definitely up for
improvement or suggestions. So we haven't really established completely a good
rhythm yet. So I definitely lean on those of you who are more experienced
holding calls like this to give me suggestions. And help me drive this till we
establish some patterns. I think most of the people here were here last time,
so everyone sort of knows each other. If anyone is new and wants to introduce
themselves, that would be nice. So maybe, Johnny, you weren't here.

Johnny9: Yeah. Yeah, I can get started. I'm Johnny or Johnny nine. Do Bitaxe
firmware stuff. And I'm currently working on the Intel ASIC and have a PR up
for that. So. So yeah, that's what I'm working on.

Ryan: Very cool. Johnny is a legend. Anybody else want to introduce himself?
All right, take that as a no. It's definitely not required. So Gary, you had a
good suggestion last time on how to run these that I didn't write down, but I
remember you said something insightful. Can you replay that for me and I will
write it down this time?

Gary: Yeah, so I would mirror your expected flow through the project. Um, so
you'd previously outlined that you want to do a discussions first. So, um, in
my opinion, handling discussions or new discussions or update to, you know, a
hot discussion or something like that would be first, since that's like the
design way. And then that can trickle down to issues and PRs that are related.
Uh, but it's sort of just kind of going through the GitHub, uh, in a, in an
ordered fashion. And since you want to drive discussions first, target that. If
there's anything to be discussed, you discuss it. Then you move on to the next
most relevant thing. Maybe it's an open PR that's ready to be merged or an open
issue that just got opened. But that was where I've seen success is just
following the GitHub flow through the various aspects of GitHub to make sure
that if there's something that somebody wants to bring up or discuss or if
you're looking for feedback on something, it kind of hits all of the boxes of
GitHub.

Ryan: OK. I like that. So not having prepared that way, I'm just thinking
through and jotting a few notes to myself here because I had a couple of
things. But let me reorganize that into this format. OK. Well, I'm not aware of
any. I guess I should open GitHub right now. Super hot discussions from the
last week. But let's pop in there and make sure I didn't miss something.

Gary: Were you planning on sharing your screen? That was another helpful thing.

Ryan: Oh, I guess I should in the future. I'm afraid if I do that now, it's
just going to mess something up. If we have something to refer to, I'll share
my screen. I'm not sure that we do.

David: OK.

Ryan: OK, well, let's do that this way. So I had an issue I was going to
explain that I did review this open YAML config file PR. And I thought it would
be something good to discuss here. I don't see, what's his name? Why am I
blanking on his name? Tyler, you're a guy.

Jayr: Jeff?

Ryan: Jeff. Yeah, of course. Sorry. Sorry, Jeff. I don't see Jeff here, but we
can relay this to him. So I reviewed this and had some thoughts that were kind
of higher level. And so I thought would communicate something about the review
process and about this issue in particular. So Jeff and Jayr had gone back and
forth on this, which is great. So this is, I think in my mind, after reading
this I realized oh this is something we probably should have kicked around a
little more at the design stage before Jeff spent so much time writing code um
because I realized that a lot of my thoughts when I was reviewing this um came
down to like you know step back design thoughts um and I think I mentioned this
a little bit last week but I'll give it a go here um And so this is one of
those areas, this area of config file and how Mujina would pass that config
information around between components inside. Seemed like one of those areas
that this is kind of a big overarching design issue. Consideration in that in
that affects a lot of things so it's not like this isolated little you know
some PRs some features that people write up and maybe sort of isolated and
nicely hid behind an interface where it doesn't have implications for the rest
of the code base but this is one of those that really does so we probably
should have spent a little more time kicking it around in design I reviewed
this and it was taking a lot of time to get my thoughts down on paper, to get
my thoughts into writing, those design thoughts. I owe this PR that, either in
a discussion or in this PR in particular, I guess at a high level here, I'll
just say repeat sort of what I did last time was my vision for a configuration
is that we think through a little bit how to make sure that configuration
values they at startup come from config files but they also sort of the same
tree of config values are basically things you can often adjust through API
calls and they are often things that we want the code to react to live so it
might pick up its pool settings out of config files at startup But those pool
settings might change through the API as it's running. And so the code needs to
be able to react to that and see that there was a change. Same thing could go
for almost anything that's configured. It's not just a startup value. It's
something the code might want to react to. So I wanted to make sure that idea
made it into the design and also the fact that config values come from multiple
places not just files but also from the API and that there's some similarity
between how this tree of config values appears in the files and appears in the
API schema and is accessed by the code on the inside so I need to put that into
writing as feedback on this PR but is there anything anyone would want would
want to to say about that from a discussion discussing it standpoint do you
want to see it uh persisting uh when you change them while it's live Yes. Well,
I think that's... Or is it like... It needs to have the ability to persist it.
This is optional. Some things may be transient. But if you want to persist it,
it should be in the design that some values can be marked as, yes, I want to
persist this change.

Gary: And when we say persist, we mean persist across startup? Yeah.

Johnny9: Is that... Yeah. Save them, write them to disk, whatever. Or overwrite
the config. I don't know.

Ryan: Yes. So I kind of sketched out, and this is what I need to put into
writing. I kind of sketched out.

Gary: He froze on my side. Anybody else?

Johnny9: Okay. Yeah.

Jayr: Yeah.

Gary: Yeah.

Ryan: My bad. Yeah. You're back. Okay. Sorry. Um, was I saying uh this is so I
will put this into writing not only like here are like the design goals but
here's sort of how I thought it would might work um so when it comes to
persisting I was imagining that we wouldn't rewrite rewrite configuration
necessarily but the configuration sort of the idea is already that it will
cascade and get merged from multiple files So the persistence would just be
another layer of that cascade that would sort of overwrite defaults. So it
would actually end up in a separate file, but essentially rewriting config,
just not actually obliterating what the user wrote. And because config files
can be hard to have the software rewrite and have humans edit, like saving
comments in them and stuff. It's really hard to restore a config file
completely.

Gary: In that sense, do you envision then a startup config file that is a
user-managed file, but at runtime there is a separate file that is hydrated by
the user's config, but that can be sort of marked? The question I would have is
sort of like, Providence priority? Because if you are making something that can
persist and it gets written to that runtime file, what's the relationship
between the runtime file and then the static user config file? Does that
question make sense?

Ryan: Yeah, that does make sense. Because then as a user, you're going to look
at that config file that you've edited and wonder why those values either do or
don't take hold the next time you restart it. That's true. Yeah. I'm not sure
how to, we'll have to think that through because obviously at start time you
would want, let's say your, the pools you've configured in your user visible
config file, you would expect that to show up. But if you were in the middle of
running and change those via the API, you would expect those to become
permanent, that change to become permanent. So yeah. How do we resolve that
tension? Without rewriting the user's config file.

Skot: I feel like there has to be a distinction, right? When you're changing
these config files via the API, you want to somehow make it clear if this is a
persistent change or not, right?

Gary: To me, it's more of, like, what's the default, right? And it's, like, if
the default is if I'm a user and I pass in a config file, I would expect all
those values to be, like, the values that are inherited by the process. But if
I'm a user and maybe I don't pass in a config file, maybe there's, like, a
default location. But it really, I think it becomes, like, which value
overrides what if you're going to have these sort of two separate configs. One
thing I will say that I don't think we're going to have a huge problem with is
whether a user is changing the file or whether the API is changing the file,
the structure of the little struct that Rust has for that, those are reusable
components. And it's just a matter of decoding and encoding from YAML versus in
memory when the API is running. Or maybe I'm missing something.

Johnny9: And I'll just add what Gary said is in my experience is important to
have like a schema. It doesn't have to be complicated, but at least distinguish
between defaults and user overrides. So that way you can update the defaults to
the system alongside having the user be able to configure it. So like if the
user hasn't set it, but an update to the software will change the default.
That's important.

Jayr: Right. Does anyone have some more concrete examples of things that we
would want to configure via API and that we would want it to persist across? Or
like which cases, like which scenarios or situations that would happen?

Skot: We have this same issue on the Bitaxe. We have, we call it the NVM, the
non-volatile storage, but there are several settings that... Might even be
automatically changed like for instance if your uh miner is starting to
overheat then you want it to uh you know turn up the fans or turn down the hash
frequency or some combination of both those things and those things actually do
persist because You know, it could be in this like extremely hot overheating
state. And then the power goes off. And so you'd want those, those new lower,
uh, lower hash frequency settings to persist when the system comes back up.
Right. So that's something that could happen automatically, uh, in Mujina, or,
you know, maybe you have a separate process that's interacting with the minor
and monitoring all this stuff over the API that's making these changes. But
those are things you'd want to persist right and we on the Bitaxe it's like
overheat mode basically but. You know you want the minor to be in a state where
the user can can address these things and obviously not just like going into
total like catastrophic thermal runaway. That makes any sense but we also have
you know however the you know like Ryan said before however the the mining pool
address gets changed like those settings persist um because presumably if
you've changed it that's what you now want to mine to uh if power goes out and
the miner comes back on later you want to be mining to that new pool that you
changed it to I think

Ryan: As I was thinking about it, I think that the vast majority of changes you
made in the API, you would want to persist.

Skot: Yeah, that's a good point. What's an example of something that you
wouldn't want to persist? Yeah. I'm not really sure now.

Johnny9: I think config, by definition, is something you persist.

Ryan: Yeah, to your comment earlier, Gary, yeah, I agree that it should be
pretty easy to just serialize a tree back into a YAML file again and and write
the file. My thoughts there were, like, if I were a user and I was sort of
carefully crafting my config file, you know, I had things in a particular
order, maybe I had comments in there, although it's YAML, so maybe there's not
comments. Then just you know if the if Mujina overwrote that config file later
with all its new changes um it would be hard to persist kind of the user's
formatting of that file order spaces comments etc so sort of hoping to avoid
clobbering the those parts in the user's config file but it may not be it may
not be practical or possible

Gary: Jayr, I think, has a hand up.

Ryan: Oh, sorry, I missed that. Go ahead.

Jayr: So just a comment, because I was just thinking on what Skot said, and
it's like the NVS is like what you feed, like you use when you're flashing the
Bitaxe. So I understand that in the Bitaxe scenario, like you have the NVS,
which is like a source of... Configuration but then you also have the UI which
is probably like what the vast majority of people would use the the GUI to
change those config values um so yeah that makes like complete sense although
it also like has this similarity of like having the NVS as the first source and
then somehow having its own persistent storage. But then I just wonder if in
Mujina's case, if it's really similar, because would we expect our users to
actually handle config files, which is something that probably almost no Bitaxe
user would do? Versus something that may be in a bigger operation, it might be
necessary for you to go a little bit down at the OS level, like replace files,
things like that, and then make it work. I'm just wondering, how are they
really similar, and where do they differ maybe in the profile of whoever is
going to use it?

Ryan: Mm-hmm. Gary?

Gary: Yeah, it's... I'm thinking the intention of Mujina is you run it, and it
stays running. We're not imagining a lot of cycling, aside from catastrophic
failure of power, hardware, whatever. Just insert chaos engineering. I wonder
if, and then this comes down to sort of like the CLI design as well, is unless
explicitly specified when you go to run Mujina with a flag that says, hey,
here's a config to run, then there is a sort of default location that is like
the runtime config file location, that that is the file that you're not
necessarily obliterating, but it would be the file that would not have comments
or anything, right? Like it would just be sort of machine readable. That is
runtime only, and that would be modified and persisted as part of the API calls
and everything like that. It seems like it would also make sense then to have a
save to this new location thing. So there's two files location. There's one
where it's like, I want to pass in an explicit startup configuration file. And
I know because I'm passing in extra parameters to the CLI, I'm overwriting
whatever may or may not have been there. And then at runtime, if there is a new
config, it will just sort of copy that config and replace whatever that runtime
file looks like as far as the runtime config file goes. But otherwise, if I
just run mujina-minerd, it just looks at the default config file location that
the process itself manages. So it's almost like there's a user-managed config
and then there's a process-managed config. The process-managed config is always
expected to be modifiable by the process itself. And it is only overwritten in
the case where a user passes in explicitly a flag that says, here's a new
config. I want you to run it like that. And that kind of gets to the point of
what Jayr was saying where a user is just going to start this thing and then
start to play with all the bells and whistles, right? But a power user, so if
I'm going to deploy a giant fleet of Mujina, I might want to co-locate config
files with very specific fig that goes along with that, that is the initial
startup one. Does that make sense? Or what sort of edge cases am I forgetting
there?

Johnny9: I wouldn't conflate the two things. You're talking about fleet
configuration management versus the processor systems configuration. I don't
think that changes. The core idea of how the configuration should work.

Skot: Yeah, I think there's there's definitely like this concept of the the
hardware, the machine and the the configuration for those things, right? That's
not going to change at runtime, right? Like I'm not going to change the
configuration of my hash boards or, you know, what the power supply I2C
communication port is at runtime. So that's almost a different set of
configuration than these runtime things.

Gary: I guess that kind of goes back to enumerating what the config values are,
and maybe it is a delineation in the config itself of like, this will only ever
be defined at runtime versus not. Am I understanding that correctly, Skot?

Skot: Yeah, yeah. We, on the Bitaxe, right, we have, the NVS is our only file
storage, right? So that's where the, all the configuration lives. But what goes
in there is just basically a like key identifier that maps out how the hardware
is connected. And that's, you know, unfortunately baked into the firmware.
Whereas I think here we'd want to have that be a separate file that really
spells out like what this hardware is, how that works. Um, cause yeah, you're
not going to change that at runtime. That's just something that needs to get
set up, whether that gets baked into the image that you flashed your device or,
you know, however it gets deployed. I think, I don't know. I think it almost
makes sense to have that just be totally separate config files versus this
runtime stuff.

Gary: How does the plug and play story work with Mujina? Is the expectation
that Mujina D is not accepting sort of plug and play hashboards, right? So if
I'm running Mujina D on my laptop, I have my Ember One already. I have that
configured. Will I get another Ember One? The expectation then is that I would
spin down Mujina D, plug the new hashboard in and restart it or some ordering
thereof.

Johnny9: I don't know if that's interesting because you do see on a lot of
these firmwares, they have this like static file that defines what the system
is. And in Bidax, we kind of have the same thing, but it's like statically
written in the code base. So yeah, that's right. There's two separate
configuration schemas.

Gary: Well, and the reason I think, I think about the proto, right? Like they
have like the hot swappable things where you can pull, pull boards out. So
like, what does that mean? What does that mean from a maintenance standpoint of
I go to do maintenance on this thing, I need to pull the hash board out now is
am I like stopping the mining on the other two hash boards? And I'm sort of
ignorant on the proto setup. So maybe it's a bad example. But

Ryan: My intention is that in the case you described, if you plugged in the
Ember one, it would be discovered and used. And same for unplugging. I think
there are going to be some cases where some static hardware configuration is
necessary because it's inherently not discoverable. But in my mind, a running
Mujina should discover as much as it can. So buses like USB are built for
discovery. We should be able to handle most of that, no problem. If, on the
other hand, we're running on some stock control board, we may have to specify a
few things in a config file that are just not discoverable, like what kind of
power supply is connected and where. So I think we're going to end up with a
mix of both of those worlds. Does that make sense?

Skot: Yeah. I could imagine you have a hardware configuration. That's like,
yeah. Hashboards, USB ports, like you can dynamically, uh, detect whatever's
attached to that. But you know, fans on the other hand, you can't really
dynamically detect what's on there. So that needs to be more statically
configured.

Ryan: I think some things are just not going to be writable from the API. Maybe
they'll be readable but not writable, something like this deep hardware
configuration you're talking about. We're not going to expose that as something
you could write. So I think whether they end up in a separate file, I don't
know. But I think there will be a distinction between changeable things and not
changeable things.

Gary: What I'm hearing is I have some ex-new hash board, the Ember 5, we'll
call it, and I plug it in. I have Mujina already running with my Ember 1
through 4. I plug in Ember 5. This is like a net new hardware config. Like what
is that surface to the user as, right? Like it would discover via USB that
maybe it has some new hardware that is capable, but what I'm hearing is there's
potential components of that hardware that are not sort of readable or
detectable from that connection that a user would have to go through like a
setup wizard almost to like finalize the addition of that hash board. Am I
understanding sort of like the painting of that user story correctly?

Ryan: The case you're just maybe the example you're describing just doesn't
cover everything you're thinking of in the case you're describing if it's a
number five and we control everything that's going on then Mujina will say hey
we'll see oh something showed up do I have a driver for that oh it's a number
five I know everything I pretty much everything I need to know about to run a
number five dynamically so that's that's a case where hopefully that case would
be just totally automatic It would just embrace the number five and run it
without any intervention.

Gary: So I guess the drivers then are the piece that's encoding those very,
very non-discoverable hardware components. Is that more accurate then? Cause
then if I, if I plug in the Gary five hash board and it's not like if there's
no drivers or anything like that, then that's, I mean, that's sort of a useless
component anyway. And I wouldn't, I shouldn't expect Mugenia to support that.

Ryan: Yeah. If Mugenia doesn't recognize it, it should leave it alone on
something like a discover, you know, a hot pluggable bus like USB. The Linux
kernel does a pretty good job of balancing this. On ARM, the ARM platform,
let's say, you've got device tree where you declare most of these static things
like that. That are just inherent to the hardware and can't be discovered.
Like, this chip is on this address on this I2C bus. That's not a dynamically
discoverable thing. And same with like, oh, here's a PCI controller at this
memory mapped location. Those are things you have to configure statically in
DeviceTree. But past that point, like everything actually on that PCI bus is
discoverable. So the device tree doesn't say anything about those. It just lets
the software figure that out at runtime. So kind of imagine our static versus
dynamic to follow along similar lines. Like some things are just, you can only
know from the outside, out of band via the, you know, this is like a schematic
detail. This has to be in a config file or something or baked into the driver
for something that doesn't, that isn't configurable at all. But everything that
can be dynamic sort of should, wherever possible. That'd be my mental model.

Skot: I'm sure there's devils in the details, but... Yeah, I think that makes
sense. I can configure my system to... I can configure my system to enable USB
and recognize devices. But if I don't have a driver for the particular Wi-Fi
dongle I'm plugging in, it's just not going to do anything. And so the USB side
of things is controlled by the device tree for the particular board that you're
running on. And then Mujina has the drivers for what you actually want to
connect to those devices.

Ryan: Yeah, and if you were making a change that required different static
hardware configuration, that would require a restart of Mujina in that case,
and I'd be okay with that. That would make sense. I mean, that's sort of like
putting Mujina on different hardware. Obviously, it's restarting at that point.
Or are you... You're starting it again because you're rebooting a new version
that has a new driver to support the Ember 6. Obviously, restarting in that
case is fine.

Skot: I feel like we need a configuration that says... I don't know how to
explain this. Something needs to tell Mujina that I have just hashboards
connected to the serial port. Something needs to tell Magina to do that, right?
Because it's not going to be able to auto-detect those things. The device tree
sets up the serial ports. Now there's three serial ports available to Magina,
but something needs to tell Magina, hey, there's three serial ports with hash
boards connected to them. How many chips are on them? Also, those hash boards
have some I2C devices on them. And here's how you communicate with them.

Ryan: Sort of. I think it depends. Like if you're talking about serial ports on
a, like the raw serial port on a server that you just, obviously there's no
dynamic discovery there. That's a situation I think you'd have to be explicit
about. But if you're running on the AMLogic S19 hash board, if Mujina can
discover, hey, I'm running on this hash board, well, then it knows without
configuration from a file, it knows. Oh there are three serial ports here and
if I try to talk to him I should be able to talk to a an e-prom on the other
side and figure out what that hash board is and if it says it's a if it says
it's a s19 such and such hash board like I know the layout of that like some
things are going to be baked in and discoverable even if even if they're on
sort of hard hardwired things like a serial port does that make sense

Skot: Yeah, I guess I'm wondering where that configuration of what to look for
comes into play. What tells Mujina to look for two I2C connected temperature
sensors per hash board? Yeah, what tells Mujina to do that and to use those
temperature sensors with this temperature profile as the main temperatures for
the system?

Gary: And that seems, I mean, that seems like a config file that you, could you
pass that at startup? And would, you know, would Mujina be able to, like if you
have some custom board that you can sort of define those things in a config
file? But then it almost seems like we're back to like two config files at this
point.

Ryan: I'm not sure what I'm answering anymore, but sorry. Yeah.

Skot: I guess my question was like, how do we, how do we set up this machine?
Like S 19 as the example, right? Like, how do I tell Magina, like, you know,
this, this is the configuration. I got these three hash boards. They got the
temperature sensors on each one. You know, how do, how do I tell Magina to do
that?

Ryan: I think it depends where Magina is running. So. I think if you're on the
Amlogic control board, that Mujina can dynamically discover that it's on that
board. And then it knows what ports it has. Like it knows those IO mouths.

Skot: So this is the driver? This is the driver? Driver in Mujina. Yeah. OK.
OK. So it's like, at startup, we determined that we're on the Amlogic control
board. And so it loads the Amlogic S19J Pro driver.

Ryan: Simplifying. Yeah. I mean, I think there'll be multiple parts to this,
but yeah. Yeah. Essentially it, Well, the control board is a little different
because you can have all sorts of different hash boards, right? So as far as
the control board goes, it would load enough to know like, oh, I have four IO
mouths. This is how I use them. I have a port that is connected to some kind of
power supply. But it still has to do discovery beyond that point out those
ports to see, can I identify the power supply out here? And then I'll load the
driver for that power supply. And can I identify the hash boards that are
connected to these IO mouths? If I can, then I'll load the driver for those
hash boards. So it kind of would build itself together in pieces. OK.

Skot: So somewhere when Mujina first turns on, it needs to learn that it's on
an Amlogic control board.

Johnny9: Does it make sense to even care that it's an Amlogic? Meaning that can
whatever makes an Amlogic an Amlogic be defined in the config schema so that
you don't need to have X number of board definitions baked into your code base?

Ryan: Yes, although I think, you know, You might as well have them there if
they're well-known configuration, and then just have the config file be able to
be a catch-all for things that aren't in the code yet, or maybe you're
developing something and it's easier to whip it together in a config file. I
don't know, because otherwise you'd have a config file or config files that
know all that same variety of hardware. Seems like the problem exists
somewhere. For sure, yeah. Yeah, Jair?

Jayr: Yeah, so far, I think the idea you mentioned of having something like a
tree makes a lot of sense because I was thinking, for example, I have a few
bidaxes, and one of them, it runs really hot. I think I need to make some
improvements with the cooling situation. But then, although from a theoretical
standpoint, they are the same. But then when I plug them, if all of them run
with the same config, it's not going to do well. Because one of them is going
to go really, really hot. So then you would need some way to say, hey, look at
this file. I'm specifying or somehow I'm fingerprinting one of the devices that
will be connected here. And then when that device is discovered, then if there
is a configuration there that applies, then it would override any defaults that
would come with that driver. But you would still need to somehow identify which
one or where do you want that config to apply, and then let the firmware do its
thing.

Johnny9: Does that make sense?

Gary: I think that makes sense. And it also seemed too, just kind of looking in
this PR, there was already some top level sort of breakout thing. It seems like
a lot of the concern as far as that we've been discussing is hardware level
things. And that almost seems very, very separate from the application surface
of Mugenia itself. So looking at the PR, there's a Daemon definition with log
levels, PID, systemd, et cetera. There's API. There's pools. But then the final
ones is like backplane and boards. Those seem like they would be more of like
there's a lot more dynamicism or they're not more dynamic than say like setting
a pool, setting API configuration. Those are all like runtime things that I
would expect that are not this like deeper hardware configuration. Does that
make sense? So it seems like there is a very clear separation between
configuration that is going to be more application focused of like users care
about it more and then more hardware focused where it has impacts on like
running hardware and all that.

Ryan: Yeah. So This is probably, I mean, I should put something in writing in
discussion so we have something more concrete to kick around is what I'm
hearing. This is all great input, and it's good to kick this around and kind of
get a feel for the whole design space and the different requirements people are
picturing. Probably to make progress on it, I need to put some stuff in writing
so we have something specific to argue around. I had one other thought. Gary,
sort of starting back at the beginning when you were talking about being able
to pass a file on a command line, that made a lot of sense to me too. Even if
it's just like that would be a useful flow during development probably. Is
being able to start it up quickly in different configurations that you were
testing or playing with. The edge case that came to mind there was if you start
with a user config file like that, a separate user config file, then where does
an API change get persisted to it in that mode? Does it overwrite the new file?
Do the changes you're passing in overwrite the default persisted values? It
wasn't clear to me how that would shake out. Does that make sense?

Gary: Yeah yeah that makes sense um one of my thoughts was like perhaps there's
an export feature or something or of the config like hey I want you to export
whatever the current config is but then you get into all kinds of uh edge cases
around like what config is active versus what's not and what's been exported
what's not been exported when most of the time users just want a sane default
for any of these things yeah

Ryan: Okay, I think we should try to capture some of this in writing. I'll
capture the stuff I already sort of had in writing, and then we can go at it
again with something more concrete to poke at. Does that make sense to
everybody? All right. Is Tyler still here? So another thing in a sort of
discussion category was a post Tyler just made to the forum about trying things
out on new hardware. Do you want to summarize that for us, Tyler? And maybe we
could discuss that quickly here.

Tyler: Yes. So as a non-developer but an avid AI user, I've been excited by
what Schnitzel and Skot have been able to accomplish trying to brute force
Mujina onto various other miners. And I was just, I figured I'd start a thread
on the forum where people can just post tips and tricks on how they went about
doing that. I know I had some personal messages with Skot where I was talking
about the M64 and specifically SSH, API, what do you call it, Skot? Like a full
security test or something. So I think that would be great for eager, excited
people that aren't particularly Mujina developers to just start to get some
tips and tricks on how they can start trying getting Mujina onto other miners
and then... Feed that feedback back upstream to the folks on this call.

Skot: I think it'd be really cool, you know, someday to have this sort of like
hacker kit, right? It's like kind of a getting started guide with porting to
Magina to new platforms, like tips and tricks for, you know, getting rid of the
proprietary firmware, getting around Secure Boot, all this stuff, you know, it
could be, part how-to part like discussion around what people have tried and
what's working because all the systems are different um but this is obviously
something we want to encourage people to do and it's important new stuff over
you know there's David Price- Ideally there's going to be more and more people
working on this for more and more different machines and so to have I think the
forum can serve as that. David Price- place where people share their
experiences with different ones, and then you know, having having some sort of
guide is to like. What do you need to change in Mujina? What do you need to add
to get support into Mujina? Because there's two different things. You need to
figure out how to load arbitrary software onto a control board or whatever
controller there is. That's outside of Mujina. But then once you've got that,
now you need to add support into Mujina.

Tyler: Yep.

Skot: So that doesn't answer your specific question, but I think- You know,
that's quite all right.

Johnny9: I mean- Practically, it might be a series of agent prompts or
something. We'd have to think about what we did with the Amlogic board.

Tyler: Well, and that's the beauty of everybody just throwing whatever worked
or didn't work for them in the forum too, because the agents can read the forum
and know what people have tried. So it's effectively, it's loose documentation.
Just all knowledge being captured right now is good, I think.

Ryan: My first thought when I read your post was whatever instructions we come
up with need to start with lots of warnings. Like, here's what you should not
do. Here's how to be careful so you don't end up with a fire. Yeah. Yeah.

Tyler: Okay. Well, I mean, if anyone has tips or maybe Michael or Skot can just
throw some comments on there and everyone else, let's keep building that
knowledge base, I guess. And then it should turn into guides, I imagine.

Skot: Definitely. That's on my to-do list to put some tips and tricks in there.
Obviously, I haven't tried the What's Miner stuff, but similar systems, I
guess.

Ryan: Yeah, this is going to be great. In some ways, it feels like we're
pioneering a new era of open source project development flow here now that
we're in 2026. It seems like we're going to end up with a lot of these Vibe
prototypes that solve a lot of the research problems. And a lot of the work for
Mujina maintainers or developers or a different segment of work for Mujina
developers is going to be take these vibes and turn them into production
merge-worthy code in the open source project. And that workflow is not
something that existed last year. What do people think about that? I don't
know. I've just... That seems like the new world we're in.

Skot: To the extent that we can encapsulate all the different things that need
to happen, like into their own, you know, areas that aren't like intricately
tied to other ones, the easier it'll be to sort of integrate these vibe coding
projects into the main thing, right? So you don't have to like completely
rewrite Mujina, right? There's just these little things that need changing.

Gary: You'll have to forgive me. I do have to drop. Johnny, I know you're
recording, so my recording will not have the final pieces of this. But thanks,
everybody, and I'll see you all around.

Ryan: Thanks for being here, Gary.

Gary: See you, man.

Skot: See you, Gary. And we need a control board reverse engineering topic,
which doesn't specifically have anything to do with Mujina.

Ryan: Yeah.

Johnny9: Yeah. That's a good idea because one of the advantages of open source
is you can just get random people to do the work for you. You know, if you, if
you clue them in on how to do it.

Ryan: Um, What do we want to accomplish with the, how long do we want these
calls to go is something I should have asked at the beginning. I mean, you
think at least an hour, what is everyone's appetite?

David: Hour 30 is, is good considering it's like, um, these are typically
Monday on a, on a weekday.

Ryan: Okay. Okay, hour 30 cap. Sounds good. Okay, that's a good answer. I
wanted to throw out a few things that I thought would be interesting. I need to
record these sort of as issues or discussions, but that would be that I'm
seeing that would be helpful. So sort of in line with what Tyler was talking
about and my thoughts about safety. Oh, wait, let me go in a different order
here. I've been thinking a lot about integration testing and how do we set up
some hardware for integration testing? And how do we do that safely? If random
bug fixes and checkouts and PRs or such kind of get run in an integration test,
I also don't want to start fires in that sort of scenario or ruin hardware. So
I'm just throwing that out there. Not something to kick around here for too
long necessarily, but I'd be curious if people started thinking about how we
could do some hardware-in-the-loop integration tests as Mujina rolls forward. I
know, Johnny, that was one of the first things you told me when we met was,
you're going to want this early. Because I'm already seeing some ways where I'm
afraid to make certain changes because I'm afraid of the impact it'll have.

Johnny9: Yeah, you get to that very quickly. Yeah. I don't know. It's a hard
problem. It can get very complicated depending on how much control you want
over it. But GitHub does allow certain things. Like if you keep it simple, you
can add a workflow that is sort of maintainer blocked on. Like it needs your
essentially. Right. So you can start there. Since we start simple. And what
that'll do by starting simply is force you to at least start writing end-to-end
tests for these things, which that's a big part of it. And then the test
infrastructure can be figured out as it gets more complicated.

Ryan: So the workflow there would be let's say even if the PR comes from
outside, you know, the normal core developers, a developer would like have to
put their eyes on it and review it and be like, okay, I'm willing to test this
and I'm willing for it to run right now. Cause maybe I'm home in my lab. And if
something happens, I'm here to stop it.

Johnny9: Yeah. It's weird. You kind of need, you kind of need some self hosted
runners, which, um, That's where it gets kind of questionable because of the
open source part of this whole thing. This thing will run on your network, on
your device.

David: It sounds like you're describing some like perpetual quality assurance
testing. And I mean, I can, if you're interested, I can describe some of the
processes we use to test our firmware across a variety of platforms. Yeah. We
mainly focus on testing releases, right? And we have a couple of metrics that
we're really focused on. So things like efficiency, stability, proper power
handling, keeping equipment in the power spec for its equipment class, and also
for varied configuration settings. So whether it's an overclock or underclock,
we actually need the machines to... Deliver on the power needs that they're
configured for. So we have a lab, and we have many duplicates of each miner
that we're testing. But we have a series of scripts that we wrote in-house,
kind of managed by a Jenkins server. But the point of this is we're perpetually
running performance tests. We have a rack full, and we're plugging in machines
and basically .

Johnny9: Lab that's we have our houses right that's where we're stuck that's
the big issue we we understand how to do the end-to-end tests it's that uh

Ryan: I'm curious, David, how often have you run into situations where machines
destroy themselves? Do you have any out of band power monitor that if it
discovered something was drawing too much power, it would just shut it down or
temperature monitor doing similar things? Does your lab include anything like
that? A lot of those controls are baked into the firmware, but no, not
specifically.

David: We have had issues when we've been modifying our auto-tuning code or
even things like rewriting our sleep architecture, like the pause and resume
cycle in the firmware that we let people trigger with the API. When we've been
modifying stuff in the past, yeah, we have experienced hardware failure. But
generally, when we're doing normal quality testing, no, we don't really
anticipate elevated hardware failure. Okay yeah I don't know maybe I'm
overblowing the concern in my head just picturing a lot of burnt hash boards it
definitely be an instance like I understand the also the issue about not having
the equipment not having the rack space not having the power I mean that's
something that's more of like a community issue than like a technical problem
to be solved, right? So I feel like asking around, but like, I feel like this
group is well connected. I mean, I can ask internally at my company, but yeah,
I feel like even if it's spread across a couple of locations, getting a few
models that could be consistently tested against, especially for the stuff
people care about, like the J pros and K pros and S21s of the world and
whatnot.

Johnny9: So you have this like, architecture in my head about sort of a service
that's authenticated and allows you to manage and monitor end-to-end tests to
do this but it's quite a lot of work to sort of set up a set up and manage a
system like this where you can kind of control when things run, schedule tests,
et cetera, and make sure it's authenticated. Because one of the problems with
this is even if we have a lab, we have this issue of like, we can't really use
GitHub for orchestrating our test cases because of the unique hardware aspect
of this thing. Like, If someone does a PR that is going to blow up our machines
or whatever, there are security issues and reliability issues with just kind of
running PRs. And letting GitHub orchestrate. So that's one of the things that I
haven't fully solved without coming up with a complex, authenticated service to
manage this for us, basically building our own test orchestrator. But there
must be something simpler before we have to build some kind of complex
orchestrated service.

Ryan: Yeah, I mean, there's stuff I do manually now that I would be comfortable
having happen automatically if I were initiating it or in control of it.

Johnny9: That's probably where I would start. Check what kind of controls
GitHub allows us to sort of manage actions. So you at least have a little bit
of comfort with triggering automated test runs on your hardware and start
simple. And then we'll see.

Ryan: Yeah. Bit Xs.

Johnny9: Yeah.

Ryan: So much better to melt one of those. Yeah, exactly.

Johnny9: We're not going to run a 3000 watt machine or whatever and burn down
our house.

Ryan: Right.

Skot: I would also just real quick, I would just be careful about having a
centralized source that's responsible for validating the complete safety on all
these devices, right? That seems like.

Johnny9: Oh, no, the idea is like a Jenkins server, essentially kind of what
David talked about, some place where you can orchestrate the runs. But that's
later.

Skot: Yeah, I mean, I just like, you know, if there's like the official like
Mujina lab, right?

Johnny9: And it's like, oh yeah, we- I don't know, it would be an orchestrator,
not the lab itself. So labs would register the orchestrator and the
orchestrator would define like when to run tests and also collect data from the
tests so that you could go there and understand the quality of each release.
That's kind of how people use Jenkins. But yeah.

Skot: I think having tools like that that people could set up to do the tests
on the units that they're working on would be huge.

Johnny9: Yeah, yeah. That's a part of a setup like that, that they're able to
easily run it locally. But also, if someone wants to sign up to manage a lab,
they could register to the orchestrator, which could then run the tests. But
that would be the ideal setup. So we would have a dashboard at some point that
you could go to to easily decide if something's releasable. We have a ways to
go before we need something like that.

Skot: I mean, I can see, like, there's this suite of tests that you can show
pass on whatever hardware you're targeting, right? And you can show, like,
yeah, I did this. But, like, I'm not going to sign up to have a bunch of
machines in my house that people can essentially run arbitrary firmware
against.

Johnny9: Yeah, that's the problem. That's the challenge. But, like, I could see
something where you can register a couple devices that are maintained. People
would have to volunteer to maintain these things. And that way we could at
least collect test results across a bunch of devices. Because the combinations
for Magina are going to start to explode once this thing starts working on a
bunch of control boards, right?

Skot: Yeah, I mean, I still think that like having this test suite that anyone
can download and run, right? And it has a standardized set of tests, right? And
it's like, okay, cool. I'm working on this new firmware. It's targeting the
Ember 5 and I've run this full suite of tests against it. The hardware that I
have sitting next to me.

Johnny9: That's really good. I like that. I like that because that's a
pragmatic way to get there. Like we don't need a an orchestrator yet you can
just tell people to do things and and uh publish the reports right yeah publish
the reports and you know

Skot: Obviously it would be ideal to have more than one person do it, right?
Just to make sure. But we start getting into real trouble when it's like, all
right, there's this centralized orchestrator of all this testing and- I like
that. I like that. People get responsible for it.

Johnny9: Because then it forces us to focus on the thing that's important,
which is actually building a test to do validation. And not worry so much about
the kind of coordination of it before we really need to. Yeah, I like that.

Skot: I mean, I would love that right now, right? Like working on the J Pro,
I'd be like, okay, here's this test suite. Like, you know, right now it's me
just trying to think about all the things that could go wrong and trying them
out. But if there was this like test suite, you know, it's like you work on,
it's like, oh, cool. Like, I didn't even think of that. That test failed. Like
something needs to be addressed. It helps for development. And then, you know,
now it's something that when the port to the new system gets further along, I
can be like, hey, you know, if you got one of these J Pros, like, run this, my
fork of Mujina on there. And then here's the test suite. Like, let me know how
it goes. And then, you know, Schnitzel's problem where he didn't have the pick
or he did have the pick would immediately show up as a problem.

Johnny9: It's a good point to start, but you know, but at the same time too,
eventually you need to automate this. You can't just wait for people. But I
think still having the test is probably a good place to start.

Ryan: Yeah, and a lot of this stuff absolutely belongs in Mujina's source repo,
like integration tests. I have some of that. I have very limited, but some
things like that in there now. Obviously, there's a lot of unit tests. And then
there are several things that are in the same unit test framework that are just
marked to not automatically run. And so I have to sort of intentionally run
them like there's there's some stuff in there for the stratum clients. Like if
you run the test and enable it, enable this integration test, it'll actually
reach out to several hardcoded pools and do some of its testing that way. But
those aren't so that's more of an integration test. That's not something that
runs automatically every time self-contained within the code because it's so
it's not a unit test. And we can put even bigger unit tests into our code,
integration tests. But yeah, I'd like to see more of that.

Jayr: Just a comment on this. I'm a gamer, so I game a lot. And a website that
I use is ProtonDB, which is this piece of software that Valve created. And then
basically, it allows you to run games on Linux. But the point I'm trying to
make is that it allows people to report the games that they run, if they crash,
or if the games run smoothly, if they had to tweak something for it to run. I
think something like that would be amazing. Imagine at some point, Mujina
supports a bunch of hardwares and then you have actual people, operators
reporting whether it worked out of the box or if they had to do something. I
don't know, just something that seemed similar to me.

Ryan: Yeah, that's cool. I mean, even if that just starts as discussion thread
or something like that. OK, well, something to start noodling on. How do we
start to build some hardware tests? And I think Johnny's right. Start simple.
We'll figure out what the problems are as we're doing it ourselves and kind of
grow from there. The other request I have, there's not that many of us on this
call, but if someone had Windows computers and knew a thing or two about
Windows, it would be nice if someone ported the hot plug discovery mechanism
for plugging in hash boards via USB to also run on Windows. I think that's the
one thing that wouldn't work on Windows right now. And I don't really have the
expertise or the hardware even. I guess I could dig something up. But if
someone cared more about Windows than I did, that'd be great. Because right now
I expect everything to work fine on Linux and Mac OS. But no discovery on
Windows. I guess that there's a point where if we had this configuration stuff
already, you could at least sort of statically... Point a Windows machine at a
hash board. That'd be nice.

Skot: What's like, I mean, I think there's going to be lots of situations just
like this, right? That we're like, we just don't have this hardware. This
probably isn't going to work. Someone test this out. So the sort of request for
help, like what's the procedure for that now?

Ryan: Well, For the thing I just mentioned, I should create an issue for that.
I could formulate a well-defined, hey, this is what I wanted to do, and tag it
like someone should work on this. A good issue for a contributor. Something we
know about that the existing developers aren't getting to yet. It's kind of an
open, defined task for someone to pick up. That's a good GitHub issue.

Skot: As soon as you think of those, just make them, right? Because as more and
more people get involved in this project, there's going to be people who are
looking for a way to contribute. And it's like if they have the hardware and
the time, they can just dive right in and do it.

Ryan: Whereas this discussion we just had about testing is sort of not
well-defined yet. It's sort of amorphous. So that would make for a good
discussion thread. Okay. I didn't have anything else prepared myself. Does
anyone else have something in the same similar vein here they want to bring to
the group?

Tyler: I got to run though, but great job, Brian and all. Good to hear from you
guys.

Ryan: Cool, glad you were here, Tyler. See you soon. David raised his hand.

David: So it's not related to the Mujina development, but it is adjacent. So
we, as part of another just random thing we were doing at work, released our
internal firmware orchestration toolkit, like our minor management application,
as an open source application. So that's on our GitHub. We were talking
internally, and we're probably going to build Mujina support in natively
ourselves. Like just cool, kind of like on our work time as a side benefit. So
that'll be able to be used to like, quickly pull metrics from Mujina miners,
like hash rate, uptime, temps, you know, what have you, whatever is available
on the API, we can, we can pipe in. But yeah, well, it'll probably be a few
weeks before we get Mujina support in, but we're excited to start adding it
testing it.

Ryan: Cool. That's awesome to hear. Yeah, the more the merrier. And I'm sure
you'll find a lot of things in the API that you want that aren't there yet. So
that'll drive further development.

David: Yeah, we'll see.

Ryan: Cool. Anybody else?

Johnny9: I have just a quick question to make progress on the Bonanza. Yeah.
And I think it's a simple answer, but I just wanted to ask it. So we need to
distinguish between the Bitaxe and the Bitaxe Bonanza. I'm guessing it's just
changed the product strength.

Ryan: Yeah, let's see.

Johnny9: And I was probably just going to change it to Bidax Bonanza and move
on. But I just want to make sure that that's...

Ryan: I guess that's sort of up to you guys as like makers of that hardware. I
mean, you can see what the what the mechanisms we have can basically match on
anything.

Johnny9: Yeah. So it's got the so it's like the Bidax Raw has a string for the
product. It says OSMU is the manufacturer and the product is Bidax. It's just
rename that string to Bidex Bonanza to differentiate between the two.

Skot: Yeah. I wonder if we should have this come from like a, like similar to
ESP minor has as a configuration file in there. I would say that we should
probably key on the hardware version number because there could be several
different, you know, potential interfaces for Bidex Bonanza. Like,

Johnny9: Hmm.

Skot: And that's how, that's how it works for ESP minor, right? As we, we key
off the, the actual hardware version number, you know, like 601, 602.

Johnny9: Well, you currently have, uh, two branches for the bitaxe-raw, right?

Ryan: Yeah. That should get fixed.

Johnny9: Oh, do you, do you, do you think that should be one? Cause they're,
they're quite different.

Ryan: I don't know if combining- Oh, well, you mean like the one that runs on
ESP? Yeah, the bitaxe-raw.

Johnny9: The one that runs on Bitaxe versus the one that runs on Ember One. Oh,
yeah, right. I forgot there's an Ember One also.

Ryan: Yeah, I mean, those are- I don't think those should be the same.

Skot: Those are fundamentally different.

Johnny9: Yeah, and I feel like the Bitaxe Bonanza, the bitaxe-raw is also
fundamentally different, so.

Skot: Yeah, that probably needs a different- That's just a totally different
firmware, right? That's just the Bonanza Bridge firmware.

Johnny9: Well, there's the bridge, and then there's the ESP Bidax Raw firmware,
right?

Skot: I don't know that it needs to be that much different. It should
definitely expose a different version string.

Johnny9: Yeah, okay.

Skot: It's just something to tell the upstream controller what's connected.

Johnny9: Yeah, to tell Mujina which board definition to load.

Ryan: Yeah. But you're right. The current Bitaxe one just assumes too much. So
that should probably get changed.

Johnny9: Okay. Yeah, that's a good point. Yeah, because right now it's just
Gamma. So it's just assuming too much. Yeah.

Ryan: I mean, even honestly with the naming of the modules within Mujina
assumes too much. I just haven't gotten around to changing it. But it says
Bitaxe now. We should be more specific.

Johnny9: OK, because this is the next thing for the Intel chip is to define
that USB.

Ryan: I mean, ideally, we'd We'd use different product numbers, USB product
numbers, but I don't think that's feasible for these projects. We don't control
those allocations.

Johnny9: Okay, so I guess maybe I just start with the string, change the string
to Bitaxe Bonanza and just assume it's this Bitaxe. I mean, there's only one
right now, so that's easy to assume. And maybe when there's more, we can adjust
after.

Skot: I would say that that string should be the hardware version number.

Johnny9: Okay. 601. What did you land on for that? This one says 1002.

Skot: Yeah, 1002 is where we're at for Bonanza.

Johnny9: Okay, so it would be a Bitaxe 1002 for the string?

Skot: Yeah, I mean, I guess we do need to specify that it's a Bitaxe. I mean,
bitaxe-raw is always going to be on a Bitaxe, but I don't know if that's a
separate string or if it's just combined into one, but yeah.

Johnny9: Okay, I'll just start a pull request on that and then we can, yeah.

Ryan: I guess sort of this, think of the scope hierarchically. You've got your
unique PID plus VID combo. And then this text description is sort of managed by
You guys underneath that. So don't be, don't worry that you're going to
conflict with somebody else because they should be using a different, you know,
VID at the very least. Yeah, we have control over your description. Doesn't
have to be globally unique.

Skot: No, you don't. What's it, we have control over PID then?

Ryan: Actually, you don't, neither, because you got that whole allocation from
that PID project.

Johnny9: I think, well, however this firmware works, I think we have control
over it. I think it's some nonsense like dead beef.

Ryan: Oh, you can change it. Yeah, I guess I just meant in the allocation
space, technically.

Johnny9: Yeah, I don't know that it's like... Oh, that's right.

Skot: Yeah, we have their VID and then we're allocated a PID.

Ryan: No, they have a PID. PID is the top level one. So they have a PID. And
they allocate VIDs to other projects. So we have one for 256. You have one for
Bitaxe. You could maybe request another one for a different instance of
hardware. That's probably how it should work.

Skot: Is there another string in there that the firmware that Mujina has access
to? I mean, there's got to be something else, right?

Ryan: Yeah, yeah. That's what Johnny's talking about. There's the string
descriptions for manufacturer and product name. And vendor, if I'm not
mistaken. Yeah, several strings that are sort of unofficial.

Skot: Okay, so we can make our own hierarchy underneath that and not screw up
the USB working group bullshit. Exactly.

Johnny9: Okay, I'll just start PR and we'll work on that. Okay. I'll be
updating that pull request and trying to get it out of draft.

Ryan: Sounds great I will pay attention all right well I think we hit our time
limit thanks everybody I have to go pack to leave on an airplane to go to
TEMS all right thanks guys all righty right on good chat thanks Ryan