[Neeraj Dantu]

Gary,

Once the EEPROM is programmed, you can use different Beagle images to boot from the board. u-boot is the 2nd stage bootloader that resides in the SD card or eMMC along with the Linux image. The boot process at u-boot level involves configuration of some hardware interfaces for Linux boot and board identification check on EEPROM. u-boot identifies the board based on the board ID it reads (such as Beaglebone Black, Beaglebone Wireless and Beaglebone Blue) and loads the appropriate device tree for Linux boot.

So, in summary there are 2 ways you can get around the EEPROM ID:

1. You can bypass the EEPROM check by creating patching u-boot on a beagle image and use that image to write to the EEPROM
2. Write to the EEPROM with u-boot

If you do one of these two things, the board will boot other Beagleboard images without modifications.

[Neeraj Dantu]

Gary,

The Beagle images definitely need EEPROM ID to boot. https://octavosystems.com/forums/topic/osd3358-boot/#post-4733 describes the easier way to get around this issue by running commands on an Ubuntu machine in order to bypass the EEPROM check completely. You just have to apply some patches to u-boot rather than modifying u-boot yourself.

Neeraj.

[Neeraj Dantu]

Gary,

The ‘C’ on UART0 terminal means that the processor is working! If you want to boot a Beagle image (https://beagleboard.org/latest-images), you have to modify/patch the boot-loader the Beagle images use (u-boot) to either write a beagle board ID to EEPROM or bypass the EEPROM check during boot using the procedure described in #4608. Here is another thread that goes through the procedure of patching u-boot to bypass EEPROM check: https://octavosystems.com/forums/topic/osd3358-boot/#post-4733 .(The procedure described in this thread does not require any UART interfacing)

Neeraj

[Neeraj Dantu]

Gary,

That is a good approach. The board puts out boot messages on UART0 also. So, you can debug any boot up issues you are having using the UART cable and Putty.

 

Here is a link to a more detailed procedure to bypass EEPROM check during boot up: https://octavosystems.com/forums/topic/osd3358-boot/#post-4733

[Neeraj Dantu]

Hi David,

Please post the error you are seeing on step 5. Also, there was a small mistake (a br tag that was not supposed to be there) in step 4 which I have now corrected. Other than that, this procedure has been verified and tested by costumers. Here is the reference to the original wiki this procedure was formulated from: https://eewiki.net/display/linuxonarm/BeagleBone+Black

For the second question, Yes. The boot configuration is required to tell the processor about the boot mode (SD card, eMMC etc.) Please take a look at the tutorial series we put together that can help designing with the OSD335x: https://octavosystems.com/app_notes/osd335x-design-tutorial/

Neeraj

[Neeraj Dantu]

David,

The Beagle images require the EEPROM programmed with a board ID in order for them to boot. See https://octavosystems.com/forums/topic/issues-booting-custom-board/#post-4608 for more information. You can also update your Beagle image with a new u-boot using the following procedure to bypass the EEPROM ID check:

– Create an SD card with the latest Beagle image or the image you want to use by following the procedure in https://beagleboard.org/getting-started

– In an Ubuntu machine or a VM that runs Ubuntu, download and compile u-boot:

1. Download the ARM cross-compiler GCC. Note the pwd in code line 3 needs a special character “`” on both sides
– wget -c https://releases.linaro.org/components/toolchain/binaries/6.4-2017.11/arm-linux-gnueabihf/gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz
– tar xf gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabihf.tar.xz
– export CC=`pwd`/gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-

2. Download u-boot
– git clone https://github.com/u-boot/u-boot
– cd u-boot/
– git checkout v2018.01 -b tmp

3. Get the patches (Needs internet connection)
– wget -c https://rcn-ee.com/repos/git/u-boot-patches/v2018.01/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
– wget -c https://rcn-ee.com/repos/git/u-boot-patches/v2018.01/0002-U-Boot-BeagleBone-Cape-Manager.patch
– wget -c https://raw.githubusercontent.com/RobertCNelson/Bootloader-Builder/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch

4. Apply patches to u-boot
– patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

– patch -p1 < 0002-U-Boot-BeagleBone-Cape-Manager.patch

– patch -p1 < 0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch

5. Configure and Build
– make ARCH=arm CROSS_COMPILE=${CC} distclean
– make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_defconfig
– make ARCH=arm CROSS_COMPILE=${CC}

6. Attach the SD card to the computer and run ‘lsblk’ to find out the id of the SD card. In our case the id was ‘sdb’

7. Install bootloader:
– export DISK=/dev/sdb
– sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
– sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=384k

This installs a new version of u-boot that does not check the EEPROM. If you insert the SD card into the
board and power it up holding down boot button, you should be able to see the user LEDs light up.

Hope this helps.

Thanks,
Neeraj

• This reply was modified 7 years ago by Neeraj Dantu.
• This reply was modified 7 years ago by Neeraj Dantu.

[Neeraj Dantu]

Based on the datasheet for the TL5209 and the resistor values chosen, the SYS_VDD1_3P3V output voltage should be 3.33 V, consistent with values published in the OSD335x/OSD335x-SM datasheet. However, after the observation that the output voltage was around 3.4 volts, we checked our production data and saw that the average output voltage was closer to 3.4 volts. We then went back to the original BeagleBone Black design on which the OSD335x/OSD335x-SM was based and found that the output voltage of the TL5209 was also 3.4 volts. We are still in the process of understanding why the output voltage is not consistent with the TL5209 datasheet. However, this should not be an issue for most systems and we will be updating our datasheet to better reflect the TL5209 performance.

[Neeraj Dantu]

Thank you Eric for your response.

There are a couple of ways to get around the EEPROM ID check.

1. Bypass the checks in u-boot:

Here is a link to the section of code that you will need to modify:

http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/am335x/mux.c;h=ad85b3a19ac3c6c4483132d763678eb7fb1b1703;hb=refs/heads/master#l341

I’m not sure if this is exactly the same code as what you are running, but we have seen in the past that the puts() for the “Bad EEPROM …” statement would not actually print anything to the UART console and it would look like everything would just hang when the EEPROM was not programmed. If you look at the board/ti/am335x/mux.c file of your u-boot build, then you can see the actual code you are running and can modify it so that you use the “board_is_bone()” configuration for the pinmux (or define your own)

2. Use Robert Nelson’s patch to create u-boot that will boot and allow you to program the EEPROM: In u-boot apply the patch:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch#L157-L164

Using the “blank” image, create a file in the first partition:

/boot/.eeprom.txt

Use the variable:  board_eeprom_header

For a built-in device:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.03-rc1/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch#L1607-L1617

board_eeprom_header=bbb_blank
board_eeprom_header=bbbl_blank
board_eeprom_header=bbbw_blank
board_eeprom_header=os00_blank
board_eeprom_header=beaglelogic_blank

 

For a non built-in, use “eeprom_program”

eeprom_program=i2c dev 0; \
i2c md 0x50 0x00.2 20; \
i2c mw 0x50 0x00.2 aa; \
i2c mw 0x50 0x01.2 55; \
i2c mw 0x50 0x02.2 33; \
i2c mw 0x50 0x03.2 ee; \
i2c mw 0x50 0x04.2 41; \
i2c mw 0x50 0x05.2 33; \
i2c mw 0x50 0x06.2 33; \
i2c mw 0x50 0x07.2 35; \
i2c mw 0x50 0x08.2 42; \
i2c mw 0x50 0x09.2 4e; \
i2c mw 0x50 0x0a.2 4c; \
i2c mw 0x50 0x0b.2 54; \
i2c md 0x50 0x00.2 20; \
reset ;

 

You can also just run the “run eeprom*” commands from U-Boot console.  (This works in “blank” and “normal” images.)

One other thing that I wanted to mention:  I know you are aware of the Linux device tree, but u-boot also uses a device tree that you might need to modify.  You should find the u-boot device tress in ./arch/arm/dts  It is useful to look through the 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch patch from Robert Nelson (see https://eewiki.net/display/linuxonarm/BeagleBone+Black) since this patch modifies device trees and can point you to important directories in u-boot.

• This reply was modified 7 years, 1 month ago by Neeraj Dantu. Reason: Formatting
• This reply was modified 7 years, 1 month ago by Neeraj Dantu.

[Neeraj Dantu]

Hi eFBe,

Thank you for the suggestion. We will update the schematics on our website. The part number for the APX811 used in the RED board is APX811-31UG-7.

 

Best regards,

Neeraj.

[Neeraj Dantu]

Hi Eric,

Yes, you need to program the EEPROM with corresponding board ID for the RED board. U-boot checks for this ID before proceeding to boot. Writing the Beaglebone Black ID to the EEPROM should be sufficient for it to boot the RED board image.

Best regards,

Neeraj.

 

[Neeraj Dantu]

acook,

Please note that the device tree files were compiled with device tree rebuilder (https://github.com/RobertCNelson/dtb-rebuilder) with no issues. The OSD3358 device tree Github (https://github.com/octavosystems/OSD335x-Device-Tree) contains 3 files listed below:

1. osd335x-common.dtsi  – OSD3358 specific
2. osd335x.dtsi – OSD3358 specific
3. osd3358-bsm-refdesign.dts – OSD3358-SM RED board specific in OSD335x-Device-Tree/OSD3358-SM-RED

There is also a compiled version of the device tree in OSD335x-Device-Tree/OSD3358-SM-RED (osd3358-bsm-refdesign.dtb)

In order to compile, the 3 files listed above need to be placed in  dtb-rebuilder/src/arm after cloning the device tree rebuilder(branch 4.4-ti). You can use the Makefile in there to compile all the files or specific ones in the src/arm directory. This is also where you should be able to find the dependency am33xx-pruss-rproc.dtsi. The device tree rebuilder uses dtc(1.4.4) also.

 

Coming to the next part of the question, assuming that you renamed the file osd3358-bsm-refdesign.dts to am335x-thecount.dts, line 139

audio-ports = <AFMT_I2S 0x03>;

is from am335x-boneblack.dts line 143 (can also be found in src/arm directory of device-tree-rebuilder) and is a not supposed to cause any issues during compilation. If you have any more information regarding the error, we will be happy to help.

 

Thank you for your question.

• This reply was modified 7 years, 2 months ago by Neeraj Dantu.
• This reply was modified 7 years, 2 months ago by Neeraj Dantu.
• This reply was modified 7 years, 2 months ago by Neeraj Dantu.
• This reply was modified 7 years, 2 months ago by Neeraj Dantu.

[Neeraj Dantu]

The TPS65217C VIO pin is internally connected to SYS_RTC_1P8V of the OSD3358-SM

[Author]

Posts