[PATCH] kbuild: dtc: Allow adding device tree fragments via config

[Trent Piepho]

On Mon, Sep 20, 2021 at 2:02 AM Ahmad Fatoum <a.fatoum at pengutronix.de> wrote:
>
> >>> Preprocessing the dts file gains another layer, where a generated dts
> >>> source consisting of an include directive for the original dts source is
> >>> followed by more includes for each fragment.  This is piped to the
> >>> existing preprocessor call on stdin to avoid another temporary file.
> >>> cpp/dtc will correctly identify errors in the source files they occur
> >>> in.  The -MT option is used so the cpp auto-dependencies reference the
> >>> original dts source and not the generated code passed on stdin.
> >>
> >> If you go this route wouldn't you want to apply device tree overlays?
> >
> > Can the Barebox apply overlays to the *Barebox dtb* when it starts?
>
> I meant overlay application at compile time. I have no experience with
> that and was interested to hear your opinion on it.

This could be done, but I think overall it is worse.  Additional
fragments can be made into dtbo files and then fdtoverlay from dtc
package can apply them to the main dtb at compile time.  But there are
drawbacks:
dtb must be compiled with symbols, which makes it larger.  And
non-fragment users get a different dtb than before for no reason.
One can not use the preprocessor to control overlays per board.  Such
as changing a node name from <&nand> to <&emmc> based on board or
enabling/disable the entire fragment.
The overlay can not delete nodes or properties, i.e. /delete-property/
and /delete-node/ are not useful.

A possible benefit of overlays is if an overlay is used in many
different images, then it could be compiled only once.  But dtc is not
any slower to compile a dts fragment append to the main dts than
fdoverlay is to apply an already compiled dtbo to the main dtb, so
there is not even a build time improvement here.

So, I can see only disadvantages and not advantages for compile time overlays.

Maybe one could ship a firmware update with a pool of overlays, then
firmware update installation could construct a final dtb from hardware
variant appropriate overlays.  That would be a way to make use of
non-dynamic overlays.  Otherwise I think there is no advantage to
non-runtime applied overlays over appended dts fragments.

>
> There is an easy way out, define the (sanitized) board name as a macro
> and let users worry about it.

Ok, I can add that.  I think the same identifier as constructed for
the C symbol of the compiled in dtb bytes will work.


> >
> > That is the use case here. So I can use rauc with just the standard
> > Barebox source without needing to patch it.
>
> I see the utility when using e.g. evaluation kits barebox already
> supports. Could be useful for DistroKit if RAUC support were to
> be added.

I used this originally for a devkit.  But it is Variscite's DART-6UL,
which is not supported in Barebox.  So I added support.  But not just
support for the one thing my FW does, support as a proper Barebox
devkit target.

Now I want to change the flash partitions for my specific FW design
and also want RAUC and barebox-state.  Should I include this in my
Barebox devkit support?  No one else wants it, at least not as I have
implemented it.   Should other users submit patches to Barebox to
change the partitions to what they want?  Of course not.

My answer is I should not have to patch Barebox to do this.  I do not
patch Barebox to change the defconfig I'm building with.  I do not
patch RAUC to configure it.  I do not patch wic to change my SD card
partitions.

Now we have made a custom board for the next phase and I have added a
new board to Barebox for this.  But still I use external dts fragments
despite having my FW specific Barebox git repo.  Because I do not want
FW system configuration to be done inside the bootloader codebase.  It
is much better if it is part of my FW git repo that configures
everything else in the system too.

In the old days, we had to patch a header in U-Boot to change *any*
bootloader configuration. Yuck! Then we had Barebox and it used the
kernel config system and we could have an external defconfig.  So much
better!  And Linux had board code with compiled in driver
configuration data, but then we got OF device trees and it was much
better.

So I want external dts files with Barebox.  Complete external dts is
really hard to do with the way Barebox images work.  But really, I
never write a complete dts from scatch. It is always a modification of
a base dts.  This patch to Barebox is not very complex and it lets me
do anything I have ever wanted to do with external Linux dts files in
Barebox.

>
> > If I was building two different
> > boards under yocto, I would have a machine specific override in my
> > barebox bbappend to add the only dts fragment for board I was building
> > for.  Yocto builds a different copy of barebox for each
> > target/machine.  I do not need barebox to use the preprocessor to turn
> > off the fragment I am not using.  I would not have yocto give it the
> > unused fragment in the first place.
>
> I usually avoid Yocto MACHINEs for board variants. Build same rootfs
> for both variants, ship two device trees and reference them either
> from FIT configurations or bootloader specs and let the bootloader worry
> about selecting the correct DT to boot.

When I have done one FW for multiple boards, I've always been able to
use the same bootloader and have it, or a preloader, determine board,
usually by resistor strapping on a GPIO or ADC, so it is easy to use
without drivers and to keep consistent on each board variant.  But if
one simply could not do that, then I see that multiple images from a
single Barebox machine target would be useful.  Also useful for
Buildroot, which is not as sophisticated as Yocto when it comes to
building a package in different ways.  One gets one target or one
host.  Not target-arm, target-arm-machineA, target-arm-machineB, etc.
like Yocto.