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

Cabral, Kevin Kevin.Cabral at gdcanada.com
Thu Dec 9 18:51:19 CET 2004


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.





More information about the U-Boot mailing list