Hi Brendan, On Wed, Mar 27, 2013 at 11:34 AM, Brendan Conoboy <blc@xxxxxxxxxx> wrote: > 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. I've had a quick glance at the U-Boot source and I think the newer 'FIT' image may be a better path to follow. In common/image.c you will find fit_image_get_load() and in common/cmd_bootm.c you will find bootm_start() and bootm_load_os(). Teasing apart these functions, it looks like fit_image_get_load() looks for a "load" property (FIT_LOAD_PROP) in the FDT first, then in the FIT image (if the FDT returns a NULL load address). Now you can set properties in the FDT in U-Boot (fdt set <path> <prop> [<val>]) So have a common FIT image with a common FDT and use U-Boot to tweak the FDT properties such as the kernel load address Regards, Graeme _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
