Challenges of migrating to DT

[David Gibson]

On Wed, Aug 29, 2012 at 08:48:15AM -0600, Daniel Drake wrote:
> Hi,
> 
> At OLPC we are working hard to migrate from board files to the device
> tree for our existing ARM laptop XO-1.75, and we are also working
> directly with the DT (no board file) from day 1 with development of
> our upcoming XO-4 ARM laptop.
> 
> While the coding aspect is going fine, we have some open questions
> around the migration aspects and sustainability of our DT efforts. I'm
> wondering if these issues extend to other DT users and if there are
> any experiences that we can learn from.
> 
> The root of the issue is that using DT creates a strong bond between
> the firmware (DT provider) and the kernel (DT consumer). However, we
> cannot guarantee that our users stick to specific firmware/DT pair.

Hrm.  Arguably, if you are making a strong bond between firmware and
kernel, you're not doing the DT right.  The DT is supposed to be an OS
neutral description of the hardware.  Now in practice there are quite
a few edge cases where that can get murky, but if you're finding you
routinely need to update DT and kernel in lockstep, then you probably
are doing something wrong.

> 1. For our existing XO-1.75 users in the field, our existing DT is not
> good enough to allow a DT-based kernel to boot. When we upgrade these
> systems from board-file-based kernels to DT ones, we can also push a
> firmware update, but we cannot guarantee that the firmware update gets
> installed at the same time as the new kernel. (The firmware will only
> be updated when AC power is available, and it typically isn't
> available at the time when the software update is received from the
> school server).
> 
> So this covers the first tricky situation: upgrades. We have an issue
> where we ideally need to support an old, DT-less firmware running
> against a kernel with no board file that looks to do everything from
> the DT.

So, this situation is pretty routine on powerpc embedded.  Powerpc
_always_ uses a DT, but it doesn't have to come from firmware.  We
have "bootwrappers" for a whole batch of legacy platforms which
contain a canned DT.  Typically these form the zImage executable which
decompresses the kernel proper (vmlinux), patches up the canned DT
with any bits of information it can extract from the firware and
branches to the kernel with the right DT entry state.

> 2. For our new XO-4 efforts, we are having to define DT layouts for
> the hardware shipped in the laptop. And while we're working hard to do
> this cleanly, I fear that the upstreaming process will result in some
> (incompatible?) changes to these nodes and layouts.

Hrm.  Why so?  You're welcome and encouraged to post device tree
bindings here for comment before you upstream any actual code.

> However, we're
> under time pressures and we're a small team; it seems unlikely that
> we'll be able to upstream much of this before our initial shipment to
> real users. So we will again potentially find ourselves in a similar
> situation to above, where "old" software releases (i.e. the one
> shipped to first customers) include a DT that it somehow
> incompatible/insufficient for a new kernel (some time later when we
> upstream things and move to the upstream-refined DT layout).

So, I think incompatible and insufficient are quite different things
here.  New kernels should not break compatibility with old device tree
bindings, even if new device bindings are introduced.  It's perfectly
acceptable for the kernel to have fallbacks for old ways of
representing things.  Obviously you should make a best effort to get
the DT bindings right in the first place so that that doesn't happen
*too* much.

Insufficient - where the old DT simply does not have enough
information for the kernel to work out what to do - is harder.  This
does represent a much more serious failure to think through your DT
bindings.  It is moderately acceptable to have hacks in the kernel to
"patch up" the device tree with information from other sources, where
available, although you really want to think about your bindings to
try to avoid that.

> I know that there is a great deal of help available on this list for
> the upstreaming process, and in an ideal world we'd upstream
> everything before shipping, but in this case reality takes a nasty
> bite (resources-wise this would be difficult to achieve for us) and
> I'm wondering if others have faced similar situations in the past.
> 
> 
> One solution that initially stands out is appending the DT to the
> kernel image, to break the tricky bond between firmware and kernel.
> But this is probably harder than it sounds; we ship slightly different
> versions of these laptops (with/without touchscreen, different camera
> sensors, ...) and shipping different kernels to cover all the
> different combinations would be painful.

Are there ID registers or firmware information of some sort that can
be used to identify which machine?  I don't know that we have any
examples right now in practice, but an approach I've long seen as
reasonable would be to have a wrapper (bundled with the kernel) which
reads whatever ID information it needs and uses that to pick between
several pre-canned device trees.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson