On Wed, 27 Mar 2013, Graeme Russ wrote:
On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre <nico(a)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(a)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
>> >> 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>
>> >> [<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.
>> > limited to the functionality provided by the firmware provided. FIT is
>> > 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
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
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
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.