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