Re: [RFC 0/2] kbuild: Add support to build overlays (%.dtbo)

[Rob Herring]

On Wed, Jan 6, 2021 at 10:35 PM Masahiro Yamada <masahiroy@xxxxxxxxxx> wrote:
>
> On Wed, Jan 6, 2021 at 12:21 AM Rob Herring <robh+dt@xxxxxxxxxx> wrote:
> >
> > On Tue, Jan 5, 2021 at 4:24 AM Viresh Kumar <viresh.kumar@xxxxxxxxxx> wrote:
> > >
> > > Hello,
> > >
> > > Here is an attempt to make some changes in the kernel to allow building
> > > of device tree overlays.
> > >
> > > While at it, I would also like to discuss about how we should mention
> > > the base DT blobs in the Makefiles for the overlays, so they can be
> > > build tested to make sure the overlays apply properly.
> > >
> > > A simple way is to mention that with -base extension, like this:
> > >
> > > $(overlay-file)-base := platform-base.dtb
> > >
> > > Any other preference ?
>
>
>
> Viresh's patch is not enough.
>
> We will need to change .gitignore
> and scripts/Makefile.dtbinst as well.
>
>
> In my understanding, the build rule is completely the same
> between .dtb and .dtbo
> As Rob mentioned, I am not sure if we really need/want
> a separate extension.
>
>
> A counter approach is to use an extension like '.ovl.dtb'
> It clarifies it is an overlay fragment without changing
> anything in our build system or the upstream DTC project.
>
> We use chained extension in some places, for example,
> .dt.yaml for schema yaml files.
>
>
>
> dtb-$(CONFIG_ARCH_FOO) += \
>     foo-board.dtb \
>     foo-overlay1.ovl.dtb \
>     foo-overlay2.ovl.dtb
>
>
> Overlay DT source file names must end with '.ovl.dts'

I like that suggestion as then it's also clear looking at the source
files which ones are overlays. Or we'd need .dtso to be consistent.


> > I think we'll want something similar to how '-objs' works for modules:
> >
> > foo-board-1-dtbs := foo-board.dtb foo-overlay1.dtbo
> > foo-board-2-dtbs := foo-board.dtb foo-overlay2.dtbo
> > foo-board-1-2-dtbs := foo-board.dtb foo-overlay1.dtbo foo-overlay2.dtbo
> > dtbs-y += foo-board-1.dtb foo-board-2.dtb foo-board-1-2.dtb
> >
> > (One difference here is we will want all the intermediate targets
> > unlike .o files.)
> >
> > You wouldn't necessarily have all the above combinations, but you have
> > to allow for them. I'm not sure how we'd handle applying any common
> > overlays where the base and overlay are in different directories.
>
>
> I guess the motivation for supporting -dtbs is to
> add per-board -@ option only when it contains *.dtbo pattern.

I hadn't thought that far, but yeah, that would be good. Really, I
just want it to be controlled per SoC family at least.

> But, as you notice, if the overlay files are located
> under drivers/, it is difficult to add -@ per board.

Generally, they shouldn't be. The exceptions are what we already have
there which are old dt fixups and unittests.

We want the stripped DT repo (devicetree-rebasing) to have all this
and drivers/ is stripped out. (Which reminds me, the DT repo will need
some work to support all this. It's a different build sys.)

> Another scenario is, some people may want to compile
> downstream overlay files (i.e. similar concept as external modules),
> then we have no idea which base board should be given with the -@ flag.
>
>
> I'd rather be tempted to add it globally
>
>
> ifdef CONFIG_OF_OVERLAY
> DTC_FLAGS += -@
> endif

We've already rejected doing that. Turning on '-@' can grow the dtb
size by a significant amount which could be problematic for some
boards.


> > Another thing here is adding all the above is not really going to
> > scale on arm32 where we have a single dts directory. We need to move
> > things to per vendor/soc family directories. I have the script to do
> > this. We just need to agree on the vendor names and get Arnd/Olof to
> > run it. I also want that so we can enable schema checks by default
> > once a vendor is warning free (the whole tree is going to take
> > forever).
>
>
> If this is a big churn, perhaps we could make it extreme
> to decouple DT and Linux-arch.

I would be fine with that, but I don't think we'll get agreement
there. With that amount of change, we'll be discussing git submodule
again.

Rereading the thread on vendor directories[1], we may just move boards
one vendor at a time. We could just make that a prerequisite for
vendor supporting overlays.

> arch/*/boot/dts/*.dts
>  ->  dts/<vendor>/*.dts
>
> Documentation/devicetree/bindings
>  -> dts/Bindings/
>
> include/dt-bindings/
>  -> dts/include/dt-bindings/
>
>
>
> Then, other project can take dts/
> to reuse for them.

This is already possible with devicetree-rebasing.git. Though it is
still by arch.

Rob

[1] https://lore.kernel.org/linux-devicetree/20181204183649.GA5716@bogus/