[PATCH 0/3] patches to allow DTB to be appended to the ARM zImage

[Arnd Bergmann]

On Sunday 12 June 2011 16:34:28 Russell King - ARM Linux wrote:
> I don't think you're considering real-world usage scenarios, but instead
> concentrating on the use issues.  If you only do that you're boxing
> yourself into a corner and will cause a world of pain for folk who would
> just like the kernel to be usable.
> 
> The information in ATAGs which will either never be in DT or which should
> override what is in DT is:
> 
> - memory parameters
> - command line
> - initrd location
> - system serial number
> - system revision number

With a device-tree aware boot loader, this is exactly the kind of
information that should be put in the device tree by the boot loader,
along with other parts like local-mac-address and actual presence
of optional devices where the kernel might not have a generic way
of probing whether they are there.

> This is the kind of information which should override whatever is in
> DT because the DT contained information could well be wrong or outdated,
> and its not the kind of information that anything other than core code
> should be dealing with in any case.

Of course it should override the device tree, I'm not arguing that.
All I'm saying is that we don't need to special-case this or support
both formats once the kernel is there as long as we move the information
into appropriate DT-representation of the same data.

The attributes you are looking for are for the information you listed:

/memory/*
/chosen/bootargs
/chosen/linux,initrd-{start,end}
/serial-number
/compatible

PowerPC was facing the exact same problem, see arch/powerpc/boot/main.c
for the solution used there. The way that the boot entry point on powerpc
works is to have a boot-protocol specific entry from which all the
necessary information is taken and then put into a flattened device tree
either built from scratch (in case of real OF) or patched into a prebuilt
device tree. From there we pass the flattened device tree with all the
correct information into the actual boot stage. In some cases, the entry
points are identical and we just jump back to the start with the updated
information.

Having a complete and correct device tree is essential for instance to make
kexec work, because the new kernel will only have the information from
the device tree available but not have access to atags, uefi of open
firmware.

It may be a good idea to preserve the atags in a new property in the
device tree, so we are able to inspect them later.

	Arnd