[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