Re: Boot interface for device trees on ARM

Grant Likely wrote:

On Tue, May 18, 2010 at 5:57 AM, Nicolas Pitre [off-list ref] wrote:

quoted

On Tue, 18 May 2010, Jeremy Kerr wrote:

quoted

Hi Nicolas,

quoted

I think that, for the moment, it is best if the bootloader on already
existing subarchitectures where DT is introduced still preserve the
already existing ability to boot using ATAGs.  This allows for the
testing and validation of the DT concept against the legacy ATAG method
more easily.

Just to clarify - by "still preserve the existing ability to use ATAGs" you
mean only for non-DT boot, right?

Exact.  Once a particular SOC family has no non-DT support anymore (due
to being entirely new, or because people get really enthusiastic and
fade out legacy machine specific init code completely) then and only
then it might be logical to remove ATAG from the concerned bootloaders.

quoted

This proposal still does not require ATAG_DEVTREE?

No.

Hmmm...  I misunderstood then.  I don't agree that this is the best way forward.

Doing it this way means a non-compatible break in the interface.  It
means that the bootloader needs to know what interface the kernel is
expecting for boot; information that is not readily available from the
image type.  The user then needs to tell the boot loader which
interface to use rather than a backwards compatible addition of a blob
of data.

Also the other way around: Sometimes you want to install the same
kernel on systems with old and new bootloaders, without touching the
bootloaders (due to that not being powerfail-safe, say).  The kernel
needs to know if it's passed a DT from a newer bootloader or not.

And sometimes you'd like to install a newer, tested kernel (that uses
DTs) on systems with old bootloaders.

You mention below "shifting the World Order on ARM" and it creating
resistance for merging DT support.  Isn't this much the same thing as
it creates a non backwards compatible change in the way bootloaders
pass data to the kernel.  The cutover in powerpc from the old
interface to the new caused no end of confusion and people who could
no longer get their systems to boot.  On PowerPC is was necessary
because the old method was completely broken, but ATAGs are clean,
simple and well implemented.

You can't always update the boot loader.  Sometimes you're stuck with
what's there for the life of a device.  Either it's ROM, or it's too
risky to modify in place.

It also means teaching every boot loader two separate methods for
booting and exposing those differences to the user.

Embedded devices usually don't have any way for the "user" to choose
from a boot menu ;-)

ATAG_DEVTREE sounds good to me for mix'n'match systems.

New systems that always use DTs could use _just_ ATAG_DEVTREE, to
avoid questions of conflicting info.  They could also settle on a
fixed R1 value meaning "devtree platform".

Or if a fixed "devtree platform" R1 is used, R2 could point directly
at the DT, no atag list in that specific case.

-- Jamie