RPi4
RPi4 copied to clipboard
pftf
Cannot use the GPIOs
Hello,
I successfully installed the latest Debian 11 with the Raspberry Pi 4 UEFI firmware v1.29 today.
Now I need access to the GPIOs. Unfortunately, the access works neither via Python nor directly via sysfs. I also installed the package rpi.gpio-common, but this did not work either.
Do I have to set any parameters in config.txt or does the access not work in general?
https://github.com/raspberrypi/windows-drivers/tree/master/drivers/gpio/bcm2836 - This is the driver for GPIO, and https://github.com/raspberrypi/windows-drivers/tree/master/drivers/i2c/bcm2836 - This is the driver for I2C for HATS. Most of this predates the Pi4 by a couple of generations and is only made available to C# Namespaces if at all.
The GPIO becomes available with GpioClx (Windows.Devices.Gpio) and the I2C becomes available with SpbClx (Windows.Devices.Sensors, surprisingly not Windows.Devices.I2c).
I have a half-baked attempt at scrapping both interfaces and using IOCTL (DeviceIoControl) instead: I2CTLdev-src.zip It is only a partial merge of the I2C driver with my own IOCTL driver (which I find works well for simple message passing) (source: https://github.com/TheMindVirus/ioctl) - I really would like to see this used to power HATs and all sorts of things but it is a pain to develop.
Thank you for your reply. Unfortunately it does not help me completely, since I use Debian.
But can you tell me if you have adjusted anything in the UEFI so that you can use the GPIOs under Windows?
The only adjustments in UEFI involve changing PinMux routing to a known state at boot, nothing that can't be then changed at runtime within the OS. Debian being Linux-based also has IOCTL but it looks slightly different to Windows IOCTL. The same thing could apply but doesn't as of yet.
@TheMindVirus Can this be closed as a not-a-UEFI issue? Maybe track in windows-drivers for the Windows work ?
The linux GPIO driver doesn't have ACPI bindings, beyond that we probably need to move the DSDT GPIO definition into its own SSDT so it can be enabled/disabled based on which HAT is attached, as well as if the user selects a GPIO fan. But this gets into pin mixing too, which I think we should avoid exposing to linux.
@TheMindVirus Can this be closed as a not-a-UEFI issue? Maybe track in windows-drivers for the Windows work ?
I'm not sure about closing just yet as some of the issues are still entangled with UEFI needing to set up the pi in a consistent state for visibility to OS's. This doesn't mean using ACPI Tables and Symbols, it means providing live communication (maybe via IOCTL_SOCKET) to the chips running the GPIO, be it a memory interface or an I2C interface on a HAT.
This is not the 1st thread to contain references to the need for GPIO pin management.
Is it possible to load a GPIO text file at run time that presets GPIO.
The idea of auto-detecting HATs is mentioned elsewhere, but what about non-HAT solutions (eg i2c Fans)
Also, some way to lock out (?) OS from specific pin use based on initial settings might be needed (eg pin 14 when used as Fan Control). Is IOCTL_SOCKET a solution here?
Would a seperate SSDT help with any of the above?
FCOS needs DeviceTree to get access to GPIO, according to a docs link in that Tracker reference. I would say most other OS would too, unless there is a known ACPI way of making GPIO available (and it gets implimented), then RPi docs should reflect this also.
What is the boot style choice order when "Both" is set, ACPI then DeviceTree, or is it left to the OS, and "Both" are accessible.