Migrating XO-1.75 to device tree - upgrade considerations

[Daniel Drake]

Hi,

We want to follow the upstream direction of dynamically driving
hardware detection by the firmware-provided device tree, rather than
hardcoding a board file into the kernel.

We have in-development kernel and firmware versions that make this
move, but we need to do this in a way that doesn't disrupt existing
users on upgrade.

These are the possible scenarios:
 new = whats currently in development, DT
 old = whats currently shipped as stable, non-DT

1. New kernel, new firmware: this is the easy case - in this scenario
we upgrade both components and we know that they work together since
we wrote tham that way.

2. New firmware, old kernel: This currently will not boot, because the
new firmware boots with a new /chosen/bootpath value which is not
recognised by the initramfs shipped with the old kernel.
However, it is not clear that we do need to support this case: the
requirement of running a new firmware on top of an old software base
is not common. And the only option we'd have of fixing it is putting
nasty hacks in the firmware, so if the need does arise in future, we
could produce new firmware versions with the required hacks included.

3. Old firmware, new kernel: This is a case we definitely have to care
about. When system updates are done in the field, it is not guaranteed
that electricity will be available upon the reboot in order to install
the updated firmware. So we need to keep this case working. (We know
this is an issue because we've pushed OS updates dependent on new
firmwares before, then we had to revert that upon realising the field
difficulties).


So #3 is the only case that needs our special attention at the present
time. The issue here is that the old firmware does not present a
good-enough device tree to the kernel, and the new kernel does not
have the old/static XO-1.75 board definitions. The system won't boot -
some corruption appears at the bottom of the screen, and nothing
appears over serial.

Ideally we want a solution for this that will hold for the long term -
i.e. its something we'd ship for considerable years to come, not only
just for the next release, to provide a direct upgrade path from the
software releases of today to any release of the future.

Options include:
1. Ship the static board file in the kernel, or maybe a cut down version of it.
I'm not so keen on this - we'd have to keep the non-upstream kernel
code around forever.

2. Append the XO-1.75 device tree to the kernel image.
This is my favourite option - while we would have to duplicate the DT
(once in the firmware, once in the kernel), at least they can be
direct copies rather than two different approaches to maintain.

(can the kernel be made to use this only when a "good DT" is
unavailable? Maybe the definition of "good DT" is hard to define - I'm
referring to the fact that we already ship a DT, but not one that can
be used to get the system on its feet in the absence of a board file)

3. Somehow detect this case and print a warning message.
Not so keen on this myself - expressing this in kid-friendly language
seems challenging, then there's internationalisation and so on.


Any thoughts or points that I'm missing?
Thanks
Daniel