Custom board in Limbo State

[ashare]

Hi,

We have built a custom board based on the BBBW using OSD335x-SM and TI’s Wilink module. We have fabricated over 100 boards and have used a patched version (Robert Nelson’s patch) of u-boot for overriding the EEPROM check. Later, we programmed the EEPROM with the board code for BBBW and this method has worked fine for us for the entire batch except for a couple of boards. We noticed that 2 boards encountered some issue when we tried to write values to the EEPROM from the serial console. The console froze in between and we reset the boards to repeat the process. After restarting the boards, nothing was printed on the serial console. To ensure that the board was otherwise fine, we removed the SD card from the slot and turned the board on. It printed a continuous string of ‘C’s which is indicative of a live processor.

To dig further into the problem, I downloaded a u-boot-spl.bin-am335x-evm to boot via UART. I sent the bin file via Teraterm in XMODEM mode and ended up with the following error message on the console:

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC U-Boot SPL 2013.10-g78d8ebd (Mar 30 2014 - 20:46:34) Unknown board, cannot configure pinmux.### ERROR ### Please RESET the board ###

1 2 3

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC U-Boot SPL 2013.10-g78d8ebd (Mar 30 2014 - 20:46:34) Unknown board, cannot configure pinmux.### ERROR ### Please RESET the board ###

To understand further, I tried the UART booting on two more boards – one with EEPROM unprogrammed and the other which is correctly programmed with the BBBW board code. The unprogrammed board showed an error saying that the ‘magic number’ was missing, which is expected. The programmed board did not show any error and waited for the u-boot.img image by printing string of ‘C’s.

Based on the above experiments, I suspect that the two boards which are stuck in a limbo state might have a wrong/incomplete version of the board code programmed via serial, possibly due to a loose connection, but what is surprising is that the patched version of the u-boot is supposed to ignore the board code or fool the board into believing it is a BBB. Am I missing something here? Can you suggest some procedure to revive the boards from this state? I do not have physical access to the I2C lines or the USB bus.

Thanks for reading and appreciate any help in solving this issue.

• This topic was modified 4 years, 11 months ago by ashare.

[Neeraj Dantu]

Hey ashare,

One possibility is a non functional I2C interface between the processor and the EEPROM. The applied patch linked above checks if the EEPROM is dead(https://github.com/trini/u-boot/blob/master/board/ti/common/board_detect.c#L287) and that might be causing u-boot to not detect the board as a blank EEPROM board. You could bypass the check in the function by hard-coding the board detection process as shown in section 4 of the EEPROM App note(https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/).

You can also try a readily available blank image from https://rcn-ee.com/rootfs/bb.org/testing/2018-10-07/stretch-iot/.

Please let us know if that helps or if you have more questions.

Best,

Neeraj

[ashare]

Hi Neeraj,

Thank you for your reply. Just to avoid confusion, let me make it clear that I have followed section 4 of the EEPROM App note and have created a version of u-boot which proceeds booting with a blank EEPROM. Hence my reference to Robert Nelson’s patch in my initial post. Are you saying that before detecting the I2C as blank the program might be probing the line and since there could be a possibility that the I2C link between the EEPROM and the processor might have gone bad, the program halts the boot? I can try to completely remove the detection code from u-boot. Can I use the blank image in the link you provided to accomplish the above? I will check and report back soon.

On the same note, I am curious to know why the I2C link would go bad on a new chip like this if at all that is the case. Have you or any of your users encountered such an issue before?

Thank you.

[Neeraj Dantu]

Hi ashare,

Apologies for the confusion. Section 4 offers 2 methods for bypassing the EEPROM check. In 4.1, it is shown to be done by changing the contents of the function “board_is_bone_lt”. In section 4.2, the patches you referred to are used. I was referring to the hard-coding method described in section 4.1.

If you are using the patched version of u-boot, the function “board_is_blank_bone_lt()” in  https://raw.githubusercontent.com/RobertCNelson/Bootloader-Builder/master/patches/v2018.03-rc1/0002-NFM-Production-eeprom-assume-device-is-BeagleBone-Bl.patch should return true. Going through this function, it looks like there is a check on whether the EEPROM interface is working. If the check returns false, u-boot might not be able to advance to the board initialization. In addition to that, you mentioned that you encountered a failure in the middle of the programming of the EEPROM. At this point, this is just a theory. If you can try the hard coding method described in section 4.1, we should be able to find out whether this is the failure point.

We have not encountered an issue like this before. It’s important to keep in mind that this is a theory based on u-boot behavior and there might be something else causing the issue. Please let us know how your debugging efforts go!

Best,

Neeraj

[ashare]

Neeraj,

I followed the method outlined in 4.1 and I was able to boot the board. Later, I used the u-boot command line to write the correct values in the EEPROM. I guess the EEPROM was corrupted in the first attempt which prevented booting because the corrupted board code was not defined anywhere in the u-boot code. Robert Nelson’s code only adds a blank EEPROM into the list, does not completely avoid the check as you pointed out. Thank you for helping.

[Neeraj Dantu]

Thanks for the update! Happy to help

Neeraj

[Author]

Posts