Custom Board Cycling During Linux Boot

[StephenHopkins]

We have created a custom board based on the BeagleBone Black using the OSD3358-SM. After going through the steps to bypass the EEPROM check and to write to the EEPROM using Robert Nelson’s patch, as described in the post https://octavosystems.com/forums/topic/osd3358-boot/#post-4733, Linux begins to boot, but eventually hangs up and begins the boot process over again. The following is the output I am getting over Putty:

U-Boot SPL 2018.01-dirty (Jun 21 2018 - 15:38:17)
Trying to boot from MMC1


U-Boot 2018.01-dirty (Jun 21 2018 - 15:38:17 -0600)

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: 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 44 ms (0 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 ...

At this point, it cycles and begins printing the same thing again. Do you have any suggestions about what might be wrong?

• This topic was modified 6 years, 9 months ago by StephenHopkins.

[StephenHopkins]

Nevermind, I determined the problem. I was not setting the EEPROM-WP signal low.

[Eshtaartha Basu]

Hello StephenHopkins,

From your serial log, it looks like your U-Boot is not able to write to the EEPROM because we can see that the contents of your EEPROM is all “ff”. What is happening now is that your U-Boot is detecting a blank EEPROM, it is trying to write to it but is not able to. So whenever it resets, it again detects a blank EEPROM and tries to do the same thing over and over again.

Did you ground the Write Protect pin (EEPROM_WP) while running the patch? Also, make sure you have a valid board ID in “.eeprom.txt” file.

We have a good app note on this (https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/). The app note should help you understand the process better.

[Eshtaartha Basu]

Oh! Good to know that you resolved the issue. Please let us know if you have any other questions.

[Author]

Posts