[fedora-arm] Raspberry Pi 2 - are post-install steps required?

[Jan]

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

[Peter Robinson]

Post by Jan
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.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fe

[Jan]

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

Post by Peter Robinson

Post by Jan
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.

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedor

[Peter Robinson]

Post by Jan
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).

Post by Jan
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.

Post by Jan
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.

Post by Jan
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.

Post by Jan
Regards
Jan
W dniu 03.01.2017, wto o godzinie 07∶11 +0000, użytkownik Peter

Post by Peter Robinson

Post by Jan
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.

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-

[Floris Bos]

Post by Peter Robinson

Post by Jan
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
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to

[Richard Ryniker]

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.

[***@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:

[***@RPi3-1 ryniker]# echo 23 >/sys/class/gpio/export
bash: echo: write error: Invalid argument
[***@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:

[***@RPi3-1 ~]$ echo $(cat /sys/firmware/devicetree/base/model)
Raspberry Pi 3 Model B
[***@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.
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an emai

[Gerd Hoffmann]

Hi,

Post by Richard Ryniker
bash: echo: write error: Invalid argument

Just the numbering is different for some reason.

raspberrypi kernel:

***@pitivi ~# cat /sys/class/gpio/gpiochip0/base
0

mainline kernel:

***@pi-two ~# cat /sys/class/gpio/gpiochip458/base
458

cheers,
Gerd
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an

[Richard Ryniker]

Thank you, that provides a welcome solution. The Fedora case is
slightly different:

[***@RPi3-1 ~]$ ls /sys/class/gpio
export gpiochip970 unexport
[***@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):

[***@RPi3-1 ryniker]# echo 993 >/sys/class/gpio/export

[***@RPi3-1 ~]$ ls /sys/class/gpio/gpio993
active_low device direction edge power subsystem uevent value

[***@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?
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproje