[PATCH RESEND] ARM: add dtbImage.<dt> and dtbuImage.<dt> rules

[Russell King - ARM Linux]

On Tue, Oct 01, 2013 at 12:41:15PM +0200, Maxime Bizon wrote:
> But for devices in the field for which upgrading the booloader is not
> an option, neither is changing anything else in the boot process
> (anything before linux starts). The risk of bricking the device is
> just too high.

Well, how does the kernel get on to these devices in the field?  Is
it burned into the flash using some laser type device, or does it
involve running some kind of a script?

If it's running a script, then that script can be modified.  The script
can take the generic zImage, and it can identify what the target hardware
is, and it can pick the appropriate DT image to append to the kernel
and then create whatever format your target uboot wants (whether that
be the new format or the uImage format.)

I'm not sure why people think this is soo difficult.  I've had my build/
boot system doing that since OMAP4 went DT only.  I'm now using it on the
Cubox-i Carrier-1 board.  I'm doing it manually there - concatenating the
kernel and DTB and then using mkimage.

If you really must have all the DT blobs as part of the kernel and select
one at boot time, that's precisely where having the kind of solution
Nicolas is suggesting comes in.

We can't keep augmenting the kernel build system with every different
magic way to generate the final platform image - it's got to the point
where there are just _far_ too many different options and to keep
adding more and more is getting really stupid.

Remember too that the plan is to drop the DT files from the kernel
tarball and maintain them in a separate _external_ tree to the kernel.
This means that any "solution" we merge today which allows you to build
a "final platform image" out of a DT file plus the zImage will only
need to be removed again when that happens.  It's far better not to
encourage these lazy methods which will only end up causing us kernel
developers more pain in the future.