Multiple device trees for OSTree deploying

[starnight]

Thanks to William's effort. OSTree supports a device tree file for a single model of hardware since commit 720e2ec "Add support for devicetree files alongside the kernel and initramfs".

However, there are lots of embedded systems and single board computers in the world. Each of them has a specified device tree.

According to current mechanism, if we have "n" models of hardware, then we have "n" device trees and have to build "n" ostrees for installation and updating. This will be a big release management problem for common distributions.

Actually, this issue is already recognized by William of the existing functionality:
#1411

"It may be useful to extend device-tree support in a number ways in the future. Device trees depend on many details of the hardware they support. This makes them unlike kernels, which may support many different hardware variants as long as the instruction-set matches. This means that a ostree tree created with a device-tree in this manner will only boot on a single model of hardware. This is sufficient for my purposes, but may not be for others'."

This problem is particularly relevant now as Linux & Mesa mainline support for ARM boards is so much better than before, e.g. RPi, Rockchip, Amlogic. And as the list the names of all the different RPi3 device trees so that it's clear that the existing ostree implementation doesn't really work even if you only want to make a "Raspberry Pi 3" image.

The device tree source list of Raspberry Pi 3 in Linux mainline kernel:
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-a-plus.dts
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
arch/arm64/boot/dts/broadcom/bcm2837-rpi-3-b-plus.dts
arch/arm64/boot/dts/broadcom/bcm2837-rpi-cm3-io3.dts

Besides, the device tree is closely linked to the kernel version, and should be updated whenever the kernel is updated. For example, Arch Linux ARM and Fedora aarch64 install the entire tree of built device trees directly alongside the kernel & initramfs, and then rely on the boot loader (u-boot) to select the right device tree
at boot time.

What is the best way forward to solving this limitation?

Perhaps the entire device tree folder hierarchy should be deployed

[agners]

We do have the same problem and currently carry a rather hakish patch which copies all device tree's in the given source dir. However, checksum is not accounted for currently.

I was thinking about this a bit more, and I think the best way to implement this would be to only support the new deployment model (in /usr/lib/modules/$kver), this will simplify the code as we do not have to filter by checksum when searching for device trees.

Further, I would suggest to use the folder name currently in use in the Fedora ARM port: /usr/lib/modules/$kver/dtb/ (see also kernel-core package for Fedora ARM on https://koji.fedoraproject.org/).

With the new deployment format, we would just check if the currently supported location for a single file at /usr/lib/modules/$kver/devicetree is present, and if yes we would only take this one device tree file. Otherwise, if /usr/lib/modules/$kver/dtb/ is a folder, we would iterate it and include all device trees in the checksum.

If the folder is found, we would deploy the complete folder to /boot and set an environment variable called fdt_path. The device tree file would then be selected by the U-Boot boot script.

@wmanley @cgwalters thoughts? If that sounds somewhat sane, I can create a pull request implementing this.