On 03/26/2013 05:26 PM, Graeme Russ wrote:
I just realised I got this a bit wrong - mkimage make a U-Boot image
with a header which contains the kernel load address. Not sure what
mkimage does to the Linux kernel binary itself
The kernel binary is left intact. Only a 64 byte header is prefixed.
That would make more sense (This was my understanding as well, actually),
but we're still having an issue: The uImage header, stored in RAM, has a
load address that is wrong for some platforms. Unless we're going to change
that with an in-uboot memory editor, bootm will honor the address in that
header and the boot will fail.
I think this is worth raising on the U-Boot ML
Perhaps so. Meanwhile, your message did get me thinking. Here is a
hypothetical mkimage command line:
mkimage -A arm -O linux -T kernel -C none -a 11223344 -e 55667788 -n
VERSION -d vmlinuz-3.9.0-0.rc3.git1.4.fc19.armv7hl uKernel
Running hexdump on the kernel shows the uboot header:
hexdump -C < uKernel | head
00000000 27 05 19 56 97 0b b9 5e 51 52 3c 77 00 47 e8 f0
|'..V...^QR<w.G..|
00000010 11 22 33 44 55 66 77 88 f2 d9 f3 9c 05 02 02 00
|."3DUfw.........|
00000020 56 45 52 53 49 4f 4e 00 00 00 00 00 00 00 00 00
|VERSION.........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
17-20: The value from -a
21-24: The value from -e (Typically we use the same -a and -e)
32-64: The value from -n
We could create a number of uboot headers. Then after loading the
default uImage, load a separate uboot header overwriting the first 64
bytes of RAM.
--
Brendan Conoboy / Red Hat, Inc. / blc@xxxxxxxxxx
_______________________________________________
arm mailing list
arm@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
