BM1370 measurements: sub-core versions under narrow masks, MIDSTATE_CONFIG fix/gen bits, CORE_MAILBOX reads

[The1Anubis]

Measured data that may be useful for bm13xx/REFERENCE.md. Hardware: NerdOCTAXE-Gamma, 8× BM1370 on one chain, ESP-Miner (NerdQAxePlus fork) with debug tooling that logs every raw 11-byte nonce response before any filtering and reads/writes registers at runtime. Pair statistics are counted on-device per (chip, job, rolled version, nonce). Ticket difficulty lowered to 512 for sampling; all pool shares were accepted throughout.

1. Sub-core version assignment under a narrow version mask

subcore_id = low nibble of the response's job-ID byte. Rolled version = response version field << 13.

	Mask 0x0007 (0xA4 low 16)	Mask 0xFFFF
subcore_id → version offset	k mod 8 (691/691 results)	k mod 16 (345/346)
Unique headers reported by two different sub-cores	158 / 160, always k and k+8	0 / 346

Example pair, identical except the sub-core nibble and CRC:

AA55 16E6C7AB 02 15 0005 84   subcore 5,  version 0x0000A000
AA55 16E6C7AB 02 1D 0005 8F   subcore 13, version 0x0000A000

So the version counter wraps within the mask, and with fewer than 4 rollable bits the 16 sub-cores repeat each other's work (16 / 2^bits duplication). Measured unique-work rate with 3 bits: ~46% of nominal once job supply isn't limiting.

Relevance to "Version" partitioning across chains: narrowing a BM1370 chain's mask below 4 bits wastes sub-cores this way. Partitioning would need to keep ≥4 rollable bits per chain (or fix bits outside 13–16).

2. MIDSTATE_CONFIG (0xA4) upper bits

Baseline write 0x90000007, reads back 0x80000007. Each value held ~90 s, judged by sub-core pairing and slot→version mapping:

Written	Readback	Effect
any single bit 16–27 set	0x80000007	not stored, no effect
gen = 0, 1, 2, 3 (0x8…, 0x9…, 0xA…, 0xB…)	0x80000007	not stored, no effect
fix = 1 (0xC/D/E/F…)	0xC0000007	stored; all 16 sub-cores hash the base version (subcore_id ≠ offset; 16-way duplicates)
auto = 0 (0x10000007)	chip 0 0x00000007, chips 1–7 no reply	no nonces at all; chain recovers on rewriting 0x90000007

3. CORE_MAILBOX (0x3C) reads

Posting a per-core read request (all=0, wr=0) broadcast to all chips, then reading 0x3C:

Command	Readback (all 8 chips)	Value previously written at bring-up
0x00000D00 (core 0, reg 0x0D)	0x00004D00	0xEE
0x00000000 (core 0, reg 0x00)	0x00004000	0x0C
0x00000200 (core 0, reg 0x02)	0x00004200	0xAA

Bit 14 sets (first poll, <65 ms) and core/reg are echoed, but the value byte is always 0. A full dump of every top-level address right after a read shows no other register picking up the value.

4. Other register observations

• Full dumps of all 256 addresses, mask 0x0007 vs 0xFFFF: only 0xA4 and 0x10 differ (the latter written by firmware).
• 0xA8: per-chip bring-up write 0x000701F0, reads 0x00070000 while hashing (bits 8–4 read clear).
• Non-zero addresses not in the register table (same on every chip unless noted): 0x27 = 0x00060000, 0xD1 = 0x0000FFFF, 0xD2 = 0xFFFFFFFF, 0xD5 = 0x00000040, 0xD9 = 0x33333333; 0x88–0x8B are four counters of similar magnitude that increase with hashing (alongside 0x8C and 0x90); 0x40 holds per-chip bit patterns that change between reads (status-like).

[rkuester]

Thanks, @The1Anubis. I'll add these to the BM13xx reference. We talked about them on the 20261026 dev call.

[The1Anubis]

Thanks for picking this up on the dev call. For context on where it came from: I wanted to mine Litecoin Cash and MazaCoin on BM1370 boards (a NerdQAxe++ and an 8-chip NerdOCTAXE-Gamma). Those coins use version bits 16–23 for the PoW algorithm id, so they need a narrow 0x0000e000 mask, which is how I ran into the sub-core duplication. Background is in NerdQAxePlus #640 and #739.

I'm happy to run follow-up measurements on this hardware if anything would help the reference doc. The tooling can already log raw nonce responses, read every top-level register, and write 0x0C/0x10/0xA4 at runtime.

One question from the dumps, after hearing the BM1370 has four internal cores/voltage sections: 0x88, 0x89, 0x8A and 0x8B read as four counters of similar magnitude that climb with hashing (alongside 0x8C and 0x90). For example, on one chip:

0x88 = 0x00007D2D   0x89 = 0x00007A63   0x8A = 0x00007E18   0x8B = 0x00007E74
0x8C = 0x0001F46C   0x90 = 0x0001CCE0

Could these be per-quarter counters for those four sections? If there's a test that would confirm it, such as reading them before and after a known change, I can run it.

Thank you,
Bryan