[U-Boot-Users] Overwriting protected flash memory!!!
I'm trying to experiment with u-boot as a possible replacement for my current bootloader (iboot). I've encountered a problem where u-boot is overwriting flash protected memory on my cerfcube pxa250.
This is my current situation:
I am using CerfBoard/CerfCube (PXA250):
Here is the flash layout - Bootloader = 0x0 - 0x3FFFF Flash Block 0 - Bootloader Reserved = 0x40000 - 0xBFFFF Flash Blocks 1 and 2 - Kernel = 0xC0000 - 0x1BFFFF Flash Blocks 3 - 10 (inclusive) - FS = 0x1C0000 - end* Flash blocks 11-127* (inclusive)
RAM starts at: 0xA0000000
Currently, the cerfboard has the i-boot bootloader installed in flash memory at sector 0. I've been trying to experiment with u-boot by loading it into RAM and then downloading a kernel into RAM through tftp and trying to boot from it.
These are the steps I took:
Download u-boot.bin into RAM and jump to it iboot$ download tftp:192.168.100.10 u-boot.bin 0xa0100000 iboot$ jump 0xa0100000
Now I'm successfully running u-boot. By default only sectors 0 & 1 are write protected but I need to make sure that the first 3 sectors are write protected and not just the first 2 sectors so I don't overwrite my default bootloader (iboot) and red boot partitions (sector 1 & 2). Looking at the table produced by flinfo confirms that the first three sectors of flash are read only
uboot$ protect on 1:0-2 uboot$ flinfo
On my host PC I ran mkimage to generate the tag header for my kernel: $ ./mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n "Linux 2.6.9-Cerf1" -d zImage uImage
On my target platform I downloaded the kernel image and booted from it uboot$ tftp 0xa0300000 uImage uboot$ bootm 0xa0300000 uImage
## Booting image at a0300000 ... Image Name: Linux 2.6.9-Cerf1 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 876940 Bytes = 856.4 kB Load Address: 00008000 Entry Point: 00008000 Verifying Checksum ... OK OK ## Loading Ramdisk Image at 00000000 ... Bad Magic Number resetting ...
************************************************** ** Intrinsyc Bootloader (IBoot) ** ** Copyright 2001-2003 Intrinsyc Software Inc. ** ** Version: 1.8 (Jun 11 2003) PXA255 ** ** Support: http://www.intrinsyc.com ** ************************************************** Using FFUART 24LC64 not detected! (using 000000AC) SMSC LAN91C111 Found at Address 0x04000000 Auto-negotiation result: 100BaseT Full-Duplex 0 Storing EEPROM contents in tagged format Relocating zImage from 000C0000 to A0008000 (len=00100000) Proper ARM zImage ID found. Booting... Uncompressing Linux...
invalid compressed format (err=2)
-- System haltedÿ
I just realized while writing this post that I had accidently passed in an extra argument into bootm, which was "uImage". This probably led to the error "## Loading Ramdisk Image at 00000000 ... Bad Magic Number". Regardless of this error, the default bootloader (iboot) is now corrupt and the kernel that was originally stored in flash @ 0xC0000 (sector 3) is also corrupt.
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.
Kevin,
in message 0843D0F1EEBB2E49A2156C6981B4A17E53B6BA@CGYSVW100.gdcan.com you wrote:
I'm trying to experiment with u-boot as a possible replacement for my current bootloader (iboot). I've encountered a problem where u-boot is overwriting flash protected memory on my cerfcube pxa250.
I hope you don't blame this on U-Boot, as you are doing quite a lot of things that plain wrong or are explicitely unsupported.
Here is the flash layout
- Bootloader = 0x0 - 0x3FFFF Flash Block 0
- Bootloader Reserved = 0x40000 - 0xBFFFF Flash Blocks 1 and 2
- Kernel = 0xC0000 - 0x1BFFFF Flash Blocks 3 - 10 (inclusive)
- FS = 0x1C0000 - end* Flash blocks 11-127* (inclusive)
...
in flash memory at sector 0. I've been trying to experiment with u-boot by loading it into RAM and then downloading a
This is an explicitely unsupported mode of use, and reason enough NOT to answer any of your other questions in this message. See the FAQ (http://www.denx.de/twiki/bin/view/DULG/CanUBootBeConfiguredSuchThatItCanBeSt...)
On my host PC I ran mkimage to generate the tag header for my kernel: $ ./mkimage -A arm -O linux -T kernel -C none -a 0x8000 -e 0x8000 -n "Linux 2.6.9-Cerf1" -d zImage uImage
This is plain wrong. How do you expect U-Boot to be able to load the kernel at a load address of 0x8000 when your above memory map shows clearly that there is no RAM but flash at this address?
On my target platform I downloaded the kernel image and booted from it uboot$ tftp 0xa0300000 uImage uboot$ bootm 0xa0300000 uImage
And this is wrong, too, as a second argument to "bootm" is taken as the address of a ramdisk image - which will be interpreted as 0x0000 in your case.
## Loading Ramdisk Image at 00000000 ... Bad Magic Number
Logical consequence.
** Intrinsyc Bootloader (IBoot) ** ** Copyright 2001-2003 Intrinsyc Software Inc. ** ** Version: 1.8 (Jun 11 2003) PXA255 ** ** Support: http://www.intrinsyc.com **
Using FFUART 24LC64 not detected! (using 000000AC) SMSC LAN91C111 Found at Address 0x04000000 Auto-negotiation result: 100BaseT Full-Duplex 0 Storing EEPROM contents in tagged format Relocating zImage from 000C0000 to A0008000 (len=00100000) Proper ARM zImage ID found. Booting... Uncompressing Linux...
invalid compressed format (err=2)
...
I just realized while writing this post that I had accidently passed in an extra argument into bootm, which was "uImage". This probably led to the error "## Loading Ramdisk Image at 00000000 ... Bad Magic Number". Regardless of this error, the default bootloader (iboot) is now corrupt and the kernel that was
What makes you think so? The boot messages above seem to indicate that the old boot loader came up just fine and started to load the linux kernel.
originally stored in flash @ 0xC0000 (sector 3) is also corrupt.
You mentioned that only the first 3 sectors (0, 1, and 2) are protected, and that you have the Linux kernel staruing in sector 4, which is NOT protected.
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
Of course U-Boot tried to copy the kernel to that address. What else should it do? It just did what you asked for.
have loaded from RAM but even making a mistake like that should not have overwritten flash memory or even protected flash memory!!!
There is no indication to me that any of the protected sectors were overwritten.
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
No, this is wrong. The "protect" feature in U-Boot just prevents you from accidential data loss when using the "erase" or "cp" commands. It does NOT (and usually cannot) protect you from doing stupid things, or from overwriting these areas whith some other command which creates an erase or programming sequence (like a couple of "mm" commands, or copying arbitrary binary data to that area). There are flash chips which expect a specific programming sequence written to specific addresses - these are pretty safe; there are other flash chips which are plain dump, and copying a binary file to such a flash chip may result in unexpected programing accesses.
bug or a known behavior of u-boot? Could someone please shed some light on why this might have happened.
What you see is a combination of (1) unsupported use, (2) combination of at least 2 serious user errors and (3) a poor hardware design (chosing dumb flash chips).
I'm sorry, but even if we add an AI machine to U-Boot this would not protect you in such a situation.
You got what you asked for (even if you did not ask explicitely ;-)
Best regards,
Wolfgang Denk
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
In message f96d234e04120911001d14d232@mail.gmail.com you wrote:
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
This has nothing to do with PXA255, and happens only ith certain types of flash chips. If you use for example AMD chips, then a special programming sequence must be written to special, no-consequtive addresses. It is impossible to generate such a write pattern by copying data sequentially to flash memory. Such chips are safe.
does is require a slightly more complicated sequence of write operations to unlock it.
No. Not even that. For most boards, the "protect" feature in U-Boot is only a flag that prevents certain commands from working on such "protected" flash areas. Only very few flash chips, and even fewer boards using these chips, actually use some kind of hardware protection.In most cases, just using a couple of "mm" or "mw" commands to enter the erase or program seqence is all what's needed to erase / corrupt "protected" sectors.
The "protect" stuff is something that is intended to prevent accidential data loss by a istyped command etc. It cannot protect you from doing stupid things.
I slightly more reliable mechanism is to gate the write strobe in hardware or some other hardware mechanism, but this is usually not
It is perfectly sufficient to chose a different kind of flash chips, that cannot be brought into erase or protgram mode by writing sequential data. If your hardware guys selected such a type of flash you just get what you deserve. There is no protection against bad design decisions.
Best regards,
Wolfgang Denk
On Thu, 09 Dec 2004 20:22:10 +0100, Wolfgang Denk wd@denx.de wrote:
No. Not even that. For most boards, the "protect" feature in U-Boot is only a flag that prevents certain commands from working on such "protected" flash areas. Only very few flash chips, and even fewer boards using these chips, actually use some kind of hardware protection.In most cases, just using a couple of "mm" or "mw" commands to enter the erase or program seqence is all what's needed to erase / corrupt "protected" sectors.
The "protect" stuff is something that is intended to prevent accidential data loss by a istyped command etc. It cannot protect you from doing stupid things.
Thanks for the information -- I had assumed the protect command set the lock bits (for Intel flash). Setting the CFG_FLASH_PROTECTION option may cause the lock bits to be set in the flash (did not trace through the code fully). But it is still very possible to corrupt flash as writes to a range of address will clear the lock bit (as Wolfgang pointed out).
Dear Cliff,
in message f96d234e04120912273b1f0a2b@mail.gmail.com you wrote:
The "protect" stuff is something that is intended to prevent accidential data loss by a istyped command etc. It cannot protect you from doing stupid things.
Thanks for the information -- I had assumed the protect command set the lock bits (for Intel flash). Setting the CFG_FLASH_PROTECTION
Some boards do this, most don't.
Best regards,
Wolfgang Denk
participants (3)
-
Cabral, Kevin -
Cliff Brake -
Wolfgang Denk