Raspberry Pi5

[ukscone]

I'm not sure if I can be of any use to you but I have a Raspberry Pi5 already in my hands as I was part of the test group for it. If you'd like any testing done on it i'm happy to help. I did try to get things running today from your github repo but i'm still a very newbie rust user so didn't get past the ''' Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" }) ''' running the examples which i believe is an error on how i built the library rather than the library itself

[golemparts]

Thanks for the offer! I've added all the basics, but there is only so much I can do without a physical device, or access to technical documentation.

I'm not that worried about SPI, I2C, UART and PWM support as these are handled by linux devices. GPIO however, reads/writes to the registers directly through /dev/gpiomem, and with the addition of the new RP1, I don't know if anything has changed there.

The error you received likely means one of the relevant devices in the /dev/ directory isn't available, and either hasn't been configured in /boot/config.txt, or isn't available on the Pi 5. Which one is missing depends on the peripheral the example(s) were trying to access. I did just add a commit to allow the library to detect the pinctrl-bcm2712 driver, so that could've been the reason for that error as well.

Since you mentioned you're relatively new to Rust, I suggest running the examples one by one to figure out which ones work, and which ones return an error, so we can narrow down what's causing the problem. For instance, to test the GPIO status example, run cargo run --example gpio_status.

[ukscone]

i'm not sure if /dev/gpiomem exists anymore as the new bookworm update to pios (public release due mid-october) has fully moved to libgpio.

update: just checked and yes no /dev/gpiomem BUT there is a /dev/rp1-gpiomem which i'm guessing is what we (ok you :) ) need

update1: ukscone@glooston:~/rppal $ gpiodetect 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) gpiochip5 [fsm_leds] (2 lines) ukscone@glooston:~/rppal $

[ukscone]

[ukscone]

and this is what i get running gpio_status

[golemparts]

update: just checked and yes no /dev/gpiomem BUT there is a /dev/rp1-gpiomem which i'm guessing is what we (ok you :) ) need

Hmm, I wonder if running bookworm on a Pi 4 or older will still get you a /dev/gpiomem instead of a /dev/rp1-gpiomem. The name change does make me wonder if the registers have changed significantly. Hopefully this'll become clear before the Pi 5 is released. I definitely don't want to just change the device name for the Pi 5 and hope for the best.

I think at this point the options are to wait for documentation and access to a Pi 5 at release, or consider libgpiod, assuming performance doesn't lag too far behind directly accessing the registers.

[golemparts]

and this is what i get running gpio_status

Did you update your local rppal clone with the latest commit? Just curious if the file not found error was caused by the lack of pinctrl-bcm2712 detection or something else.

[ukscone]

just did a git pull and get the same ukscone@glooston:~/rppal $ git pull remote: Enumerating objects: 15, done. remote: Counting objects: 100% (15/15), done. remote: Compressing objects: 100% (2/2), done. remote: Total 10 (delta 8), reused 10 (delta 8), pack-reused 0 Unpacking objects: 100% (10/10), 2.18 KiB | 744.00 KiB/s, done. From https://github.com/golemparts/rppal c475002..3a199de master -> origin/master Updating c475002..3a199de Fast-forward src/gpio/ioctl.rs | 2 ++ src/gpio/mem.rs | 6 +++--- 2 files changed, 5 insertions(+), 3 deletions(-) ukscone@glooston:~/rppal $ cargo run --example gpio_status Compiling rppal v0.14.1 (/home/ukscone/rppal) Finished dev [unoptimized + debuginfo] target(s) in 1.25s Runningtarget/debug/examples/gpio_status Error: PermissionDenied("/dev/mem") ukscone@glooston:~/rppal $ sudo target/debug/examples/gpio_status Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" }) ukscone@glooston:~/rppal $

[golemparts]

Thanks for all the testing so far. I think it's time to dive into https://github.com/raspberrypi/linux/pull/5618 and see what exactly has changed. Hopefully that'll give me a better picture of what I can do at this point.

My best guess is that I'm trying to look for the wrong driver name, but speculation will only get me so far 😁. I'll give that PR a read and will ping you when there's more to test. I appreciate the help!

[golemparts]

@ukscone would you mind giving https://github.com/golemparts/gpiochip a run on your Pi 5 and paste the results? It should give you a list of all available gpiochip driver names and the number of lines, similar to this

meer@flex:~/gpiochip $ cargo run
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/gpiochip`
ChipInfo { name: "gpiochip0", label: "pinctrl-bcm2711", lines: 58 }
ChipInfo { name: "gpiochip1", label: "raspberrypi-exp-gpio", lines: 8 }

We should be seeing pinctrl-bcm2712 and/or pinctrl-rp1, but I'd like to confirm.

[ukscone]

sorry for the delay. I overslept

ukscone@glooston:~ $ git clone https://github.com/golemparts/gpiochip.git Cloning into 'gpiochip'... remote: Enumerating objects: 11, done. remote: Counting objects: 100% (11/11), done. remote: Compressing objects: 100% (10/10), done. remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0 Receiving objects: 100% (11/11), 7.41 KiB | 7.41 MiB/s, done. ukscone@glooston:~ $ cd gpiochip ukscone@glooston:~/gpiochip $ cargo run Compiling libc v0.2.148 Compiling gpiochip v0.1.0 (/home/ukscone/gpiochip) Finished dev [unoptimized + debuginfo] target(s) in 2.86s Runningtarget/debug/gpiochip ChipInfo { name: "gpiochip0", label: "gpio-brcmstb@107d508500", lines: 32 } ChipInfo { name: "gpiochip1", label: "gpio-brcmstb@107d508520", lines: 4 } ChipInfo { name: "gpiochip2", label: "gpio-brcmstb@107d517c00", lines: 17 } ChipInfo { name: "gpiochip3", label: "gpio-brcmstb@107d517c20", lines: 6 } ChipInfo { name: "gpiochip4", label: "pinctrl-rp1", lines: 54 } ChipInfo { name: "gpiochip5", label: "fsm_leds", lines: 2 } ukscone@glooston:~/gpiochip $

[ukscone]

sorry that's a mess recopying

ukscone@glooston: $ git clone https://github.com/golemparts/gpiochip.git Cloning into 'gpiochip'... remote: Enumerating objects: 11, done. remote: Counting objects: 100% (11/11), done. remote: Compressing objects: 100% (10/10), done. remote: Total 11 (delta 0), reused 11 (delta 0), pack-reused 0 Receiving objects: 100% (11/11), 7.41 KiB | 7.41 MiB/s, done. ukscone@glooston:$ cd gpiochip ukscone@glooston:/gpiochip $ cargo run Compiling libc v0.2.148 Compiling gpiochip v0.1.0 (/home/ukscone/gpiochip) Finished dev [unoptimized + debuginfo] target(s) in 2.86s Running target/debug/gpiochip ChipInfo { name: "gpiochip0", label: "gpio-brcmstb@107d508500", lines: 32 } ChipInfo { name: "gpiochip1", label: "gpio-brcmstb@107d508520", lines: 4 } ChipInfo { name: "gpiochip2", label: "gpio-brcmstb@107d517c00", lines: 17 } ChipInfo { name: "gpiochip3", label: "gpio-brcmstb@107d517c20", lines: 6 } ChipInfo { name: "gpiochip4", label: "pinctrl-rp1", lines: 54 } ChipInfo { name: "gpiochip5", label: "fsm_leds", lines: 2 } ukscone@glooston:~/gpiochip $

[ukscone]

the above matches exactly what we get from libgpio's gpiodetect

ukscone@glooston:/gpiochip $ gpiodetect 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) gpiochip5 [fsm_leds] (2 lines) ukscone@glooston:/gpiochip $

[golemparts]

Awesome. I'll have it grab pinctrl-rp1 when a Raspberry Pi 5 is detected. That should fix the File not found error message.

The next hurdle is /dev/rp1-gpiomem, although it would be nice to switch over to gpiochip completely (basically the same thing libgpiod does). I do recall looking into that before and finding some issues at the time (see https://github.com/golemparts/rppal/issues/23#issuecomment-468914674 if you're interested). However, that was 4 years ago and things may have improved. I'll have a look and see if it's ready for use now, as that would be the easiest way to support GPIO going forward.

[golemparts]

Things seem to have improved a lot with the v2 API. Let's see if moving away from directly accessing gpiomem is an option now.

[ukscone]

that's great. hopefully you'll be able to get everything Pi5 compatible by the time people start getting them in their paws. i'v been slowly porting all my stuff that used python* & gpiozero to rust & rust+tauri and rppal is part of my path to a pythonfree life

*the python/pip/venv stuff on bookworm makes it a bit harder to quickly knock up a script

[golemparts]

Great to hear rppal has been useful to you! I've only dabbled in python - my background lies in C++. When I started this project ~7 years ago (it actually started out as part of the blinkt crate) I was still relatively new to Rust, and I'm still as excited about the language as when I first heard about it.

I think we'll be okay with Pi5 support for the launch date with your help. I've reached out to Raspberry Pi to see if they have any leftover review units available (and for future device releases as well), but I haven't heard back from them yet. So for now we'll have to rely on your testing, which has been invaluable so far.

[ukscone]

did a git pull just now just for the hell of it and tried gpio_status and that's looking much better :)

ukscone@glooston:~/rppal/target/debug/examples $ ./gpio_status Error: PermissionDenied("/dev/mem") ukscone@glooston:~/rppal/target/debug/examples $ sudo !! sudo ./gpio_status +------+-------+---+---------+---+-------+------+ | GPIO | Mode | L | Pin | L | Mode | GPIO | +------+-------+---+----+----+---+-------+------+ | | 3.3 V | | 1 | 2 | | 5 V | | | 2 | IN | 0 | 3 | 4 | | 5 V | | | 3 | IN | 0 | 5 | 6 | | GND | | | 4 | IN | 0 | 7 | 8 | 0 | IN | 14 | | | GND | | 9 | 10 | 0 | IN | 15 | | 17 | IN | 0 | 11 | 12 | 0 | IN | 18 | | 27 | IN | 0 | 13 | 14 | | GND | | | 22 | IN | 0 | 15 | 16 | 0 | IN | 23 | | | 3.3 V | | 17 | 18 | 0 | IN | 24 | | 10 | IN | 0 | 19 | 20 | | GND | | | 9 | IN | 0 | 21 | 22 | 0 | IN | 25 | | 11 | IN | 0 | 23 | 24 | 0 | IN | 8 | | | GND | | 25 | 26 | 0 | IN | 7 | | 0 | IN | 0 | 27 | 28 | 0 | IN | 1 | | 5 | IN | 0 | 29 | 30 | | GND | | | 6 | IN | 0 | 31 | 32 | 0 | IN | 12 | | 13 | IN | 0 | 33 | 34 | | GND | | | 19 | IN | 0 | 35 | 36 | 0 | IN | 16 | | 26 | IN | 0 | 37 | 38 | 0 | IN | 20 | | | GND | | 39 | 40 | 0 | IN | 21 | +------+-------+---+----+----+---+-------+------+ ukscone@glooston:~/rppal/target/debug/examples $

[golemparts]

Solved the file not found error at least 😁 . I wouldn't trust the GPIO data at the moment though, since the /dev/mem method still tries to access the registers directly using the old layout, which may have changed completely because of the RP1.

[golemparts]

After checking out the gpiochip v2 API interface today, I've hit the same roadblocks as with v1, with the exception of pull-ups/pull-downs, which are supported now.

As far as I can tell, gpiochip isn't able to tell when a GPIO line has been set to any of the Alt functions. It shows those as Input instead. While that isn't a major issue per se, since a GPIO line configured for an alternative function technically isn't a GPIO line anymore, the problem lies with tools such as the gpio_status example, that need to be able to show the mode and pin level for each GPIO line.

When a GPIO_V2_GET_LINE_IOCTL and a subsequent GPIO_V2_LINE_GET_VALUES_IOCTL ioctl request is sent to get the pin level of such a line, gpiochip ends up changing the mode from whatever Alt function it used to have to Input. That means gpio_status simply wouldn't work anymore, because it would overwrite any configured Alt modes to Input simply by reading their levels. It's possible I missed something, so I'll be going over this in more detail tomorrow, but considering v1 had the same issue, I think this might not be solvable. I grabbed the gpiod commandline tools to compare, but they gave me the same results.

Additionally, it looks like gpiochip doesn't see pin mode changes that were made directly through the registers until a GPIO line has been accessed at least once, requiring 2 reads. I'm not sure if this issue is worth a workaround, since it only seems to be caused by changes that were made through /dev/gpiomem, but it's definitely a concern to think about.

It basically boils down to gpiochip only offering a subset of the register access RPPAL currently uses.

Assuming there are no easy fixes for the above, that leaves me with a few options.

1. Move to gpiochip, remove any support for Alt functions, and require a GPIO mode to be set before its level can be read, which means getting rid of Pin and only having InputPin, OutputPin and IoPin. Tools like gpio_status won't work anymore with RPPAL.
2. Wait for technical documentation and add support for /dev/rp1-gpiomem. All functionality will remain the same, but the library probably won't be Pi 5 compatible on the launch date.
3. Stick with gpiochip for now, remove the above-mentioned functionality, then switch back to /dev/gpiomem and /dev/rp1-gpiomem when technical documentation has been made available. I'm not a fan of removing and adding back functionality people might be relying on, but at least everything would work eventually, and RPPAL will be ready for the Pi 5. Users with older models can stick to the current release of RPPAL.

If I had a Pi 5 here I'd probably grab the pinctrl-rp1 source and work on direct register access support based on that, but it's simply too time consuming to test with our current situation.

Open to any other suggestions if you have some.

[golemparts]

Just mulling over a 4th option, since I might be able to determine a GPIO line isn't configured as a GPIO anymore based on the name instead. For instance, GPIO 9, 10, 11 are set to Alt0 for SPI. gpiochip doesn't show the alt mode, but it does mention the appropriate functionality in the name field (SPI_MISO, SPI_MOSI, SPI_SCLK) as opposed to a GPIO line configured for GPIO having a GPIOxx name.

I could add some restrictions to what a Pin can read based on the name provided by gpiochip.

[golemparts]

Looks like the names are hardcoded. After disabling SPI and rebooting, the names remain the same even though they're not configured for SPI anymore.

[ukscone]

I'm not sure if it's any use but gpiozero v2 is compatible with the Pi5 so it might be worth looking in there to see if there is any info that'll give clues.

https://github.com/gpiozero/gpiozero/tree/pi5

[golemparts]

Thanks for the link. While I'm not experienced with python, I gave it a quick look. It seems to be using lgpio under the hood to access gpiochip, which, based on the docs, has the same limitations as mentioned above - it only recognizes and works with input and output pins.

[golemparts]

Hm... Option 5, switch to gpiochip, leave Pin as-is except for the ability to read the current pin level. That way, anyone reading the level will have to make a conscious decision to set a specific mode for the pin through into_input / into_output / into_io. No pin levels anymore for gpio_status, but it can still show input/output as reported by gpiochip, and the overall structure of the Gpio module remains mostly the same.

[golemparts]

Btw, I've updated https://github.com/golemparts/gpiochip with the code I've been testing. If you look at https://github.com/golemparts/gpiochip/blob/main/src/main.rs, you'll see a commented out section that'll retrieve the GPIO pin levels. Uncommenting it causes any alt-configured pins to be changed to inputs.

[ukscone]

oh btw not sure if you realized that once pios (bookworm) is released libgpio and thus gpiochip (&gpiomem probably) will be the way for the gpio on the pi (all models) any other methods will go away. i think you are ok with the pi1 to pi4 but just wanted to make sure you were aware :)

[ukscone]

Btw, I've updated https://github.com/golemparts/gpiochip with the code I've been testing. If you look at https://github.com/golemparts/gpiochip/blob/main/src/main.rs, you'll see a commented out section that'll retrieve the GPIO pin levels. Uncommenting it causes any alt-configured pins to be changed to inputs.

remote: Enumerating objects: 13, done. remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 100% (7/7), done. remote: Total 9 (delta 4), reused 7 (delta 2), pack-reused 0 Unpacking objects: 100% (9/9), 5.33 KiB | 1.78 MiB/s, done. From https://github.com/golemparts/gpiochip 0f7ec31..fcd6b6d main -> origin/main Updating 0f7ec31..fcd6b6d Fast-forward src/ioctl.rs | 615 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--------------------------------------- src/main.rs | 48 ++++++++--- 2 files changed, 476 insertions(+), 187 deletions(-) ukscone@glooston:~/gpiochip $ cargo run Compiling gpiochip v0.1.0 (/home/ukscone/gpiochip) Finished dev [unoptimized + debuginfo] target(s) in 0.66s Running target/debug/gpiochip ChipInfo: "gpiochip4" "pinctrl-rp1" 54 0: ID_SD Consumer:[] Flags:[input] 1: ID_SC Consumer:[] Flags:[input] 2: PIN3 Consumer:[] Flags:[input] 3: PIN5 Consumer:[] Flags:[input] 4: PIN7 Consumer:[onewire@0] Flags:[used output open_drain] 5: PIN29 Consumer:[] Flags:[input] 6: PIN31 Consumer:[] Flags:[input] 7: PIN26 Consumer:[spi0 CS1] Flags:[used active_low output] 8: PIN24 Consumer:[spi0 CS0] Flags:[used active_low output] 9: PIN21 Consumer:[] Flags:[input] 10: PIN19 Consumer:[] Flags:[input] 11: PIN23 Consumer:[] Flags:[input] 12: PIN32 Consumer:[] Flags:[input] 13: PIN33 Consumer:[] Flags:[input] 14: PIN8 Consumer:[] Flags:[input] 15: PIN10 Consumer:[] Flags:[input] 16: PIN36 Consumer:[] Flags:[input] 17: PIN11 Consumer:[] Flags:[input] 18: PIN12 Consumer:[] Flags:[input] 19: PIN35 Consumer:[] Flags:[input] 20: PIN38 Consumer:[] Flags:[input] 21: PIN40 Consumer:[] Flags:[input] 22: PIN15 Consumer:[] Flags:[input] 23: PIN16 Consumer:[] Flags:[input] 24: PIN18 Consumer:[] Flags:[input] 25: PIN22 Consumer:[] Flags:[input] 26: PIN37 Consumer:[] Flags:[input] 27: PIN13 Consumer:[] Flags:[input]

[golemparts]

oh btw not sure if you realized that once pios (bookworm) is released libgpio and thus gpiochip (&gpiomem probably) will be the way for the gpio on the pi (all models) any other methods will go away. i think you are ok with the pi1 to pi4 but just wanted to make sure you were aware :)

Yeah, thankfully I moved away from using sysfs years ago. I think I'll just have to switch to gpiochip for now on systems that have the v2 API available (another thing to check for. good thing bookworm is required for the Pi 5 at least), and reassess /dev/gpiomem and /dev/rp1-gpiomem at a later date. I'll have to remove some of RPPAL's functionality, but considering how widely gpiochip / libgpiod are used, at least we'll all be in the same boat. 😁

[golemparts]

I've also come across https://github.com/raspberrypi/utils/tree/master/pinctrl after spotting Gadgetoid's fancy new CLI tool that uses its data. Unfortunately it requires sudo, so not really an option, but its source is a good starting point for eventual /dev/rp1-gpiomem support as I assume the register layout is the same.

[golemparts]

After sleeping on it, I think the best way forward is to make gpiochip the default interface used by the Gpio module, which means I'll have to remove the above-mentioned functionality. The existing gpiomem interface, including the removed functionality, will be put behind a feature flag, so older systems that don't have the v2 API or users that require the removed functionality are still able to use RPPAL the same way as before.

I'll let you know when the library is ready for some Pi 5 testing.

[ukscone]

two documents have been released today that might be of use to you (disclaimer: not read them myself yet) https://datasheets.raspberrypi.com/rp1/rp1-peripherals.pdf rp1-peripheral and https://datasheets.raspberrypi.com/bcm2711/bcm2711-peripherals.pdf bcm2711 peripherals

[golemparts]

Oh wow. I thought we weren't getting any RP1 documentation for weeks. That is going to be very helpful for adding rp1-gpiomem support. This certainly changes things. I should be able to add support for reading/writing to the registers directly based on this, which means gpiochip and its limitations won't be an issue anymore.

Would you mind checking if /dev/rp1-gpiomem has properly configured file permissions? I would expect its group to be set to gpio with read/write permissions.

[ukscone]

ukscone@glooston:/dev $ ls -al /dev/rp1-gpiomem crw-rw---- 1 root gpio 240, 0 Oct 6 10:41 /dev/rp1-gpiomem ukscone@glooston:/dev $

[golemparts]

Just to give you a quick update, I've had a busy week because of unrelated work stuff, but I should have some time over the next few days to get this up and running. I've made some initial internal changes to use a different gpiomem interface based on the Pi model, but I haven't implemented any specific functionality for the Pi 5 yet.

Based on what I found in the DTs and the documentation I think I have an accurate idea of the rp1-gpiomem layout, but misinterpretation and bugs are possible, so we should take things slow when testing this. Will ping you when it's time to run gpio_status 😁

[ukscone]

i'll be out and about on Saturday but apart that that i'm at your beck and call :)

[golemparts]

@ukscone I implemented all the needed functionality to work with rp1-gpiomem. The internal interface is a lot more involved compared to the old gpiomem so there's a higher chance for bugs, but we'll have to start testing to find any issues at this point since the code looks good to me.

While reading from the registers should be safe, there is a risk when changing modes / levels / bias. Values could be written to the wrong register, causing unexpected results. If you'd rather stick to only testing read operations, I completely understand.

When you have some time, you can update your local rppal repo and run cargo run --example gpio_status. Assuming you have some pins configured for I2C, SPI, as outputs, etc, you should be seeing the appropriate Alt modes or Input/Output and the pin levels in the output.

Should we run into any unsolvable issues, I'll probably ask you to dump the contents of rp1-gpiomem to a file so I can use that to do some debugging on my side. It's not perfect, but it beats having no test data at all.

EDIT: That should be cargo run --example gpio_status of course ;)

[ukscone]

heh you are not going to believe this. switched to bookworm release image rather than the beta image i had been using and the rp1-gpiomem has gone away :)

ukscone@glooston:~/rppal $ cargo run --example gpio_status Updating crates.io index Downloaded simple-signal v1.1.1 Downloaded lazy_static v1.4.0 Downloaded libc v0.2.149 Downloaded 3 crates (729.2 KB) in 1.00s Compiling libc v0.2.149 Compiling lazy_static v1.4.0 Compiling rppal v0.14.1 (/home/ukscone/rppal) Compiling simple-signal v1.1.1 Finished dev [unoptimized + debuginfo] target(s) in 6.45s Running target/debug/examples/gpio_status Error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

smh

we now have 5 gpiomems -- gpiomem0-4

lol it doesn't rain it pours :)

[golemparts]

Well, on the bright side, at least that matches with the bcm2712-rpi.dtsi I've been basing some of this on. gpiomem0 should contain the same stuff. I'll make the change and we can see what roadblock we run into next. 😁

[golemparts]

Should be good to go now.

[ukscone]

the libgpiod tool gpioinfo shows this on the release image

ukscone@glooston:~/rppal $ gpioinfo gpiochip0 - 32 lines: line 0: "-" unused input active-high line 1: "2712_BOOT_CS_N" "spi10 CS0" output active-low [used] line 2: "2712_BOOT_MISO" unused input active-high line 3: "2712_BOOT_MOSI" unused input active-high line 4: "2712_BOOT_SCLK" unused input active-high line 5: "-" unused input active-high line 6: "-" unused input active-high line 7: "-" unused input active-high line 8: "-" unused input active-high line 9: "-" unused input active-high line 10: "-" unused input active-high line 11: "-" unused input active-high line 12: "-" unused input active-high line 13: "-" unused input active-high line 14: "PCIE_SDA" unused input active-high line 15: "PCIE_SCL" unused input active-high line 16: "-" unused input active-high line 17: "-" unused input active-high line 18: "-" unused input active-high line 19: "-" unused input active-high line 20: "PWR_GPIO" "pwr_button" input active-low [used] line 21: "2712_G21_FS" unused input active-high line 22: "-" unused input active-high line 23: "-" unused input active-high line 24: "BT_RTS" unused input active-high line 25: "BT_CTS" unused input active-high line 26: "BT_TXD" unused input active-high line 27: "BT_RXD" unused input active-high line 28: "WL_ON" "wl_on_reg" output active-high [used] line 29: "BT_ON" "shutdown" output active-high [used] line 30: "WIFI_SDIO_CLK" unused input active-high line 31: "WIFI_SDIO_CMD" unused input active-high gpiochip1 - 4 lines: line 0: "WIFI_SDIO_D0" unused input active-high line 1: "WIFI_SDIO_D1" unused input active-high line 2: "WIFI_SDIO_D2" unused input active-high line 3: "WIFI_SDIO_D3" unused input active-high gpiochip2 - 17 lines: line 0: "RP1_SDA" unused input active-high line 1: "RP1_SCL" unused input active-high line 2: "RP1_RUN" "RP1 RUN pin" output active-high [used] line 3: "SD_IOVDD_SEL" "vdd-sd-io" output active-high [used] line 4: "SD_PWR_ON" "sd_vcc_reg" output active-high [used] line 5: "SD_CDET_N" unused input active-high line 6: "SD_FLG_N" unused input active-high line 7: "-" unused input active-high line 8: "2712_WAKE" unused input active-high line 9: "2712_STAT_LED" "ACT" output active-low [used] line 10: "-" unused input active-high line 11: "-" unused input active-high line 12: "PMIC_INT" unused input active-high line 13: "UART_TX_FS" unused input active-high line 14: "UART_RX_FS" unused input active-high line 15: "-" unused input active-high line 16: "-" unused input active-high gpiochip3 - 6 lines: line 0: "HDMI0_SCL" unused input active-high line 1: "HDMI0_SDA" unused input active-high line 2: "HDMI1_SCL" unused input active-high line 3: "HDMI1_SDA" unused input active-high line 4: "PMIC_SCL" unused input active-high line 5: "PMIC_SDA" unused input active-high gpiochip4 - 54 lines: line 0: "ID_SD" unused input active-high line 1: "ID_SC" unused input active-high line 2: "PIN3" unused input active-high line 3: "PIN5" unused input active-high line 4: "PIN7" unused input active-high line 5: "PIN29" unused input active-high line 6: "PIN31" unused input active-high line 7: "PIN26" "spi0 CS1" output active-low [used] line 8: "PIN24" "spi0 CS0" output active-low [used] line 9: "PIN21" unused input active-high line 10: "PIN19" unused input active-high line 11: "PIN23" unused input active-high line 12: "PIN32" unused input active-high line 13: "PIN33" unused input active-high line 14: "PIN8" unused input active-high line 15: "PIN10" unused input active-high line 16: "PIN36" unused input active-high line 17: "PIN11" unused input active-high line 18: "PIN12" unused input active-high line 19: "PIN35" unused input active-high line 20: "PIN38" unused input active-high line 21: "PIN40" unused input active-high line 22: "PIN15" unused input active-high line 23: "PIN16" unused input active-high line 24: "PIN18" unused input active-high line 25: "PIN22" unused input active-high line 26: "PIN37" unused input active-high line 27: "PIN13" unused input active-high line 28: "PCIE_RP1_WAKE" unused input active-high line 29: "FAN_TACH" unused input active-high line 30: "HOST_SDA" unused input active-high line 31: "HOST_SCL" unused input active-high line 32: "ETH_RST_N" "phy-reset" output active-low [used] line 33: "-" unused input active-high line 34: "CD0_IO0_MICCLK" "cam0_reg" output active-high [used] line 35: "CD0_IO0_MICDAT0" unused input active-high line 36: "RP1_PCIE_CLKREQ_N" unused input active-high line 37: "-" unused input active-high line 38: "CD0_SDA" unused input active-high line 39: "CD0_SCL" unused input active-high line 40: "CD1_SDA" unused input active-high line 41: "CD1_SCL" unused input active-high line 42: "USB_VBUS_EN" unused output active-high line 43: "USB_OC_N" unused input active-high line 44: "RP1_STAT_LED" "PWR" output active-low [used] line 45: "FAN_PWM" unused output active-high line 46: "CD1_IO0_MICCLK" "cam1_reg" output active-high [used] line 47: "2712_WAKE" unused input active-high line 48: "CD1_IO1_MICDAT1" unused input active-high line 49: "EN_MAX_USB_CUR" unused output active-high line 50: "-" unused input active-high line 51: "-" unused input active-high line 52: "-" unused input active-high line 53: "-" unused input active-high

[ukscone]

[golemparts]

Nice! GPIO 9, 10 and 11 marked as Alt0 is exactly as it should be when you have SPI enabled. Looks like it's reading the correct data.

[ukscone]

it seems to be doing all the right things. i've asked in the pi forums what's up with the rp1-gpiomem vanishing and multiple gpiomems. it makes life easier in the end not to have to have two different gpiomems to have to check for but i don't recall it being mentioned anywhere and i thought the rp1 doc mentioned rp1-gpiomem

[golemparts]

Considering read operations work as expected, that leaves write operations.

That will either require some coding (or using any of your existing code), or using the gpio_blinkled or gpio_blinkled_signals examples with an LED and resistor attached to GPIO 23 (physical pin 16) to see if changing modes and levels works. Another thing to double check would be to write some code to check the level on an input pin while it changes between high and low. It would also be helpful if you could test enabling a pull-up or pull-down and physically checking the voltage on the pin.

Let me know if you need any help with writing up some sample code.

[ukscone]

i'll dig out some leds, jumper wires and breadboard

[golemparts]

it seems to be doing all the right things. i've asked in the pi forums what's up with the rp1-gpiomem vanishing and multiple gpiomems.

Yeah the whole naming convention is a bit vague to me, but I can at least see the point in using a different name for gpiomem on older Pi models compared to the Pi 5, considering the registers are completely different. On my Pi 4 running Bookworm I'm still only seeing the old gpiomem without any suffix, so at least no changes are needed there. As long as they've settled on this scheme we should be okay.

[ukscone]

gpio_blinkled & gpio_blinkled_signals are blinking an led :)

so gpio23 is working :)

[golemparts]

Awesome! Thanks for the quick test results. I'm glad it's all going smoothly. That means both mode changes and level changes are working. That just leaves checking an input pin's level with the level getting changed between high and low by some external source, and checking the voltage on an input pin with pull-up/pull-down enabled, both of which will require some coding and external parts/multimeter (happy to help if needed).

It sounds like it's all working as expected though. After you get a chance to check the above-mentioned, that should be the entire GPIO module ready for the Pi 5! While I don't expect any major issues with the other peripherals, if you have any hardware lying around that would let you perform some tests on SPI/I2C/PWM/UART, it would be good to confirm they're still working before launch day.

BTW, the new GPIO registers also give us access to a few new toys (change output drive strength, input Schmitt trigger hysteresis, output slew rate limiter, debounce), but I'll wait until I have my hands on a Pi 5 as well before adding support for those, so something to look forward to for 0.16.0. 😁

[ukscone]

i'll dig out all my bits and pieces tomorrow and start playing. i have a few i2c & spi displays & sure i have a few pwm thingies just a matter of finding them

[ukscone]

dug out my ds3231 and the example i2c_ds3231.rs seems to work as expected