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

[Nicolas Pitre]

On Thu, 21 Feb 2013, Tom Rini wrote:

> FIT isn't required.  FIT is just trying to offer a nice usability
> thing to folks.

Usability is often counter-balanced by maintenance costs.

> A point of device trees is a single image works in a
> lot of places.  FIT gives you a single file works in a lot of places.

The whole _point_ for bringing DT into the ARM land was to decouple the 
the various platform specific stuff from the kernel, and even allow 
existing distros to work on yet-to-be-created devices unchanged, just 
like X86 PC class machines.  Now you're suggesting that the kernel and 
the DT information should be glued together again.  That looks like a 
move backward to me.  Yet, having that platform stuff in plain C code as 
we had before, given it is maintained properly, is still the most 
efficient way to achieve that usability wise.

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.

> > uboot dug _itself_ into this hole.  It's uboot's problem.
> 
> A whole lot  of people dug this particular hole.  Joel is trying to
> offer up a solution that maybe makes things easier for everyone.  Or
> it gets rejected here too and distros will come up with their N
> different ways to try and provide easier experiences to the end user.

Nothing being perfect, it is probably unreasonable to think that every 
board will start shipping with complete and correct DT description, etc.  
But so is the state of FIT support right now.  That solution to make 
things easier for everyone should actually make that DT vs kernel 
separation more effective and provide better mechanisms for gluing the 
various DTBs to their respective boards, and not to glue them to the 
kernel to populate a distro filesystem with them.


Nicolas