Hi, I've problems with using GPIO from python. It just throws some memory error and dumps. I'm not familiar with C/dumps and so on, so I did not yet start to try to get details of it.
One thing I noticed is different content of /proc/cpuinfo between Raspbian and Fedora 25. Thus my interpretation is that if Fedora reports a bit different hardware then some calls to some methods might fail. Am I missing some step that should be done after install?
It could be some mutation of FAQ: about support for HATs. But I would love clear statement, which would point that it just does not work out-of-the-box and there is/isn't way to manually fix it for someone who is not C/kernel developer. As for me support for HATs and support to set GPIO pin 18 to HIGH state are slightly different things. But maybe they have same root cause.
Regards Jan
On Tue, Dec 6, 2016 at 8:08 AM, Jan spljaa@gmail.com wrote:
Hi, I've problems with using GPIO from python. It just throws some memory error and dumps. I'm not familiar with C/dumps and so on, so I did not yet start to try to get details of it.
One thing I noticed is different content of /proc/cpuinfo between Raspbian and Fedora 25. Thus my interpretation is that if Fedora reports a bit different hardware then some calls to some methods might fail. Am I missing some step that should be done after install?
It could be some mutation of FAQ: about support for HATs. But I would love clear statement, which would point that it just does not work out-of-the-box and there is/isn't way to manually fix it for someone who is not C/kernel developer. As for me support for HATs and support to set GPIO pin 18 to HIGH state are slightly different things. But maybe they have same root cause.
I've not had time to test GPIO, what python libraries are you using to access it? Basically some more details would be useful.
Hi, It was standard package that provides RPi.GPIO for python. I think I checked versions both from dnf and pip.
I do understand that to debug my configuration I would need to collect more data.
My question was more about current user's experiences. Does interaction with GPIO is expected to work. Which is needed step before jumping into problem solving. If GPIO is not expected to work yet, then debugging case is pointless.
I wanted also to use some Adafruit libs latter for DHT22 sensor. It failed to compile as its detection of device is based on /proc/cpuinfo.
Right now I put back Raspbian, as GPIO part there just works.
And I do not understand the device tree concept. It is not something I have noticed before on desktop or server. That's why I might miss some quite obvious step.
Regards Jan W dniu 03.01.2017, wto o godzinie 07∶11 +0000, użytkownik Peter Robinson napisał:
On Tue, Dec 6, 2016 at 8:08 AM, Jan spljaa@gmail.com wrote:
Hi, I've problems with using GPIO from python. It just throws some memory error and dumps. I'm not familiar with C/dumps and so on, so I did not yet start to try to get details of it.
One thing I noticed is different content of /proc/cpuinfo between Raspbian and Fedora 25. Thus my interpretation is that if Fedora reports a bit different hardware then some calls to some methods might fail. Am I missing some step that should be done after install?
It could be some mutation of FAQ: about support for HATs. But I would love clear statement, which would point that it just does not work out-of-the-box and there is/isn't way to manually fix it for someone who is not C/kernel developer. As for me support for HATs and support to set GPIO pin 18 to HIGH state are slightly different things. But maybe they have same root cause.
I've not had time to test GPIO, what python libraries are you using to access it? Basically some more details would be useful.
On Tue, Jan 3, 2017 at 3:47 PM, Jan spljaa@gmail.com wrote:
Hi, It was standard package that provides RPi.GPIO for python. I think I checked versions both from dnf and pip.
What was that package's name? I'm not sure off hand which packages are packaged in Fedora TBH (there's well over 18K source packages).
I do understand that to debug my configuration I would need to collect more data.
My question was more about current user's experiences. Does interaction with GPIO is expected to work. Which is needed step before jumping into problem solving. If GPIO is not expected to work yet, then debugging case is pointless.
I'm not aware of any reason it shouldn't. I don't have direct access to a working RPi ATM but the lsgpio tool (built in the 4.9 kernel-tools package) gave me a list of GPIOs the last time I tested it, I've not had time to dig deeper although it's on my todo list.
I wanted also to use some Adafruit libs latter for DHT22 sensor. It failed to compile as its detection of device is based on /proc/cpuinfo.
Well that's just a terrible library by the sounds of it.
Right now I put back Raspbian, as GPIO part there just works.
And I do not understand the device tree concept. It is not something I have noticed before on desktop or server. That's why I might miss some quite obvious step.
Well on x86 it's not standard, on ARM, Power and other platforms it is. It's a means of defining the layout of hardware on some platforms that don't have an x86 style BIOS.
Regards Jan W dniu 03.01.2017, wto o godzinie 07∶11 +0000, użytkownik Peter Robinson napisał:
On Tue, Dec 6, 2016 at 8:08 AM, Jan spljaa@gmail.com wrote:
Hi, I've problems with using GPIO from python. It just throws some memory error and dumps. I'm not familiar with C/dumps and so on, so I did not yet start to try to get details of it.
One thing I noticed is different content of /proc/cpuinfo between Raspbian and Fedora 25. Thus my interpretation is that if Fedora reports a bit different hardware then some calls to some methods might fail. Am I missing some step that should be done after install?
It could be some mutation of FAQ: about support for HATs. But I would love clear statement, which would point that it just does not work out-of-the-box and there is/isn't way to manually fix it for someone who is not C/kernel developer. As for me support for HATs and support to set GPIO pin 18 to HIGH state are slightly different things. But maybe they have same root cause.
I've not had time to test GPIO, what python libraries are you using to access it? Basically some more details would be useful.
On 01/04/2017 04:09 AM, Peter Robinson wrote:
I do understand that to debug my configuration I would need to collect more data.
My question was more about current user's experiences. Does interaction with GPIO is expected to work. Which is needed step before jumping into problem solving. If GPIO is not expected to work yet, then debugging case is pointless.
I'm not aware of any reason it shouldn't. I don't have direct access to a working RPi ATM but the lsgpio tool (built in the 4.9 kernel-tools package) gave me a list of GPIOs the last time I tested it, I've not had time to dig deeper although it's on my todo list.
A potential problem with the various gpio packages designed specifically for the Pi, is that they tend not to use the standard kernel sysfs interface for accessing gpios. They think that is too slow, and access hardware registers directly by mmap'ing /dev/mem (or the the non-standard /dev/gpiomem)
The memory range used differs by model, so they either use information in the device-tree or /proc/cpuinfo to detect that.
And I recall the physical pin to gpio number mapping also differs by model/revision, so even packages that do use the standard sysfs interface may look at cpuinfo, and could be confused by the Fedora kernel reporting BCM2835 for a Pi 2
Yours sincerely,
Floris Bos
I believe GPIO is broken because the Raspbery Pi hardware platform is not correctly recognized, but I have not had available time to look carefully.
[root@RPi3-1 ryniker]# uname -a Linux RPi3-1 4.8.4-301.fc25.armv7hl #1 SMP Tue Oct 25 02:01:39 UTC 2016 armv7l armv7l armv7l GNU/Linux
Simple test to demonstrate failure:
[root@RPi3-1 ryniker]# echo 23 >/sys/class/gpio/export bash: echo: write error: Invalid argument [root@RPi3-1 ryniker]#
Suspicious symptom: look at /proc/cpuinfo and see:
Hardware : Generic DT based system Revision : 0000 Serial : 00000000b9dd7fd3
Using Raspbian, where GPIO works, /proc/cpuinfo reports:
Hardware : BCM2709 Revision : a22082 Serial : 00000000e0b59fb5
I suspect the required files may be present in Fedora, possibly one of these:
/boot/dtb-4.8.4-301.fc25.armv7hl/bcm2836-rpi-2-b.dtb /boot/dtb-4.8.4-301.fc25.armv7hl/bcm2837-rpi-3-b.dtb
but they may not be used because of some failure to correctly identify the hardware platform. On the other hand:
[ryniker@RPi3-1 ~]$ echo $(cat /sys/firmware/devicetree/base/model) Raspberry Pi 3 Model B [ryniker@RPi3-1 ~]$
seems to get it right, therefore it is not complete failure to recognize the platform, maybe just a partial failure because names have evolved so some match fails. And it remains possible some configuration data is simply absent, or incorrect.
Hi,
Simple test to demonstrate failure:
[root@RPi3-1 ryniker]# echo 23 >/sys/class/gpio/export bash: echo: write error: Invalid argument [root@RPi3-1 ryniker]#
Just the numbering is different for some reason.
raspberrypi kernel:
kraxel@pitivi ~# cat /sys/class/gpio/gpiochip0/base 0
mainline kernel:
kraxel@pi-two ~# cat /sys/class/gpio/gpiochip458/base 458
cheers, Gerd
Thank you, that provides a welcome solution. The Fedora case is slightly different:
[ryniker@RPi3-1 ~]$ ls /sys/class/gpio export gpiochip970 unexport [ryniker@RPi3-1 ~]$ cat /sys/class/gpio/gpiochip970/base 970
Now the following works (at least there is no complaint; I will run a real application later to check actual output, but expect no trouble):
[root@RPi3-1 ryniker]# echo 993 >/sys/class/gpio/export
[ryniker@RPi3-1 ~]$ ls /sys/class/gpio/gpio993 active_low device direction edge power subsystem uevent value
[root@RPi3-1 ryniker]# echo 993 >/sys/class/gpio/unexport
I wonder how stable the "970" is. Will it be the same for all Raspberry Pi models? Will it be the same for all Fedora builds to run on a specific hardware model? I suspect the safe answer is "No." Even if this has been true for previous cases, without some explicit design assurance it may change in the future.
Next question: how do I get /dev/i2c and /dev/spi in Fedora when there is no /boot/config.txt file?
-
Floris Bos -
Gerd Hoffmann -
Jan -
Peter Robinson -
Richard Ryniker