raspberry pi 4 (Buster) gpiomem

[witje_]

Allen,

Raspberry Pi 4 (4GB) met Raspberry pi OS (versie Bullseye)

Wanneer ik de Rpi boot dan worden de persmissie voor /dev/gpiomem:

code:

bartje@WijzeVaren:~ $ ls -la /dev/gpio*
crw-rw---- 1 root gpio 254, 0 Oct 10 19:23 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Oct 10 19:23 /dev/gpiochip1
crw------- 1 root root 238, 0 Oct 10 19:23 /dev/gpiomem

Wat niet juist is, normaal zou de gpiomem ook als group gpio moeten hebben en ook 'rw' als group permissies.
(ik moet dit nu bij elke reboot manueel wijzigen, om mijn code te laten werken)

Normaal zou RPI.gpio-common hiervoor moeten zorgen dat dit goed komt te staan

code:

rpi.gpio-common/oldstable,now 0.7.0-0.2+b2 arm64 [installed,automatic]

deze is correct geinstalleerd (was al zo vermits dit raspberry os is)

Dit stukje software zou /etc/udev/rules.d/99-com.rules correct moeten zetten om dit na booten en creatie van de /dev de permissies goed moeten zetten.

De inhoud van die .rules is identiek gelijk aan die van mijn andere raspberry pi 4, waar de permissie voor gpiomem wel correct staan.

code:

SUBSYSTEM=="input", GROUP="input", MODE="0660"
SUBSYSTEM=="i2c-dev", GROUP="i2c", MODE="0660"
SUBSYSTEM=="spidev", GROUP="spi", MODE="0660"
SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"
SUBSYSTEM=="rpivid-*", GROUP="video", MODE="0660"

KERNEL=="vcsm-cma", GROUP="video", MODE="0660"
SUBSYSTEM=="dma_heap", GROUP="video", MODE="0660"

SUBSYSTEM=="gpio", GROUP="gpio", MODE="0660"
SUBSYSTEM=="gpio", KERNEL=="gpiochip*", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys/class/gpio && chmod -R g=u /sys/class/gpio'"
SUBSYSTEM=="gpio", ACTION=="add", PROGRAM="/bin/sh -c 'chgrp -R gpio /sys%p && chmod -R g=u /sys%p'"

Mijn vraag
Wat zie ik over het hoofd, wie kan me in de goede richting duwen om dit probleem op te lossen?

Bij voorkeur doe ik geen reïnstall van de rPi, want deze is op dit moment de kern van mijn home-monitor systeem (mosquitto, zigbee2mqtt, input/outputs lezen van relais --> waarvoor ik GPIO gebruik)

Thanks

[Hero of Time]

Op m'n eigen 2 Pi's gekeken, eentje draait 11, de andere al 12, en daar staan de rechten wel zoals je zou verwachten. Dit komt idd door /etc/udev/rules.d/99-com.rules en zit in package raspberrypi-sys-mods.

Als de juiste packages en de udev rules er staan, kijk dan eens of je handmatig die rules kan laten uitvoeren. Met iets als dit zou dat moeten gebeuren (uitvoeren als root):

udevadm control --reload-rules && udevadm trigger

Wat zijn de rechten hierna? Heeft die 99-com.rules ook de juiste rechten om te kunnen worden gelezen?

Als het bestand wel gelezen kan worden en de rechten op gpiomem blijven verkeerd staan, moet er ergens nog een andere .rules bestand zijn of een ander proces dat dit aanpast.

[witje_]

wanneer ik:

code:

sudo udevadm control --reload-rules && udevadm trigger

dan krijg ik een hoop lijn met allemaal permission denied, waaronder ook

code:

Failed to write 'change' to '/sys/devices/platform/soc/fe200000.gpio/uevent': Permission denied
Failed to write 'change' to '/sys/devices/platform/soc/fe200000.gpiomem/uevent': Permission denied

[Hero of Time]

Die 'udevadm trigger' moet natuurlijk ook als root uitgevoerd worden.

[witje_]

ja.........

dan krijg ik geen foutmeldingen meer en blijven de rechten wel goed staat van de gpiomem.

enig idee wie of wat de rechten bij het booten zou veranderen?

[Hero of Time]

Dat is aan jou nu om uit te zoeken. Je hebt iets geïnstalleerd/draaien dat de defaults, die dus wel correct zijn, wijzigt. Een recursive grep voor 'gpiomem' in o.a. /etc/ toont wellicht wat meer. En vergelijk de resultaten met je andere Pi waar het wel blijft staan.

[witje_]

ik zal wat proberen, maar je eerste tip geeft alvast geen nieuwe inzichten. Merci om me op gang te zetten en de nuttige antwoorden.

ik ga nog wat verder zoeken, maar ik denk dat een reïnstal (en ineens naar Bookworm) misschien wel de snelste manier kan zijn.

[witje_]

Ik kom hier toch nog even op terug, want het probleem zit toch ergens anders denk ik.

Wanneer ik een reboot doe, dan staan de permissie niet correct. Laat ik op dat moment de Udev rules opnieuw lopen, dan worden de permissie niet gewijzigd. Pas wanneer ik ze manueel wijzig dan staan ze goed. Laat ik de Udev rules opnieuw lopen, dan worden de permissie niet terug gewijzigd.

Zie output:

code:

bartje@WijzeVaren:~ $ ls /dev/gpio* -la
crw-rw---- 1 root gpio 254, 0 Oct 13 07:10 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 Oct 13 07:10 /dev/gpiochip1
crw------- 1 root root 238, 0 Oct 13 07:10 /dev/gpiomem
bartje@WijzeVaren:~ $ ls -la --time-style=full-iso /dev/gpio*
crw-rw---- 1 root gpio 254, 0 2023-10-13 07:10:27.939999998 +0200 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 2023-10-13 07:10:28.551999998 +0200 /dev/gpiochip1
crw------- 1 root root 238, 0 2023-10-13 07:10:28.587999998 +0200 /dev/gpiomem
bartje@WijzeVaren:~ $ sudo udevadm control --reload-rules && sudo udevadm trigger
bartje@WijzeVaren:~ $ ls -la --time-style=full-iso /dev/gpio*
crw-rw---- 1 root gpio 254, 0 2023-10-13 07:13:15.694960936 +0200 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 2023-10-13 07:13:15.790960080 +0200 /dev/gpiochip1
crw------- 1 root root 238, 0 2023-10-13 07:13:15.846959580 +0200 /dev/gpiomem
bartje@WijzeVaren:~ $ sudo chown root:gpio /dev/gpiomem 
bartje@WijzeVaren:~ $ sudo chmod g+rw /dev/gpiomem 
bartje@WijzeVaren:~ $ ls -la --time-style=full-iso /dev/gpio*
crw-rw---- 1 root gpio 254, 0 2023-10-13 07:13:15.694960936 +0200 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 2023-10-13 07:13:15.790960080 +0200 /dev/gpiochip1
crw-rw---- 1 root gpio 238, 0 2023-10-13 07:13:15.846959580 +0200 /dev/gpiomem
bartje@WijzeVaren:~ $ sudo udevadm control --reload-rules && sudo udevadm trigger
bartje@WijzeVaren:~ $ ls -la --time-style=full-iso /dev/gpio*
crw-rw---- 1 root gpio 254, 0 2023-10-13 07:14:47.030574743 +0200 /dev/gpiochip0
crw-rw---- 1 root gpio 254, 1 2023-10-13 07:14:47.126574517 +0200 /dev/gpiochip1
crw-rw---- 1 root gpio 238, 0 2023-10-13 07:14:47.234574262 +0200 /dev/gpiomem

[Hero of Time]

Er moet dan toch ergens nog iets van een override rond zwerven. Net op m'n eigen Pi 2B, die alleen Pi-Hole draait en dus geen problemen zal krijgen bij een tijdelijke wijziging, wat getest. Als ik in /etc/udev/rules.d/99-com.rules regel 4 aanpas en dan udevadm trigger uitvoer, veranderen de rechten. De betreffende regel bevat dit:

code:

SUBSYSTEM=="bcm2835-gpiomem", GROUP="gpio", MODE="0660"

De 'GROUP' had ik tijdelijk aangepast naar 'kvm' en /dev/gpiomem kreeg ook die groep.

Het is jammer dat er niks in de logs te vinden is wanneer udev regels uitgevoerd worden.