[U-Boot-Users] Overwriting protected flash memory!!!

[Wolfgang Denk]

Kevin,

in message <0843D0F1EEBB2E49A2156C6981B4A17E53B6BA at 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/CanUBootBeConfiguredSuchThatItCanBeStartedInRAM)

> 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
: 1.  What is the possibility of this being added in the future?
In the near future, the probability is close to zero. In the  distant
future, I'll be dead, and posterity can do whatever they like... :-)
                                                              - lwall