On Tue, 2012-08-21 at 12:04 -0600, Daniel Drake 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 > 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). >
While working with Australia, we have found the need to have the AC plugged-in for a firmware update while not requiring AC for a image upgrade to be problematic in the field. You can start an OS upgrade then run out of battery leaving a incomplete upgrade, while an AC adaptor may not always be available to use while your employing charging racks. We make our signed firmware available for download outside of the image, to enable the firmware to be installed from a USB drive before updating the OS. We disable the AC check and force a minimum 50% battery level before either actions can occur with our custom olpc.fth script which is part of our One Education USB[1] project. To my knowledge we have not bricked any XOs in the field using this method. Jerry 1. https://dev.laptop.org.au/projects/xo-au-usb/ > > 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 _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
