soc_esp32::efuse

eFuse block 0, and the factory MAC address in it.

One fact, and it is needed in two places already: the radio binds its RF calibration to the part’s MAC so a calibration restored onto different silicon is refused, and anything that ever brings up a network interface needs the same six bytes.

The layout is bit offsets, not bytes

esp-idf describes the factory MAC as six 8-bit fields at bit offsets within block 0, and in descending order:

MAC_FACTORY[0] = BLK0 bits 72..79
MAC_FACTORY[1] = BLK0 bits 64..71
MAC_FACTORY[2] = BLK0 bits 56..63
MAC_FACTORY[3] = BLK0 bits 48..55
MAC_FACTORY[4] = BLK0 bits 40..47
MAC_FACTORY[5] = BLK0 bits 32..39

Bit 32 is the first bit of word 1, so the whole address lives in RDATA1 and the low half of RDATA2 — and it reads out backwards relative to the byte order everything prints it in. Extracting it in the obvious little-endian way gives a plausible-looking MAC with its bytes reversed, which is exactly the sort of wrong answer that survives review.

Verified against hardware rather than argued: espflash board-info reports the same address this returns.

Functions

base_mac

unsafe fn base_mac() -> [u8; 6]

The factory MAC address, as it is printed.

Safety

Reads two eFuse registers. No side effects; eFuse is read-only here.

mac_from_words

const fn mac_from_words(w1: u32, w2: u32) -> [u8; 6]

The bit extraction, split out so it can be tested against a known part without an eFuse to read.

See the module docs for why the order looks inverted: the fields descend through the block, so byte 0 of the address is the highest of the six.