[U-Boot] [RFC] Kbuild support for ARM FIT images

[Nicolas Pitre]

On Thu, 21 Feb 2013, Jason Gunthorpe wrote:

> On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
> 
> > So let's stop kidding ourselves and be coherent please: either we move 
> > device specifics away from the kernel, or we keep them together.  In 
> > other words, the DT should ideally come preinstalled with the bootloader 
> > on a given board/device for distros to not even have to care about it, 
> > or we put that data back inside the kernel and dispense ourselves from 
> > all the added DT overhead entirely.  But an hybrid mixed solution like 
> > FIT is IMHO the worst of both worlds and sending a wrong message.
> 
> Just to thread jack a bit here..
> 
> We've been using DT on production embedded stuff sice about 2.6.20ish
> on PPC and now ARM. We treat the dtb as a kernel version specific
> file, much like an initrd and ensure that the kernel only ever boots
> with its proper dtb. This is based on experience that the dtbs change
> depending on the state of the drivers in the kernel, what gets
> mainlined and when, etc.

For embedded appliance product you may do as you wish.  Nobody will 
interfere in the way you develop and support your own products (as long 
as you honor the applicable licenses of course).

But here we're discussing ARM Linux distributions having to deal with 
different hardware devices.  It simply doesn't make sense to bundle 
every hardware specific data with the kernel in that context.

> Embedding this stuff into the bootloader is *not* desirable for my
> embedded scenarios. We don't use FIT (or uboot) but we do the same
> thing: a single image is constructed with the proper dtb, kernel and
> initrd, and that is what the bootloader boots.

No one is advocating to embed the DT stuff in the bootloader.  The DTB 
may be buggy and/or incomplete and being able to update it safely i.e. 
independently from the bootloader is necessary.

> Why? This is an embedded appliance product. We need to be able to
> deliver firmware upgrades that *work*. We can't brick the board
> because the bootloader and kernel get out of sync. The boot loader has
> to be *simple*, it has to boot every past, present and future kernel
> or we start taking risks that a firmware flash will end up bricking
> it.
> 
> People making dev boards and distros for them certainly have different
> requirements, but we've decided that the single image approach is the
> best for appliance style products.

Absolutely.  And in your case, DT is not bringing any benefit over the 
previous situation where everything was compiled into the kernel.  I 
suspect you're not using the multi-platform support either which is one 
of the major endeavor on ARM right now.


Nicolas