Kernel Programmierung unter Linux. Programmierung von Kernelmodulen für den Raspberry PI

Transkript

1 Kernel Programmierung unter Linux Programmierung von Kernelmodulen für den Raspberry PI Referent Klaus Ruhwinkel

2 Das Betriebssystem Aufbau des Betriebssystem: Es besteht aus den Betriebssystemkern und den sonstigen Betriebssystemkomponenten (Userland) Der Betriebssystemkern stellt Dienste über z.b. Systemcalls für sämtliche Applikationen her. Dadurch ist es möglich Daten auf dem Bildschirm darzustellen, Daten in Dateien abzulegen etc. Das Userland nutzt die Dienste, um damit Systemkonfigurationen und ähnliches vorzunehmen 2

3 Kernelarten Es gibt drei Arten von Kernel: 1. Monolithischer Kernel, dazu zählen die Kernel von Linux und Windows. Diese Kernel übernehmen alle Aufgaben wie Speicher- und Prozessverwaltung und sind auch für die Kommunikation zwischen den Prozessen und zwischen den Prozessen und der Hardware zuständig. 2. Microkernel, dazu zählen die Kernel von QNX, Singularity von Microsoft und Symbian OS. Der Kernel verfügt nur über grundlegenden Funktionen des Speicher- und Prozessmanagement sowie der Prozesskommunikation. Alles andere wird durch Server Clientsysteme, die im Benutzermodus laufen verwaltet. 3. Hybridkernel, dazu zählen die Kernel von MacOSX, Windows NT, ReactOS. Diese Kernel bilden einen Kompromiss zwischen dem monolithischen Kernel und dem Mircrokernel da. 3

4 Kernelstrukturen Grafik entnommen: 4

5 Komponenten des Linux-Kernel Userland Service Bibliotheken Sonstige BS-Komponenten Systemcall-Interface I/O-Subsystem Prozessmanagement Speichermanagement Kernel Gerätetreiber Hardware Grafik entnommen: Linux Treiber entwickeln, Quade u. Kunst 5

6 Systemcall-Interface Applikationen nutzen die Dienste des Betriebssystem über Sytemcalls. Technisch ist das eine Art Software-Interrupt, dieser wird in der Regel durch die eingebundenen Bibliotheken ausgeführt. Der Kernel selbst führt nach dem Auslösen des Software- Interrupt die zugehörige Interrupt-Service-Routine aus. Die entsprechenden Systemcalls in Abhängigkeit der Architektur, finden sich in der Datei <arch/arm/include/asm/unistd.h> die wiederum die Headerdatei <arch/arm/include/uapi/asm/unistd.h> inkludiert. Es gibt 392 Systemcalls für die Architektur ARM. 6

7 Prozessmanagement I Das Prozesssubsystem verwaltet die Prozesse Die Prozesse werden auch Tasks oder Threads genannt Jeder Prozess belegt drei Speicherblöcke: Codesegment, Datensegment und Stacksegment. Teilen sich mehrere Prozesse das Code- und Datensegment spricht man von Threads Prozesse die ein eigenes Datensegment besitzen nennt man Tasks Des weiteren verwaltet das Prozesssubsystem die Zustände der Prozesse. Diese können sein: aktiv, lauffähig(running, schlafend und ruhend. 7

8 Prozessmanagement II Der Kernel unterteilt den Zustand schlafend in unterbrechbare, nichtunterbrechbares und killable Schlafen. Weitere Zustände findet man in der Headerdatei <include/linux/sched.h> - - #define TASK_RUNNING 0 - #define TASK_INTERRUPTIBLE 1 - #define TASK_UNINTERRUPTIBLE 2 - #define TASK_STOPPED 4 - #define TASK_TRACED 8 - /* in tsk->exit_state */ - #define EXIT_ZOMBIE 16 - #define EXIT_DEAD 32 - /* in tsk->state again */ - #define TASK_DEAD 64 - #define TASK_WAKEKILL 128 8

9 Prozessmanagement III Rechenprozesszustände: fork/clone lauffähig/ru nning TASK_WAKING wakeup ruhend/terminiert ununterbrechbar UNINTERRUPTIBLE ZOMBIE wait Scheduler sleep unterbrecbar INTERRUBTIBLE sleep exit aktiv/curre nt Grafik entnommen: Linux Treiber entwickeln, Quade u. Kunst 9

10 Speichermanagement Das Speichermanagement ermöglicht die Reservierung von Speicher. Der Zugriff wird überwacht. Der Speicherbereich wird unterteilt in Kernelspace und Userspace. Der Kernel bzw. der Gerätetreiber kann nicht direkt auf den Speicher einer Applikation zugreifen. Das Umrechnen der logischen Speicheradressen auf die physikalischen Adressen wird durch Funktionen im Kernel durchgeführt. Es funktioniert nur im Zustand current einer Task Das Speichersubsystem übernimmt das Paging und Swapping, was den Zugriff auf den Speicher durch den Treiber erschwert. 10

11 IO-Management Das IO-Management ist für den Datenaustausch zwischen den Programmen und der Peripherie zuständig. Das IO-Management stellt ein: Interface zur systemkonformen Integration von Hardware Eine einheitliche Programmierschnittstelle Ordnungsstrukturen in Form von Dateien und Verzeichnissen siehe auch /dev/... zur Verfügung. Es gibt traditionell Schnittstellen für zeichen- und blockorientierte Geräte. Und eine Vielzahl von Subsystemen die Hardware wie USB, PCI etc. ansprechen. 11

12 Voraussetzungen Gerätetreiber I Um einen Treiber zu entwickeln benötigen man zuerst die Kernelsourcen, </usr/src/linux>, beachten Sie, das dieses im Allgemeinen ein Link auf die Sourcen ist. Hinweis: alle weiteren Angaben zu Dateien und Verzeichnissen sind ab jetzt relativ zum Sourcepfad Einen übersetzten Kernel mit Modulen. Eine Entwicklungsumgebung zur Übersetzung der Sourcen. In unserem Falle benutzen wir den Crosscompiler. Den aktuellen Kernel für den Raspberry Pi kann man mit dem folgendem Befehl laden. git clone --depth=1 12

13 Voraussetzungen Gerätetreiber II 1. Anpassen und Übersetzten eines Kernels Zum Anpassen wechselt man in das Verzeichnis in dem die Kernelsourcen liegen. Durch den Aufruf make menuconfig wird eine grafische (Ncurses) Oberfläche gestartet. Dazu wir die Bibliothek libncurses5-dev benötigt. Durch Auswahl von Save, wird die Konfiguration in die Datei.config gespeichert 13

14 Voraussetzungen Gerätetreiber III 14

15 Voraussetzung Gerätetreiber, Device-Tree Die Vielzahl der ARM-Prozessoren führte nicht nur zu einer Überfrachtung der Kernelsourcen sondern auch dazu, dass das eigentliche Ziel compile once, run everywhere nicht erreicht wurde. Deshalb bediente man sich der bestehenden Technik die beim Linuxkernel für Power-PC genutzt wurde. Die Hardwarekonfiguration wurde nicht in den Kernel compiliert, sondern man stellt sie in einer Datenstruktur neben dem Kernel im Speicher zur Verfügung. Das ganze passiert während der Startphase durch den Bootloader. Daher muss der Device-Tree für die Hardware auch im unserem Fall im Verzeichnis /boot liegen. Neben den Device-Trees gibt es noch das Pincontrol-System, das ab der Kernelversion 3.1 eingeführt wurde. Jerder PIN bekommt einen Namen und eine Nummer PINCTRL_PIN0(0, A1 ). Die PIN s werden anschließend zu Gruppen zusammengefasst und konfiguriert. 15

16 Voraussetzungen Gerätetreiber IV speziell Raspberry PI In der Datei README finden sich weitere Möglichkeiten die Kernelkonfiguration anzupassen. Mit dem Befehl make ARCH=arm bcm2709_defconfig erzeugt man die Konfigurationsdatei.config speziell für den Raspberry ab Version 2 Der Aufruf make ARCH=arm CROSS_COMPILE=arm-linuxgnueabihf- -j16 erzeugt den Kernel und die Module. Jetzt muss noch das Sourceverzeichnis gepackt und auf den PI übertragen werden. Nutzen Sie folgenden Befehle: tar cfz linux_cross.tar.gz linux scp linux_cross.tar.gz pi@raspxx:/home/pi/progs CROSS_COMPILE ist eine Umgebungsvariabel aus kbuild 16

17 Voraussetzungen Gerätetreiber V speziell Raspberry PI Sind die Sourcen übertragen werden sie mit dem Befehl tar xfz linux_cross.tar.gz entpackt. Mit uname a ermittelt man die bereits installierte Kernelversion Wechseln Sie in das Verzeichnis linux und geben Sie make modules_install ein. Kopieren Sie den kompilierten Kernel mit dem Befehl cp arch/arm/boot/zimage /boot/linux-<kernel-version> Bearbeiten der Datei config.txt im Verzeichnis /boot auf dem Raspberry Pi. Das hinzufügen bewirkt, dass der neu installierte Kernel gestartet wird. Fügen Sie die Zeile: kernel=linux<kernel version> zb.: linux v7+ und die Zeile:device-tree=<device-tree-version> z.b.: bcm2709-rpi-2-b.dtb sudo cp arch/arm/boot/dts/*.dtb /boot/ sudo cp arch/arm/boot/dts/overlays/*.dts /boot/overlays Rebooten Sie das System GOOD LUCK!!! Loggen Sie sich wieder ein und überprüfen Sie die Version 17

18 Der erste Gerätetreiber I module_init() und module_exit() sind Funktionen die Funktionen bekanntgeben, um den Treiber zu initialisieren und aus dem Kernelspace zu entfernen. Sie nutzen spezielle Kernelmakros um die Rollen der Funktionen zu identifizieren. printk() ist ein Pendant zu printf(), nur das printk() speziell für den Kernel ist, da er sich nicht der C-lib bedient. 18

19 Der erste Gerätetreiber Das Makefile: Dokumentation: Documentation/kbuild/ Oder online: 19

20 Tools zum Einbinden und Entfernen von Modulen insmod bindet das Modul in den Kernel ein rmmod entfernt das Modul aus dem Kernel lsmod zeigt die geladenen Module an modinfo gibt Informationen zu dem Modul aus modprobe lädt und entfernt Module aus dem Kernel Fehlersuche: Der syslog Dämon zeigt die Ausgabe der Befehle in /var/log/messages an dmesg 20

21 Literatur Linuxsourcen Ldd3: Linux Device Driver 3rd Edition Embedded Linux lernen mit dem Raspberry Pi, Jürgen Quade, ISBN , Ergänzungen und Downloads zum Buch Linux Treiber entwickeln, Jürgen Quade u. Eva-Katharina Kunst, ISBN , Ergänzungen und Downloads zum Buch 21

22 Literatur Jake Edge, "ARM and defconfig files": Das U-Boot: BCM 2835: Pincontrol-Subsystem Dokumentation im Kernel-Quellcode: Raspbian: "How to boot using device tree": Device Tree Usage: J. Quade, K. Kunst, "Linux-Treiber entwickeln", 3. Auflage: Dpunkt-Verlag 2011; S. 113 ff. "A Tutorial on the Device Tree (Zynq)":