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

[Russell King - ARM Linux]

On Mon, Jun 13, 2011 at 08:24:27PM +0000, Dmitry Eremin-Solenikov wrote:
> Russell King - ARM Linux wrote:
> 
> > On Sun, Jun 12, 2011 at 05:01:22PM +0200, Arnd Bergmann wrote:
> >> 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.
> >
> > You're arguing for it to be parsed by whatever fragment of assembly code
> > we have to place around the zImage to merge it into DT.
> >
> > And yes, it's going to have to be assembly code because we don't have a
> > C environment at that point which can run in a relocatable way.
> 
> Please, again look at the cuboot stuff which is used on powerpc. It uses
> limited C environment: it's executed before kernel entry, so it can use
> stack, etc. as setup by the bootloader.

Boot loaders don't pass a stack to the kernel - what may be in the
stack pointer may not be valid at the point when the kernel is called -
it may be that it can only be used while the MMU is on, and at this
point the MMU will be off.  So you can't rely on anything from the
boot loader which I haven't documented as being part of the ARM kernel
boot protocol.

Please understand that we absolutely must get this issue resolved before
the next merge window, and have a solution ready to be merged at that
point.  As I see it, this is one of the major issues that requires
addressing.  Why?

At the moment we can't sensibly accept new board support adding several
thousand lines of new code to arch/arm.  Effectively that means that
the ARM platform people are in limbo at present, and have been for the
past three months.

We _desperately_ need to get the DT story sorted and starting to be
usable, with a transition path for existing SoC support so that
the platform people know where they are and how they can proceed.

The cost to the entire community of not having that sorted by the next
merge window will be enormous - I would not be surprised if it isn't
_already_ turning platform people away from Linux.  The longer this
situation continues, the more damage will be done.

So, for our own sakes, we must get the issue of ATAG and DT
interoperability resolved so that SoC people can rest assured in the
knowledge that they can start moving SoC data into DT without breaking
existing platforms.