Add support for BZM2

[johnny9]

Looking into adding BZM2 modules to mujina.

The BZM2 doesn't support version rolling so its implementation will be closest to the bm1397. It does do ntime rolling, though, so the frequency of work sent to the chips should take this into account. It uses a 9bit serial so adjustments will need to be made to get it working with the modified bitaxe-raw/emberone fw that does 8bit to 9bit translation. It defaults to 5mbps baud. It has a built in self test feature. And finally, It has a voltage and temperature sensor and sends readings back periodically. I think those are the major differences that might require some modification to common interfaces. The rest should work similar enough (init, frequency ramp, work generation, and response parsing).

Here is what I think are the work items to get this implemented.

1. Define BIRDS board and implement usb detection. Can implement it as BIRDS Board and then rename to BitaxeBonanza or just start with BitaxeBonanza.

2. Implement 8bit-to-9bit serial in transport crate.

3. Add BIRDS control uart (GPIO) to the board definition

4. Define core BZM2 protocol and codecs. This should include all of the basic op codes, registers, and constants. Should be able to validate NOOP is working at this point as well as register setting a reading.

5. BIRDS reset/power-up and thread start. At this point should configure the BZM2 and initialize the threads for sending work and parsing responses.

6. BZM job pipeline with timestamp rolling. At this point should be able to demo mining with the BZM2.

Post-mining features.

1. Add support for bitaxeBonanza/BIRDS voltage regulator

2. Add support for bitaxeBonanaza fan controller

3. Thermal and voltage readings

This is how I'm thinking about breaking down the work for this. Let me know your thoughts and if this makes sense and any core pieces that might be missing.

[recklessnode]

The BZM2 doesn't support version rolling so its implementation will be closest to the bm1397.

That statement isn't accurate, bzm2 supports 2-bit version rolling as well as the timestamp. It also supports unicast of the full nonce range to all engines, as well as broadcast of a partial nonce range.

[johnny9]

The BZM2 doesn't support version rolling so its implementation will be closest to the bm1397.

That statement isn't accurate, bzm2 supports 2-bit version rolling as well as the timestamp. It also supports unicast of the full nonce range to all engines, as well as broadcast of a partial nonce range.

By that do you mean it does 4 midstates at once? Or is there a job command to send the header fields and it actually rolls the version internally? What i mean by its not supported is that it uses the midstates produced from the host like the bm1397 and doesn't generate midstates itself like bm1366 and newer. Having to manage midstates just adds a bit of complexity to the job generation and nonce result mapping.

[skot]

The BZM2 doesn't support version rolling so its implementation will be closest to the bm1397.

That statement isn't accurate, bzm2 supports 2-bit version rolling as well as the timestamp. It also supports unicast of the full nonce range to all engines, as well as broadcast of a partial nonce range.

We've been referring to ASIC "version rolling" as in the ASIC increments the version field and creates the midstates internally. I think this needs to be done in firmware for the BZM2.

[rkuester]

Looking into adding BZM2 modules to mujina.

LFG! 🔥

As you can see, the idea is once you're behind the board and hash thread abstractions, you can implement things pretty much however you want, and bring in useful, shared components... eh, compositionally. Random thoughts:

• If BIRDS and Bonanza speak the bitaxe-raw/emberone-usbserial-fw protocol (we really need a good name for this protocol ¹!), drivers for, e.g., Skot's favorite regulator are already in the tree and should tunnel over the protocol (see the Bitaxe board). Drivers for new I2C components on the board would make good common components.

• Defining a standard, reusable way to do this 9-bit serial thing feels like a good idea.

• If you're going to roll version, hopefully the VersionTemplate type and its friends gives you everything you need. I.e., it should let you know what bits you're allowed by the job source (pool) to roll. I had rolling in mind, but haven't needed to manually roll version yet, so there might be more to add here, like some iterator functionality.

• Generically generating misstates might make for a nice component too.

Everything's open for modification and extension. It's early days, so these type and interfaces probably don't support everything they should yet.

Footnotes

1. Brainstorm:
   HBCP: hash board control protocol
   SHCP: serial hashboard control protocol
   OHCP: open hashboard control protocol ↩

[johnny9]

* If BIRDS and Bonanza speak the bitaxe-raw/emberone-usbserial-fw protocol (we really need a good name for this protocol [1](#user-content-fn-1-997f5e8a79e926c489f67b2cf79744f6)!), drivers for, e.g., Skot's favorite regulator are already in the tree and should tunnel over the protocol (see the Bitaxe board). Drivers for new I2C components on the board would make good common components.

* Defining a standard, reusable way to do this 9-bit serial thing feels like a good idea.

I agree that this seems to be the first issue to solve. @skot mentioned "EmberOne/01" will be the name for the BZM based.

Everything else sounds right and what I expected. Should I turn these into issues?