DT overlay issues - dtc flags

Andreas Färber afaerber at suse.de
Mon Apr 10 09:16:19 PDT 2017


Hi,

I've tried to play around with Device Tree overlays (.dtbo files):

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/overlay-notes.txt

First of all, that document refers to a non-existing
Documentation/devicetree/dt-object-internal.txt. Could someone please
fix that one way or another?

In my particular example I've tried to extend the &i2c1 and &gpio nodes
of 4.11-rc5 arm64 broadcom/bcm2837-rpi-3-b.dts. The above documentation
prominently claims that this can be done via target = <&foo> syntax, but
U-Boot's fdt apply command fails for such a file. If instead I use the
alternative target-path = "/soc/..." then it works just fine.

As mentioned in the very bottom of the documentation, resolution of
phandle target references requires a __symbols__ node in the base .dtb.
IIUC this is only generated when passing the -@ dtc command line flag.

At first I thought this were an issue with how we build the .dtb files
in openSUSE [1], but by my reading of the kernel Makefiles not passing
-@ in DTC_FLAGS or cmd_dtc, you should run into the exact same issue.

I could think of a few ARMv7-M systems where such DT bloat might be
undesired (small flash sector sizes), but then it would seem easier to
suppress -@ where needed than to have a feature that by all practical
means is half unusable by default.

U-Boot itself appears to face a similar issue in that its internal
Device Trees are built without -@, and via Alex' distro boot extensions
this internal DT is passed on via UEFI as fallback when no external .dtb
file is found. So in the non-SPL case the DT should probably be built
with -@, too.

Or am I misunderstanding something here?

Thanks,
Andreas

[1]
https://build.opensuse.org/package/view_file/Kernel:HEAD/dtb-aarch64/dtb-aarch64.spec?expand=1

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)



More information about the linux-rpi-kernel mailing list