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