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

[Nicolas Pitre]

On Mon, 13 Jun 2011, Russell King - ARM Linux wrote:

> On Mon, Jun 13, 2011 at 10:14:07AM -0400, Nicolas Pitre wrote:
> > On Mon, 13 Jun 2011, Tony Lindgren wrote:
> > 
> > > I agree that we need to parse the user configurable ATAGs to support
> > > existing hardware properly. Otherwise we have edit the .dts for each board
> > > to change the user configurable things, which is not nice for distros.
> > 
> > You mean "existing bootloaders", right?
> > 
> > Updated bootloaders should translate user configurable information into 
> > proper DT records and pass the resulting DTB to the kernel separately.
> 
> OMAP is one of the code bases where this really matters - they have a
> _lot_ of existing platforms with boot loaders which do the ATAG stuff.
> They also have a lot of code in arch/arm that needs to be converted to
> a DT representation.

Yes, agreed.  I just wanted to make the situation clear above, so people 
aren't confused in believing that the DT data is always static.  New 
bootloaders should have the same ability to dynamically change some of 
the parameters passed to the kernel.  So the issue is not about existing 
hardware, but rather about existing bootloaders.

> With the current situation where you can have either ATAGs or DT but
> not both, they're currently facing either having to break all the
> existing platforms by ignoring the ATAGs _or_ keeping two copies of
> a considerable amount of data - one in DT form and one in its existing
> form.
> 
> At present, DT can only be used sensibly on brand new SoCs where there
> are no existing platforms with ATAG based boot loaders to worry about.
> As things stand at present, even with your patch series, existing SoCs
> have no viable path to transition to DT.

As I said, I'm now convinced that the patch adding a shim to translate 
ATAGs into DT entries should be added to this series.  I was reluctant 
initially for insentive purposes, but your argument clearly tilted the 
balance the other way.


Nicolas