R2.8 board EEPROM reads all-zeros (4096 bytes) — board worked previously, now

[RSTChile]

My CaribouLite R2.8 (full 6 GHz version) worked correctly in the past, but has stopped being detected. The HAT EEPROM responds at I2C address 0x50, but a full read returns 4096 bytes of 0x00 — the EEPROM appears to have been completely erased. I'm looking for the correct .eep image (and, if possible, the factory calibration data for my unit) to reflash it.
Hardware

Board: CaribouLite R2.8 (full version, HiF + S1G)
Serial / PCB marking: IL000002
R 94V-0
E333158
Host: Raspberry Pi 4B

Operating system

DragonOS Pi64 (Ubuntu 22.04.4 LTS, Jammy)
Kernel: 6.5.0-1008-raspi
VideoCore firmware: 2022-10-26 (hash c72ad6b26ff40c91ef776b847436094ee63fabee)

What I have already verified

The board is mounted directly on the 40-pin header (no extender/ribbon).
The kernel modules build and load correctly after the class_create(DEVICE_NAME) fix (line ~1053 in driver/smi_stream_dev.c).

smi_stream_dev 28672 0
bcm2835_smi 32768 1 smi_stream_dev

config.txt is applied (verified via device-tree): spi@7e215080 shows status okay, i2c_vc enabled.

dtparam=audio=on
dtparam=i2c_arm=off
dtparam=spi=off
dtparam=i2c_vc=on
dtoverlay=spi1-3cs

Auto-detection via HAT EEPROM fails: /proc/device-tree/hat/ does not exist.
I forced the overlay manually (dtoverlay=cariboulite after copying cariboulite.dtbo to /boot/firmware/overlays/), and /dev/smi is now created, with a clean probe:

smi-bcm2835 fe600000.smi: initialised
smi-stream-dev: smi_stream_dev_probe (...)
smi-stream-dev: creating a device and registering it with sysfs
smi-stream-dev soc:smi_dev: initialised

However, sudo SoapySDRUtil --probe fails at EEPROM validation:

EEPROM on addr 0x50 probing successful
EEPROM data is not valid. Try reconfiguring it.
Failed to detect the board in /proc/device-tree/hat - EEPROM needs to be configured.
Please run the cariboulite_prod application with sudo permissions...
EEPROM dump (read-only) — confirms it is blank, not partially corrupt
sudo hexdump -C /sys/class/i2c-adapter/i2c-0/0-0050/eeprom
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00001000
The chip is electrically healthy (responds at 0x50, full read with no bus errors), but the entire 4096-byte content is 0x00. No header, no overlay, no proprietary calibration data survived.
Questions

Is there an official .eep image for the R2.8 board I can flash to restore HAT identity and auto-detection?
Do you retain factory calibration data (I/Q imbalance, Tx power, TCXO) per serial number? If so, can it be recovered for my unit?
Could you document the exact eepmake/eepflash procedure (settings file + parameters) for reprogramming the CaribouLite EEPROM? The cariboulite_prod binary referenced in the error is not produced by the standard install.sh build.

I noticed issue #187 reported a very similar EEPROM failure. Any guidance would be appreciated — happy to provide additional logs.
Thank you.

[unixpunk]

The eeprom is flashed each first use after boot, IIRC. Have you seen these steps? https://github.com/ResistanceIsUseless/cariboulite/blob/main/CaribouLite-Kernel-Fixes.md Maybe this applies if you're using a new/updated OS without rebuilding from source? HTH

[RSTChile]

Thanks @unixpunk, appreciate it.The kernel fixes from that doc I’ve already applied — the driver compiles fine and /dev/smi comes up clean (same class_create() signature change for 6.4+). So the build side is sorted on my end; my issue is specifically the EEPROM contents, not the driver.On the auto-flash you mention (“flashed each first use after boot”): that’s the part I’d like to pin down. I did run the EEPROM write routine, and afterward the device still reads all-zeros (full 4096 bytes). The write doesn’t take.Looking at the R2.8 schematic, I think I see why: the WP pin (pin 7) of the CAT24C32 (U26) is tied to 3V3 through R42 (1k pull-up), with no GPIO or jumper control over it. So WP is held high permanently in hardware, which per the CAT24C32 datasheet blocks all writes. That would explain why a software write silently fails — the hardware WP rejects it.So my question: does the first-boot auto-flash somehow release/handle WP on its own, or does it assume WP is already pulled low? On my R2.8 it looks physically tied high, which would make any software write impossible without intervention. Before I resort to manually pulling U26 pin 7 to GND during the write, I’d like to confirm whether there’s a software path I’m missing — or whether on R2.8 the WP genuinely has to be released by hand.For context: board is the Full version, serial IL000002 (early unit). EEPROM responds at I2C 0x50, just reads all-zeros. Everything else on the board works through the forced overlay.Thanks again.AlexisEl 16-06-2026, a la(s) 9:34 p.m., unixpunk ***@***.***> escribió:unixpunk left a comment (cariboulabs/cariboulite#253) The eeprom is flashed each first use after boot, IIRC. Have you seen these steps? https://github.com/ResistanceIsUseless/cariboulite/blob/main/CaribouLite-Kernel-Fixes.md Maybe this applies if you're using a new/updated OS without rebuilding from source? HTH

[RSTChile]

Thanks @unixpunk, appreciate it.

The kernel fixes from that doc I’ve already applied — the driver compiles fine and /dev/smi comes up clean (same class_create() signature change for 6.4+). So the build side is sorted on my end; my issue is specifically the EEPROM contents, not the driver.

On the auto-flash you mention (“flashed each first use after boot”): that’s the part I’d like to pin down. I did run the EEPROM write routine, and afterward the device still reads all-zeros (full 4096 bytes). The write doesn’t take.

Looking at the R2.8 schematic, I think I see why: the WP pin (pin 7) of the CAT24C32 (U26) is tied to 3V3 through R42 (1k pull-up), with no GPIO or jumper control over it. So WP is held high permanently in hardware, which per the CAT24C32 datasheet blocks all writes. That would explain why a software write silently fails — the hardware WP rejects it.

So my question: does the first-boot auto-flash somehow release/handle WP on its own, or does it assume WP is already pulled low? On my R2.8 it looks physically tied high, which would make any software write impossible without intervention. Before I resort to manually pulling U26 pin 7 to GND during the write, I’d like to confirm whether there’s a software path I’m missing — or whether on R2.8 the WP genuinely has to be released by hand.

For context: board is the Full version, serial IL000002 (early unit). EEPROM responds at I2C 0x50, just reads all-zeros. Everything else on the board works through the forced overlay.

Thanks again.

Alexis