Access to GPIO/I2C fails with latest version of RaspiOS image 2024-10-28 with Raspberry Pi 5

[ciacco85]

Describe the bug
It was ok with previous versions unitl 2024-07-04.
This bug was found using I2C with PN532.
The code runs in a container under IotHub module.

Before entering in details, I've inspected LibGpiodDriver source code for Raspberry 5

 case RaspberryBoardInfo.Model.RaspberryPi5:

                // For now, for Raspberry Pi 5, we'll use the LibGpiodDriver.
                // We need to create a new driver for the Raspberry Pi 5,
                // because the Raspberry Pi 5 uses an entirely different GPIO controller (RP1)
                return new LibGpiodDriver(4);

So I've analyzed these libraries both on host

gpiod/stable,now 1.6.3-1+b3 arm64 [installed]
libgpiod2/stable,now 1.6.3-1+b3 arm64 [installed,automatic]
liblgpio1/stable,now 0.2.2-1~rpt1 arm64 [installed,automatic]
libpigpio-dev/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
libpigpio1/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
libpigpiod-if-dev/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
libpigpiod-if1/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
libpigpiod-if2-1/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
pigpio-tools/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
pigpio/stable,now 1.79-1+rpt1 arm64 [installed]
pigpiod/stable,now 1.79-1+rpt1 arm64 [installed,automatic]
python3-gpiozero/stable,stable,now 2.0.1-0+rpt1 all [installed]
python3-lgpio/stable,now 0.2.2-1~rpt1 arm64 [installed,automatic]
python3-libgpiod/stable,now 1.6.3-1+b3 arm64 [installed]
python3-pigpio/stable,stable,now 1.79-1+rpt1 all [installed]
python3-rpi-lgpio/stable,stable,now 0.6-0~rpt1 all [installed]
raspi-gpio/stable,now 0.20231127 arm64 [installed]

and inside the container

libgpiod-dev/stable,now 1.6.3-1+b3 arm64 [installed]
libgpiod2/stable,now 1.6.3-1+b3 arm64 [installed,automatic]

This happens for all version of RaspiOS.
After a lot of attempt, the only solution was to rollback the RaspiOS version (starting form a clean install)

I can detect I2C both on the host and inside a simple container run with the following command sudo docker run -it --privileged mcr.microsoft.com/dotnet/runtime-deps:8.0.10-bookworm-slim-arm64v8 after installing the tool with

apt update
apt-get install i2c-tools

and running

i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

Steps to reproduce

I2cDevice? _i2cDevice = I2cDevice.Create(new I2cConnectionSettings(1, Pn532.I2cDefaultAddress));
if (_i2cDevice != null)
{
    _logger.LogInformation(_i2cDevice.QueryComponentInformation().ToString());
}

The application run inside a simple autogenerated docker file with visual studio applied to a console application and adding these lines to the base image

RUN apt-get update \
    && apt install -y sudo libgpiod-dev
RUN sudo /bin/su -c "echo 'vm.max_map_count=262144' >> /etc/sysctl.conf"

Expected behavior

{System.Device.I2c.UnixI2cDevice} Unix I2C device
Is it a PN532!: True, Version: 1.6, Version supported: IsoIec14443TypeA, IsoIec14443TypeB, Iso18092

Actual behavior

Exception with the following stack trace

[11-11 13:22:45 Production velletri-1 Information] {System.Device.I2c.UnixI2cDevice} Unix I2C device
11/11/2024 14:22:45 +01:00 System.IO.IOException: Unable to find a chip, error code: 2
   at System.Device.Gpio.Drivers.Libgpiod.V1.LibGpiodV1Driver..ctor(Int32 gpioChip)
   at System.Device.Gpio.Drivers.LibGpiodDriverFactory.CreateInternal(LibGpiodDriverVersion version, Int32 chipNumber)
   at System.Device.Gpio.Drivers.LibGpiodDriverFactory.CreateAutomaticallyChosenDriver(Int32 chipNumber)
   at System.Device.Gpio.Drivers.LibGpiodDriverFactory.Create(Int32 chipNumber)
   at System.Device.Gpio.Drivers.LibGpiodDriver..ctor(Int32 gpioChip)
   at System.Device.Gpio.GpioController.GetBestDriverForBoardOnLinux()
   at System.Device.Gpio.GpioController.GetBestDriverForBoard()
   at System.Device.Gpio.GpioController..ctor(PinNumberingScheme numberingScheme)
   at System.Device.Gpio.GpioController..ctor()

Versions used
all current latest version 3.2.0 of System.Device and net8

[Ellerbach]

Couple of remarks:

• The issue doesn't seems related to I2C as it's not using Libgpiod.
• The error is because you are indeed trying to open a GpioController. See here:

  iot/src/devices/Pn532/Pn532.cs

  Line 160 in ddb69e5

  public Pn532(SpiDevice spiDevice, int pinChipSelect, GpioController? controller = null, bool shouldDispose = false, bool checkVersion = true)

  . As you need as well a pin, then pin, a GpioControler is created.

Couple of questions:

• Does the access work without the container on the new versions? Install the i2c-tools on the image and check if it detects. And if you can run the code natively, without the container, it will prove that you have all needed elements.
• If previous point work fine, make sure you also install Libgpiod in the container. And try again
• Has there been any change on the security model, privilege is not necessary enough? In a recent project (Windows + WSL with containers), I faced similar issues with security. See this: https://github.com/nanoframework/nanoFramework.IoT.TestStream/tree/main/agent#accessing-serial-port-from-the-container. You may have to explicitly give access to the GPIO bus. That project was with serial ports, but the principle is the same.

Hopefully one of this way will help you find out the problem.

[ciacco85]

@Ellerbach thanks for the precious suggestions, they have helped me a lot.
I've understood that the issue is with GPIOController, not I2CDevice (little dependancy injection hell, my bad), especially with LibGpiodDriver ctor.
The issue is still present with the newer version os RaspiOS Lite 2024-11-19
I'll close this one and open up a new more pertinent issue from scratch soon.
Thanks