The EEPROM on BBBw has board_id flashed. And the BBBw is using this id to identify the variations of hardware and boot into right version. My question is which module (U-BOOT, Kernel) is checking the board_id? Or both are checking the ID.
I assume if U-Boot is checking the id, then I only need to modify the u-boot code to by-pass the id checking, which will lead to Debian (kernel) booting.
Also, I found it is hard to locate the exact version of u-boot source code to download. There are many related sites hosting u-boot source. My current version of u-boot is
U-Boot 2019.04-00002-gb96b20de74 (Jun 25 2019 - 11:39:43 -0500), Build: jenkins-github_Bootloader-Builder-122
Also there are U-Boot overlays. Does the latest source of u-boot include all the overlays, or I have to identify myself what overlays needed and download and flash myself. (it seems to me they are all *.dtbo binary files. I am not clear they are flashed with u-boot or flashed with separate from u-boot.)
Please help me to point the git hub source (web link) for downloading.
I found that in board_detect.c/h source,
it has functions to read/write board name, version, serial, and MAC addr.
It also reads from mmc partition 2 /dev/mmcblk1boot1 ( in fucntion: ti_emmc_boardid_get()).
and with 3rd option
and the conditional compilation is DEFINED.
name = “BBBw”; // I guess board_late_init(); is not called
I guess it is a good place to fake EEPROM: in functions: (in board_detect.c)
But the mac address is also in the EEPROM data structure. The BBBw (rev=BWA5) doesn’t have Ethernet Phy. So it is a hardcoded MAC address. Am I right? Will that be an issue if two or more devices are networked? I an wandering how MAC address is generated through software and hard coded into u-boot env.
Hi @dzhou, i personally like attacking the return of the ti_i2c_eeprom_get function, and then prep my own emulated eeprom name “A335BLNK” and basically assume the am335x-bonegreen.dtb for booting in a blank case. (it’s a simple board with DDR3+eMMC)
The AM335x SOC has two MAC address’s burned into effuses. U-Boot has a built-in “fixup” function to copy the first mac address into the device tree structure. U-Boot does the same thing for the amount of memory detected.
Read the patch you posted. I think this is a generic approach for blank EEPROM. But the fdt file is loaded
setenv fdtfile am335x-bonegreen.dtb.
( I have make sure that -bonegreen.dtb is equivalent to boneblack-wireless.dtb)
For us, it is going to be fixed. So, if we rebuild the u-boot, hard code all the EEPROM data structure in the U-BOOT code sector as it is read from EEPROM. (Whatever goes to EEPROM is stored as part of the u-boot static data as part of its code sector). Although it is not modifiable through external flashing tool, it is fixed anyway (for us) and there is no reason for a change. If it needs to be changed, it will be a new build of u-boot (our own version of u-boot, with blank or hard-code, we are rebuilding it anyway). Then the rest will be no change. It sitll uses:
setenv fdtfile am335x-boneblack-wireless.dtb
for device tree, and all other environment settings.
Hi @dzhou, correct. As long as you take care of maintaining your software stack and what the board runs, you don’t really need to worry about the i2c eeprom value. The eeprom is really only useful if you plan to sell your boards to the mass market (aka like BeagleBoard.org)…
Correct, you can pick any *.dtb to boot, the BeagleBone Green is the simplistic of all the AM335x designs…
I have a question related to this. I know we can write EEPROM through i2c because EEPROM is interfaced through i2c. But that’s under the condition that a version of u-boot or kernel is loaded and running. For bare metal, this is not the case. So, is there a way EEPROM can be flashed through a J-Tag or similar tool?