On Mon, Feb 8, 2021 at 10:35 PM Alexandre Belloni
[off-list ref] wrote:

On 08/02/2021 20:52:37+0100, Arnd Bergmann wrote:

quoted

On Mon, Feb 8, 2021 at 7:42 PM Krzysztof Kozlowski [off-list ref] wrote:

quoted

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.

You do not have to write the correct DT for this, the only requirement
is that any changes to a node are backward-compatible, which is
typically the case if you add properties or compatible strings without
removing the old one. A bugfix in this case is also backward-compatible.

The part that can not happen instead is to write a DT that can expose
features that any future kernel will use.

quoted

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.

Embedded systems that do this have no requirement for backward
or forward compatibility at all, the only requirement for these is bisectability
of git commits.

quoted

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?

I think most traditional PowerPC systems fall into this category, most
systems that boot using UEFI+grub (as I explained), and anyone who
uses a distro kernel on custom hardware with their own dtb.

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel