Hi,
after updating CODESYS Control for Raspberry Pi SL from patch level 18 to 21 (currently 4.21.0.0), the IoDrvGPIO driver ("GPIOs B+/Pi2") can no longer open any GPIO chip on a Raspberry Pi 5. Log output on login:

Could not open GPIOChip0.
Access to path /dev/gpiochip0 not allowed. Add /dev/gpiochip0 to permitted paths in configuration file if required
Could not open GPIOChip4. Trying to open GPIOChip0
Access to path /dev/gpiochip4 not allowed. Add /dev/gpiochip4 to permitted paths in configuration file if required
Could not open any GPIOChip.

System details:
Raspberry Pi 5, 32-bit Raspberry Pi OS (armv7l), kernel 6.12.47+rpt-rpi
gpiodetect correctly shows gpiochip0 [pinctrl-rp1] (54 lines) as the RP1 GPIO controller
Runtime: CODESYS Control for Raspberry Pi SL 4.21.0.0, Runtime Toolkit SP21+

This worked without issues before the update to SP21. I've tried adding the following to CODESYSControl_User.cfg without success:
ini[CmpCharDevice]
Linux.DevicePath.1=/dev/gpiochip0
Linux.DevicePath.2=/dev/gpiochip4
Could you tell me the correct section/key to whitelist /dev/gpiochip0 (and /dev/gpiochip4) for CmpCharDevice? I suspect this is part of the general security hardening introduced around SP21 (similar to ForceIecFilePath for SysFile, or the new Gateway "accept local clients only" default), but I couldn't find it documented anywhere.
Thanks in advance!

this is probably:
https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_linux_dedicated_user.html
..switch back from rootless mode due GPIO will not work.

Hallo Herr Schwellinger - Danke für die Info. Der Fehler besteht weiterhin:
Follow-up: Rootless mode is not the cause here — verified with ps aux, the runtime binary runs as root:

root 1974 48.9 0.7 854852 62140 ? SLl 13:00 0:04 /opt/codesys/bin/codesyscontrol.bin /etc/codesyscontrol/CODESYSControl.cfg

gpioinfo gpiochip0 as root also works flawlessly (all 54 lines listed correctly, no permission errors at the kernel level). So the block is happening purely inside CmpCharDevice's own sandboxing, not at the Linux/kernel permission level and not due to a dedicated unprivileged user. The correct config key to whitelist /dev/gpiochip0 for CmpCharDevice is still what I'm looking for.

Im Voraus herzlichen Dank für Ihre Hilfe
Karl Schuler

Hallo Herr Schwellinger - Danke für die Info. Der Fehler besteht weiterhin:
Follow-up: Rootless mode is not the cause here — verified with ps aux, the runtime binary runs as root:

root 1974 48.9 0.7 854852 62140 ? SLl 13:00 0:04 /opt/codesys/bin/codesyscontrol.bin /etc/codesyscontrol/CODESYSControl.cfg

gpioinfo gpiochip0 as root also works flawlessly (all 54 lines listed correctly, no permission errors at the kernel level). So the block is happening purely inside CmpCharDevice's own sandboxing, not at the Linux/kernel permission level and not due to a dedicated unprivileged user. The correct config key to whitelist /dev/gpiochip0 for CmpCharDevice is still what I'm looking for.

Im Voraus herzlichen Dank für Ihre Hilfe
Karl Schuler

Noch eine Info dazu:
als Version der Pi MC SL wird mir 4.21.0.0 angezeigt.
In der log steht jedoch für IoDrvGPIO: 4.17.0.0
was ist das Problem?

Problem gefunden und erledigt => in CODESYSControl_User.cfg ergänzt:
[CmpCharDevice]
PermittedPath.0=/dev/i2c
PermittedPath.1=/dev/spidev
PermittedPath.2=/sys/class/gpio/
PermittedPath.3=/dev/gpiochip

Dann funktioniert es wieder
Gruß
Karl Schuler

• wird nicht mit kopiert - sorry:
  PermittedPath.0=/dev/i2c
  PermittedPath.1=/dev/spidev
  PermittedPath.2=/sys/class/gpio/
  PermittedPath.3=/dev/gpiochip

Hi, I added the following lines to /etc/codesyscontrol/CODESYSControl_User.cfg:

[CmpCharDevice]
PermittedPath.0=/dev/i2c*
PermittedPath.1=/dev/spidev*
PermittedPath.2=/sys/class/gpio/*
PermittedPath.3=/dev/gpiochip*

However, I'm still unable to read or control GPIO pins from any CODESYS application. Specifically, setting the pin direction (and, thus, the IoDrvGpioSysfs driver configuration) fails, with a rather non-descript error in the logs:

I'm running CODESYS Control for Linux ARM64 SL version 4.21.0.0; it's running in rootless mode, as the codesyscontrol user, but said user is in the gpio group and can otherwise normally interact with GPIO, both via gpioset/gpioget and via the sysfs driver in /sys/class/gpio/.
The system is a custom 64-bit Raspberry OS based distro, running on a Raspberry Pi CM5 on kernel 6.18.34 with PREEMPT_RT scheduling.

yes, this is a known issue which will be fixed with 3.5.23.0 .. soll will take some time.
You need to switch back the runtime running not as dedicated user, like it was before 4.21.0.0
How to switch back you'll find here. ('Change service user' in the deploy tool)
https://content.helpme-codesys.com/en/CODESYS%20Control/_rtsl_linux_dedicated_user.html
to sumerize both problems:
1. missing entries in CODESYSControl_Usr.cfg was the problem on Raspberry PI Runtime
2. Arm64 SL is running rootless by default since 4.21.0.0 ( Pi not by default you need to switch manually if needed due this GPIO restriction)