Just out of curiosity, wondering:
How are the EEPROMs for the BBB programmed in production? How are per-device things like serial numbers allocated? Curious also how that’s matched up to the sticker with the serial number?
If I wanted to mess around with the EEPROM, what’s the best way to keep a backup (particularly with respect to things like the serial number)?
I connected up a Bluetooth serial module and played with the i2c commands in uboot.
Sorry if this is a dumb q, but when I try to read all I see is a load of 'ff’s:
U-Boot# i2c md 0x50 0x0 0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................
So far as I know 0x50 is the right address for the EEPROM, but looking at the BBB SRM I believe it should actually start with: 0xAA, 0x55, 0x33, 0xEE
In Linux land I confirmed this:
beaglebone:/sys/class/i2c-dev/i2c-0/device/0-0050# cat eeprom | xxd | head 0000000: aa55 33ee 4133 3335 424e 4c54 3041 3543 .U3.A335BNLT0A5C
I rather suspect I’m doing something dumb, so apologies in advance!
Just to add, while i2c reads don’t seem to work in uboot for the EEPROM, it does seem to work for the power control:
-Boot# i2c md 24 0 0000: e2 3e 00 01 b1 80 b2 01 00 00 84 00 7f 0c 18 02 .>..............
As I recall, there is indeed an issue with I2C working on all buses under the UBoot mode.
Just wondering then how the terminal script you mentioned you use in production works? Is it just a uboot version issue?
They use the BeagleBone White to program the capes. It uses an older UBoot that works like it is supposed to.
In case anyone comes looking - I found the equivalent question on the TI forums too:
The most recent response at time of writing is:
Because the SW for doing this is not yet completed. .Oh, and we are on 2.0 silicon.
Hmmm. I realise the ‘A’ in the chip name XAM3359AZCZ100 means rev 2.0 - however looking at the errata here : http://www.ti.com/lit/er/sprz360e/sprz360e.pdf
Page 24, Advisory 1.0.20:
The USB boot ROM code is overlapping data in the TXFIFO and RXFIFO which leads to
data corruption. This data corruption causes a data abort and prevents USB boot from
That was the only thing I could see mentioning anything to do with issues booting from USB, but the document states that only affects rev 1.0. Is that not correct?
I know that the SW that supports the USB boot is still being worked on. We are hoping to be able to boot over USB and then flash the eMMC at some point. But that is a ways down the road.
Initially, I assumed when you said ‘SW that supports USB boot’ you must have meant ‘software’ on the AM335x itself - so I went looking for the source for the Sitara bootloader ROM (which as I understand it is the very 1st bootloader stage, to load the U-Boot MLO into memory). But then I read that actually the ROM is just masked out (i.e. implemented in discrete logic, not a writeable ROM of some sort).
So I was confused until I finally realised (I think) that USB boot in this case doesn’t mean booting from a USB drive (as it does on a PC) - it means booting with a virtual ethernet connection created with an RNDIS over a physical USB connection. Is that correct?
This means (again pls correct me if I’m wrong, I’m just learning here!) that to ‘USB boot’ actually you’re just plugging the BBB into a computer with an RNDIS driver, and running a BOOTP server on that same computer? And thus I presume the software you’re talking about is just a turn-key solution for people to use that sets this up?
I meant the application on a PC that supports this feature.
i have 5 bbb with new eeprom… can you help me with script???
And where did you get these boards without the EEPROM programmed?
I mounted this in led illumination project but i make a error with program eeprom and this result blank.
the problem is the boot… not load null because read eeprom and not view the original value.
Can you help me with file boot…
i buy less 40 board but this is urgently and important for my work.
Help me please.
Can I assume these are Embest boards?
are bbb rev c
and personal maker.
i need file for boot.
i testing this
thanks very very very much.