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.
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.
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields