Through Fedora 18 GA we've had a one-to-one mapping between the SoC and the kernel rpm. Likewise, we produced a different filesystem image for each SoC (EG, a highbank image, a panda image, a trimslice image, etc). Since then the unified kernel in 3.7 and beyond has introduced the ability to use a single kernel for multiple SoCs. This introduces the pleasant prospect of having a single filesystem image that boots on multiple ARM platforms. In fact, the standard unified kernel for F19 (3.9) may support highbank, omap, and versatile express all from the same vmlinuz. Doing this still requires loading the right dbt, but I have a plan for that. Doing this also requires creating a uImage with the right load address, IE:
mkimage -A arm -O linux -T kernel -C none -a $ubootAddress
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?
Hi Brendan,
I may be way of the mark with my suggestions as I am not that familiar with ARM, but here goes:
On Wed, Mar 27, 2013 at 10:39 AM, Brendan Conoboy blc@redhat.com wrote:
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:
- 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.
- Generate multiple uImage files from a single kernel, then load the
appropriate uImage on boot.
- 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?
4. Relocatable kernel (like x86)
5. Have U-Boot process uImage to adjust for load location (U-Boot already does a similar thing for itself)
Regards,
Graeme
On 03/26/2013 04:49 PM, Graeme Russ wrote:
- 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.
- 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.
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
- 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.
- 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.
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)
Regards,
Graeme
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
- 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.
Hi Brendan,
On Wed, Mar 27, 2013 at 11:20 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
- 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?
Ah, I think I get it now. The x86 relocatable kernel is truly relocatable - the kernel itself figures out where is has been loaded and performs some adjustments
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)
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
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
Regards,
Graeme
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.
Hi Brendan,
On Wed, Mar 27, 2013 at 11:34 AM, Brendan Conoboy blc@redhat.com 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
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.
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy blc@redhat.com 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
Regards,
Graeme
I feel we gain the greatness of unified kernel but we make separate images that handle the u-boot quirks. We push down the stack so to speak. The only diff of each image being load addr's.
The exynos5 kernel requires FIT images, so an extra dimension of complexity. Well, at least for chromebook. Anyhow, fit images is a move in the right direction but not all u-boot support that so....
The problem statement is different u-boot are different, and we cannot have unified images.
We have a rootfs and make images for boards based on uboot quirks. Lucky if we can simplify load addr's, but we just have to test.
-Jon Disnard Fas: parasense Irc: masta On Mar 26, 2013 8:31 PM, "Graeme Russ" graeme.russ@gmail.com wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy blc@redhat.com 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
Regards,
Graeme _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 27 Mar 2013 03:24, "Jon" jdisnard@gmail.com wrote:
I feel we gain the greatness of unified kernel but we make separate
images that handle the u-boot quirks. We push down the stack so to speak. The only diff of each image being load addr's.
The exynos5 kernel requires FIT images, so an extra dimension of
complexity. Well, at least for chromebook. Anyhow, fit images is a move in the right direction but not all u-boot support that so....
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.
We have a rootfs and make images for boards based on uboot quirks. Lucky
if we can simplify load addr's, but we just have to test.
On Wed, 27 Mar 2013, Peter Robinson wrote:
On 27 Mar 2013 03:24, "Jon" jdisnard@gmail.com 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.
Nicolas
On Wed, Mar 27, 2013 at 3:15 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Wed, 27 Mar 2013, Peter Robinson wrote:
On 27 Mar 2013 03:24, "Jon" jdisnard@gmail.com 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.
The tool is not mkimage, it does likely use mkimage underneath though, it's a ncurses menu which allows you to select the device you have and it generates the correct bits for boot. Whether Hans generates all the mkimage options before hand and just copies the right one into place or generates them on the fly I'm not 100% sure.
Peter
On Wed, 27 Mar 2013, Peter Robinson wrote:
On Wed, Mar 27, 2013 at 3:15 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Wed, 27 Mar 2013, Peter Robinson wrote:
On 27 Mar 2013 03:24, "Jon" jdisnard@gmail.com 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.
The tool is not mkimage, it does likely use mkimage underneath though, it's a ncurses menu which allows you to select the device you have and it generates the correct bits for boot. Whether Hans generates all the mkimage options before hand and just copies the right one into place or generates them on the fly I'm not 100% sure.
Good. My point is that mkimage, if needed, should be run at installation time, and not to produce a distributable kernel.
Nicolas
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy blc@redhat.com 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.
Nicolas
Hi Nicolas
On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy blc@redhat.com 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? With the recent unification of SPL and some massive architectural changes to bringing all the arch's together in common code, there are many benefits to 'moving on' from uImage.
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)
Regards,
Graeme
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Nicolas
On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre nico@fluxnic.net wrote:
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy blc@redhat.com 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).
IMHO this is the wrong direction to take for a distribution. If you start bundling things together in a FIT image, you'll end up distributing one such image per supported target which is I believe what you wish to avoid in the first place.
The FDT has far more differences per device than just the load address. It is not recommended to "adjust" the FTD from U-Boot to cater for those differences. Instead, it would be much better to simply have a suitable FDT stored in a separate flash partition for U-Boot to load without fiddling.
If the target _requires_ a uImage or a FIT image, then the bundling tool should be used at _installation_ time, not for the purpose of distribution.
Then, a single zImage for many targets may be distributed, and that's all you need to provide when distributing kernel updates.
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?
Laziness. It wasn't that long ago when those "everyone" shipped ancient kernels with their most recent devices too. I know that as I did work for one of those companies and fought to change that.
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)
... or just use a plain zImage, which they already do in most cases.
Nicolas
Hi Nico, Graeme,
On 03/27/2013 11:01 AM, Nicolas Pitre wrote:
On Wed, 27 Mar 2013, Graeme Russ wrote:
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).
IMHO this is the wrong direction to take for a distribution. If you start bundling things together in a FIT image, you'll end up distributing one such image per supported target which is I believe what you wish to avoid in the first place.
I'm with Nico on this. We don't want to do Ubuntu-style hardware packs and tailor per-board in the longer term any more than we need to. I would favor just loading the kernel zImage (which is more than the kernel anyway, it's also got the uncompressor, and it's the same concept as how we boot x86) and having the specifics of where that is loaded handled by U-Boot.
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.
Jon.
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.
I mentioned already that I favor ignoring the uImage header and just loading the kernel where we know it needs to be.
But U-Boot will fight against you nevertheless. Irrespective of where in RAM you ask it to load a uImage, it will still relocate it according to the address provided in its header before executing the kernel.
I agree that the easiest way to do that is to drop uImage loading and do zImage.
Nicolas
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.
Jon.
On Wed, 27 Mar 2013, Jon Masters wrote:
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.
It is not a branch limit. The zImage decompressor simply masks the pc register with 0xf8000000 to determine the start of RAM, hence the 128MB restriction. That mask was selected to cover all the possible RAM start addresses encountered so far, and we believe that no one is going to produce a system with a smaller alignment for RAM.
Bootloaders can branch into the kernel at any address since they use absolute branches for that.
Nicolas
On 27 Mar 2013 01:31, "Graeme Russ" graeme.russ@gmail.com wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy blc@redhat.com 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
Not to the devices shipped with uboot in firmware. Some of the Marvell shipped uboots date back to early 2009.
Regards,
Graeme _______________________________________________ arm mailing list arm@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 default uImage, load a separate uboot header overwriting the first 64 bytes of RAM.
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
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, but let's take tally:
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 uImage for it then use bootz on everything else.
On 27 Mar 2013 05:12, "Brendan Conoboy" blc@redhat.com wrote:
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,
but let's take tally:
Highbank has it. Trimslice (2012 firmware) has it VExpress doesn't have uboot OMAP/Beaglebone? Dennis?
If it doesn't we should be able to enable it.
Arndale? Armada XP does *not* have it
Sigh!
Anything else?
I'd be interested if any if the imx and a1x boards had it.
If Armada XP is the only board that doesn't support bootz we can make a
uImage for it then use bootz on everything else.
-- Brendan Conoboy / Red Hat, Inc. / blc@redhat.com _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Tue, 26 Mar 2013, Brendan Conoboy wrote:
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, but let's take tally:
Highbank has it. Trimslice (2012 firmware) has it VExpress doesn't have uboot
Recent versions of Boot Monitor for VExpress do support the loading of zImage (not uImage) and FDT natively already.
OMAP/Beaglebone? Dennis? Arndale?
Those should be recent enough to have it, or be well supported enough in mainline U-Boot for an upgrade.
Armada XP does *not* have it
Shame Marvell for that. They are still learning.
Nicolas
On 27 Mar 2013 03:38, "Nicolas Pitre" nico@fluxnic.net wrote:
On Tue, 26 Mar 2013, Brendan Conoboy wrote:
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.
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.
Can you substantiate "recent enough"? The bootz option was in my mind but I have no recollection of how recently it was introduced.
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Wed, 27 Mar 2013, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 11:20 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/26/2013 05:04 PM, Graeme Russ wrote:
Hi Brendan,
On Wed, Mar 27, 2013 at 10:54 AM, Brendan Conoboy blc@redhat.com wrote:
On 03/26/2013 04:49 PM, Graeme Russ wrote:
- 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?
Ah, I think I get it now. The x86 relocatable kernel is truly relocatable - the kernel itself figures out where is has been loaded and performs some adjustments
The ARM kernel zImage does that too. It is the uImage wrapping that U-Boot used to impose on it that insists on absolute load addresses.
At least with zImage and the bootz command, you can store the load address in the U-Boot environment where it belongs.
Nicolas
-
Brendan Conoboy -
Graeme Russ -
Jon -
Jon Masters -
Nicolas Pitre -
Peter Robinson