Hi Dennis,
As you described below I have the permissions sets as below for both gpio48 and
gpio60.
debian@ebb:/sys/class/gpio$ echo 48 > export
debian@ebb:/sys/class/gpio$ ls -l gpio48
lrwxrwxrwx 1 root gpio 0 May 12 10:22 gpio48 ->
../../devices/platform/ocp/4804c000.gpio/gpiochip1/gpio/gpio48
debian@ebb:/sys/class/gpio$
And user debian has belongs to these groups including 'gpio'
debian@ebb:/sys/class/gpio$ groups debian
debian : debian adm kmem dialout cdrom floppy sudo audio dip video plugdev
users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep admin spi
tisdk weston-launch xenomai
debian@ebb:/sys/class/gpio$
So now let's play with gpio48 which has an LED attached to it.
debian@ebb:/sys/class/gpio/gpio48$ ls
active_low device direction edge label power subsystem uevent value
debian@ebb:/sys/class/gpio/gpio48$ cat direction
in
debian@ebb:/sys/class/gpio/gpio48$ echo out > direction
debian@ebb:/sys/class/gpio/gpio48$ cat direction
out
debian@ebb:/sys/class/gpio/gpio48$ cat value
0
LED is currently OFF
debian@ebb:/sys/class/gpio/gpio48$ echo 1 > value
debian@ebb:/sys/class/gpio/gpio48$ cat value
1
debian@ebb:/sys/class/gpio/gpio48$
LED is ON.
No "sudo" required.
Now let's look at groups.
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ls -l
Blinky
-rwxr-xr-x 1 debian debian 270880 May 11 15:08 Blinky
Hmmm. Not part of the gpio group
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ./Blinky
An unhandled exception occurred at $000282E0:
ESysfsFileOpenWrite: Cannot open
file </sys/class/gpio/gpio48/direction> for writing.
$000282E0 WRITETEXTTOFILE, line 68 of
/home/debian/lazarus/pxl/Source/PXL.Sysfs.Types.pas
$00021CB4 TSYSFSGPIO__SETPINMODE, line 200 of
/home/debian/lazarus/pxl/Source/PXL.Sysfs.GPIO.pas
So let’s add it to the gpio group:
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ chgrp
gpio Blinky
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ls -l
Blinky
-rwxr-xr-x 1 debian gpio 270880 May 11 15:08 Blinky
debian@ebb:~/lazarus/pxl/Samples/FreePascal/SingleBoard/Generic/Blinky$ ./Blinky
An unhandled exception occurred at $000282E0:
ESysfsFileOpenWrite: Cannot open
file </sys/class/gpio/gpio48/direction> for writing.
$000282E0 WRITETEXTTOFILE, line 68 of
/home/debian/lazarus/pxl/Source/PXL.Sysfs.Types.pas
$00021CB4 TSYSFSGPIO__SETPINMODE, line 200 of
/home/debian/lazarus/pxl/Source/PXL.Sysfs.GPIO.pas
So at the command line level I can work with gpio48 turning on and off the
output (and the LED).
>From the program I cannot since I don't have permission without using sudo to
>write to ...gpio48/direction
After every compile I could run the application from the command line with a
sudo but that's not the solution I need. Nor to each time change the
permissions at the command line level. If we can figure out what the
attributes of the program are supposed to be so it runs without the sudo then I
can potentially change something with the Lazarus IDE or Free Pascal Compiler
to properly configure the executable. But at the moment I can't get the
executable to run.
I recall reading that permissions of the gpio48 folder aren't enough. That the
links may be a problem but each of the entries in gpio48 are also in the gpio
group.
debian@ebb:/sys/class/gpio/gpio48$ ls -l
total 0
-rwxrwx--- 1 root gpio 4096 May 12 10:47 active_low
lrwxrwxrwx 1 root gpio 0 May 12 10:47 device -> ../../../gpiochip1
-rwxrwx--- 1 root gpio 4096 May 12 10:47 direction
-rwxrwx--- 1 root gpio 4096 May 12 10:47 edge
-rwxrwx--- 1 root gpio 4096 May 12 10:47 label
drwxrwx--- 2 root gpio 0 May 12 10:47 power
lrwxrwxrwx 1 root gpio 0 May 12 10:47 subsystem ->
../../../../../../../class/gpio
-rwxrwx--- 1 root gpio 4096 May 12 10:47 uevent
-rwxrwx--- 1 root gpio 4096 May 12 10:47 value
debian@ebb:/sys/class/gpio/gpio48$
So still basically lost. What sort of permissions does the executable "Blinky"
need in order to be able to write to .../gpio/gpio48/direction?
Thanks
John
Oh, and one other thing with respect to the SPI. Here's another weird thing
about the Beagle. Notice how the numbering is shifted from 0 relative to 1
relative. So I believe when the program tries to open spidev1.0 it's really
still going for the physical spi0 port. But I could be wrong.
debian@ebb:/sys/class/gpio/gpio48$ ls /dev/spi*
/dev/spidev1.0 /dev/spidev1.1 /dev/spidev2.0 /dev/spidev2.1
/dev/spi:
0.0 0.1 1.0 1.1
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of Dennis Lee Bieber
> Sent: May-12-21 9:24 AM
> To: Beagleboard
> Subject: [beagleboard] Re: Using GPIOs without Using sudo
>
> On Tue, 11 May 2021 18:51:22 -0700, in gmane.comp.hardware.beagleboard.user
> "John Dammeyer" <[email protected]> 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/k8on9gd9tbk7v4t3qd2rdbhi4h3ih81bi5%404ax.com.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/0a1001d74757%24d23e3ce0%2476bab6a0%24%40autoartisans.com.
