On Tue, 11 May 2021 18:51:22 -0700, in gmane.comp.hardware.beagleboard.user
"John Dammeyer" <johnd-5o6ditlojsohvde0pjs...@public.gmane.org> wrote:
>But I'm trying to keep this discussion pointed in the direction of the subject
>line. The problem with access to GPIO seems to exist in both the Pi and
>Beagle world. One posting mentioned how his software broke when the Pi OS was
>upgraded to 4.14.
>
pi@rpi3bplus-1:~/PI_GPIO$ uname -a
Linux rpi3bplus-1 5.10.17-v7+ #1403 SMP Mon Feb 22 11:29:51 GMT 2021 armv7l
GNU/Linux
pi@rpi3bplus-1:~/PI_GPIO$
If I interpret that, the current R-Pi is up to kernel 5.10 vs 4.18 for
BBB
debian@beaglebone:~$ uname -a
Linux beaglebone 4.19.94-ti-r48 #1buster SMP PREEMPT Wed Aug 19 17:38:55
UTC 2020 armv7l GNU/Linux
debian@beaglebone:~$
Well, there are some weird things on the R-Pi... My Ada program is able
to export a GPIO (they aren't exported by default, unlike the BBB). But it
fails when opening the direction file to change from "in" to "out". I even
tried changing from "out_file" to "append_file".
Turns out to be a timing issue -- the OS hasn't finished creating the
pin files by the time it tried to write the direction. {This is
Raspberry-Pi -- I didn't have that problem on BBB, but wasn't exporting in
code either}. Putting in a 1 second delay after closing the export file let
the program run. I also had to add an exception handler on the export
operation in case the pin had already been exported (along with adding an
Unexport function called at the end). Other than using GPIO 18, and using
export (with delay), unexport -- this is the same program that ran on the
BBB. In fact, I just built and ran it on the BBB (Using GPIO 18). (Changed
to GPIO 48 -- and first run had the same timing error -- since it took the
exception branch; subsequent runs no problem).
pi@rpi3bplus-1:~/PI_GPIO$ gnatmake main
arm-linux-gnueabihf-gcc-8 -c main.adb
arm-linux-gnueabihf-gnatbind-8 -x main.ali
arm-linux-gnueabihf-gnatlink-8 main.ali
pi@rpi3bplus-1:~/PI_GPIO$ ./main
Opening /sys/class/gpio/export
Writing pin number: 18
Closing /sys/class/gpio/export
Delaying to allow pin control files to be set up
Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value
Current value of 18 is 1
Opening /sys/class/gpio/gpio18/direction
Writing direction: out
Closing /sys/class/gpio/gpio18/direction
Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value
Current value of 18 is 0
Opening /sys/class/gpio/gpio18/value
Writing value: 0
Closing /sys/class/gpio/gpio18/value
Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value
Current value of 18 is 0
Opening /sys/class/gpio/gpio18/value
Writing value: 1
Closing /sys/class/gpio/gpio18/value
Opening /sys/class/gpio/gpio18/value
Reading value
Closing /sys/class/gpio/gpio18/value
Current value of 18 is 1
Opening /sys/class/gpio/gpio18/direction
Writing direction: in
Closing /sys/class/gpio/gpio18/direction
Opening /sys/class/gpio/unexport
Writing pin number: 18
Closing /sys/class/gpio/unexport
>My experience with changing Beagle versions is fraught with disaster where the
>change then breaks all sorts of stuff that was working. This is why I'm
>staying on 4.11 which is what the book uses and at least there's 1.25" of
>paper all pointing to the same OS.
>
As I mentioned, uSD cards are getting cheap... Write a current OS image
and try it on a fresh 8+GB card (don't forget to resize the partition after
first boot). If it works, great. If it doesn't you still have your original
image to mess with. I'd suggest
https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_LXQt
at a minimum, or
https://rcn-ee.net/rootfs/bb.org/testing/2021-04-19/buster-lxqt/ (to save
time bringing the image up-to-date -- note that the latter is Buster 10-9
while the shipping image https://beagleboard.org/latest-images is 10-3 and
a year out-of-date).
>So. Should I just blindly, in the command line way, type all that stuff with
>no idea of why I'm doing it, run it and if it works be happy?
>
>As an example the second link uses:
>chown -R nick:digital /sys/devices/gpio
>
>The first link above uses
>chown -R debian:root /sys/devices/gpio
>
>I think debian:root is what I want to do but I don't understand why the
>nick:digital allows root access. Why not nick:root?
It doesn't... It changes the OWNER of /sys/devices/gpio to BE the user
"nick" (note -- it isn't changing the files under that directory!), while
also putting them into a group called "digital". As owner, "nick" then has
full privileges to the file, and any user in the "digital" group has group
privileges.
The second, again, would change the OWNER to "debian" but put the file
into a group called "root". And, again, it doesn't change what is below
that directory. That's one reason for all those nasty udev rules -- the
sysfs is created at boot time, and the pin files are created when the pin
is exported. Those files would be created using whatever the kernel is
configured to use for permissions (likely root:root) unless over-written by
a udev rule.
In a proper system (current BBB and R-Pi), the GPIO should be
root:gpio, and the user "debian" ("pi") set as a member of the gpio group
-- owned by root, with access to any member of the "gpio" group, and group
permissions should be RWX
pi@rpi3bplus-1:~/PI_GPIO$ ls -l /sys/class/gpio
total 0
-rwxrwx--- 1 root gpio 4096 May 12 11:05 export
lrwxrwxrwx 1 root gpio 0 May 3 11:30 gpiochip0 ->
../../devices/platform/soc/3f200000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 May 3 11:30 gpiochip504 ->
../../devices/platform/soc/soc:firmware/soc:firmware:expgpio/gpio/gpiochip504
-rwxrwx--- 1 root gpio 4096 May 12 11:05 unexport
vs
debian@beaglebone:~/BBB_IO$ ls -l /sys/class/gpio
total 0
--w--w---- 1 root gpio 4096 May 12 11:20 export
lrwxrwxrwx 1 root gpio 0 May 11 20:40 gpio10 ->
../../devices/platform/ocp/44e07000.gpio/gpiochip0/gpio/gpio10
<SNIP>
lrwxrwxrwx 1 root gpio 0 May 11 20:40 gpiochip0 ->
../../devices/platform/ocp/44e07000.gpio/gpio/gpiochip0
lrwxrwxrwx 1 root gpio 0 May 11 20:40 gpiochip32 ->
../../devices/platform/ocp/4804c000.gpio/gpio/gpiochip32
lrwxrwxrwx 1 root gpio 0 May 11 20:40 gpiochip64 ->
../../devices/platform/ocp/481ac000.gpio/gpio/gpiochip64
lrwxrwxrwx 1 root gpio 0 May 11 20:40 gpiochip96 ->
../../devices/platform/ocp/481ae000.gpio/gpio/gpiochip96
--w--w---- 1 root gpio 4096 May 12 11:20 unexport
pi@rpi3bplus-1:~/PI_GPIO$ groups pi
pi : pi adm dialout cdrom sudo audio video plugdev games users input netdev
spi i2c gpio lpadmin
pi@rpi3bplus-1:~/PI_GPIO$
... So, again... CAN you access GPIO 48 (from "debian", without using
sudo) from the SHELL itself?
-=-=-
debian@beaglebone:~/BBB_IO$ echo 48 > /sys/class/gpio/export
debian@beaglebone:~/BBB_IO$ cat /sys/class/gpio/gpio48/*
0 <<<<< active_low
cat: /sys/class/gpio/gpio48/device: Is a directory
in <<<<< direction
none <<<<< edge (trigger)
sysfs <<<<< label
cat: /sys/class/gpio/gpio48/power: Is a directory
cat: /sys/class/gpio/gpio48/subsystem: Is a directory
1 <<<<< value
debian@beaglebone:~/BBB_IO$ echo out > /sys/class/gpio/gpio48/direction
debian@beaglebone:~/BBB_IO$ cat /sys/class/gpio/gpio48/*
0
cat: /sys/class/gpio/gpio48/device: Is a directory
out
none
sysfs
cat: /sys/class/gpio/gpio48/power: Is a directory
cat: /sys/class/gpio/gpio48/subsystem: Is a directory
0
debian@beaglebone:~/BBB_IO$ echo 1 > /sys/class/gpio/gpio48/value
debian@beaglebone:~/BBB_IO$ cat /sys/class/gpio/gpio48/*
0
cat: /sys/class/gpio/gpio48/device: Is a directory
out
none
sysfs
cat: /sys/class/gpio/gpio48/power: Is a directory
cat: /sys/class/gpio/gpio48/subsystem: Is a directory
1
debian@beaglebone:~/BBB_IO$ echo 0 > /sys/class/gpio/gpio48/value
debian@beaglebone:~/BBB_IO$ cat /sys/class/gpio/gpio48/*
0
cat: /sys/class/gpio/gpio48/device: Is a directory
out
none
sysfs
cat: /sys/class/gpio/gpio48/power: Is a directory
cat: /sys/class/gpio/gpio48/subsystem: Is a directory
0
debian@beaglebone:~/BBB_IO$
-=-=-
If you can do that, you do NOT have a permission problem for GPIO (SPI
is another matter) -- and the problem is either in PXL library or your
code. As I mentioned previously, your code may need to EXPORT the GPIOs
before you can pass the pins to your display driver call. PXL appears to
assume the two GPIOs are already exported with direction set to OUT.
*************************************
I would also like to point out that
https://beagleboard.org/Support/bone101 indicates that SPI1 (pins P9_28,
P9_29, P9_31) are used by the HDMI system -- in order to gain use of SPI1
you may have to disable the HDMI device tree overlay (besides maybe needing
to add a SPI1 overlay) in /boot/uEnv.txt... say goodbye to using a direct
monitor/keyboard/mouse on the BBB; you'd have to export the display to some
external X-server and use its monitor/keyboard/mouse.
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo <<<<<<
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1 <<<<<<<
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
debian@beaglebone:~/BBB_IO$ ls /lib/firmware/*SPI1*
/lib/firmware/ADAFRUIT-SPI1-00A0.dtbo ???????????
/lib/firmware/PB-SPI1-ETH-WIZ-CLICK.dtbo
/lib/firmware/BB-LCD-ADAFRUIT-18-SPI1-00A0.dtbo
/lib/firmware/PB-SPI1-MICROSD-CLICK.dtbo
/lib/firmware/BB-LCD-ADAFRUIT-24-SPI1-00A0.dtbo
/lib/firmware/PB-SPI1-OLEDB-CLICK.dtbo
/lib/firmware/BB-SPI1-LTC2947-00A0.dtbo
/lib/firmware/PB-SPI1-OLEDC-CLICK.dtbo
/lib/firmware/PB-MCP2515-SPI1.dtbo /lib/firmware/PB-SPI1-RTC-5-CLICK.dtbo
/lib/firmware/PB-SPI1-7SEG-TECHLAB-CAPE.dtbo
/lib/firmware/PB-SPI1-THUNDER-CLICK.dtbo
/lib/firmware/PB-SPI1-ETH-CLICK.dtbo
debian@beaglebone:~/BBB_IO$
Could be that just disabling the HDMI overlay will make SPI1 available.
--
Dennis L Bieber
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/k8on9gd9tbk7v4t3qd2rdbhi4h3ih81bi5%404ax.com.
