Hi,
Am Dienstag 27 März 2012, 13:05:05 schrieb Prafulla Wadaskar:
I removed the hardcoded values from the environment and put it into a special rescue mode, so it won't show up until the user is explicitly choosing that mode. I can understand, that hardcoded values are bad but in this case i cannot think of any other (easy and reliable) way to get access to a misconfigured linkstation.
Do you have any other idea? again, the only interfaces you have are ethernet, one button, two (multiple color leds), one switch with three positions [and an usb port, only available on older linkstations].
You need special environment variables by default, u-boot development policy does not allow this, so you can have clean code mainlined and keep this customization patch private to you. This is what I think the solution could be :-(
Wolfgang, what do you think about relaxing this policy a bit and allowing this class of devices (no service port/serial port available, no storage for the MAC address besides the environment) to use hardcoded values (maybe defined in a place common to all boards). Again, i don't think my device is the only one with this problem.
mh? the lschlv2_ramboot is just for testing purposes. So you can try the bootloader without actually overwriting it in the boot flash. The actual images are the lschlv2 and lsxhl targets. I guess i should add a lsxhl_ramboot, too. There was no need for the latter because i have a jtag connector on my lsxhl (but not on the lschlv2).
AFAIK, for ram boot you need u-boot ELF image, you can use u-boot.bin but u-boot.kwb image cannot be used for boot from RAM, kwbimage.cfg helps to create u-boot.kwb target which is useless for boot from RAM use case. So you need to remove it.
The elf/bin is just for testing and the kwb image will be written into the spi flash, i need both (at least i need the kwb image). I could remove the ramboot target, but i think its really handy if someone likes to play with a self compiled uboot.