Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #68820 > unrolled thread

devicetrees overlays support

Back to article view | Back to linux.debian.kernel

Contents

  devicetrees overlays support Vincent Pelletier <plr.vincent@gmail.com> - 2020-12-13 09:20 +0100
    Re: devicetrees overlays support Vincent Pelletier <plr.vincent@gmail.com> - 2020-12-20 03:30 +0100
      Re: devicetrees overlays support Vincent Pelletier <plr.vincent@gmail.com> - 2020-12-20 10:50 +0100
    Re: devicetrees overlays support Vincent Pelletier <plr.vincent@gmail.com> - 2021-01-05 02:20 +0100
      Re: devicetrees overlays support Vincent Pelletier <plr.vincent@gmail.com> - 2021-01-05 14:30 +0100

#68820 — 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

[toc] | [next] | [standalone]

#68950

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

To put more concrete commands behind this request, see the README I
wrote here:
  https://github.com/vpelletier/python-smartcard-app-openpgp/tree/master/examples/randompin-epaper-raspi#notes-for-debian

Regards,
-- 
Vincent Pelletier

[toc] | [prev] | [next] | [standalone]

#68951

On Sun, 20 Dec 2020 11:36:59 +0530, Karthik <karthikgatiganti@gmail.com> wrote:
> compile your own kernel
> 
> On Sun, Dec 20, 2020 at 7:51 AM Vincent Pelletier <plr.vincent@gmail.com> wrote:
> >
> > On Sun, 13 Dec 2020 07:57:24 +0000, Vincent Pelletier <plr.vincent@gmail.com> wrote:  
> > > 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 ?  
> >
> > To put more concrete commands behind this request, see the README I
> > wrote here:
> >   https://github.com/vpelletier/python-smartcard-app-openpgp/tree/master/examples/randompin-epaper-raspi#notes-for-debian
> >
> > Regards,
> > --
> > Vincent Pelletier

By requesting to keep me CC'ed, I do not mean to leave the list out.

I do not see the point of suggesting that I rebuild a whole kernel when
I can already just build the devicetree. Wouldn't it be just more work
for no gain ?

And my point is that I would very much like to *not* have to rebuild
the devicetree (which is kind of why I'm asking Debian kernel
maintainers to begin with, of which I am not sure are part of).

Regards,
-- 
Vincent Pelletier

[toc] | [prev] | [next] | [standalone]

#69055

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

[toc] | [prev] | [next] | [standalone]

#69057

On Tue, 5 Jan 2021 00:55:32 +0000, Vincent Pelletier <plr.vincent@gmail.com> wrote:
> Ping ?

And I got an answer from upstream, directing me at the following thread:
  https://lore.kernel.org/linux-devicetree/71fb0ff289e84c55bd92ecd96bc9aa76@svr-chch-ex1.atlnz.lc/
and especially this reply:
  https://lore.kernel.org/linux-devicetree/5ca84216.1c69fb81.3205c.592c@mx.google.com/
which outlines the desired design if this is to be implemented.

Regards,
-- 
Vincent Pelletier

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web