Use gpiochip0 for the user-facing GPIOs on Pi 5

[pelwell]

Pi 5 contains multiple GPIO controllers; running gpiodetect shows that there are five. Prior to this patch set, they appear like this:

gpiochip0 [gpio-brcmstb@107d508500] (32 lines)
gpiochip1 [gpio-brcmstb@107d508520] (4 lines)
gpiochip2 [gpio-brcmstb@107d517c00] (17 lines)
gpiochip3 [gpio-brcmstb@107d517c20] (6 lines)
gpiochip4 [pinctrl-rp1] (54 lines)

Notice how pinctrl-rp1 - the driver for the GPIOs that appear on the 40-pin header - is shown as gpiochip4. This is not user-friendly, requiring careful handling when trying to locate a particular GPIO via libgpiod.

This patch set adds the ability to override the gpiochip numbers using DT aliases, just as is done for I2C, SPI etc. It also adds a gpiochip0 alias to pinctrl-rp1. changing the gpiochip numbering to this:

gpiochip0 [pinctrl-rp1] (54 lines)
gpiochip1 [gpio-brcmstb@107d508500] (32 lines)
gpiochip2 [gpio-brcmstb@107d508520] (4 lines)
gpiochip3 [gpio-brcmstb@107d517c00] (17 lines)
gpiochip4 [gpio-brcmstb@107d517c20] (6 lines)

P.S. There's now an additional commit that sets the base of the SoC gpiochips to 10, for two reasons:

1. it makes it more clear that these are system resources, like i2c10 and spi10, and
2. there will no longer be a gpiochip4, preventing any existing code that chooses gpiochip4 on a Pi 5 from changing the wrong GPIOs accidentally.

With this commit, the final picture is:

gpiochip0 [pinctrl-rp1] (54 lines)
gpiochip10 [gpio-brcmstb@107d508500] (32 lines)
gpiochip11 [gpio-brcmstb@107d508520] (4 lines)
gpiochip12 [gpio-brcmstb@107d517c00] (17 lines)
gpiochip13 [gpio-brcmstb@107d517c20] (6 lines)

[6by9]

Are we not risking breaking existing users who have hard coded gpiochip4 into their library? I'm looking at https://github.com/gpiozero/gpiozero/blob/master/gpiozero/pins/lgpio.py#L66 for example.

@waveform80 would probably have a better knowledge of the current assumptions made.

[pelwell]

Heads up, @waveform80. I see that rpi-lgpio selects gpiochip0 by default on BCM2712. Would you be happy making it fall back to gpiochip0 if gpiochip4 is not found? I'd like to think the main gpiolib patch would be acceptable upstream, and I think it lowers the barrier-to-entry a bit more for people switching from sysfs.

[waveform80]

Yes, I'm afraid gpiozero and rpi-lgpio both assume gpiochip4 at the moment (which is almost certainly terrible laziness on my part, but the latter in particular has been a bit of a rush-job).

I did something slightly more respectable for our GPIO udev rules, filtering on the driver, and ideally I think something similar should work for the two libraries, by querying sysfs (e.g. /sys/bus/gpio/devices/gpiochip4/of_node/compatible). Something like:

• If a gpiochip is specified explicitly, use it. If it fails, die with exception (don't second-guess explicit requests)
• If a gpiochip is not specified explicitly, find first gpiochip with a driver {rpi1-gpio, bcm2835-gpio, bcm2711-gpio} and try that (some nuance there if multiple devices with such a driver exist, and we can't access the first one)
• If that fails, fall back to gpiochip0
• If that fails, die with exception

I'll see what I can do about pushing a fix out to the libraries in the next few days.

[pelwell]

The issue of discovering the user-facing GPIOs, the subject of this PR, came up again today. How are people feeling about the possibility of this being merged in the near future?

[waveform80]

Let me double-check I've got things in place. I definitely have in rpi-lgpio but I think I forgot to release a version of gpiozero with this in place. I'll have a look this evening!

[pelwell]

If there are no objections, this will be merged next week.

[ragazenta]

Sorry if I ask in the wrong place, when will these changes uploaded to APT repository? I hope it will soon. Thanks.

[popcornmix]

We don't have a specific date planned. In "some" weeks time is my guess.

[HiassofT]

quick heads up: gpiozero using the lgpio pin factory (recommended default on RPiOS) is currently broken due to this change, I've created a gpiozero issue https://github.com/gpiozero/gpiozero/issues/1166

[L4wnmower]

Yesternights RPi kernel bump from 6.6.31 to 6.6.47 effectively broke gpiozero. Python PWM-control is currently dead-in-the-water

[pelwell]

So 4 months' notice was not enough?

[L4wnmower]

Sadly

[pelwell]

I didn't see this coming - WiringPi got there first: https://github.com/WiringPi/WiringPi/releases

[L4wnmower]

I'm glad they did! From things I've read, I thought that project was faltering. Those good reflexes are a healthy sign

[mstroh76]

can’t an alias be created from gpiochip4 to gpiochip0? That would solve all the problems, making both gpiochip0 and gpiochip4 functional,

[pelwell]

can’t an alias be created from gpiochip4 to gpiochip0?

Not without adding some potentially large hack to the kernel code. The client-side fix is much easier.

[mstroh76]

I understand that it is a large hack, but I would like to point out that a client-side fix means that:

• All internet blogs/guides
• YouTube tutorials
• Books
• libgpiod guides and programs
• GPIO libraries

need to implement these changes.

Furthermore, there is the problem that if the client is changed, one cannot assume that Kernel 6.6.47 is installed. The current Pi OS image (July 4th, 2024) still contains the old kernel. With older kernel versions, gpiochip0 can be opened, but this is the wrong chip. To be sure, a check of the chip label must be performed.

For me, however, this topic is now closed.

[lurch]

I suspect that most internet blogs / YouTube tutorials / etc. are simply using a 3rd-party library (e.g. GpioZero) rather than making low-level libgpiod calls directly; so once GpioZero is fixed to work with this kernel change, all that tutorial content will be totally fine again!

With older kernel versions, gpiochip0 can be opened, but this is the wrong chip. To be sure, a check of the chip label must be performed.

Yes, that's exactly what https://github.com/waveform80/rpi-lgpio/commit/bb7ff0e2072eb15ad81c713201a2616e69c464a8 does, and I assume the eventual GpioZero fix will be similar.

[pelwell]

It turns out that we may be able to put a workaround into RPiOS - watch this space.

[pelwell]

sudo apt update and sudo apt full-upgrade should get you a working gpiozero. It's a belt-and-braces (suspenders, for non Brits) double fix:

1. The version of gpiozero installed includes an unofficial patch for the problem.
2. There's a udev rule that creates a symbolic link from gpipchip4 to gpiochip0. This has the minor unwanted side-effect that gpiochip0 shows up twice when running gpioinfo and gpiodetect, but it should fix the problem for apps and libraries other than gpiozero.

[lgeitner]

Meteo-pi on a Raspberry Pi 5 still does not work with the above changes!

pi@cumulusmxkitchen:~ $ gpiodetect gpiochip0 [pinctrl-rp1] (54 lines) gpiochip10 [gpio-brcmstb@107d508500] (32 lines) gpiochip11 [gpio-brcmstb@107d508520] (4 lines) gpiochip12 [gpio-brcmstb@107d517c00] (17 lines) gpiochip13 [gpio-brcmstb@107d517c20] (6 lines) gpiochip0 [pinctrl-rp1] (54 lines)

[pelwell]

That looks like a commercial product - have you reported the problem to the manufacturer?

[lgeitner]

I have reported the problem to both the developer of cumulusmx https://cumulus.hosiene.co.uk/viewtopic.php?t=22529 and have sent an email to the manufacturer of the meteo-pi.

[L4wnmower]

sudo apt update and sudo apt full-upgrade should get you a working gpiozero. It's a belt-and-braces (suspenders, for non Brits) double fix:

1. The version of gpiozero installed includes an unofficial patch for the problem.
2. There's a udev rule that creates a symbolic link from gpipchip4 to gpiochip0. This has the minor unwanted side-effect that gpiochip0 shows up twice when running gpioinfo and gpiodetect, but it should fix the problem for apps and libraries other than gpiozero.

After upgrading, gpiozero's PWM is back in working order. Well Done!

[lgeitner]

I use the below dtparam and dtoverlay in my config.txt

Is it possible whoever created the below dtparam for uart0 and uart0_console hard coded a reference to gpiochip4? Is it possible whoever created the below dtoverlay for uart0-pi5 hard coded a reference to gpiochip4?

Can the dtparam and dtoverlay reference the udev rule that was created? Would that explain why the udev rule doesn't seem to work?

Here is what i have in my config.txt

/boot/firmware/config.txt

dtparam=uart0=on dtparam=uart0_console=on dtoverlay=uart0-pi5

Thanks, Lance

[lgeitner]

That looks like a commercial product - have you reported the problem to the manufacturer?

I have contacted the manufacturer of the meteo-pi

Here is the response from the manufacturer:

MeteoPi is just connectivity tool. It provides wires from Console's UART TX and RX, to RP UART RX and TX on PIN 8(GPIO14), and 10(GPIO15). If you want to use MeteoPi with it, you have to do something to enable UART on Pins 8(GPIO14) and 10(GPIO15), because there are connected wires.

I enable uart on Pins 8(GPIO14) and 10(GPIO15) with the following lines in the config.txt as mentioned above.

dtparam=uart0=on dtparam=uart0_console=on dtoverlay=uart0-pi5

I contacted the developer of Cumulusmx and asked if there where any hard coded references to gpiochip4 in the cumulusmx software and he said no.

Thanks, Lance

[pelwell]

It doesn't sound as though MeteoPi is using GPIOs - just a UART.

To enable UART0 on GPIOs 14 & 15 (pins 8 & 10) on a Pi 5, all you need is:

dtparam=uart0=on

Enabling the console on that UART may interfere with however MeteoPi is using it, but if you do want to be able to log in over that UART then you should use:

dtparam=uart0_console=on

You don't need to keep dtparam=uart0=on because that is a part of the uart0_console parameter, but there is no harm in doing so.

[lgeitner]

the meteopi uses the gpio on the Raspberry PI 5. It uses the Uart0 on GPIO 14(pins 8) and GPIO 15(pin 10).

uart0_console is a dtparam that enables uart0, maps it to GPIOs 14 & 15, and makes it the "console" UART (i.e. serial0 points to it).

please see this topic for details. https://forums.raspberrypi.com/viewtopic.php?t=359132&start=25

Unfortunately, this is a major breaking change for me! Is there someplace I can report this issue to?

Thanks, Lance

[pelwell]

the meteopi uses the gpio on the Raspberry PI 5. It uses the Uart0 on GPIO 14(pins 8) and GPIO 15(pin 10).

Using two pins for UART does not amount to using GPIO in the strictest sense. GPIO standards for General Purpose Input/Output, and it allows software to set or read the level on a pin.

uart0_console is a dtparam that enables uart0, maps it to GPIOs 14 & 15, and makes it the "console" UART (i.e. serial0 points to it).

I know - I created uart0_console, and the whole dtoverlay/dtparam mechanism.

Is there someplace I can report this issue to?

Here, and you have done, but arguing with the people trying to help is not a good way to go about it.

[lgeitner]

I am very grateful for the help you have been giving me.

Would there be any log files I could generate and send to you that may help to diagnose the reason the meteopi no longer works?

Thanks, Lance