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@lists.laptop.org > http://lists.laptop.org/listinfo/devel =--------------------- paul fox, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel