Hello, On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote: > On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote: > > Let me steer the discussion to original topic - it's about old kernel > > and new DTB, assuming that mainline kernel bisectability is not > > affected. > > > > Flow looks like this: > > > > 0. You have existing bidings and drivers. > > 1. Patch changing bindings (with new compatible) and drivers gets > > accepted by maintainer. > > 2. Patch above (bindings+drivers) goes during merge window to v5.11-rc1. > > 3. Patch changing in-tree DTS to new compatible gets accepted by > > maintainer and it is sent as v5.12-rc1 material to SoC maintainers. > > > > So again: old kernel, using old bindings, new DTB. > > I don't think forward compatibility was ever considered. I've seen it being mentioned a few times on #armlinux but honestly this simply can't be achieved. This would mean being able to write complete DT bindings for a particular SoC at day 0 which will realistically never happen. You may noteven have a complete datasheet and even if you have a datasheet, it may not be complete or it may be missing hw errata that are discovered later on and need a new binding to handle. > > Another case is where out-of-tree user of bindings, e.g. FreeBSD, takes > > new DTS (at point of #3 above or later) but did not take the bindings. > > Such system would be broken but it's their fault - they took DTS without > > taking the bindings (which were there already for one release!). > > The particular boot flow that I am worried about here is when the dtb and > kernel are not updated in sync. Traditionally this happens when the dtb > is contained in the firmware image or generated by the firmware, as would > be the case on any server class system, but also on embedded systems > that can run an upstream kernel but without having the dts contributed > into the kernel sources. > > When you have this case, you can install a working system, and install > an upgraded kernel without problems. You might then want to update the > firmware as well, in order to take advantage of the features implemented > in the kernel kernel that require a DT description. Again, no problem. > > However, once the firmware is updated, it may no longer be possible to > go back to the old kernel in case the new one is busted. > Any serious update strategy will update both the kernel and device tree at the same time, exactly like you already have to update the initramfs with the kernel as soon as it is including kernel modules. I would expect any embedded platform to actually use a container format, like a FIT image that will ship the kernel, DT and intiramfs in a single image and will allow to sign all parts. > A similar problem can happen with the EBBR boot flow that relies on > a uefi-enabled firmware such as a u-boot, while using grub2 as the > actual boot loader. This is commonly supported across distros. While > grub2 can load a matching set of kernel+initrd+dtb from disk and run > that, this often fails in practice because u-boot needs to fill a > board specific set of DT properties (bootargs, detected memory, > mac address, ...). The usual way this gets handled is that u-boot loads > grub2 and the dtb from disk and then passes the modified dtb to grub, > which picks only kernel+initrd from disk and boots this with the dtb. > > The result is similar to case with dtb built into the firmware: after > upgrading the dtb that gets loaded by u-boot, grub can still pick > old kernels but they may not work as they did in the past. There are > obviously ways to work around it, but it does lead to user frustration. > Are there really any platforms with the dtb built into the firmware? I feel like this is a mythical creature used to scare people into keeping the DTB ABI stable. Aren't all the distribution already able to cope with keeping DTB and kernel in sync? -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
