[Neeraj Dantu]

Joe,

Here is what I would go through to bring your board up and running:

1. Bypass the EEPROM check in Beagleboard image(https://beagleboard.org/latest-images) by following the instructions here and boot the board:

https://octavosystems.com/forums/topic/osd3358-boot/#post-4733

2. Program the EEPROM by grounding the EEPROM_WP of the OSD335x-SM to boot standard beagle images. There are a couple of ways of doing this. You can boot patched Linux image from sdtep 1 and use the SYSFS interface to write the ID to EEPROM directly. You can also use the I2C commands in u-boot to program the EEPROM: http://beagleboneblack.blogspot.com/2016/01/bbb-magic-number-programming.html.

3. Use the device tree rebuilder(https://github.com/RobertCNelson/dtb-rebuilder) to modify the RED board device tree source files(https://github.com/octavosystems/OSD335x-Device-Tree) to reflect the hardware on your board and compile it to .dtb. This is the kernel device tree. You should more than likely not have to modify the u-boot device tree.

4. Place the custom .dtb file in /boot/dtbs/[Kernel Version]/ and modify dtb variable in /boot/uEnv.txt to your custom device tree file

Your board should boot up with the custom device tree at this point and you should be able to start integrating your software. Make sure you can access your SD card offline through a host computer so you can iterate the device tree modifications easily.

You should not have to modify u-boot in order to boot the board. If you want to, you can use a u-boot overlay to customize the boot(https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays). Here is a repository of overlays: https://github.com/beagleboard/bb.org-overlays .If you see strange behavior in u-boot, it may be  because u-boot prefers to boot Linux from the MMC0 interface and this may result in some things not working as they do in the standard beagle image configuration. In this case you have to modify some u-boot config files to work around this.

 

[Neeraj Dantu]

Hi Gary,

From the schematics you provided us, the Atmega2560 looks like it is connected to pins (A13, B13) which are pins for UART2 and not UART3.

The interface does need to be enabled in device tree. You can also specify a device tree overlay to instantiate the UART interface. For this, you will need to modify uEnv.txt located on /boot folder. You will need root privileges to modify this file. So, make sure you are root.

I made 2 modifications to this file:

1. uncommented uboot_overlay_addr0 and specified BB-UART2-00A0.dtbo as the device tree overlay(changes shown below)

###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/BB-UART2-00A0.dtbo
#uboot_overlay_addr1=/lib/firmware/.dtbo
#uboot_overlay_addr2=/lib/firmware/.dtbo
#uboot_overlay_addr3=/lib/firmware/.dtbo
###

2. Commented the line to enable universal cape(shown below).

###Cape Universal Enable
#enable_uboot_cape_universal=1

Then I rebooted the board. I was able to see that UART2 was available as ttyO2:

root@beaglebone:/var/lib/cloud9# ls -l /dev/ttyO*
lrwxrwxrwx 1 root root 5 Mar 20 16:16 /dev/ttyO0 -> ttyS0
lrwxrwxrwx 1 root root 5 Mar 20 16:16 /dev/ttyO2 -> ttyS2

In order to test the interface, I used a UART to USB FTDI cable and connected it to my computer. I monitored the connection using Putty with baud rate 9600.

On the board, I installed minicom which is a serial console program.

sudo apt-get install minicom

I ran the following command to start a communication terminal on the board.

root@beaglebone:~# minicom -D /dev/ttyO2 -b 9600

I then input some characters and verified that they were showing up on my computer’s Putty terminal.

Hope this helps,

Please let us know if you have any more questions.

 

 

[Neeraj Dantu]

Gary,

I fixed the post I linked to to display the correct special character. We are currently working on an Application note that goes through working with EEPROM IDs. Please let us know if you have any more issues and look out for the application note.

Neeraj

[Neeraj Dantu]

Gary,

I just reviewed the post and found the editor on the forum does not handle the special character “`” well. In step 1, code line 3, please add the special character on both sides of the word pwd and let us know if that fixes the error.

Neeraj

[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, 1 month ago by Neeraj Dantu.
• This reply was modified 7 years, 1 month 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, 2 months ago by Neeraj Dantu. Reason: Formatting
• This reply was modified 7 years, 2 months 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, 3 months ago by Neeraj Dantu.
• This reply was modified 7 years, 3 months ago by Neeraj Dantu.
• This reply was modified 7 years, 3 months ago by Neeraj Dantu.
• This reply was modified 7 years, 3 months ago by Neeraj Dantu.

[Author]

Posts