OSD3358 Boot

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 6 years, 9 months ago by Neeraj Dantu.
• This reply was modified 6 years, 8 months ago by 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

Hello Mr. Neeraj,

I have developed my custom board based on OSD3358 beaglebone black wireless version. I am attaching my circuit design png below.

Changes in my board:

different wireless module and instead of HDMI i am using LCD interface directly. All remaining things are exact of the octavo’s BBB.

Now current status of board is as follows :

EMMC is empty and i am not inserting sd card in slot.My intention is to go in UART boot mode and see “CCCC” coming on the serial monitor.

Power led,PMIC_LED_GOOD ,reset_signal all power voltage rails are working fine. currently I am unable to check crystals because of  CRO unavailability.

Question : I am getting 0.60 volt on UART0_Tx debug header instead of 3.3 volts.   I have checked buffer ic and all traces on pcb they all checked out. And resistance of trace is 4.5 OHM so that should be not an issue for fast signal like this. I am thinking it is because at power on boot lines aren’t getting latched!  what are your thoughts on this?

Note : On pcb i have kept 47pF capacitors pads open(They are connected to BOOT lines/LCD lines). They are not populated, should i populate them??

Thank you,

Keval Desai

Hello kd,

I didn’t find anything on the schematic that would interfere with UART0 operation. Boot configuration seems to be fine. I don’t think absence of 47pF caps are causing problems either.

We will need a little more information before we proceed further.

1. What is the voltage on the UART0_TX line at the input of buffer U8?

2. Did you actually try connecting UART0 pins to a Serial Client like Putty? Were you able to see any messages?

• This reply was modified 6 years, 8 months ago by Eshtaartha Basu.

Hi,

Thank you for coming to my aid,First of all I like to mention one thing which I forgot last time is, between poweronreset(cold reset) and nreset(warm reset) there is a buffer. We haven’t populated that buffer  on Pcb due to unavailability of that ic on our end. But I don’t think that can cause any problems.

1) at the input of buffer U8 , it is 0.60 voltage. Same reflects on its output pin.

2)I am using pqcom in windows which perfectly works with original BBB. At 115200 baud rate. I tried to connect it but it didn’t show anything.

3) we have eeprom that Is not programmed so we have to bypass that check in uboot,my colleague is working on that as soon as he is done I will test to see if I get any status led working.

But I doubt that wont work until we solve this problem. It is something in hardware but I am unable to pinpoint it exactly.

What do you think,what should I do next?

Thank you,

Keval desai

It is my pleasure to help you. I believe the absence of buffer U5 is not the problem. We need to first find out if the processor is alive.

1. In the beginning of our discussion, you said “Power led,PMIC_LED_GOOD ,reset_signal all power voltage rails are working fine.” I’m not yet sure if you’ve already tested the voltages on the following test points (corresponding correct voltages are also given below):

VDDS_DDR: 1.5V

VDD_CORE: 1.1V

VDD_MPU: 1.1V

VDDS_PLL: 1.8V

By verifying the above voltages we can make sure that AM335x is receiving necessary voltages from PMIC during and after boot.

2. I believe you have already verified boot configuration resistors. Make sure all the resistors are properly populated and resistor values are correct.

3. If all the above two tests pass, use a JTAG cable and try to connect to AM335x using Code Composer Studio. OSD335x Bare Minimum Boot Process Article will help you setup Code Composer Studio and connect to OSD335x using a debugger. 

If steps 1, 2 pass and JTAG test fails, I would strongly recommend getting a CRO and verifying if OSD335x is receiving proper clock input before debugging the hardware further.

After trying the above steps, I would also recommend going through AM335x Board Bring Up Tips Wiki.

I just found out the problem. i assumed that processor is working fine and focused on just uart signaling part and found out that i made a mistake in schematic.

If you follow my schematic properly you will find that due to my wrong labels of signals input/output of uart buffer ic  got shorted out. I removed the UART buffer ic and now i am able to see “CCCC”on serial monitor.

Right now i am attaching FTDI cable directly to processor’s debugger without buffer ic. And its working fine. should i keep buffer ic between them?

I’m glad the problem is solved. The buffer IC is not mandatory.

Out of curiosity, I would like to know what exactly caused the short. I went back and looked at your schematic again. Your labels are NOT wrong. When 2OE is pulled high and *1OE is pulled low, the buffer IC (SN74LVC2G241) passes data from 2A (UART0_TX) to 2Y (B_UART0_TX) and from 1A(B_UART0_RX) to 1Y(UART0_RX). The pin to signal mapping of the buffer also seems to be correct on schematic. I’ll be glad if you could elaborate a bit more.

Actual connector is on left-top corner of the schematic.  You will notice that , those pins have UART0_TX  labeled, in the updated and final schematic i removed those extra small pins and routed only main big connector. So in the end B_UART0_TX got replaced with UART0_TX.  You will find routing error in attached file.

I have one query left which is as follows

Right now i do not have EEPROM programmed and so when i boot readymade BBB images through SD card will it throw anything on serial debug? like MLO found and reading boot image etc… We haven’t provided bypass for the check of the eeprom in uboot. My intention here is to check sd card interface working properly or not!

Yes my team mate is currently working on that patch. Mine and my team mate’s understanding is EEPROM check happens in uboot spl stage. Before that MLO  and uboot spl (starting ) log should be printed by UART console. But i am getting none when in SD card boot mode!!!

I am booting this image through SD Card  :

bone-debian-9.3-lxqt-armhf-<wbr style=”color: #222222; font-family: arial, sans-serif; font-size: small;” />2018-01-28-4gb.img.xz

What i am expecting is something like this..

• This reply was modified 6 years, 8 months ago by kd.
• This reply was modified 6 years, 8 months ago by kd.

Okay, I will test it right away and update you with the result.

Hi, I just tested your suggested image and it is working as expected.  It is throwing error message on uart which means sd card interface is working.

Thank you so much for your constant support.

@EshtaarthaAs i mentioned before i have blank EEPROM on my board so i tried following method to bypass the check.

@Neeraj First we tried this post #4733 

It is part of this thread . in this process we face no difficulty while applying the patch and building the source. But when i boot image through sd card my board didn’t responded on uart debug terminal.  We haven’t received anything on the uart console.

@EricT So second we tried this post #4582

We made a change in latest version of uboot available on github.

u-boot/board/ti/am335x/board.h

And i dump this image on sd card and boot my custom board. it started throwing messages on serial uart as follows.

it continuously reset the board with these two errors repeatedly.

What do you think? is it a hardware problem? or uboot problem? i tested this image on real BBB which works fine.

My main objective here is to reach at the uboot console somehow.  I dont know where exactly problem is happening!!!

HI,

Recently  we tried resetting board several times with image which contains eeprom bypass check. And 1 in 5 try we were able to get into uboot console. at the end we realize we can not write eeprom because on our custom board i2c0’s SCL line is shorted to V3.3B. There is no way to remove that short.

other peripheral seems to be getting proper voltages without any pcb design fault. Do you think if we can properly bypass eeprom check in uboot we will be able to use our board as intended . We are not using i2c0 except on pmic/eeprom (by default). We haven’t tried booting a kernel yet.  Do you think that is it possible if we properly work on uboot we can overcome this hardware fault?

yes, it is shorted in layout. And i wont be able to remove it. Do you think default configuration will work ? i am aiming for  processor, ddr, and sd card to work properly. i am able to get to the uboot console.

Hi,

We received our custom boards with the OSD3358. I carefully followed the instructions described by Neeraj in post #4733 and having some issues getting the flasher image to flash the image to the emmc. I am using the “Debian 9.5 2018-10-07 4GB eMMC IoT Flasher” beagle image and followed all instructions without any errors. Now when I insert the sd card and power the board, the flashing process does not start nor the user LED’s light up. Below is the log I got from the serial console.

Setting bus to 0
Setting bus to 0
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
resetting …

U-Boot SPL 2018.01-dirty (Jan 30 2020 – 14:20:06)
Trying to boot from MMC1

U-Boot 2018.01-dirty (Jan 30 2020 – 14:20:06 +1300)

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

<ethaddr> not set. Validating first E-fuse MAC
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BLNK] …
30 bytes read in 16 ms (1000 Bytes/s)
Loaded environment from /boot/.eeprom.txt
Setting bus to 0
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
Setting bus to 0
Setting bus to 0
Setting bus to 0
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
resetting …

U-Boot SPL 2018.01-dirty (Jan 30 2020 – 14:20:06)
Trying to boot from MMC1

U-Boot 2018.01-dirty (Jan 30 2020 – 14:20:06 +1300)

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

<ethaddr> not set. Validating first E-fuse MAC
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: usb_ether
Press SPACE to abort autoboot in 2 seconds
board_name=[A335BLNK] …
30 bytes read in 16 ms (1000 Bytes/s)
Loaded environment from /boot/.eeprom.txt
Setting bus to 0
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
Setting bus to 0
Setting bus to 0
Setting bus to 0
0000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
0010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff …………….
resetting …

U-Boot SPL 2018.01-dirty (Jan 30 2020 – 14:20:06)
Trying to boot from MMC1

U-Boot 2018.01-dirty (Jan 30 2020 – 14:20:06 +1300)

CPU : AM335X-GP rev 2.1
I2C: ready
DRAM: 512 MiB
No match for driver ‘omap_hsmmc’
No match for driver ‘omap_hsmmc’
Some drivers were not found
Reset Source: Global warm SW reset has occurred.
Reset Source: Power-on reset has occurred.
MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

<ethaddr> not set. Validating first E-fuse MAC
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: usb_ether
Press SPACE to abort autoboot in 2 seconds
=>
=> unam
Unknown command ‘unam’ – try ‘help’
=> uname
Unknown command ‘uname’ – try ‘help’
=> uname -a
Unknown command ‘uname’ – try ‘help’
=> help
? – alias for ‘help’
askenv – get environment variables from stdin
base – print or set address offset
bdinfo – print Board Info structure
boot – boot default, i.e., run ‘bootcmd’
bootd – boot default, i.e., run ‘bootcmd’
bootefi – Boots an EFI payload from memory
bootelf – Boot from an ELF image in memory
bootm – boot application image from memory
bootp – boot image via network using BOOTP/TFTP protocol
bootvx – Boot vxWorks from an ELF image
bootz – boot Linux zImage image from memory
btrsubvol- list subvolumes of a BTRFS filesystem
cmp – memory compare
coninfo – print console devices and information
cp – memory copy
crc32 – checksum calculation
dfu – Device Firmware Upgrade
dhcp – boot image via network using DHCP/TFTP protocol
dm – Driver model low level access
echo – echo args to console
editenv – edit environment variable
eeprom – EEPROM sub-system
env – environment handling commands
exit – exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls – list files in a directory (default /)
ext4load- load binary file from a Ext4 filesystem
ext4ls – list files in a directory (default /)
ext4size- determine a file’s size
ext4write- create a file in the root directory
false – do nothing, unsuccessfully
fastboot- use USB Fastboot protocol
fatinfo – print information about filesystem
fatload – load binary file from a dos filesystem
fatls – list files in a directory (default /)
fatsize – determine a file’s size
fatwrite- write file into a dos filesystem
fdt – flattened device tree utility commands
fstype – Look up a filesystem type
go – start application at address ‘addr’
gpio – query and control gpio pins
gpt – GUID Partition Table
help – print command description/usage
i2c – I2C sub-system
iminfo – print header information for application image
imxtract- extract a part of a multi-image
itest – return true/false on integer compare
load – load binary file from a filesystem
loadb – load binary file over serial line (kermit mode)
loads – load S-Record file over serial line
loadx – load binary file over serial line (xmodem mode)
loady – load binary file over serial line (ymodem mode)
loop – infinite loop on address range
ls – list files in a directory (default /)
md – memory display
mdio – MDIO utility commands
mii – MII utility commands
mm – memory modify (auto-incrementing address)
mmc – MMC sub system
mmcinfo – display MMC info
mw – memory write (fill)
nfs – boot image via network using NFS protocol
nm – memory modify (constant address)
part – disk partition related commands
ping – send ICMP ECHO_REQUEST to network host
printenv- print environment variables
pxe – commands to get and boot from pxe files
reset – Perform RESET of the CPU
run – run commands in an environment variable
save – save file to a filesystem
setenv – set environment variables
sf – SPI flash sub-system
showvar – print local hushshell variables
size – determine a file’s size
sleep – delay execution for some time
source – run script from memory
spl – SPL configuration
sspi – SPI utility command
sysboot – command to get and boot from syslinux files
test – minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
time – run commands and summarize execution time
true – do nothing, successfully
usb – USB sub-system
usbboot – boot from USB device
version – print monitor, compiler and linker version
=>

Could someone help me resolve this?

Thanks.

I have made some progress. I included the “v2019.04” branch and followed the same process. And I hardcoded board id as below:

Now, at least I can see the user LEDs flashing when booting up. But now the image flashing never initiates and system resets. I think I am very close to resolving this, below is the logs during boot over the serial console. It would be great if someone here could take a look at it to advise on how to proceed.