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
