devicetrees overlays support
Hello,
(please keep me CC'ed, I'm not subscribed)
I am using the (non-official) Debian port for raspberry pi from
raspi.debian.net , and have a device connected to the SPI bus pins on
the 40-pins extension connector. In my understanding, the proper
approach to interfacing with such device is to write a devicetree
overlay declaring the device.
So I wrote one, but then when I tried to confirm it would apply over
the package-provided dtb (using the fdtoverlay command as a simulation
of what would happen during boot), I realised it would not: it fails
with FDT_ERR_NOTFOUND, which I traced to the absence of any __symbols__
in the base dtb.
Rebuilding the devicetree from source, just adding "-@" to the cmd_dtc
rule in scripts/Makefile.lib, and the overlay could be applied by
fdtoverlay, and worked as expected after a reboot on this new dtb.
Given the widespread use of such devices (SPI or otherwise) in the
raspberry pi ecosystem and the widespread use of overlays to interface
with them, wouldn't it be better to provide devicetrees with
__symbols__ ?
Sadly, the commonly available overlays do not expect a Debian kernel,
so they may not apply cleanly. I did not try any myself, but the
raspberrypi.org kernel do contain symbols and elements not present in
vanilla, so this seems likely to happen. Which means either these would
need to be adapted to vanilla dtb (hopefully Debian will not customise
the vanilla dtb), or the vanilla dtb extended to meet the needs. IMHO,
both are out of Debian responsibility, but I thought I should mention
this family of possible issues.
Another possible issue may be that the produced device tree is
substantially larger than without __symbols__: +40% on the "pi zero
wifi". Which seems huge, but this is in fact an increase of only a bit
above 5kB, which, once put next to a kernel image, seems really not
much.
Would there be a particular reason __symbols__ are not output by the
kernel build command ?
Maybe making it optional if the size increase matters for some very
tightly constrained platforms ?
Regards,
--
Vincent Pelletier
Reply to: