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

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

[Cabral, Kevin]

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.

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

[Wolfgang Denk]

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/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

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

[Cliff Brake]

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

-- 
=======================
Cliff Brake
http://bec-systems.com

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The human race is faced with a cruel choice: work  or  daytime  tele-
vision.

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

[Cliff Brake]

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).

-- 
=======================
Cliff Brake
http://bec-systems.com

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

[Wolfgang Denk]

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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ernest asks Frank how long he has been working for the company.
        "Ever since they threatened to fire me."

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

[Cabral, Kevin]

<Wolfgang Denk wrote...>
> 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.

Sorry, for not being more specific but when I try to enter the (i-boot) bootloader 
I get the i-boot prompt but then the system freezes. This would probably suggest
that part of the bootloader is corrupt but not the entire thing. Perhaps only
part of the bootloader that didn't get over written still works (i.e. Just enough
to try and load the kernel).

<Wolfgang Denk wrote...>
> 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)

Until reading this article I wasn't aware that loading u-boot into RAM was an unsupported mode of use.
Instead, I may will try loading u-boot into flash. (Thanks for the article)

<Wolfgang Denk wrote...>
> The  "protect"  stuff  is  something  that  is  intended  to  prevent
> accidental data loss by a istyped command etc. It cannot protect you
> from doing stupid things.

Thanks for the explanation of "protect" for flash in u-boot. Originally, 
I had the impression that my bootloader in flash was safe, even from 
doing stupid things, which would allow me experiment since I'm just a 
newbie at these things but I guess I learned the hard way. 

I appreciate your responses and insight. Your right, there were a couple 
of serious errors made on my part. But as you can see from my original 
post that I was aware of most of these errors; unfortunately, I wasn't 
aware of these errors before it was too late. 

Thanks for your help