Device tree.

[broonie@opensource.wolfsonmicro.com (Mark Brown)]

On Thu, Jul 19, 2012 at 05:32:09PM -0400, Nicolas Pitre wrote:
> On Thu, 19 Jul 2012, Ian Molton wrote:

> > * Old bootloaders cant always be replaced (ROM) or chainload (lack
> >   of flash) a newer one.

> Hence CONFIG_ARM_APPENDED_DTB.  And don't tell me that you have u-Boot 
> in ROM, in which case uImage shouldn't matter.

For most of the boards I have it doesn't matter that the bootloader is
in flash, there's no way I'm going to risk bricking the board by trying
to replace the bootloader as I've got no way to recover the board if the
bootloader fails.  There's also the fact that if the bootloader supplies
the DT it can't boot kernels that don't understand DT as the machine ID
is changed (which isn't enormously helpful).

> > If zImage is the one true way, thats fine - and I actually would prefer
> > that, I think uImages are stupid.

> > But - since its not the only way, it'd be sensible if the 'other way'
> > actually worked, or was officially made an out of tree option (thus
> > making it work again because you can concat. the .dtb file prior to
> > making the uImage.)

> Isn't that what I just showed above?

It's possible to work with it, but then it's not clear to me why we have
CONFIG_ARM_APPENDED_DTB at all since pretty much the same thing applies
to non-DT cases.