Issues Booting Custom Board

Tagged: Boot from SD

This topic has 31 replies, 7 voices, and was last updated 4 years ago by Neeraj Dantu.

Viewing 19 reply threads

Author
Posts

January 22, 2018 at 12:24 pm #4524
EricT
Participant
Hello Forum,
We have a board that we designed, pretty much following the OSD3358-SM-RED reference design.
The system appears to be running (everything from the Octavo bring up guide looks good).
I am able to get to the UART boot mode, and am receiving a repeating ASCII ‘C’ over the terminal. I am assuming this indicates power rails and clocks are working as they are supposed too.
However, I can not seem to get this design to run u-boot off an SD card or UART. I have tried some beaglebone SD card images, the OSD3358-sm-red image, and have built a few custom images.
A logic analyzer on the SD lines show pulses on clock, cmd, and data for about 250 msec, then stops.
I am missing some custom config/build setting? do I need to program the on chip EEPROM?
Thanks!
Eric

January 22, 2018 at 1:21 pm #4527

Neeraj Dantu

Moderator

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.

January 31, 2018 at 5:08 pm #4583
bpiquette
Participant
Neeraj, What is the recommended process for getting the eeprom programmed?

February 1, 2018 at 12:30 pm #4608

Neeraj Dantu

Moderator

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

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 ;

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

January 24, 2018 at 8:33 am #4555
EricT
Participant
Ok, we programmed the internal EEPROM with the proper values and our system is running. We were wrongly assuming this was pre-programmed.
Thanks,
Eric
January 31, 2018 at 11:51 am #4581
bpiquette
Participant
Any suggestions on the best method to program the EEPROM? We are seeing a very similar issue.
When we compare the SDcard commands on our board to those of the RED Dev board, we see a a pretty different looking trace.
The SD CLK is running at ~120kHz on our board, compared to 400kHz on RED is a clear example of the differences.
Can a non-programmed EEPROM cause these differences?
January 31, 2018 at 1:09 pm #4582
EricT
Participant
Yes, a non-programmed EEPROM will do to that to the SD clock.
What I learned, is u-boot needs the EEPROM data to set things like clock speed, MMC, and other stuff. If you have access to the I2C_0 pins, you can use a i2c tool to program the EEPROM.
I was being lazy, so tried to boot over the UART following this guys blog:
http://linuxkernel51.blogspot.com/2015/08/booting-beagle-bone-black-over-uart.html

however I went in and hacked the uboot source to force it to use the BeagleBone Black configuration. if you want to do the same, edit:
u-boot/board/ti/am335x/board.h
static inline int board_is_bone_lt(void) { return 1; }
1
2
3
4
static inline int board_is_bone_lt(void)
{
return 1;
}

Once in the Uboot bootloader, I use the uboot i2c application to program the EEPROM.

Eric
January 31, 2018 at 7:29 pm #4584
bpiquette
Participant
We’ve had success with the same approach!
Thanks so much for blazing the trail EricT!
February 27, 2018 at 12:31 pm #4760
garybronson
Participant
This thread basically describes the problem i am having also. My board is headless so i need to figure out how to program the EEPROM without a display port. I took a guess and ordered a USB to UART adapter –
Maybe that will get me into the EEPROM.
My board also has built in RS232 that maps to UART0 so maybe i can get to it using a USB to RS232 cable and Putty. I’m not completely sure so i thought i would post here to see if anyone had some other suggestions.
- February 27, 2018 at 1:59 pm #4761
  Neeraj Dantu
  Moderator
  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
March 2, 2018 at 8:06 am #4827
garybronson
Participant
I have a serial connection to UART0. My device has RS232 that connects to UART0 so i used that to connect. I connected at 9600 – 8-N-1 and software flow control. I wasn’t sure what the default Baud rate was going to be in this case. I launched Putty and prints an “@” first and then the letter “B” every few seconds. Does that mean anything to anyone? I tried to type in the terminal but it doesn’t respond to anything.
- This reply was modified 6 years, 8 months ago by garybronson.
- This reply was modified 6 years, 8 months ago by garybronson.
- This reply was modified 6 years, 8 months ago by garybronson.
March 2, 2018 at 8:34 am #4831
EricT
Participant
baud rate is 115200 if you made it to the UART bootloader you should be getting a ‘C’ every few seconds.
March 2, 2018 at 8:55 am #4832
garybronson
Participant
That was very helpful. I am getting “C” now. Now that i have that, what’s next? Since i’m using Putty, are there any special settings i need to make in the Putty configuration to allow me to run commands?
- March 2, 2018 at 10:51 am #4835
  Neeraj Dantu
  Moderator
  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
March 2, 2018 at 11:31 am #4836
garybronson
Participant
Oh. I misundertood i guess. I assumed i needed to connect to UART0 so i can write an ID to the EEPROM. I thought that was an option rather than patching images or boot loaders. Doing that seemed like a harder task to accomplish. So the only thing i accomplished here is to verify that the processor is working. I’ll look at the other options you provided.
March 2, 2018 at 11:35 am #4837
garybronson
Participant
I just had a quick look at the provided links. It looks like i have to get down into the weeds to make this thing boot.
So, there is no easier way to do this?
- March 2, 2018 at 11:43 am #4838
  Neeraj Dantu
  Moderator
  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.
March 2, 2018 at 11:45 am #4839
garybronson
Participant
What happens when i want to try a new BB Image later on? Do i or my customers need to go through this process every time or does the U-boot remain loaded locally?
- March 4, 2018 at 8:05 pm #4851
  Neeraj Dantu
  Moderator
  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.
March 2, 2018 at 5:01 pm #4843
garybronson
Participant
I went through the procedure to bypass the EEPROM. The procedure assumed a lot but i got through most of it. I installed an Ubunto VM and then figured out i needed to search for Terminal to run those commands that were listed. Then found out i had to install wget and git. I got up to step 5 and ran into a problem. I attached what was displayed in the terminal. Maybe i was supposed to change to a different directory or something. I’m a Windows guy so the direction needs to be fairly clear. Using ubuntu in a VM was painful to navigate but i have to do this.
- This reply was modified 6 years, 8 months ago by garybronson.
Attachments:
1. error.jpg
- March 5, 2018 at 10:45 am #4857
  Neeraj Dantu
  Moderator
  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
March 5, 2018 at 9:07 am #4853
garybronson
Participant
I am having a problem with these steps
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}
Do you have any tips?
- March 5, 2018 at 10:32 am #4856
  Neeraj Dantu
  Moderator
  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
March 5, 2018 at 2:32 pm #4865
garybronson
Participant
I’m afraid it made no difference. I also created a new VM using Virtualbox because my first VM was in VMWARE VSphere and i could not gain access to the SD card. The VM that I created in Virtualbox gave me SD Card access but i had the same “no such file or directory” error when running the command. I can use pwd by itself and it will print the current working directory.
When i run this –
export CC=?pwd?/gcc-linaro-6.4.1-2017.11-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-
and then run this to check it –
${CC}gcc –version
I get the error
I even typed in the full path instead of using ‘pwd’
I looked in the bin directory and there is no directory with the name “arm-linux-gnueabihf-”
I’m not sure what the purpose of the export is but it looks like its creating a variable called “CC” that is used in the calls to compile
- This reply was modified 6 years, 8 months ago by garybronson.
October 26, 2019 at 11:00 am #9295
rogerlucas
Participant
Hello guys, even with this approach or Robert Nelson patch is it still necessary to configure eeprom?
static inline int board_is_bone_lt(void)
{
return 1;
}
Is there any alternative for those who will need to do a large scale production?
Regards.
- October 28, 2019 at 11:40 am #9317
  Neeraj Dantu
  Moderator
  Roger,
  In addition to Eric’s inputs, if you are not planning to update the bootloader, or if you plan to make this modification for future revisions of the bootloader, there is no need to program the EEPROM.
  The advantage of having the EEPROM programmed is that the board will be able to run Beagle distros out of the box, while this modification will be required if the EEPROM is not programmed.
  Best,
  Neeraj
- October 28, 2019 at 11:55 am #9319
  rogerlucas
  Participant
  Thank you very much. I will opt for the modified u-boot because the device will only run its own OS.
October 28, 2019 at 8:21 am #9305
EricT
Participant
Hi RogerLucas, It would depend on what your “large scale production” is. If it’s your own product and no one will be trying to run different distos or whatevers on it, the methods discussed in this thread should be fine.
Otherwise you will have to program the EEPROM either externally or create some code to do it (as long as the EEPROM write protect line is not enabled)
- October 28, 2019 at 11:52 am #9318
  rogerlucas
  Participant
  Thank you very much for your attention in replying.
September 15, 2020 at 12:12 pm #10759
LoriNagle
Participant
Hello. Is there anything extraordinary that we ought to design in u-boot “bootcmd” or different contents that will let uncovered OSD module (exposed am3358 withouth cpsw, usb center point and with void EEPROM) to appropriately stack Linux/DTB into RAM and begin booting ? We saw that in U-boot there is no local help for pocket beagle or remote beagle bone buth in Linux part there are extraordinary setups for portion assemble.
- October 8, 2020 at 3:59 pm #10843
  Neeraj Dantu
  Moderator
  Lori,
  The pocketBeagle bootcmd supports generic functions loading the kernel and device tree. You can halt the boot process during U-Boot countdown and explore the bootcmd by using printenv.
  Best,
  Neeraj
September 26, 2020 at 12:42 am #10786
Eshtaartha Basu
Moderator
Hello LoriNagle,
Can you please elaborate on what you’re trying to do or what issue you’re facing?