Board_ID, U-BOOT related question

Hi,

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.

Thank you,
David

I downloaded u-boot source from:
http://github.con/u-boot/u-boot.git
as (from master branch)
ver=U-Boot 2020.07-00442-g186529953f (Jul 08 2020 - 14:03:50 -0400)

I am not sure the latest is the greatest and it really is also for BeagleBone Black.
But it compiled and loaded and run from RAM.

Thanks,

David

U-Boot is reading the device ID to figure out which board it’s booting on:

That is the current shipping build, it matches this git checkout and 2 patches:

Mainline u-boot will run fine on the board.

Here is BeagleBoard.org’s list of id’s: https://github.com/beagleboard/image-builder/blob/master/readme.md

The first part of the eeprom:

aa 55 33 ee 41 33 33 35  42 4e 4c 54

Means AM335X, DDR3, TPS65217C or OSD3358

The next 4 ASCI characters determine which model…

For example:

and

Regards,

Hi Robert,

Thank you so much! You have answered all of my questions.

Best Regards,

David

Hi Robert,

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
board\ti\am335x\board.c(806):#ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
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)
ti_emmc_boardid_get() ;
ti_i2c_eeprom_am_get();

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.

Thank You,
David

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.

Regards,

Hi Robert,

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.

Will you agree with me?

Regards,

David

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…

Regards,

Hi Robert,

Thank you for your confirmation.

David

Hi Robert,

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?

Thank you,

David

Hi Robert,

I found from OCTAVO document that EEPROM can be programmed through external I2C programmer, or use TI Starterware to do that.

Regards,

David

Hi @dzhou, personally i just use u-boot, but the i2c bus is accessible from outside the SIP…

Regards,