[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: devicetrees overlays support



Ping ?

On Sun, 13 Dec 2020 07:57:24 +0000, Vincent Pelletier <plr.vincent@gmail.com> wrote:
> (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 ?
-- 
Vincent Pelletier


Reply to: