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-revb1... 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
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-revb1... 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
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-revb1... 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
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-revb1... 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/arch...
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/arch...
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/arch...
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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
Hi Peter,
On Mon, April 15, 2024 1:47 pm, Peter Robinson wrote:
I'm using https://download.technexion.com/development_resources/wandboard/wbquad-revb1... 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/arch...
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/arch...
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
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-revb1... 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/arch...
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/arch...
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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Mon, 15 Apr 2024 at 19:39, Derek Atkins derek@ihtfp.com 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-revb1... 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/arch...
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/arch...
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@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
-- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
On Mon, 15 Apr 2024 at 19:12, Derek Atkins derek@ihtfp.com 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-revb1... 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/arch...
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/arch...
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.
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
On Mon, 15 Apr 2024 at 21:38, Derek Atkins derek@ihtfp.com 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:
- 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?
- 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.
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@ihtfp.com 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 -
Peter Robinson