Migrating XO-1.75 to device tree - upgrade considerations

[Paul Fox]

daniel wrote:
 > 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

this is the case someone will be in if they install a new release,
then re-install an old release.  perhaps not something universally
done, but is it really that "uncommon"?

paul

 > 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
 > _______________________________________________
 > Devel mailing list
 > Devel at lists.laptop.org
 > http://lists.laptop.org/listinfo/devel

=---------------------
 paul fox, pgf at laptop.org