Boot interface for device trees on ARM
Grant Likely
grant.likely at secretlab.ca
Wed May 19 13:10:01 EDT 2010
Hi Jamie,
On Wed, May 19, 2010 at 10:45 AM, Jamie Lokier <jamie at shareable.org> wrote:
> Grant Likely wrote:
>> 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.
Which will be an issue regardless of which approach is chosen. Either
way, this case does require the use of a boot shim or wrapper.
>> 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.
Yes. Though this is a bit of a side issue when talking about the boot
interface. We're still going to have cases where the bootloader
passes bad data and we may need a shim or wrapper (not part of
firmware) to adapt or fix it up. Just like with booting new kernels
on old (no-dt-support) firmware.
There is a larger issue w.r.t. what the overall boot architecture is,
and what recommendations distributions (like Ubuntu) should make to
device manufactures to ensure firmware is reliable and can boot a
distribution OS image. That's a topic for a different email.
>> 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.
Yes, this is trivial to do.
> 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.
My sticking point is I want there to be exactly one method of passing
the device tree blob. I don't see any advantage in having more than
one mechanism for passing the dtb pointer. Whether it be ATAG or bare
DT pointer, we should be able to choose a single method now that is
suitable for the foreseeable future.
Thanks,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
More information about the linux-arm-kernel
mailing list