EEPROM Settings kill boot with Known Good board

[amcfarland]

I have a couple of builds of a custom OSD3358-512M-BSM based boards that have been working well.   This design was based on the PocketBeagle and runs a standard PocketBeagle BB Bullseye image.   Due to supply chain lead times, the first couple of builds used OSD3358-512M-BSM removed and reballed from actual PocketBeagle boards, and therefore had their EEPROMs programmed as such.

I am now bringing up our first boards (3rd build run) with new OSD3358-512M-ISM and un-programmed EEPROMs  (all xFFs).   I would like not have to not rebuild U-Boot and use the standard BB builds, therefore I would like to reprogram the EEPROM.  I followed these steps (shown elsewhere in the forums)  to do so:

1 ) I downloaded RobertCNelson’s older EEPROM build to drop into the U-Boot console:

https://rcn-ee.net/rootfs/bb.org/testing/2016-10-02/console/a335-eeprom-debian-8.6-console-armhf-2016-10-02-2gb.img.xz

2) Booted the image and dropped into the U-Boot console.  Verified the EEPROM was all xFFs, then followed the instructions for reprogramming the EEPROM here:

https://www.siliconbladeconsultants.com/2020/07/06/beaglebone-black-and-osd335x-eeprom/

I also cloned the 0x0010 offset serial number from a PocketBeagle I have.  This resulted in the EEPROM reading:

=> i2c dev 0 Setting bus to 0 => i2c md 0x50 0x00.2 20 0000: aa 55 33 ee 41 33 33 35 50 42 47 4c 30 30 41 32 .U3.A335PBGL00A2 0010: 31 37 35 30 45 50 42 30 36 30 35 38 ff ff ff ff 1750EPB06058....

1 2 3 4 5 6

=> i2c dev 0 Setting bus to 0   => i2c md 0x50 0x00.2 20 0000: aa 55 33 ee 41 33 33 35 50 42 47 4c 30 30 41 32    .U3.A335PBGL00A2 0010: 31 37 35 30 45 50 42 30 36 30 35 38 ff ff ff ff    1750EPB06058....

3) Powered down, swapped the SD card back to a standard PocketBeagle image (am335x-debian-11.3-iot-armhf-2022-04-01-4gb).  At this point, the board does not show “C”s on the console at boot and does not boot.  The UART0 console is blank. Removing the SD card brings back the “C”s.

Things to note:

• If I understand correctly, the lack of “C”s means U-Boot started but did not find an image on the SD matching the EEPROM magic word
• The standard PocketBeagle image boots fine on a PocketBeagle and on the previous run of these boards
• The RobertCNelson a335-eeprom-debian-8.6-console-armhf image will boot and load the Linux kernel when the EEPROM is all FFs, but will not boot once the EEPROM is programed (in fact I can get no image to boot!)
• I can use the a335-eeprom-debian-8.6-console-armhf image to set the first 32 bytes to FFs on a PocketBeagle board, reboot, and then reprogram the EEPROM back to the above and it successfully boots the PocketBeagle image again.

Question:

Is there any other information contained in the EEPROM that affects the SD card boot beyond the first 32 bytes?

Is there any known difference in a Q3 2022 OSD3358-512M-ISM SoC versus an earlier OSD3358-512M-BSM SoC that would affect SD Booting?

 

Thanks,

Aaron

[Neeraj Dantu]

Issue resolved offline. Root cause is said to be power sequencing.

Best,

Neeraj

[amcfarland]

For reference, is case someone runs across something similar:

We went back through things with a fine toothed comb, we were able to get the new boards to boot a few days ago.   Our bench tester power up sequence had changed (thought the board with the OSD3358-512M-BSM powered up with the same sequencing as always).   An external +3.3V to +5.0V level converter tied to UART1 and UART4 (on a USB-to-Serial convertor connected to the Test Laptop) was powering up after SYS_3V3B, where before it was first.  It is totally unclear why the UART IO pins being unknown would affect the boot up process, but we are up and running.

I would note, I found some SD images would complete U-Boot and others would not.  This could be just timing, or U-Boot may be sensitive to data in the other UARTs.

In summary: Always verify all IO are in a known state at boot time if you are having odd boot issues.

[Author]

Posts