On Thu, 9 Dec 2004 10:51:19 -0700, Cabral, Kevin Kevin.Cabral@gdcanada.com wrote:
This means that the bootm command must have tried to copy the kernel image to the load address (0x8000) specified in the tag header in uImage. Thus, overwriting flash memory. I do understand that I probably should have specified a load address and a entry point of 0xA0008000 instead of 0x8000 so that the kernel would have loaded from RAM but even making a mistake like that should not have overwritten flash memory or even protected flash memory!!!
I thought that as long as my first 3 sectors in flash were write protected that it wouldn't be able to overwrite them. Is this a bug or a known behavior of u-boot? Could someone please shed some light on why this might have happened.
I have seen this several times over the years while working on embedded systems (including U-boot on PXA255 -- I did the same thing you did). If you write random data to flash, chances are you will hit a sequence that will corrupt the flash. All "protecting" flash memory does is require a slightly more complicated sequence of write operations to unlock it.
I slightly more reliable mechanism is to gate the write strobe in hardware or some other hardware mechanism, but this is usually not practical as most modern systems use flash file systems and a run-away program could also turn off the hardware lockout mechansim.
Cliff