The BBB reference manual specifies the Format of the content in the equipped EEPROM:
Let me show 4 examples I read out now here from real devices:
00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30 |.U3.A335BNLT00C0|
00000010 32 31 33 34 53 42 42 30 30 37 36 38 ff ff ff ff |2134SBB00768….|
00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30 |.U3.A335BNLT00C0|
00000010 32 32 31 32 53 42 42 33 30 37 35 34 ff ff ff ff |2212SBB30754....|
0000: aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30 .U3.A335BNLT00C0
0010: 32 32 33 32 53 42 42 30 38 32 32 32 ff ff ff ff 2232SBB08222....
This shows me production Years of: 34, 12 and 32.
This is not possible. Is WW and YY exchanged?
Can I rely upon the uniqueness of the Numbers anyway?
Goes nnnn up to 9999 or FFFF?
Regards
Konsti
What are you using to read that out? data sheet shows ascii values, it looks like you have hex. Try converting to ascii and see if it make sense.
Looking at my reference eeprom, looks like with Seeed we swapped this a few years back. boot-scripts/device/bone/bbb-eeprom.dump at master · RobertCNelson/boot-scripts · GitHub (you can see how the “C” got moved too…)
They are programmed while testing, (with a bar code scanner), so yes uniqueness.
Each AM335x also has a 2 unique “mac” address pre-programmed by TI…
Regards,
31 and 34 ARE the ASCII pendants of the raw hex codes.
Thank you very much!
Do you know by change if the incrementing board number is decimal (up to 9999) or hex (up to FFFF)?
All numbers are in human readable ascci… “0h3x”. 
Mostly so users can dump eeprom directly without calculating values…
Regards,
Can those be over written as well as the serial number?
they are efused locked by ti…
Read Only…
Regards,
1 Like
What I now got clearly is that YY and WW is exchanged from the spec in the reference manual and that its ASCII coded.
What I still did not get, the incrementing number part “xxxx” in �U3�A335BNLT000CyywwBBoxxxx, is that counting to 9999 or to FFFF?
How many BBBs are produced in one week, in other words. Is this number expected to go beyond 9999, do I need to expect letters ABCDEF in there?
I brute forced checked a couple of our current delivery and the SNs shows as
�U3�A335BNLT00C02246SBB03883
�U3�A335BNLT00C02246SBB05161
�U3�A335BNLT00C02246SBB02821
�U3�A335BNLT00C02246SBB03811
�U3�A335BNLT00C02213SBB21067
�U3�A335BNLT00C02213SBB20974
�U3�A335BNLT00C02213SBB20009
�U3�A335BNLT00C02233SBB13624
�U3�A335BNLT00C02233SBB13623
�U3�A335BNLT00C02233SBB10271
�U3�A335BNLT00C02134SBB00768
�U3�A335BNLT00C02212SBB30754
�U3�A335BNLT00C02232SBB08222
So 00C0 still seems to be valid, then YY+WW, then SBB and then we have 5 instead of 4 rolling numbers?
So beagle-version and the old version.sh scripts has always gone up to lenght 28…
if [ -f /sys/bus/i2c/devices/0-0050/eeprom ] ; then
board_eeprom=$(hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28 || true)
echo "eeprom:[${board_eeprom}]"
fi
I’ve also ignored everything after…
Regards,
Robert, I just realise your number at boot-scripts/device/bone/bbb-eeprom.dump at master · RobertCNelson/boot-scripts (github.com) looks a bit to schort:
A335BNLT000CyywwBBoxxxx
The command you use
hexdump -e '8/1 "%c"' /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28 || true
gets it complete, though:
hexdump -e ‘8/1 “%c”’ /sys/bus/i2c/devices/0-0050/eeprom -n 28 | cut -b 5-28 || true
A335BNLT00C02134SBB00768
Reference manual points out:
A335BNLT00C0WWYY4P16nnnn
And I read:
A335BNLT00C02233SBB13623
So there are 5 NNNNN at the end and the 4 char part before looks like only 3.
