On Wed, 27 Mar 2013, Graeme Russ wrote: > Hi Nicolas > > On Wed, Mar 27, 2013 at 2:29 PM, Nicolas Pitre <nico@xxxxxxxxxxx> wrote: > > On Wed, 27 Mar 2013, Graeme Russ wrote: > > > >> Hi Brendan, > >> > >> On Wed, Mar 27, 2013 at 12:13 PM, Brendan Conoboy <blc@xxxxxxxxxx> 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
