The trouble is, there is no unified $ubootAddress available. The pandaboard uses 0x80008000, highbank and tegra use 0x00008000, a10 and exynos5 use 0x40008000, and so forth. Not sure about beaglebone. If we want to realize the dream of having a unified F19 release we need a solution to this problem. I see three options: 1. Use the 0x00008000 address for highbank/tegra, demand bootz support for everybody else. Since we control the panda/beagle/beaglebone uboots they would be covered. Not clear on what this means for exynos5, but exynos5 will use an LPAE kernel so that's a separate uimage already. 2. Generate multiple uImage files from a single kernel, then load the appropriate uImage on boot. 3. Split up images to cope. All 3 are viable, none are desirable. Is there a 4th option? If not, what do want to go with?

On 03/26/2013 04:49 PM, Graeme Russ wrote: > > 4. Relocatable kernel (like x86) If I understand correctly it already is relocatable. This is simply the address that uboot is instructed to load the kernel into memory at.

> 5. Have U-Boot process uImage to adjust for load location (U-Boot > already does a similar thing for itself) Likewise, this is the address uboot is instructed to load the kernel at. My naive understanding is that uboot loads the header, analyzes it, then loads the rest of the file based on the content of that header. If the header instructs uboot to load the kernel into non-existent memory it not operate correctly.

On 03/26/2013 05:04 PM, Graeme Russ wrote: > > Hi Brendan, > > On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy <blc(a)redhat.com&gt; wrote: >> >> On 03/26/2013 04:49 PM, Graeme Russ wrote: >>> >>> >>> 4. Relocatable kernel (like x86) >> >> >> If I understand correctly it already is relocatable. This is simply the >> address that uboot is instructed to load the kernel into memory at. > > > So why worry? Just have the load address in the U-Boot environment. Because uboot's bootm does not handling the relocation?

> Not 100% sure the mechanics of U-Boot loading an ARM kernel but I > think it just loads it blindly where it is told to (i.e. does not > analyse the header)

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.

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.

On 03/26/2013 06:09 PM, Graeme Russ wrote: > > 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 I'd love to, but we don't ship uboot for a number of our boards. We are limited to the functionality provided by the firmware provided. FIT is not universal.

I feel we gain the greatness of unified kernel but we make separate

The exynos5 kernel requires FIT images, so an extra dimension of

The problem statement is different u-boot are different, and we cannot

We have a rootfs and make images for boards based on uboot quirks. Lucky

On Wed, 27 Mar 2013, Peter Robinson wrote: > On 27 Mar 2013 03:24, "Jon" <jdisnard(a)gmail.com&gt; wrote: > > The problem statement is different u-boot are different, and we cannot > > have unified images. > > Yes we can, we just need a tool to adjust the uboot bit like Han's tool for > the A1x devices. Its less ugly than multiple images which are even less > workable. That tool is called 'mkimage'. You grab a universal zImage, and use mkimage on it at installation time to adjust it to the U-Boot runtime environment where it is installed. Morale of this story: including mkimage (aka "make uImage") as part of the kernel build process was a mistake. It has sent the wrong message to people, presenting uImage as the distributable build product which it is not.

Hi Brendan, On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy <blc(a)redhat.com&gt; wrote: > On 03/26/2013 06:09 PM, Graeme Russ wrote: >> >> 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 > > > I'd love to, but we don't ship uboot for a number of our boards. We are > limited to the functionality provided by the firmware provided. FIT is not > universal. Well at least you can have a common image for all U-Boot boards :) I suppose the 64-byte header per-board would work. Ugly, but not as ugly as some of the other options. You could also make a small mod to U-Boot to allow the load address of legacy images to be changed via a command to make the hack slightly less ugly

Hi Nicolas On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre <nico(a)fluxnic.net&gt; wrote: > On Wed, 27 Mar 2013, Graeme Russ wrote: > >> Hi Brendan, >> >> On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy <blc(a)redhat.com&gt; wrote: >> > On 03/26/2013 06:09 PM, Graeme Russ wrote: >> >> >> >> 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 >> > >> > >> > I'd love to, but we don't ship uboot for a number of our boards. We are >> > limited to the functionality provided by the firmware provided. FIT is not >> > universal. >> >> Well at least you can have a common image for all U-Boot boards :) >> >> I suppose the 64-byte header per-board would work. Ugly, but not as >> ugly as some of the other options. >> >> You could also make a small mod to U-Boot to allow the load address of >> legacy images to be changed via a command to make the hack slightly >> less ugly > > What about simply using zImage directly? U-Boot has supported the bootz > command for quite a while now. > > I've beel claming for _years_ that the uImage file format is broken. > But Mr U-Boot would not hear it. You mean the _legacy_ image format, not the newer FIT image format? Using FIT you should be able to bundle a unified uImage, initramfs and FDT. You can then edit the FDT within U-Boot for device specific parameters (like load address).

It still astounds me that new devices are shipped with U-Boot 1.1.4 which is well over five years old! Why is it that everyone ships with a recent kernel and file system but sill insist on shipping ancient U-Boot?

And as for non-U-Boot devices, why not either: a) Migrate to U-Boot b) Copy the FIT image code from U-Boot into the existing bootloader (providing GPL compatibility is not an issue) c) Implement support for the FIT format from scratch (it's not that complex)

Prior to Brendan sending that mail last night, we had an internal RH meeting wherein this topic came up (and precipitated the email). I explained already in that and will repeat here that the ARM kernel is already relocatable. It has only two major requirements right now: 0). That it be loaded into actual RAM somewhere. Most boards direct map physical RAM at 0. Some do it at 2GB or higher. Others have aliasing where you see physical RAM in two ranges and other weirdness. The reason we have these different load addresses today is that the hardware platforms are not all consistent around physical map. 1). That it be loaded at sufficient alignment (low-order bits 0x8000 due to the exception vectors). Maybe that one even can/could/is handled by the uncompressor. I dunno if that limitation is relaxed somewhere.

I mentioned already that I favor ignoring the uImage header and just loading the kernel where we know it needs to be.

I agree that the easiest way to do that is to drop uImage loading and do zImage.

On 03/27/2013 11:26 AM, Nicolas Pitre wrote: > On Wed, 27 Mar 2013, Jon Masters wrote: > >> Prior to Brendan sending that mail last night, we had an internal RH >> meeting wherein this topic came up (and precipitated the email). I >> explained already in that and will repeat here that the ARM kernel is >> already relocatable. It has only two major requirements right now: >> >> 0). That it be loaded into actual RAM somewhere. Most boards direct map >> physical RAM at 0. Some do it at 2GB or higher. Others have aliasing >> where you see physical RAM in two ranges and other weirdness. The reason >> we have these different load addresses today is that the hardware >> platforms are not all consistent around physical map. >> >> 1). That it be loaded at sufficient alignment (low-order bits 0x8000 due >> to the exception vectors). Maybe that one even can/could/is handled by >> the uncompressor. I dunno if that limitation is relaxed somewhere. > > The decompressor code takes care of that already. If you compile your > kernel with CONFIG_AUTO_ZRELADDR=y then all you need is to load the > zImage within the first 128MB of physical RAM. Good to know. Then we're not specifically stuck with any special alignment requirements as long as we load within the branch limit.

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.

On 03/26/2013 08:38 PM, Nicolas Pitre wrote: > > If uImage is a problem, just don't use it, period. Problem solved. All > the targets supported by the unified kernel are recent enough to have > bootz support in their U-Boot source. Please use that. Is bootz supported everywhere we need? I was under the impression not,

Highbank has it. Trimslice (2012 firmware) has it VExpress doesn't have uboot OMAP/Beaglebone? Dennis?

Arndale? Armada XP does *not* have it

Anything else?

If Armada XP is the only board that doesn't support bootz we can make a

-- Brendan Conoboy / Red Hat, Inc. / blc(a)redhat.com _______________________________________________ arm mailing list arm(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm

On Tue, 26 Mar 2013, Brendan Conoboy wrote: > We could create a number of uboot headers. Then after loading the

> uImage, load a separate uboot header overwriting the first 64 bytes of

Please don't engage in those senseless games just to work around a stupid restriction of the uImage file format. If uImage is a problem, just don't use it, period. Problem solved. All the targets supported by the unified kernel are recent enough to have bootz support in their U-Boot source. Please use that.

Or, consider the mkimage process as part of the kernel _installation_ procedure and not a pre-distribution step. But if I were you I'd go the bootz route for its simplicity. Nicolas _______________________________________________ arm mailing list arm(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm