Mapping GPIO Pins from Wandboard to Fedora/libpiod

[Derek Atkins]

Hi Arm Team,

I have a Wandboard (yeah, I know, OLD Hardware) currently running a
project, and I'm trying to add some GPIO inputs to it.  In previous GPIO
handling (on a different platform) I used the /sys/class/gpio interfaces
to set up the GPIO, but I've discovered this is now deprecated and removed
from Fedora.  So I installed libgpiod and am trying to use it.

I'm using
https://download.technexion.com/development_resources/wandboard/wbquad-re...
as a reference for the board layout.  Specifically, on page 27, it shows
me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, CPIO1_24,
GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.

I figure that GPIO_18 is going to be gpiochip0 line 18, and GPIO3_12 will
be gpiochip3 line 12..  Except that gpiodetect only tells me I have
gpiochip0 through gpiochip6, so I'm not sure where GPIO7_8 would get
mapped.  That's the first issue I have.

The second issue is that the kernel does not have any named mappings, so
running gpioinfo just displays generic data, like:

gpiochip6 - 32 lines:
	line   0:      unnamed       unused   input  active-high
	line   1:      unnamed       unused   input  active-high

Except, of course, looking at gpiochip3 line 12 shows me:

gpiochip3 - 32 lines:
...
	line  12:      unnamed        "scl"  output  active-high [used open-drain]

Which seems to imply that that GPIO3_12 is actually used for something
else -- or my mapping strategy is off.

I'd appreciate any guidance anyone might have on this subject.

Thanks,

-derek

-- 
       Derek Atkins                 617-623-3745
       derek(a)ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

[Peter Robinson]

Hi Derek,

>  I have a Wandboard (yeah, I know, OLD Hardware) currently running a
As in the imx6 based Wandboard? Which model/rev? What release of
Fedora, what kernel etc?

>  project, and I'm trying to add some GPIO inputs to it.  In
> previous GPIO
>  handling (on a different platform) I used the /sys/class/gpio interfaces
>  to set up the GPIO, but I've discovered this is now deprecated and removed
>  from Fedora.  So I installed libgpiod and am trying to use it. 
Yes, we stopped supporting that because it was deprecated and upstream
asked us to.

>  I'm using
>
> https://download.technexion.com/development_resources/wandboard/wbquad-re...
>  as a reference for the board layout.  Specifically, on page 27, it shows
>  me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31, CPIO1_24,
>  GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
>
>  I figure that GPIO_18 is going to be gpiochip0 line 18, and GPIO3_12 will
>  be gpiochip3 line 12..  Except that gpiodetect only tells me I have
>  gpiochip0 through gpiochip6, so I'm not sure where GPIO7_8 would get
>  mapped.  That's the first issue I have. 
You'd likely need to look at the device tree and pinmappings to see
how they're mapped out.

>  The second issue is that the kernel does not have any named mappings,
> so
>  running gpioinfo just displays generic data, like:
>
>  gpiochip6 - 32 lines:
>          line   0:      unnamed       unused   input  active-high
>          line   1:      unnamed       unused   input  active-high
>
>  Except, of course, looking at gpiochip3 line 12 shows me:
>
>  gpiochip3 - 32 lines:
>  ...
>          line  12:      unnamed        "scl"  output  active-high [used
> open-drain]
>
>  Which seems to imply that that GPIO3_12 is actually used for something
>  else -- or my mapping strategy is off. 
Probably a kernel device, often GPIOs are used for other things.

A quick look at the dtsi for the wandboards some of the GPIOs re used
for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have
anything attached so I guess in on a pin header for end user use, and
i2c12 has a audio codec and for the camera connector.

>  I'd appreciate any guidance anyone might have on this subject.
If it's a iMX6 based Wandboard the guidance will be limted as the
support for ARMv7 went EOL when F-36 did so I have no recollection of
what kernel, libgpiod version etc was shipped there.

Peter

[Derek Atkins]

Hi,

Thank you the response!  My replies inline below...

On Mon, April 15, 2024 11:14 am, Peter Robinson wrote:
>  Hi Derek,
>
> > I have a Wandboard (yeah, I know, OLD Hardware) currently running a
>
>  As in the imx6 based Wandboard? Which model/rev? What release of
>  Fedora, what kernel etc? 
Yes, an imx6 Wandboard.  I'll have to go upstairs and open the case to see
the EXACT model/rev printed on the PCB.  Running "cat /proc/cpuinfo" only
shows a single core.  And it's running Fedora 36, currently running
5.18.9-200.fc36.armv7hl and libgpiod-1.6.3-7.fc36.armv7hl

> > project, and I'm trying to add some GPIO inputs to it.  In
> previous GPIO
> > handling (on a different platform) I used the /sys/class/gpio interfaces
> > to set up the GPIO, but I've discovered this is now deprecated and
> > removed
> > from Fedora.  So I installed libgpiod and am trying to use it.
>
>  Yes, we stopped supporting that because it was deprecated and upstream
>  asked us to.
>
> > I'm using
> >
> https://download.technexion.com/development_resources/wandboard/wbquad-re...
> > as a reference for the board layout.  Specifically, on page 27, it shows
> > me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31,
> > CPIO1_24,
> > GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
> >
> > I figure that GPIO_18 is going to be gpiochip0 line 18, and GPIO3_12
> > will
> > be gpiochip3 line 12..  Except that gpiodetect only tells me I have
> > gpiochip0 through gpiochip6, so I'm not sure where GPIO7_8 would get
> > mapped.  That's the first issue I have.
>
>  You'd likely need to look at the device tree and pinmappings to see
>  how they're mapped out. 
I was trying to follow the device tree, and found a dts in the
wandboard-org tree that seemed to match the settings from that PDF I
pointed to.  Of course, that may or may not be correct to the actual
hardware I have running upstairs.

> > The second issue is that the kernel does not have any named
> mappings, so
> > running gpioinfo just displays generic data, like:
> >
> > gpiochip6 - 32 lines:
> >         line   0:      unnamed       unused   input  active-high
> >         line   1:      unnamed       unused   input  active-high
> >
> > Except, of course, looking at gpiochip3 line 12 shows me:
> >
> > gpiochip3 - 32 lines:
> > ...
> >         line  12:      unnamed        "scl"  output  active-high [used
> > open-drain]
> >
> > Which seems to imply that that GPIO3_12 is actually used for something
> > else -- or my mapping strategy is off.
>
>  Probably a kernel device, often GPIOs are used for other things. 
Being only ancillarily associated with Arm/Embedded HW -- what does it
mean for a GPIO to be "used for other things"?  And more importantly, why
would it be wired to a header if it's being used for something else?

>  A quick look at the dtsi for the wandboards some of the GPIOs re
> used
>  for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have
>  anything attached so I guess in on a pin header for end user use, and
>  i2c12 has a audio codec and for the camera connector. 
How exactly is this done?  Is the pin wired to two places on the PCB?

> > I'd appreciate any guidance anyone might have on this
> subject.
>
>  If it's a iMX6 based Wandboard the guidance will be limted as the
>  support for ARMv7 went EOL when F-36 did so I have no recollection of
>  what kernel, libgpiod version etc was shipped there. 
Understood.  I just happen to have bought into the Wandboard platform a
long time ago, so this is what I've been using for the project.  It uses a
USB Relay, leveraging CRelay, so theoretically I could swap the system out
for a different board in order to get 4 GPIOs for external switch
detction, but honestly I'd rather not spend the money...  :)

>  Peter 
-derek

-- 
       Derek Atkins                 617-623-3745
       derek(a)ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

[Peter Robinson]

>  >> I have a Wandboard (yeah, I know, OLD Hardware) currently
> running a
>  >
>  > As in the imx6 based Wandboard? Which model/rev? What release of
>  > Fedora, what kernel etc?
>
>  Yes, an imx6 Wandboard.  I'll have to go upstairs and open the case to see
>  the EXACT model/rev printed on the PCB.  Running "cat /proc/cpuinfo" only
>  shows a single core.  And it's running Fedora 36, currently running
>  5.18.9-200.fc36.armv7hl and libgpiod-1.6.3-7.fc36.armv7hl
>
>  >> project, and I'm trying to add some GPIO inputs to it.  In previous GPIO
>  >> handling (on a different platform) I used the /sys/class/gpio interfaces
>  >> to set up the GPIO, but I've discovered this is now deprecated and
>  >> removed
>  >> from Fedora.  So I installed libgpiod and am trying to use it.
>  >
>  > Yes, we stopped supporting that because it was deprecated and upstream
>  > asked us to.
>  >
>  >> I'm using
>  >>
> https://download.technexion.com/development_resources/wandboard/wbquad-re...
>  >> as a reference for the board layout.  Specifically, on page 27, it shows
>  >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31,
>  >> CPIO1_24,
>  >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
>  >>
>  >> I figure that GPIO_18 is going to be gpiochip0 line 18, and GPIO3_12
>  >> will
>  >> be gpiochip3 line 12..  Except that gpiodetect only tells me I have
>  >> gpiochip0 through gpiochip6, so I'm not sure where GPIO7_8 would get
>  >> mapped.  That's the first issue I have.
>  >
>  > You'd likely need to look at the device tree and pinmappings to see
>  > how they're mapped out.
>
>  I was trying to follow the device tree, and found a dts in the
>  wandboard-org tree that seemed to match the settings from that PDF I
>  pointed to.  Of course, that may or may not be correct to the actual
>  hardware I have running upstairs. 
Best ones are probably the upstream ones:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...

>  >> The second issue is that the kernel does not have any named
> mappings, so
>  >> running gpioinfo just displays generic data, like:
>  >>
>  >> gpiochip6 - 32 lines:
>  >>         line   0:      unnamed       unused   input  active-high
>  >>         line   1:      unnamed       unused   input  active-high
>  >>
>  >> Except, of course, looking at gpiochip3 line 12 shows me:
>  >>
>  >> gpiochip3 - 32 lines:
>  >> ...
>  >>         line  12:      unnamed        "scl"  output  active-high
> [used
>  >> open-drain]
>  >>
>  >> Which seems to imply that that GPIO3_12 is actually used for something
>  >> else -- or my mapping strategy is off.
>  >
>  > Probably a kernel device, often GPIOs are used for other things.
>
>  Being only ancillarily associated with Arm/Embedded HW -- what does it
>  mean for a GPIO to be "used for other things"?  And more importantly, why
>  would it be wired to a header if it's being used for something else? 
So in the case I mention below the GPIO pin is used for i2c and it's
on that header so you could add say a i2c based temp sensor or other
i2c device.

Also board designers may use a GPIO to hook up a mSD card detect pin,
or a WiFi interface reset pin, or something else on the board layout.

You can see the default pin allocation here from line 152-195:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...

And the GPIOs mapped to i2c here on lines 103-104 and again 113-114,
and then as a camera enable/reset at 139-140:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...

>  > A quick look at the dtsi for the wandboards some of the GPIOs re
> used
>  > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have
>  > anything attached so I guess in on a pin header for end user use, and
>  > i2c12 has a audio codec and for the camera connector.
>
>  How exactly is this done?  Is the pin wired to two places on the PCB? 
It depends, for example on a RPi header you can use a DT overlay to
change the default use of a PIN, by default is might be a standard
GPIO but you apply an overlay that remaps it so it routes a i2s audio
interface so you can use a DAC to output sound. So it's generally more
about being able to use the reduced amounts of external pins for
different usecases, someone might want it in a robot, someone else
might want it to output audio.

> >> I'd appreciate any guidance anyone might have on this subject.
> >
> > If it's a iMX6 based Wandboard the guidance will be limted as the
> > support for ARMv7 went EOL when F-36 did so I have no recollection of
> > what kernel, libgpiod version etc was shipped there.
>
> Understood.  I just happen to have bought into the Wandboard platform a
> long time ago, so this is what I've been using for the project.  It uses a
> USB Relay, leveraging CRelay, so theoretically I could swap the system out
> for a different board in order to get 4 GPIOs for external switch
> detction, but honestly I'd rather not spend the money...  :)
>
> > Peter
>
> -derek
>
> --
>        Derek Atkins                 617-623-3745
>        derek(a)ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>

[Derek Atkins]

Hi Peter,

On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote:

> > >> I'm using
> > >>
> https://download.technexion.com/development_resources/wandboard/wbquad-re...
> > >> as a reference for the board layout.  Specifically, on page 27, it
> > shows
> > >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31,
> > >> CPIO1_24,
> > >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
> > >> 
[snip]

> > Being only ancillarily associated with Arm/Embedded HW -- what
> does it
> > mean for a GPIO to be "used for other things"?  And more importantly,
> > why
> > would it be wired to a header if it's being used for something else?
>
>  So in the case I mention below the GPIO pin is used for i2c and it's
>  on that header so you could add say a i2c based temp sensor or other
>  i2c device.
>
>  Also board designers may use a GPIO to hook up a mSD card detect pin,
>  or a WiFi interface reset pin, or something else on the board layout. 
I guess I don't understand why they would expose GPIO-x on a header and
ALSO use it elsewhere on the board.   In my case, I just need to find 4
open "button" inputs.

>  You can see the default pin allocation here from line 152-195:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
>
>  And the GPIOs mapped to i2c here on lines 103-104 and again 113-114,
>  and then as a camera enable/reset at 139-140:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
Thanks.  I see the duplication of scl-gpois and sda-gpios names in those
two sections, but in the first section it uses gpio3 21/28 and in the
second section is used gpio4 13/14.

I also don't see the specific bindings for the pins on the JP4 header
(e.g. I don't see gpio3 12 being specified here).

> > > A quick look at the dtsi for the wandboards some of the
> GPIOs re used
> > > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have
> > > anything attached so I guess in on a pin header for end user use, and
> > > i2c12 has a audio codec and for the camera connector.
> >
> > How exactly is this done?  Is the pin wired to two places on the PCB?
>
>  It depends, for example on a RPi header you can use a DT overlay to
>  change the default use of a PIN, by default is might be a standard
>  GPIO but you apply an overlay that remaps it so it routes a i2s audio
>  interface so you can use a DAC to output sound. So it's generally more
>  about being able to use the reduced amounts of external pins for
>  different usecases, someone might want it in a robot, someone else
>  might want it to output audio. 
How would an end-user do that without building a custom kernel?  Like I
said, all I need is to read from four input GPIOs for a water-detection
system, so instead of using a 'sleep' after opening the relay, it waits
for the appropriate gpio to turn on based on a water detector connected to
it (so it will turn off the relay as soon as it detects the water tank is
full).

So really I just need to choose 4 pins that I can use, and map those to an
event manager to wait for the pin to go on.  JP4 seems to be the only
layout with GPIO labeled, so I just need to figure out which pins to use
and how to read those inputs in this brave new world.

Thanks,

-derek

-- 
       Derek Atkins                 617-623-3745
       derek(a)ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

[Derek Atkins]

Hi again,
I just went and cracked open the case.
According the chip ID, it's an IMX6 Dual.  Although cpuinfo only reports
cpu 0.
The main board says revision A1; the baseboard says revision A0.  I guess
this is one of my older units.

-derek

On Mon, April 15, 2024 2:12 pm, Derek Atkins wrote:
>  Hi Peter,
>
>  On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote:
>
> >> >> I'm using
> >> >>
> https://download.technexion.com/development_resources/wandboard/wbquad-re...
> >> >> as a reference for the board layout.  Specifically, on page 27, it
> >> shows
> >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31,
> >> >> CPIO1_24,
> >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
> >> >>
>  [snip]
>
> >> Being only ancillarily associated with Arm/Embedded HW -- what does it
> >> mean for a GPIO to be "used for other things"?  And more importantly,
> >> why
> >> would it be wired to a header if it's being used for something else?
> >
> > So in the case I mention below the GPIO pin is used for i2c and it's
> > on that header so you could add say a i2c based temp sensor or other
> > i2c device.
> >
> > Also board designers may use a GPIO to hook up a mSD card detect pin,
> > or a WiFi interface reset pin, or something else on the board layout.
>
>  I guess I don't understand why they would expose GPIO-x on a header and
>  ALSO use it elsewhere on the board.   In my case, I just need to find 4
>  open "button" inputs.
>
> > You can see the default pin allocation here from line 152-195:
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
> >
> > And the GPIOs mapped to i2c here on lines 103-104 and again 113-114,
> > and then as a camera enable/reset at 139-140:
> >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
>
>  Thanks.  I see the duplication of scl-gpois and sda-gpios names in those
>  two sections, but in the first section it uses gpio3 21/28 and in the
>  second section is used gpio4 13/14.
>
>  I also don't see the specific bindings for the pins on the JP4 header
>  (e.g. I don't see gpio3 12 being specified here).
>
> >> > A quick look at the dtsi for the wandboards some of the GPIOs re used
> >> > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have
> >> > anything attached so I guess in on a pin header for end user use, and
> >> > i2c12 has a audio codec and for the camera connector.
> >>
> >> How exactly is this done?  Is the pin wired to two places on the PCB?
> >
> > It depends, for example on a RPi header you can use a DT overlay to
> > change the default use of a PIN, by default is might be a standard
> > GPIO but you apply an overlay that remaps it so it routes a i2s audio
> > interface so you can use a DAC to output sound. So it's generally more
> > about being able to use the reduced amounts of external pins for
> > different usecases, someone might want it in a robot, someone else
> > might want it to output audio.
>
>  How would an end-user do that without building a custom kernel?  Like I
>  said, all I need is to read from four input GPIOs for a water-detection
>  system, so instead of using a 'sleep' after opening the relay, it waits
>  for the appropriate gpio to turn on based on a water detector connected to
>  it (so it will turn off the relay as soon as it detects the water tank is
>  full).
>
>  So really I just need to choose 4 pins that I can use, and map those to an
>  event manager to wait for the pin to go on.  JP4 seems to be the only
>  layout with GPIO labeled, so I just need to figure out which pins to use
>  and how to read those inputs in this brave new world.
>
>  Thanks,
>
>  -derek
>
>  --
>         Derek Atkins                 617-623-3745
>         derek(a)ihtfp.com             www.ihtfp.com
>         Computer and Internet Security Consultant
>
>  

-- 
       Derek Atkins                 617-623-3745
       derek(a)ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

[Peter Robinson]

On Mon, 15 Apr 2024 at 19:39, Derek Atkins <derek(a)ihtfp.com&gt; wrote:
>  Hi again,
>  I just went and cracked open the case.
>  According the chip ID, it's an IMX6 Dual.  Although cpuinfo only reports
>  cpu 0.
>  The main board says revision A1; the baseboard says revision A0.  I guess
>  this is one of my older units. 
Makes sense, there was either dual or quad models, as to why it's not
finding the other core I am not sure, it might be a DT issue, might be
a kernel issue, unfortunately with F-36 EOL there's no a lot I can do
to help you there, all my imx6 devices are packed away in a box
somewhere.

> -derek
>
> On Mon, April 15, 2024 2:12 pm, Derek Atkins wrote:
> > Hi Peter,
> >
> > On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote:
> >
> >>> >> I'm using
> >>> >>
https://download.technexion.com/development_resources/wandboard/wbquad-re...
> >>> >> as a reference for the board layout.  Specifically, on page 27,
it
> >>> shows
> >>> >> me that the JP4 header connects to GPIO3_12, GPIO3_27,
GPIO6_31,
> >>> >> CPIO1_24,
> >>> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
> >>> >>
> > [snip]
> >
> >>> Being only ancillarily associated with Arm/Embedded HW -- what does it
> >>> mean for a GPIO to be "used for other things"?  And more
importantly,
> >>> why
> >>> would it be wired to a header if it's being used for something
else?
> >>
> >> So in the case I mention below the GPIO pin is used for i2c and it's
> >> on that header so you could add say a i2c based temp sensor or other
> >> i2c device.
> >>
> >> Also board designers may use a GPIO to hook up a mSD card detect pin,
> >> or a WiFi interface reset pin, or something else on the board layout.
> >
> > I guess I don't understand why they would expose GPIO-x on a header and
> > ALSO use it elsewhere on the board.   In my case, I just need to find 4
> > open "button" inputs.
> >
> >> You can see the default pin allocation here from line 152-195:
> >>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
> >>
> >> And the GPIOs mapped to i2c here on lines 103-104 and again 113-114,
> >> and then as a camera enable/reset at 139-140:
> >>
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
> >
> > Thanks.  I see the duplication of scl-gpois and sda-gpios names in those
> > two sections, but in the first section it uses gpio3 21/28 and in the
> > second section is used gpio4 13/14.
> >
> > I also don't see the specific bindings for the pins on the JP4 header
> > (e.g. I don't see gpio3 12 being specified here).
> >
> >>> > A quick look at the dtsi for the wandboards some of the GPIOs re
used
> >>> > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not
have
> >>> > anything attached so I guess in on a pin header for end user use,
and
> >>> > i2c12 has a audio codec and for the camera connector.
> >>>
> >>> How exactly is this done?  Is the pin wired to two places on the PCB?
> >>
> >> It depends, for example on a RPi header you can use a DT overlay to
> >> change the default use of a PIN, by default is might be a standard
> >> GPIO but you apply an overlay that remaps it so it routes a i2s audio
> >> interface so you can use a DAC to output sound. So it's generally more
> >> about being able to use the reduced amounts of external pins for
> >> different usecases, someone might want it in a robot, someone else
> >> might want it to output audio.
> >
> > How would an end-user do that without building a custom kernel?  Like I
> > said, all I need is to read from four input GPIOs for a water-detection
> > system, so instead of using a 'sleep' after opening the relay, it waits
> > for the appropriate gpio to turn on based on a water detector connected to
> > it (so it will turn off the relay as soon as it detects the water tank is
> > full).
> >
> > So really I just need to choose 4 pins that I can use, and map those to an
> > event manager to wait for the pin to go on.  JP4 seems to be the only
> > layout with GPIO labeled, so I just need to figure out which pins to use
> > and how to read those inputs in this brave new world.
> >
> > Thanks,
> >
> > -derek
> >
> > --
> >        Derek Atkins                 617-623-3745
> >        derek(a)ihtfp.com             www.ihtfp.com
> >        Computer and Internet Security Consultant
> >
> >
>
>
> --
>        Derek Atkins                 617-623-3745
>        derek(a)ihtfp.com             www.ihtfp.com
>        Computer and Internet Security Consultant
>

[Peter Robinson]

On Mon, 15 Apr 2024 at 19:12, Derek Atkins <derek(a)ihtfp.com&gt; wrote:
>  Hi Peter,
>
>  On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote:
>
>  >> >> I'm using
>  >> >>
> https://download.technexion.com/development_resources/wandboard/wbquad-re...
>  >> >> as a reference for the board layout.  Specifically, on page 27, it
>  >> shows
>  >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27, GPIO6_31,
>  >> >> CPIO1_24,
>  >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
>  >> >>
>  [snip]
>
>  >> Being only ancillarily associated with Arm/Embedded HW -- what does it
>  >> mean for a GPIO to be "used for other things"?  And more importantly,
>  >> why
>  >> would it be wired to a header if it's being used for something else?
>  >
>  > So in the case I mention below the GPIO pin is used for i2c and it's
>  > on that header so you could add say a i2c based temp sensor or other
>  > i2c device.
>  >
>  > Also board designers may use a GPIO to hook up a mSD card detect pin,
>  > or a WiFi interface reset pin, or something else on the board layout.
>
>  I guess I don't understand why they would expose GPIO-x on a header and
>  ALSO use it elsewhere on the board.   In my case, I just need to find 4
>  open "button" inputs. 
They're not, eg to use the i2c example, they are changing those GPIOs
to be i2c and exposing it on the header as an i2c interface (and hence
they are not usable as a generic GPIO interface).

To use 4 GPIOs to use for buttons you just need to work out where the
open GPIOs as documented on the header map as open unused GPIO PINs.

>  > You can see the default pin allocation here from line 152-195:
>  >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
>  >
>  > And the GPIOs mapped to i2c here on lines 103-104 and again 113-114,
>  > and then as a camera enable/reset at 139-140:
>  >
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/a...
>
>  Thanks.  I see the duplication of scl-gpois and sda-gpios names in those
>  two sections, but in the first section it uses gpio3 21/28 and in the
>  second section is used gpio4 13/14. 
That's two different i2c interfaces, one I suspect is mapped out to
the PIN headers, the other is used for audio codec and camera
elsewhere on the board.

>  I also don't see the specific bindings for the pins on the JP4
> header
>  (e.g. I don't see gpio3 12 being specified here). 
You need to follow the docs, I am not looking at that, I was purely
explaining how the mappings are happening, not how they're routed on
the HW.

>  >> > A quick look at the dtsi for the wandboards some of the
> GPIOs re used
>  >> > for SCL/SDA pins on two of the i2c buses. The i2c1 seems to not have
>  >> > anything attached so I guess in on a pin header for end user use, and
>  >> > i2c12 has a audio codec and for the camera connector.
>  >>
>  >> How exactly is this done?  Is the pin wired to two places on the PCB?
>  >
>  > It depends, for example on a RPi header you can use a DT overlay to
>  > change the default use of a PIN, by default is might be a standard
>  > GPIO but you apply an overlay that remaps it so it routes a i2s audio
>  > interface so you can use a DAC to output sound. So it's generally more
>  > about being able to use the reduced amounts of external pins for
>  > different usecases, someone might want it in a robot, someone else
>  > might want it to output audio.
>
>  How would an end-user do that without building a custom kernel?  Like I
>  said, all I need is to read from four input GPIOs for a water-detection
>  system, so instead of using a 'sleep' after opening the relay, it waits
>  for the appropriate gpio to turn on based on a water detector connected to
>  it (so it will turn off the relay as soon as it detects the water tank is
>  full). 
Basically read the docs and map that through to free GPIO PINS.

>  So really I just need to choose 4 pins that I can use, and map those
> to an
>  event manager to wait for the pin to go on.  JP4 seems to be the only
>  layout with GPIO labeled, so I just need to figure out which pins to use
>  and how to read those inputs in this brave new world. 
I've not dug out a pdf to work out the physical pins and how they map
to the SOC and hence the DT, I've left that up to you, I was just
answering your questions about why some appear to be in use and trying
to help you understand as you requested.

[Derek Atkins]

Hi,

On Mon, April 15, 2024 4:21 pm, Peter Robinson wrote:

> > >> >> me that the JP4 header connects to GPIO3_12,
> GPIO3_27, GPIO6_31,
> > >> >> CPIO1_24,
> > >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
> > >> >>
> > [snip] 
>  I've not dug out a pdf to work out the physical pins and how they
> map
>  to the SOC and hence the DT, I've left that up to you, I was just
>  answering your questions about why some appear to be in use and trying
>  to help you understand as you requested. 
I've read the docs; the pins on the header map to the above-listed lanes.
What I need to figure out are:

1) How do these map to gpiochipN X -- e.g. if GPIO_18 maps to gpiochip0,18
and GPIO3_12 maps to gpiochip3,12 -- what does GPIO7_8 map to?

2) How to figure out which ones are available?  I presume I can just look
at the output of gpioinfo for the aforementioned mappings?

Thanks,

-derek

-- 
       Derek Atkins                 617-623-3745
       derek(a)ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant

[Peter Robinson]

On Mon, 15 Apr 2024 at 21:38, Derek Atkins <derek(a)ihtfp.com&gt; wrote:
>  Hi,
>
>  On Mon, April 15, 2024 4:21 pm, Peter Robinson wrote:
>
>  >> >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27,
> GPIO6_31,
>  >> >> >> CPIO1_24,
>  >> >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
>  >> >> >>
>  >> [snip]
>
>  > I've not dug out a pdf to work out the physical pins and how they map
>  > to the SOC and hence the DT, I've left that up to you, I was just
>  > answering your questions about why some appear to be in use and trying
>  > to help you understand as you requested.
>
>  I've read the docs; the pins on the header map to the above-listed lanes.
>  What I need to figure out are:
>
>  1) How do these map to gpiochipN X -- e.g. if GPIO_18 maps to gpiochip0,18
>  and GPIO3_12 maps to gpiochip3,12 -- what does GPIO7_8 map to?
>
>  2) How to figure out which ones are available?  I presume I can just look
>  at the output of gpioinfo for the aforementioned mappings? 
In both cases above it should be in the docs, or at the very least the
DT in combination with the docs. In the later case they should
document what GPIOs are available for use and what the pins on the
header do similar to how the RPi document the 40 pin header there.

[Derek Atkins]

Hi,

First, thank you for all the time you're putting into helping me.
I really do appreciate it, especially since the platform is not currently
supported.

(More below)

On Mon, April 15, 2024 4:49 pm, Peter Robinson wrote:
>  On Mon, 15 Apr 2024 at 21:38, Derek Atkins <derek(a)ihtfp.com&gt;
> wrote:
> >
> > Hi,
> >
> > On Mon, April 15, 2024 4:21 pm, Peter Robinson wrote:
> >
> > >> >> >> me that the JP4 header connects to GPIO3_12, GPIO3_27,
> > GPIO6_31,
> > >> >> >> CPIO1_24,
> > >> >> >> GPIO7_8, GPIO3_26, GPIO_18, and GPIO_19.
> > >> >> >>
> > >> [snip]
> >
> > > I've not dug out a pdf to work out the physical pins and how they map
> > > to the SOC and hence the DT, I've left that up to you, I was just
> > > answering your questions about why some appear to be in use and trying
> > > to help you understand as you requested. 
By "docs", I am looking at the schematics.  Starting at JP4, we have:

JP4 4 -> GPIO3_12 -> MXM Pin 256 -> EIM_DA11 -> IMX6 NVCC_EIM2 EIM_DA11 (M20)
JP4 6 -> GPIO3_27 -> MXM Pin 258 -> GPIO3_27 -> IMX6 NVCC_EIM0 EIM_D27 (E25)
JP4 8 -> GPIO6_31 -> MXM Pin 260 -> GPIO6_31 -> IMX6 NVCC_EIM2 EIM_BCLK (N22)
JP4 10-> GPIO1_24 -> MXM Pin 262 -> MIC_DET  -> IMX6 NVCC_ENET ENET_RX_ER
(W23)
JP4 12-> GPIO7_8  -> MXM Pin 264 -> SD3_RST  -> IMX6 NVCC_SD3 SD3_RST (D15)
JP4 14-> GPIO3_26 -> MXM Pin 259 -> GPIO3_26 -> IMX6 NVCC_EIM0 EIM_D26 (E24)
JP4 16-> GPIO_18  -> MXM Pin 261 -> EIM_DA8  -> IMX6 NVCC_EIM2 EIM_DA8 (L24)
JP4 18-> GPIO_19  -> MXM Pin 263 -> GPIO_19  -> IMX6 NVCC_GPIO GPIO_19 (P5)

So clearly some of the JP4 pins get "renamed" when crossing the MXM
connector boundary, and some get renamed again when connecting to the
IMX6.  However, I still don't know how to map the e.g. IMX6 NVCC_GPIO to a
libgpiod gpiochipN.

>  In both cases above it should be in the docs, or at the very least
> the
>  DT in combination with the docs. In the later case they should
>  document what GPIOs are available for use and what the pins on the
>  header do similar to how the RPi document the 40 pin header there. 
One would expect that, but I'm having a heck of a time tracking that down.

-derek

-- 
       Derek Atkins                 617-623-3745
       derek(a)ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant