Embedded Linux Interrupt Handling

[Michael S. (alteraonlinux)]

Hallo Zusammen,

ich nutze ein Altera Evaluation Board mit einem Cyclone V SoC FPGA.
Auf dem intergrierten ARM-Cortex läuft ein YOCTO-Linux, Kernel Version 
3.8.0.

Folgende Situation:
Ich möchte in meinem Linux System eine Interrupt-Service-Routine 
schreiben, die auf GPIO Interrupts reagiert.

Verstehe ich das richtig, dass der einzige Weg über ein Kernel Modul 
führt?
Also ich ein Kernel Modul schreibe und dann meine Interrupt Routine auf 
Anwendungsebene laufen lasse?

Ich freue mich über jeden Tipp.

Viele Grüße

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Michael Schäfer schrieb:
> Verstehe ich das richtig, dass der einzige Weg über ein Kernel Modul
> führt?

Normalerweise ja. Userland Programme können dann über /dev, /udev und 
/proc mit dem Modul kommunizieren.

[Michael S. (alteraonlinux)]

Vielen Dank für die schnelle Antwort.
Dann ist das also wirklich der "richtige" Weg.

Eine Frage habe ich noch,
Im Moment kann ich mit Hilfe von "polling" auftretende Interrupts an 
festen Speicheradressen abfragen.

Linux verwendet ja gpio Nummern. Wie finde ich die zu einer 
Speicheradresse z.B. 0xff200000 dazugehörige gpio nummer heraus?

[Klaus W. (mfgkw)]

Das würde ich im Datenblatt des Prozessors suchen.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Noch ein Tipp: Wenn dir die Hardware noch unbekannt ist, sind /proc und 
/dev dein Freund (sonst auch, aber hier besonders). Dadrin sind 
vielerlei Hinweise auf die Hardware wie z.B. die derzeit benutzten 
Busse, Devices, Interrupts usw. zu finden. Einfach mal mit cat ein paar 
der Nodes anschauen und wenn möglich auch mit deiner 'grossen' Linux Box 
vergleichen.

[Michael S. (alteraonlinux)]

Dann bedanke ich mich erstmal für die vielen gute Tipps.

Ich bin bei meiner Recherche noch auf UIO-Treiber aufmerksam geworden. 
Das sind vereinfacht gesagt "Kernel-Module" im User Space. Allerdings 
weiß ich nicht so recht, was ich davon halten soll.

@KLaus Wachtler:
Aus meiner Dokumentation werde ich nicht so richtig schlau. Der Bereich 
der mich interessiert liegt bei 0xff70a050 (GPIO2), davon allerdings nur 
bit 13 bis 26.

Im Datenblatt steht für GPIO2 --> gpio nr. 198
gpio nr. 199 ist schon wieder etwas anderem zugeordnet.

Das verstehe ich nicht.

[Konrad (Gast)]

Je nach Latenzanforderungen kannst Du auch in einem Thread Deiner 
Applikation mit z.B. select darauf warten, dass das sysfs-Device Deines 
Pins lesbar wird. Dann sparst Du das Kernelmodul.

Weiterlesen hier:
https://www.kernel.org/doc/Documentation/gpio/

HTH
Konrad

[Hans Ulli K. (Gast)]

Michael Schäfer schrieb:
> Dann bedanke ich mich erstmal für die vielen gute Tipps.
>
> Ich bin bei meiner Recherche noch auf UIO-Treiber aufmerksam geworden.
> Das sind vereinfacht gesagt "Kernel-Module" im User Space. Allerdings
> weiß ich nicht so recht, was ich davon halten soll.
>
> @KLaus Wachtler:
> Aus meiner Dokumentation werde ich nicht so richtig schlau. Der Bereich
> der mich interessiert liegt bei 0xff70a050 (GPIO2), davon allerdings nur
> bit 13 bis 26.
>
> Im Datenblatt steht für GPIO2 --> gpio nr. 198
> gpio nr. 199 ist schon wieder etwas anderem zugeordnet.
>
> Das verstehe ich nicht.

GPIO2 kannst du dir als Bank vorstellen.

Habe gerade mal in meinen lokalen linux-master pre. 3.15-rc1 
nachgesehen.

find arch/arm/boot/dts/ -name '*cyc*'
arch/arm/boot/dts/socfpga_cyclone5_sockit.dts
arch/arm/boot/dts/socfpga_cyclone5.dtsi
arch/arm/boot/dts/socfpga_cyclone5_socdk.dts

da sind aber keine GPIOs dabei

Das mit Bits 13-26 ist auch schon seltsam. Kenne jetzt nur 32Bit Breite 
GPIO Bänke..
Und GPIO 198 ??

[Tux (Gast)]

GPIO198 geht.

Beim Beaglebone Black gibts auch so hohe..

Das liegt daran, dass da irgendwas mit 32 multipliziertz wird und dann 
der normale Offset drauf kommt. Such ma nach BeagleBone und GPIO da 
findeste bestimmt was..

[Michael S. (alteraonlinux)]

Meine Latenzanforderungen sind hoch, es geht um Echtzeit-Verarbeitung 
:-D

Das mit dem Beaglebone Black war ein sehr guter Hinweis.

Das Signal, welches mich interessiert lautet "GPI6", die physikalische 
Adresse liegt bei 0xff70a050.
Laut Datenblatt liegt der GPIO PIN bei 198 (für die komplette GPIO2 
Bank).

6 * 32 = 192 (geht in die Richtige Richtung)

Mit
# echo 198 > /sys/class/gpio/export
# cd gpio198
# cat value

erthalte ich aber immer '1'. Beim drücken meines Push Buttons sollte da 
aber eine '0' erscheinen.

Wenn ich rausfinde woran es liegt, verrate ich es :-D

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Michael Schäfer schrieb:
> Meine Latenzanforderungen sind hoch, es geht um Echtzeit-Verarbeitung
> :-D

Das ist nicht gut - Linux liefert im Normalfall kein vorhersagbares 
Antwortverhalten auf Interrupts. Allerdings gibt es Mods, die probieren, 
das zu verbessern, wie z.B. RTLinux. Obs noch gepflegt wird? KA, schaus 
dir mal an.
Evtl. hat Altera aber so etwas schon implementiert.

Michael Schäfer schrieb:
> Mit
> # echo 198 > /sys/class/gpio/export
> # cd gpio198
> # cat value

Das ist mir jetzt nicht ganz klar - gibt es denn schon einen gpio 
Treiber in deiner Distri? Wenn ja, solltest du auch ohne touch oder echo 
schon einen Eintrag in /proc zum lesen der gpio haben.

[Michael S. (alteraonlinux)]

Mein YOCTO-Linux hat einen GPIO-Treiber im Kernel:

root@socrates:/lib/modules/3.8.0-00074-g68c58e0/kernel/drivers/gpio# ls
gpio-dw.ko  gpio-generic.ko

Die sind auch beide eingebunden via "insmod", aber die scheinen 
Interrupts von einem Push-Button nicht zu interessieren. Da kann ich 
drauf rum drücken wie ich will, es erhöht sich kein Wert. Davon 
abgesehen, kann ich auch keinen der Einträge (siehe unten) meinem 
Push-Button zuordnen.

Ich hatte gehofft, mit dem On-Board interrupt-treiber von Linux arbeiten 
zu können.

root@socrates:/# cat /proc/interrupts 
           CPU0       CPU1       
525:      42650      42598       GIC  twd
653:          0          0       GIC  dwc_otg, dwc_otg_hcd:usb1
656:          1          0       GIC  dwc_otg, dwc_otg_hcd:usb2
667:      47619          0       GIC  dw-mci
679:          0          0       GIC  ff705000.spi
682:          0          0       GIC  dw_spi0
684:          0          0       GIC  dw_spi1
686:          4          0       GIC  ffc04000.i2c
687:          0          0       GIC  ffc05000.i2c
690:       2732          0       GIC  serial
697:          9          0       GIC  timer2
IPI0:          0          0  CPU wakeup interrupts
IPI1:          0          0  Timer broadcast interrupts
IPI2:       1340       1498  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:          1          2  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
Err:          0
root@socrates:/#

Weitere Ausgaben:

root@socrates:/sys/class/gpio# ls
export  gpiochip171  gpiochip198  gpiochip227  unexport
root@socrates:/sys/class/gpio#

Device-Tree:

root@socrates:/proc/device-tree/soc# ls -l
total 0
-r--r--r-- 1 root root  4 Jun 28 16:26 #address-cells
-r--r--r-- 1 root root  4 Jun 28 16:26 #size-cells
dr-xr-xr-x 3 root root  0 Jun 28 16:26 amba
dr-xr-xr-x 3 root root  0 Jun 28 16:26 clkmgr@ffd04000
-r--r--r-- 1 root root 11 Jun 28 16:26 compatible
-r--r--r-- 1 root root  4 Jun 28 16:26 device_type
dr-xr-xr-x 3 root root  0 Jun 28 16:26 dwmmc0@ff704000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 ethernet@ff700000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 ethernet@ff702000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 gpio@0xc0000000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 gpio@ff708000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 gpio@ff709000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 gpio@ff70a000
dr-xr-xr-x 4 root root  0 Jun 28 16:26 i2c@ffc04000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 i2c@ffc05000
-r--r--r-- 1 root root  4 Jun 28 16:26 interrupt-parent
dr-xr-xr-x 2 root root  0 Jun 28 16:26 l2-cache@fffef000
-r--r--r-- 1 root root  4 Jun 28 16:26 name
dr-xr-xr-x 2 root root  0 Jun 28 16:26 nand@ff900000
-r--r--r-- 1 root root  0 Jun 28 16:26 ranges
dr-xr-xr-x 2 root root  0 Jun 28 16:26 rstmgr@ffd05000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 serial0@ffc02000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 serial1@ffc03000
dr-xr-xr-x 3 root root  0 Jun 28 16:26 spi@ff705000
dr-xr-xr-x 3 root root  0 Jun 28 16:26 spi@fff00000
dr-xr-xr-x 3 root root  0 Jun 28 16:26 spi@fff01000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 sysmgr@ffd08000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 timer0@ffc08000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 timer1@ffc09000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 timer2@ffd00000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 timer3@ffd01000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 timer@fffec600
dr-xr-xr-x 2 root root  0 Jun 28 16:26 uio-gpio@ff2000000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 usb@ffb00000
dr-xr-xr-x 2 root root  0 Jun 28 16:26 usb@ffb40000

So langsam gehen mir die Ideen aus...

[Max G. (l0wside)]

Michael Schäfer schrieb:
> Meine Latenzanforderungen sind hoch, es geht um Echtzeit-Verarbeitung
> :-D
>
> Das mit dem Beaglebone Black war ein sehr guter Hinweis.

Der BBB hätte den Vorteil, dass der darauf verbaute AM3358 noch die PRUs 
an Bord hat. Das sind unabhängige µCs auf dem gleichen Die, die 
Echtzeitanwendungen ohne das Betriebssystem behandeln können. Das 
Betriebssystem macht dann wohl nur noch die Parametrierung dieser 
Funktionen.

Wenn du auf das Altera-Board festgelegt bist, hilft dir diese Erkenntnis 
leider auch nicht viel. Wäre ein Softcore im FPGA ggf. eine Option, um 
die harten Echtzeitanforderungen abzuarbeiten?

Max

[Michael S. (alteraonlinux)]

Ich hab jetzt mal mit Kanonen auf Spatzen geschossen und ein kleines 
Shell-SKript geschrieben, was mit alle GPIO exportiert und deren Wert 
abfragt:

#!/bin/bash
echo 198 > /sys/class/gpio/export
echo 199 > /sys/class/gpio/export
echo 200 > /sys/class/gpio/export
echo 201 > /sys/class/gpio/export
echo 202 > /sys/class/gpio/export
echo 203 > /sys/class/gpio/export
echo 204 > /sys/class/gpio/export
echo 205 > /sys/class/gpio/export
echo 206 > /sys/class/gpio/export
echo 207 > /sys/class/gpio/export
echo 208 > /sys/class/gpio/export
echo 209 > /sys/class/gpio/export
echo 210 > /sys/class/gpio/export
echo 211 > /sys/class/gpio/export
echo 212 > /sys/class/gpio/export
echo 213 > /sys/class/gpio/export
echo 214 > /sys/class/gpio/export
echo 215 > /sys/class/gpio/export
echo 216 > /sys/class/gpio/export
echo 217 > /sys/class/gpio/export
echo 218 > /sys/class/gpio/export
echo 219 > /sys/class/gpio/export
echo 220 > /sys/class/gpio/export
echo 221 > /sys/class/gpio/export
echo 222 > /sys/class/gpio/export
echo 223 > /sys/class/gpio/export
echo 224 > /sys/class/gpio/export
echo 225 > /sys/class/gpio/export
echo 226 > /sys/class/gpio/export
cd /sys/class/gpio/gpio198/
cat value
cd /sys/class/gpio/gpio199/
cat value
cd /sys/class/gpio/gpio200/
cat value
cd /sys/class/gpio/gpio201/
cat value
cd /sys/class/gpio/gpio202/
cat value
cd /sys/class/gpio/gpio203/
cat value
cd /sys/class/gpio/gpio204/
cat value
cd /sys/class/gpio/gpio205/
cat value
cd /sys/class/gpio/gpio206/
cat value
cd /sys/class/gpio/gpio207/
cat value
cd /sys/class/gpio/gpio208/
cat value
cd /sys/class/gpio/gpio209/
cat value
cd /sys/class/gpio/gpio210/
cat value
cd /sys/class/gpio/gpio211/
cat value
cd /sys/class/gpio/gpio212/
cat value
cd /sys/class/gpio/gpio213/
cat value
cd /sys/class/gpio/gpio214/
cat value
cd /sys/class/gpio/gpio215/
cat value
cd /sys/class/gpio/gpio216/
cat value
cd /sys/class/gpio/gpio217/
cat value
cd /sys/class/gpio/gpio218/
cat value
cd /sys/class/gpio/gpio219/
cat value
cd /sys/class/gpio/gpio220/
cat value
cd /sys/class/gpio/gpio221/
cat value
cd /sys/class/gpio/gpio222/
cat value
cd /sys/class/gpio/gpio223/
cat value
cd /sys/class/gpio/gpio224/
cat value
cd /sys/class/gpio/gpio225/
cat value
cd /sys/class/gpio/gpio226/
cat value
cd /sys/class/gpio/gpio227/
cat value

Bei der Ausgabe sehe ich immer lediglich '1'en, egal wie sehr ich auch 
meinen Button betätige.

Frage ich den Status der physikalischen Adresse ab (devmem2.c), sehe ich 
eine Änderung.

Mir scheint, als wäre da was nicht "aktiv" oder eingebunden.

Merkwürdig

[Michael S. (alteraonlinux)]

Für all Jene, die ebenfalls das EBV SoCrates SoC Evaluation Board der 
Firma EBV haben und wissen wollen, auf welche gpio's der Navigation 
Switch gemappt ist, hier die Lösung:

Links : 195
Rechts: 194
Hoch  : 190
Runter: 191
Push  : 186

Wie man darauf rechnerisch kommt, bleibt mir weiterhin rätselhaft.