When using a custom `hardware.deviceTree.dtbSource`, we cannot assume
that all DTBs in this directory are regular files. This change allows
for file symlinks to be present as well, which fixes the issue where
only file (a symlink) is present in `dtbSource` and the copy fails with
`cp: missing file operand`.
Previously whenever an overlay was found to be incompatible with a base
device tree blob, the entire base dtb would be skipped in favor of
processing the next one. This had the unfortunate effect where overlays
would not fully be applied if any incompatibility was found. For
example, this is an issue with build device trees specific for one
flavor of raspberry pi if the overlay was not compatible _everywhere_.
The solution is to forego the `continue` keyword if an overlay is in
compatible and instead use a compound conditional statement to skip
incompatible overlays but continue trying to apply it to any remaining
dtbs.
This make the process of applying overlays more reliable by:
1. Ignoring dtb files that are not really device trees. [^1]
2. Adding a `filter` option (per-overlay, there already is a global one)
to limit the files to which the overlay applies. This is useful
in cases where the `compatible` string is ambiguous and multiple
unrelated files match.
Previously the script would fail in both cases.
[^1]: For example, there is dtbs/overlays/overlay_map.dtb in the
Raspberry Pi 1 kernel.
Now allows applying external overlays either in form of
.dts file, literal dts context added to store or precompiled .dtbo.
If overlays are defined, kernel device-trees are compiled with '-@'
so the .dtb files contain symbols which we can reference in our
overlays.
Since `fdtoverlay` doesn't respect `/ compatible` by itself
we query compatible strings of both `dtb` and `dtbo(verlay)`
and apply only if latter is substring of the former.
Also adds support for filtering .dtb files (as there are now nearly 1k
dtbs).
Co-authored-by: georgewhewell <georgerw@gmail.com>
Co-authored-by: Kai Wohlfahrt <kai.wohlfahrt@gmail.com>
