Boot interface for device trees on ARM
Jamie Lokier
jamie at shareable.org
Wed May 19 12:45:34 EDT 2010
Grant Likely wrote:
> On Tue, May 18, 2010 at 5:57 AM, Nicolas Pitre <nico at fluxnic.net> wrote:
> > On Tue, 18 May 2010, Jeremy Kerr wrote:
> >
> >> Hi Nicolas,
> >>
> >> > 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.
> >
> >
> >> 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
More information about the linux-arm-kernel
mailing list