kbuild: Add support to build overlays (%.dtbo)

Update dtc compiler to accept dtbo as an outform.

Signed-off-by Viresh Kumar <[email protected]>

---
I feel that this needs to go directly to
https://git.kernel.org/pub/scm/utils/dtc/dtc.git

Right ? I will send it separately if the idea is accepted here.

---
 scripts/dtc/dtc.c | 2 ++
 1 file changed, 2 insertions(+)

scripts/dtc/dtc.c +0 -0

index bdb3f5945699..40fa7128b3d6 100644

Quoted 10 lines · Viresh Kumar

Update dtc compiler to accept dtbo as an outform.

Signed-off-by Viresh Kumar <[email protected]>

---
I feel that this needs to go directly to
https://git.kernel.org/pub/scm/utils/dtc/dtc.git

Right ? I will send it separately if the idea is accepted here.

Yes, needs to go to devicetree-compiler list. I think this came up before and IIRC David wasn't completely in agreement. I looked briefly and couldn't find the thread though...

We really don't need a different extension because we could just examine the dtb to determine if it is an overlay or not. That's less obvious. We could also add meta-data to overlays defining what base they apply to. If we had that, a tool could just list all overlays

that should apply to a base and we could use that info for build time applying overlays. Of course, that and a dtbo extension/format are not mutually exclusive.

Quoted 9 lines

---
 scripts/dtc/dtc.c | 2 ++
 1 file changed, 2 insertions(+)

scripts/dtc/dtc.c +0 -0

index bdb3f5945699..40fa7128b3d6 100644

scripts/dtc/dtc.c int main(int argc, char *argv[]) · line 364

Quoted 8 lines

scripts/dtc/dtc.c +2 -0

@@ -357,6 +357,8 @@ int main(int argc, char *argv[])
 #endif
        } else if (streq(outform, "dtb")) {
                dt_to_blob(outf, dti, outversion);
+       } else if (streq(outform, "dtbo")) {
+               dt_to_blob(outf, dti, outversion);
        } else if (streq(outform, "asm")) {
                dt_to_asm(outf, dti, outversion);
        } else if (streq(outform, "null")) {

You also need to extend guess_type_by_name().

Rob

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 ?

Also fdtoverlay is an external entity right now, and is not part of the kernel. Do we need to make it part of the kernel ? Or keep using the external entity ?

We will start building overlays for platforms soon in the kernel and would need these tools going forward. Lets fetch and build these.

Note that a copy of fdtdump.c was already copied back in the year 2012, but it was never updated or built for some reason.

Signed-off-by Viresh Kumar <[email protected]>

---
 scripts/dtc/Makefile             | 8 +++++++-
 scripts/dtc/update-dtc-source.sh | 6 +++---

 2 files changed, 10 insertions(+), 4 deletions(-)

scripts/dtc/Makefile +7 -1

index 4852bf44e913..c607980a5c17 100644
@@ -1,12 +1,18 @@
 # SPDX-License-Identifier: GPL-2.0
 # scripts/dtc makefile
 
-hostprogs-always-$(CONFIG_DTC)         += dtc
+hostprogs-always-$(CONFIG_DTC)         += dtc fdtdump fdtoverlay
 hostprogs-always-$(CHECK_DT_BINDING)   += dtc
 
 dtc-objs       := dtc.o flattree.o fstree.o data.o livetree.o treesource.o \
                   srcpos.o checks.o util.o
 dtc-objs       += dtc-lexer.lex.o dtc-parser.tab.o
+fdtdump-objs   := fdtdump.o util.o
+
+libfdt_dir     = libfdt
+libfdt-objs    := fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o fdt_empty_tree.o fdt_addresses.o fdt_overlay.o
+libfdt         = $(addprefix $(libfdt_dir)/,$(libfdt-objs))
+fdtoverlay-objs        := $(libfdt) fdtoverlay.o util.o
 
 # Source files need to get at the userspace version of libfdt_env.h to compile
 HOST_EXTRACFLAGS += -I $(srctree)/$(src)/libfdt

scripts/dtc/update-dtc-source.sh +3 -4

index bc704e2a6a4a..9bc4afb71415 100755
@@ -31,9 +31,9 @@ set -ev
 DTC_UPSTREAM_PATH=`pwd`/../dtc
 DTC_LINUX_PATH=`pwd`/scripts/dtc
 
-DTC_SOURCE="checks.c data.c dtc.c dtc.h flattree.c fstree.c livetree.c srcpos.c \
-               srcpos.h treesource.c util.c util.h version_gen.h yamltree.c \
-               dtc-lexer.l dtc-parser.y"
+DTC_SOURCE="checks.c data.c dtc.c dtc.h fdtdump.c fdtoverlay.c flattree.c \
+               fstree.c livetree.c srcpos.c srcpos.h treesource.c util.c \
+               util.h version_gen.h yamltree.c dtc-lexer.l dtc-parser.y"
 LIBFDT_SOURCE="fdt.c fdt.h fdt_addresses.c fdt_empty_tree.c \
                fdt_overlay.c fdt_ro.c fdt_rw.c fdt_strerror.c fdt_sw.c \
                fdt_wip.c libfdt.h libfdt_env.h libfdt_internal.h"
--

2.25.0.rc1.19.g042ed3e048af

Quoted 10 lines · Viresh Kumar

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.

Quoted 5 lines

A simple way is to mention that with -base extension, like this:

$(overlay-file)-base := platform-base.dtb

Any other preference ?

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.

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).

Quoted 3 lines

Also fdtoverlay is an external entity right now, and is not part of the kernel. Do we need to make it part of the kernel ? Or keep using the external entity ?

Part of the kernel. We just need to add it to the dtc sync script and makefile I think.

Rob

Quoted 14 lines · Rob Herring

Quoted 12 lines · Viresh Kumar

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:

Quoted 3 lines

Quoted 3 lines

$(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'

Quoted 12 lines · Rob Herring

Quoted 10 lines · Viresh Kumar

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.

Quoted 5 lines

Quoted 5 lines

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'

Quoted 10 lines

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.)

Quoted 3 lines

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.

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

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

Quoted 7 lines

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.

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.

Quoted 34 lines · Masahiro Yamada

Quoted 12 lines · Rob Herring

Quoted 10 lines · Viresh Kumar

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 3 lines

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.

Quoted 12 lines

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

Quoted 1 line

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.

Quoted 11 lines

Quoted 11 lines

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.)

Quoted 7 lines

Quoted 3 lines

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.

Quoted 2 lines

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.)

Quoted 11 lines

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 >

Quoted 11 lines

Quoted 7 lines

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.

Quoted 6 lines

arch/*/boot/dts/*.dts
-> dts/<vendor>/*.dts

Documentation/devicetree/bindings
-> dts/Bindings/

Quoted 7 lines

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/

Quoted 43 lines · Masahiro Yamada

Quoted 12 lines · Rob Herring

Quoted 10 lines · Viresh Kumar

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.

Quoted 5 lines

Quoted 5 lines

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.

Quoted 7 lines

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.

Quoted 10 lines

Quoted 10 lines

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.)

Quoted 7 lines

Quoted 3 lines

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.

Quoted 2 lines

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.)

Quoted 11 lines

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.

Quoted 11 lines

Quoted 7 lines

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.

Quoted 11 lines

arch/*/boot/dts/*.dts
-> dts/<vendor>/*.dts

Documentation/devicetree/bindings
-> dts/Bindings/

include/dt-bindings/
-> dts/include/dt-bindings/

Quoted 2 lines

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/

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.

Quoted 5 lines · Masahiro Yamada

Viresh's patch is not enough.

We will need to change .gitignore
and scripts/Makefile.dtbinst as well.

Quoted 8 lines

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.

By the time you gave feedback, I have already sent the dtbo change for DTC to the device-tree-compiler list (based on Rob's suggestion).

And it got merged today by David:

https://github.com/dgibson/dtc/commit/163f0469bf2ed8b2fe5aa15bc796b93c70243ddc

Can we please finalize what we need to do with naming here and be done with it, so I can rework my patches and get going ?

Thanks.

--
viresh

Quoted 28 lines · Viresh Kumar

Quoted 5 lines · Masahiro Yamada

Viresh's patch is not enough.

We will need to change .gitignore
and scripts/Makefile.dtbinst as well.

Quoted 8 lines

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.

By the time you gave feedback, I have already sent the dtbo change for DTC to the device-tree-compiler list (based on Rob's suggestion).

And it got merged today by David:

https://github.com/dgibson/dtc/commit/163f0469bf2ed8b2fe5aa15bc796b93c70243ddc

Can we please finalize what we need to do with naming here and be done with it, so I can rework my patches and get going ?

Thanks.

Quoted 2 lines

--
viresh

It is unfortunate to see such a patch merged before getting agreement about how it should work as a whole.

Review

Quoted 4 lines

(quoted diff) +4 -0

+# enable creation of __symbols__ node
+ifneq ($(dtbo-y),)
+DTC_FLAGS += -@
+endif

I am not convinced with this code.

A single user of the dtbo-y syntax gives -@ to all device trees in the same directory.

This is not a solution since Rob already stated -@ should be given per board (or per platform, at least).

I still do not understand why adding the new syntax dtbo-y is helpful.

Have we already decided to use separate ".dtb" and ".dtbo" for blobs?

Will we use ".dts" for all source files?
Or, will we use ".dtso" for overlay source files?

How should the build system determine the targets that should have -@ option?

For consistency, will we need a patch like follows?

dtc.c +2 -0

index bdb3f59..474401e 100644
@@ -120,6 +120,8 @@ static const char *guess_type_by_name(const char
 *fname, const char *fallback)
                return fallback;
        if (!strcasecmp(s, ".dts"))
                return "dts";
+       if (!strcasecmp(s, ".dtso"))
+               return "dts";
        if (!strcasecmp(s, ".yaml"))
                return "yaml";

        if (!strcasecmp(s, ".dtb"))

dtc.c +2 -0

@@ -349,6 +351,8 @@ int main(int argc, char *argv[])
 
        if (streq(outform, "dts")) {
                dt_to_source(outf, dti);
+       else if (streq(outform, "dtso")) {
+               dt_to_source(outf, dti);
 #ifndef NO_YAML
        } else if (streq(outform, "yaml")) {
                if (!streq(inform, "dts"))

Overall solution looks unclear to me.

Again, it is unfortunate that we did not take enough time (in spite of the RFC prefix) before proceeding.

+David Gibson

Quoted 35 lines · Masahiro Yamada

Quoted 30 lines · Viresh Kumar

Quoted 5 lines · Masahiro Yamada

Viresh's patch is not enough.

We will need to change .gitignore
and scripts/Makefile.dtbinst as well.

Quoted 8 lines

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.

By the time you gave feedback, I have already sent the dtbo change for DTC to the device-tree-compiler list (based on Rob's suggestion).

And it got merged today by David:

https://github.com/dgibson/dtc/commit/163f0469bf2ed8b2fe5aa15bc796b93c70243ddc

Can we please finalize what we need to do with naming here and be done with it, so I can rework my patches and get going ?

Thanks.

--
viresh

Quoted 3 lines

It is unfortunate to see such a patch merged before getting agreement about how it should work as a whole.

Given the feedback that dtbo is already a standard, I'd suggest we just stick with dts->dtbo.

Quoted 7 lines

Review

Quoted 4 lines

(quoted diff) +4 -0

+# enable creation of __symbols__ node
+ifneq ($(dtbo-y),)
+DTC_FLAGS += -@
+endif

I am not convinced with this code.

Quoted 5 lines

A single user of the dtbo-y syntax gives -@ to all device trees in the same directory.

This is not a solution since Rob already stated -@ should be given per board (or per platform, at least).

Agreed.

Quoted 2 lines

I still do not understand why adding the new syntax dtbo-y is helpful.

I think we should stick with 'dtb-y' here.

Quoted 7 lines

Have we already decided to use separate ".dtb" and ".dtbo" for blobs?

Will we use ".dts" for all source files?
Or, will we use ".dtso" for overlay source files?

How should the build system determine the targets that should have -@ option?

The way it does already. Either:

DTC_FLAGS += -@

in a directory of dts files. Or on a per file basis like:

DTC_FLAGS_foo_base += -@

Quoted 30 lines

For consistency, will we need a patch like follows?

dtc.c +2 -0

index bdb3f59..474401e 100644
@@ -120,6 +120,8 @@ static const char *guess_type_by_name(const char
 *fname, const char *fallback)
                return fallback;
        if (!strcasecmp(s, ".dts"))
                return "dts";
+       if (!strcasecmp(s, ".dtso"))
+               return "dts";
        if (!strcasecmp(s, ".yaml"))
                return "yaml";

        if (!strcasecmp(s, ".dtb"))

dtc.c +2 -0

@@ -349,6 +351,8 @@ int main(int argc, char *argv[])
 
        if (streq(outform, "dts")) {
                dt_to_source(outf, dti);
+       else if (streq(outform, "dtso")) {
+               dt_to_source(outf, dti);
 #ifndef NO_YAML
        } else if (streq(outform, "yaml")) {
                if (!streq(inform, "dts"))

Quoted 5 lines

Overall solution looks unclear to me.

Again, it is unfortunate that we did not take enough time (in spite of the RFC prefix) before proceeding.

I should have added David here from the start. Honestly, I expected some discussion there.

Rob

Quoted 1 line · Rob Herring

On Mon, Jan 11, 2021 at 9:40 AM Masahiro Yamada <[email protected]> wrote:

We do not need the dtbo-y syntax.

Quoted 14 lines · Viresh Kumar

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

Quoted 1 line

Any other preference ?

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.

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).

Quoted 3 lines

Also fdtoverlay is an external entity right now, and is not part of the kernel. Do we need to make it part of the kernel ? Or keep using the external entity ?

Part of the kernel. We just need to add it to the dtc sync script and makefile I think.

Rob