|
|
II-PRT SS05
|
In den vorausgehenden Vorlesungen wurden vorwiegend Grundbegriffe von Realzeitsystemen vermittelt sowie einige abstrakte Modelle zur Beschreibung solcher Systeme; ein Schwerpunkt lag auch auf der Planung von Taskmengen unter Berücksichtigung der Resourcen und der Deadlines.
In den verbleibenden Vorlesungen soll nun der Versuch unternommen werden, zu zeigen, wie man von solchen abstrakten Modellen von Realzeitsystemen zu konkreten Systemen kommt. Dabei wird zusätzlich thematisiert werden, dass es sich nicht nur um Realzeitsysteme handelt, sondern um eingebettete Realzeitsysteme ('embedded realtime systems').
Der Begriff des 'eingebetteten' Systems ist kein ganz scharfer Begriff, er ist unscharf, 'fuzzy'. Eingebettete Systeme unterscheiden sich von 'normalen' Systemen in der Regel dadurch, dass eingebettete Systeme solche Systeme meinen, in denen ein Computer als 'Teil' eines grösseren Systems vorkommt. In [YAGHMOUR 2003:5-7] werden eingebettete Systeme klassifiziert nach den Kriterien {Grösse, Zeitanforderungen, Vernetzbarkeit, Grad der Interaktion mit Benutzer}. Entsprechend der Breite dieser Kriterien fallen unter den Begriff 'eingebettete' Systeme eine grosse Bandbreite real existierender Systeme, und zwar nicht nur einzelne Systeme sondern auch ganze Cluster, die zusammen ein komplexes System bilden (z.B. Benutzerschnittstellen, die mit einem Systemmanager verknüpft sind, der sowohl 'nach aussen' mit anderen Netzen kommunizieren kann wie auch 'nach innen' mit Modulen wie Datengewinnung und Kontrolle ('Control')). Der entscheidende Unterschied zur 'normalen' Softwareentwicklung ist im Falle von engebetteten Systemen möglicherweise der Aspekt, dass ein Entwickle von eingebetteten Systemen vollständige Systeme entwickeln muss, d.h. der Entwickler muss alle Komponenten im Blick haben: die Besonderheiten der Hardware, das Betriebssystem sowie die Anwendungssoftware. Die typische Entwicklungssituation wird durch folgendes Schaubild gekennzeichnet:
Cross-Plattform-Entwicklungsumgebung und Zielsystem Es gibt eine bestimmte Hardware, auf der eine bestimmte Funktionalität realisiert werden soll. Dies ist das Zielsystem ('target'). Die Entwicklung der Software, die für das Zielsystem bestimmt ist, wird gewöhnlich auf davon getrennten und für die Entwicklung eigens eingerichteten Entwicklungsrechnern ('host') vorgenommen. Der Entwicklungsrechner hat Zugriff auf die Quellen des geplanten Betriebssystems, auf die geplante Anwendungssoftware, verfügt über eine Reihe von Softwarewerkzeugen zum Editieren, Modellieren, Testen und Optimieren, möglicherweise auch zum Emulieren. Meistens verfügt das Entwicklungssystem auch über eine Verbindung zum Zielsystem um implementierte Software auf dem Zielsystem direkt testen und debuggen zu können. Die Software des Zielsystems muss so beschaffen sein, dass das Zielsystem, wenn es eingeschaltet wird, bootet und durch das Booten sämtliche Software aktiviert, die für sein angezieltes Verhalten notwendig ist. Im Bereich des Bootens unterscheidet man unterschiedliche Bootstrategien, z.B.: Von Diskette Aus einem (Flash-)ROM Von CD-ROM/DVD Von Platte Aus dem Netz (Ethernet...) Für die Qualität und Zuverlässigkeit eines Zielsystems spielen folgende Aspekte eine Rolle: Modularität: wichtige Funktionalitäten sollten soweit wie möglich in eigenen Modulen gekapselt werden Einfache Fehlerbehebung: für alle, die das System verstehen, sollte es einfach sein, Fehler imKode zu beheben. Erweiterbarkeit: es sollte gut möglich sein, neue Eigenschaften hinzuzufügen. Konfigurierbarkeit: es muss leicht möglich sein, die notwendigen Programmteile aus den verfügbaren Quellen für bestimmte 'Anwendungen' zusammenstellen zu können. Voraussagbarkeit: das gestartete Programm sollte sich ensprechend den Vorgaben verhalten. Fehlerbehebung: im Falle von Fehlern sollten rechtzeitig aussagekräftige Fehlermeldungen generiert werden. Langlebigkeit: das Programm soll 'möglichst lange' ohne Fehler laufen, auch unter 'schwierigen' Umgebungsbedingngen. Eine sehr schöne Einführung in die Entwicklung von eingebetteten Systemen am Beispiel des Ziel-Betriebssystem Symbian auf der Hardware von bestimmten Handy-Modellen ist das Buch von Gehrlicher und Rupp [GERLICHER/RUPP 2004]. In diesem Buch wird gezeigt wie man unter Windows (alternativ soll auch Linux möglich sein) eingebettete Anwendungen für das Betriebssystem Symbian (Series 60 Vers.6.1 sowie UIQ Vers.7.0) entwickeln kann, so dass die Funktionalität von Smartphones entsteht. Die dazu notwendige SDKs ('Software Development Kits') kann man kostenfrei direkt von Symbian beziehen (siehe: Symbian OS software development kits. Während Symbian mittlerweile Versionen für C++ und Java anbietet, konzentriert sich das Buch von GERLICHER und RUPP an C++, da damit die besonderen Eigenschaften der Hardware --nach den Autoren-- besser ausgenutzt werden können als unter Verwendung der JVM ('Java Virtual Machine'). In dieser Vorlesung werden wir auf Symbian und dessen Programmierung nicht weiter eingehen, da Symbian kein vollständiges Realzeitbetriebssystem ist und ausserdem der Quellkode nicht offen liegt; damit ist Symbian nur als 'black box' nutzbar. Ein anderes heute immer wichtiger werdende Betriebssystem für eingebettete Systeme ist das opensource Betriebssystem Linux. Laut [YAGHMOUR 2003:11-13], der verschiedene Marktuntersuchungen zitiert, war Linux als eingebettetes System in den Jahren 200-2002 schon an vierter Stelle der benutzten Systeme. Gemessen an den zuvor genannten Kriterien für Qualität und Zuverlässigkeit kann man sagen, dass Linux den genannten Forderungen umfassend gerecht wird. Dies liegt nicht zuletzt auch an dem opensource Entwicklungsmodell, das die kontinuierliche Entwicklung des Systems auszeichnet. Das nachfolgende Schaubild zeigt die Grundstruktur des Linux Kernels (www.kernel.org), wie er für alle Einsatzarten (eingebettet, Arbeitsplatz oder Server):
Grundstruktur Linuxkernel Mit Blick auf die Einsatzart 'eingebettet' ist hervorzuheben, dass Linux mindestens eine 32-Bit-CPU mit MMU ('memory management unit') voraussetzt! Dies schliesst einen grossen Teil der kleineren Microcontroller aus. Mit Blick auf die verwendeten Bibilotheken ('Libraries') ist die wichtigste Bibliothek für die meisten Anwendungen die GNU C Bibliothek. Wegen ihrer Grösse gibt es alternative Versionen (z.B. 'uClibc' (www.uclibc.org) und 'diet libc' (www.fefe.de/dietlibc/)).2. Eingebettete Systeme
3. Beispiel Symbian
4. Beispiel Linux
Da die RTAI-Funktionalitäten als Module nachgeladen werden, soll hier Linux soweit erklärt werden, wie es zum Verständnis dieses Zusammenhanges notwendig ist.Fuer weitere Informationen sei verwiesen auf die Webseite von Herrn Houssaini, ganz besonders aber auf die Webseite des hervorragenden Buches von Alessandro RUBINI/Jonathan CORBET [2nd Edition June 2001], hier besonders Kap.2 (dieses Buch ist komplett online verfügbar, dazu die Beispiele im Quellkode!).
Module sind Teile des Betriebsystems, die sich im laufenden Betrieb einfügen und entfernen lassen.
Es sind Programme, die im Kern laufen. Linuxmodule werden mit der Programmiersprache C entwickelt und sind im einfachsten Fall folgendermaßen aufgebaut (Beispiel von der Webseite zu Rubini):
/*
* $Id: hello.c,v 1.7 2000/08/17 11:11:48 rubini Exp $
*/
#define MODULE
#include <linux/module.h>
int init_module(void) { printk("<1>Hello, world\n"); return 0; }
void cleanup_module(void) { printk("<1>Goodbye cruel world\n"); }
Ein Linux bzw. RTAI-Linux Modul hat im Gegensatz zu einem herkömmlichen C-Programm keine main()-Funktion. Es bestehet aus mindestens diesen zwei Funktionen: int init_module(void) und void cleanup_module(void).
Für die Ausgabe kann die bekannte C-Funktion printf von einem Modul nicht benutzt werde, dafür bietet der Kern die Funktion printk (RTAI: rt_printk).
Die Präprozessoranweisung #define MODULE sorgt dafür, dass der für die Modul- und Kernelprogrammierung notwendige Anteil in den Headerdateien Verwendung findet.
Besteht das Programm(Modul) aus mehreren Dateien, wird zunächst jede Datei für sich kompiliert (Option ld -r) und es wird eine einzige Objektdatei Moduol.o erzeugt. Dann werden alle Module miteinander verbunden. Damit entsteht eine einzige ausführbare Datei.
Dies sei hier an einem Beispiel mit einem Kernel der Version 2.4.xx durchgespielt (mit Version 2.6.xx funktioniert es nicht, da das Modulformat anders ist!).
Will man das Modul kompilieren, ohne den Kernel konfiguriert zu haben, ergibt sich folgende Fehler-Meldung:
turing:/home/gerd/public_html/fh/I-RT04/VL/VL9 # gcc -I /usr/src/linux -I/usr/src/linux/include -O2 -Wall -D__KERNEL__ -DCONFIG_M386 -c hello.c
In file included from /usr/src/linux/include/linux/module.h:10,
from hello.c:5:
/usr/src/linux/include/linux/config.h:4:28: linux/autoconf.h: Datei oder Verzeichnis nicht gefunden
In file included from /usr/src/linux/include/linux/list.h:241,
from /usr/src/linux/include/linux/module.h:12,
from hello.c:5:
/usr/src/linux/include/linux/prefetch.h:13:26: asm/prefetch.h: Datei oder Verzeichnis nicht gefunden
In file included from /usr/src/linux/include/linux/module.h:299,
from hello.c:5:
/usr/src/linux/include/linux/version.h:6:2: #error "The kernel sources in /usr/src/linux are not yet configured."
/usr/src/linux/include/linux/version.h:7:2: #error "Please run 'make cloneconfig && make dep' in /usr/src/linux/"
/usr/src/linux/include/linux/version.h:8:2: #error "to get a kernel that is configured like the running kernel."
/usr/src/linux/include/linux/version.h:9:2: #error "Alternatively, you can copy one of the config files"
/usr/src/linux/include/linux/version.h:10:2: #error "arch/$ARCH/defconfig.* to .config, and run"
/usr/src/linux/include/linux/version.h:11:2: #error "'make oldconfig && make dep' to configure the kernel"
/usr/src/linux/include/linux/version.h:12:2: #error "for that configuration."
In file included from hello.c:5:
/usr/src/linux/include/linux/module.h:301: error: parse error before "UTS_RELEASE"
Nach Bereitstellung der Sourcen und Ausführung des folgenden Befehls:
make cloneconfig && make dep
ist der Kernel konfiguriert und in der Datei /usr/src/linux/include/linux/version.h finden sich dann folgende Daten:
#define UTS_RELEASE "2.4.21-99-default" #define LINUX_VERSION_CODE 132117 #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
Wiederholt man jetzt den Befehl zum Kompilieren gibt es keine Fehlermeldung mehr:
turing:/home/gerd/public_html/fh/I-RT04/VL/VL9 # gcc -I /usr/src/linux -I/usr/src/linux/include -O2 -Wall -D__KERNEL__ -DCONFIG_M386 -c hello.c
Der folgende Aufruf des Moduls produziert zwar Warnungen, aber das Modul wird geladen und ausgeführt:
turing:/home/gerd/public_html/fh/I-RT04/VL/VL9 # insmod ./hello.o Warning: loading ./hello.o will taint the kernel: no license See http://www.tux.org/lkml/#export-tainted for information about tainted modules Module hello loaded, with warnings
Da das Modul von einem xterm-Fenster aufgerufen wird, erscheint die Ausgabe nicht direkt auf dem Bildschirm, sondern wird der Datei /usr/var/messages angefügt:
Dec 4 19:16:01 turing kernel: Hello, world
Wird das Modul wieder entfernt:
turing:/home/gerd/public_html/fh/I-RT04/VL/VL9 # rmmod hello
Dann erscheint die Meldung bei der Entfernung des Moduls wieder in /usr/var/messages:
Dec 4 19:41:20 turing kernel: Goodbye cruel world
Für weitere Details siehe das Kapitel 2 (Webversion) (Kapitel 2 (lokale Version) des hervorragenden Buches von Alessandro RUBINI/Jonathan CORBET [2nd Edition June 2001]
Linux Kernel 2
Realzeitsysteme mit Linux und RTAI
Realzeitsysteme
Software Architektur für Realzeitsysteme für WS03
Wie man aus dem Schaubild erkennen kann, liegt RTAI als Schicht zwischen einer anderen Anwendung --einschliesslich einem anderen Betriebssystem-- und der Hardware, und zwar als vollständig transparente Schicht; das andere Betriebssystem --in unserem Fall Linux-- weiss von RTAI nichts.
Anwendungen, die mit RTAI laufen sollen, interagieren mit RTAI über eine eigene Schnittstelle und sind dann von Linux völlig losgelöst. Diese Anwendungen unter RTAI sind vollständig preemptable.
NEWLXRT ist ein Scheduler, der alle Arten von Tasks auf allen Arten von Maschinen verwalten kann. Konkret heisst dies, wenn ein Prozess unter RTAI laufen soll, kann dieser sich beim NEWLXRT 'melden'; er wird daraufhin aus dem Linuxscheduler 'rausgenommen' und direkt RTAI unterstellt.
Damit Realzeit- und Nichtrealzeit-Prozesse miteinander kommunizieren können, benötigen Sie Kommunikationsmechanismen. Diese Kommunikationsmechanismen sind verschieden von den Linux-IO-Systemen. Angeboten werden von RTAI FIFOs, Shared Memory and Bits. Am flexibelsten und am meisten benutzt sind FIFOs.
FIFOs werden über das Modul rtai_fifos zur Verfügung gestellt. Das Verhalten der Realzeit-Fifos ist identisch mit denen der 'normalen' FIFOs unter Linux. FIFOs transportieren Byteströme.
Als Quelle für die folgende Darstellung von RTAI siehe einmal das Usermanual der Sysgo AG zu ELinOS v2.2 sowie die Beiträge des Entwicklerteams von RTAI ( siehe [DIAPM-RTAI [2000]: DIAPM RTAI - Beginner's Guide (Weblocation), (Lokal), Realtime Application Interface for Linux (Erklärung der Systemaufrufe) + Programming Guide).
In einer Kurzbeschreibung kann man sagen, dass es sich bei RTAI um einen kleinen Echtzeitkern handelt, der Linux in einer eigenen Task ablaufen läßt. Linux ist dabei die Idletask, die nur dann aufgerufen wird, wenn keine andere Echtzeittask lauffähig ist. Linux-Interrupts werden vom RTAI abgefangen und in eine Warteschlange gelenkt. Existiert keine Realtime-Routine, so wird das Interrupt an den Standard-Linuxkernel weitergereicht. Die entsprechende Routine wird dann ausgeführt um den Interrupt zu behandeln. Unter RTAI werden Realtime-Programme als Module implementiert, was ihre Funktionalität beschränkt, weswegen werden mit RTAI nur die zeitkretischen Teile des Programms implementiert, alles andere wird von Linux durchgeführt. Dies ist möglich, da RTAI dem Linuxkernel erlaubt, alle seine Funktionen und Dienste beizubehalten.
Ereignisse unter RTAI
Beim Eintreten bestimmter Ereignisse startet RTAI benutzerdefinierte Programmteile. Es gibt zwei Arten von Ereignissen (Interrupts):
Intern: Zeitgesteuerte Interrupts (Timer Interrupts)
Extern: externe Interrupts
RTAI Scheduler
Da Linux ein Multitaskingsystem ist dh. mehrere Programme können gleichzeitig ausgeführt werden müssen zur Laufzeit ständig Entscheidungen über die Zuteilung des Prozessors zu den einzelnen Programmen erfolgen. Diese Entscheidungen, die in Abhängigkeit von dem gewünschten Systemverhalten, der eingestellten Prozesszuteilungsstrategie und der dem Betriebssystem bekannten Prozessparameter gefällt werden, übernimmt der Scheduler. Der Scheduler eines Betriebssystems kann abhängig von der Implementierung bei folgenden Aktivitäten aufgerufen werden:
RTAI stellt drei verschiedene Scheduler-Varianten zur Verfügung. Diese unterscheiden sich dadurch, dass sie zum einen für den Einsatz auf Ein-Prozessor-Maschinen und zum anderen für den Einsatz auf Multi-Prozessor-Maschinen spezialisiert sind. In der Kategorie der Multi-Prozessor-Scheduler gibt es weiterhin zwei Varianten, eine in der die Mehr-Prozessor-Maschine als SMP-(Symmetric Multi-Processor) System und eine in der sie als mehrere Einzel-Prozessoren gesehen wird. Benannt sind diese Varianten nach dieser Eigenschaft ( UNI-Prozessor- , SMP- und Multi-Uni-Prozessor-Scheduler). Alle diese Varianten können sowohl im so genannten Oneshot-Timer-Mode (also der Timer läuft einmal ab und unterbricht dann einmal) oder im Periodic-Timer-Mode betrieben werden (in dem der Timer das System periodisch unterbricht).
Uni-Prozessor-Scheduler: Dieser Scheduler ist recht simpel. Er besteht aus mehreren Listen mit verschiedenen Prioritäten, welche er linear durchläuft und zur Vermeidung von Prioritätenumkehr das Priority-Inhartitance-Protocol nutzt. In dieser Konfiguration ist Linux ein Echtzeit-Prozess wie jeder andere, allerdings mit geringster Priorität.
SMP-Scheduler: Der SMP-Scheduler unterscheidet sich vom Uni-Prozessor-Scheduler dadurch, dass er die Prozesse auf die zur Verfügung stehenden Prozessoren verteilen kann. Das ermöglicht ein paar zusätzliche Dienste, so können zum Beispiel die Paare CPU,Prozess) und (CPU,IRQ) konkret zugeordnet werden. Außerdem können die Timer des APIC (Advanced Programmable Interrupt Controller) der SMP-Architektur genutzt werden.
Multi-Uni-Prozessor Scheduler: Wie der Name schon sagt, sieht dieser Scheduler die SMP-Maschine als eine Ansammlung von Einzel-Prozessor-Maschinen, was bedeutet, dass jeder Prozessor seine Timer unabhängig von den anderen programmieren kann. Also können die Timer-Modi periodic und oneshot abhängig von der CPU verschieden sein.
Bevor wir ein eigene kleine Anwendung unter RTAI betrachten, schauen wir uns an, wie man mit ELinOS v2.2 ein fertiges Projekt klont, realisiert und dann, in einem weiteren Schritt, zu einem anderen Projekt abwandeln kann. Das Projekt, das wir klonen wollen, nennt sich RTAI und findet sich im demos-Ordner von /opt/elinos.
(Hinweis fuer die Umgebung Realzeitlabor: es ist möglich, als normaler User --nicht Root!-- alle Quellen zu kompilieren und eine bootfähige Diskette zu erzeugen. Man muss nach dem Einsatz von Diskettenbefehle nur darauf achten, dass --falls notwendig--, das Diskettenlaufwerk mit dem Befehl umount /media/floppy wieder freigegeben wird. Andernfalls muesste ein neuer User den PC von neuem starten, was etwas aufwendig ist...)
gerd@turing:~/public_html/fh/I-RT04/VL/VL10> /opt/elinos/bin/elinos-cloneproject /opt/elinos/demos/RTAI RTAIDEMO CLONING PROJECT `RTAIDEMO' FROM `/opt/elinos/demos/RTAI' ======================================================== Checking existing project /opt/elinos/demos/RTAI... ok Checking new project RTAIDEMO... ok Cloning project /opt/elinos/demos/RTAI as RTAIDEMO... ok CONFIGURING PROJECT =================== Configuration: reading from ./project.config... ok Current Settings: ELINOS_BOARD = custom ELINOS_CPU = x86 ELINOS_ARCH = 386 ELINOS_LIBC = libc6 ELINOS_DOSNAME = realtime ELINOS_BOOT_STRAT = floppy Please select your board type. (1) 386_libc5 (2) 486_libc5 (3) 486_FPU_libc5 (4) 386_FPU_libc5 (5) dilnet_pc_libc5 (6) 386 (7) 486 (8) 486_FPU (9) 386_FPU (10) dilnet_pc (11) custom Board Type [custom]: 486 Project Name (8 characters at most, no blanks) [realtime]: RTAIDEMO You must now select the boot strategy for your new project: (1) floppy -- Floppy Bootstrap (2) lilo -- Hard-Disk Bootstrap (3) rolo -- x86 ROM Bootstrap with ROLO (4) rolo_rawdisk -- ROLO disk boot image (eg. for CompactFlash) (5) etherboot -- Diskless Network Bootstrap (6) etherboot_multi -- Diskless Network Bootstrap (one Image for Kernel/Root-Filesystem) Boot Strategy: [floppy]: 1 Please select your kernel source tree. The suggested order is: (1) linux-x86-2.4.18 Kernel Source Tree [1]: Checking Kernel-Source /opt/elinos/linux/linux-x86-2.4.18... ok Wiping old kernel... ok Setting up new kernel... ok Rename mkefs script "realtime.mkefs" to match new project name? [y]: y Writing file ./project.config... ok Writing file ELINOS.sh... ok Configuring Features in /home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO ========================================================================= *** initializing features *** feature input complete *** initializing features *** feature input complete *** running feature configuration scripts ... (prepare) done. (commit) done. (mkefs) done. (kernel) done. (unkernel) done. *** merging kernel configuration with feature-config ... Feature build complete. ---------------------------------------------- Your new project has been set up successfully. To work on it, type: sh# cd "/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO" sh# . ELINOS.sh ---------------------------------------------- CLONING DONE.
gerd@turing:~/public_html/fh/I-RT04/VL/VL10> su Password: turing:/home/gerd/public_html/fh/I-RT04/VL/VL10 # cd RTAIDEMO/ turing:/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO # . ELINOS.sh STARTING ELINOS SESSION ======================= Setting up CDK x86_386 for libc6 $ELINOS_BOARD = 486 $ELINOS_BIN_PREFIX = x86_386 $ELINOS_PROJECT = /home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO $ELINOS_DOSNAME = RTAIDEMO $CC = x86_386-gcc $CXX = x86_386-g++ $AS = x86_386-as $GDB = x86_386-gdb
turing:/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO # l insgesamt 70 drwxr-xr-x 8 gerd users 504 2004-12-11 15:47 ./ drwxr-xr-x 4 gerd users 472 2004-12-11 15:45 ../ drwxr-xr-x 2 gerd users 48 2004-12-11 15:45 app.rootfs/ drwxr-xr-x 2 gerd users 48 2004-12-11 15:45 boot/ lrwxrwxrwx 1 gerd users 32 2004-12-11 15:45 configure -> /opt/elinos/bin/elinos-configure* -rw-r--r-- 1 gerd users 2732 2004-12-11 15:46 ELINOS.sh lrwxrwxrwx 1 gerd users 19 2004-12-11 15:45 elk -> /opt/elinos/bin/elk* -rw-r--r-- 1 gerd users 380 2004-12-11 15:47 feature.mkefs drwxr-xr-x 3 gerd users 72 2004-12-11 15:46 feature.rootfs/ -rw-r--r-- 1 gerd users 12741 2004-12-11 15:46 .features drwxr-xr-x 2 gerd users 48 2004-12-11 15:45 kernel.rootfs/ drwxr-xr-x 14 gerd users 688 2004-12-11 15:47 linux/ -rwxr-xr-x 1 gerd users 21761 2004-12-11 15:45 makeboot* -rw-r--r-- 1 gerd users 5085 2004-12-11 15:45 Makefile -rw-r--r-- 1 gerd users 885 2004-12-11 15:46 project.config -rw-r--r-- 1 gerd users 191 2004-12-11 15:45 README -rw-r--r-- 1 gerd users 63 2004-12-11 15:45 RTAIDEMO.mkefs drwxr-xr-x 4 gerd users 96 2004-12-11 15:45 src/
(Anmerkung : der nachfolgende Wechsel nach root ist nicht notwendig !)
turing:/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO # make boot
Reading feature configuration ... complete
Reading implications from /opt/elinos/elk/valid.elk ... ok.
Reading implications from /home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO/valid.elk ... n/a.
make -C /home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO/linux symlinks clean install
...
Preparing for floppy-boot:
Checking for banner ... installing default banner.
Writing syslinux.cfg ... ok.
Ok.
As a final step to get a bootable floppy disk, please copy the
following files to an empty, MS-DOS formatted floppy:
cp syslinux.cfg /floppy/syslinux.cfg
cp banner /floppy/banner
cp boot/vmlinuz /floppy/linux
cp RTAIDEMO.tgz /floppy/RTAIDEMO.tgz
To make the floppy bootable, please type:
/opt/elinos/bin/syslinux /dev/fd0
- NOTE -
You may need root privileges to execute the above commands.
- NOTE -
You may want to customise this script to meet any special
requirements of your target hardware. For instance, you could
add the commands neccessary to copy the boot files to a floppy
disk, or to the download directory of your tftp-server.
The script is located here:
/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO/makeboot
Achtung: Wechsel in den normalen User-Mode!
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> fdformat /dev/fd0h1440
Doppelseitig, 80 Spuren, 18 Sektoren/Spur, Totale Kapazität: 1440kB.
Formatieren ... Beendet
Überprüfen ... Beendet
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> mformat a:
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> mdir
Volume in drive A has no label
Volume Serial Number is 7E35-AA2E
Directory for A:/
No files
1 457 664 bytes free
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> mcopy syslinux.cfg banner RTAIDEMO.tgz a:
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> mcopy boot/vmlinuz a:linux
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> mdir
Volume in drive A has no label
Volume Serial Number is 7E35-AA2E
Directory for A:/
syslinux cfg 78 2004-12-11 16:12
banner 2532 2004-12-11 16:12
RTAIDEMO tgz 848088 2004-12-11 16:12
linux 339599 2004-12-11 16:15
4 files 1 190 297 bytes
266 240 bytes free
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> /opt/elinos/bin/syslinux /dev/fd0
umount: /media/floppy: Das Gerät wird momentan noch benutzt
Man muss jetzt wiedr in den root-Modus wechseln, um auf das Floppy schreiben zu können (Im Falle des Realzeitlabors ist dies nicht notwendig !).
gerd@turing:~/public_html/fh/I-RT04/VL/VL10/RTAIDEMO> su Password: turing:/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO # /opt/elinos/bin/syslinux /dev/fd0 mount: /dev/fd0 ist bereits eingehängt oder /tmp/syslinux.mnt.10865.0 wird gerade benutzt mount: Laut mtab ist /dev/fd0 auf /media/floppy eingehängt turing:/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO # umount /media/floppy turing:/home/gerd/public_html/fh/I-RT04/VL/VL10/RTAIDEMO # /opt/elinos/bin/syslinux /dev/fd0
Wenn man den PC mit der Diskette gebootet hat, wird man aufgefordert, bestimmte Module zu laden:
insmod rtai insmod rtai_sched_up insmod rtai_fifos insmod rt_process
Dann kann man sein eigenes Demoprogramm starten:
/bin/cscope
Beenden erfolgt über Ctrl-C gefolgt von
rmmod rt_process
Noch zu schreiben....