Embedded Systems:Teil Linux (KT1)

• Mittels tmpfs können RAM-Disks an beliebiger Stelle im Verzeichnisbaum eingebunden werden. U.a. wird auf unserem Zielsystem eine RAM-Disk für temporäre Daten auf das Verzeichnis /tmp gemountet: diese ist schneller und verhindert unnötige Schreibvorgänge resp. Abnutzung der SD.

• Via Pseudofilesystem devtmpfs werden in unserer Konfiguration die Devicenodes unter /dev
  direkt vom Kernel bereitgestellt. Die Einträge (Devicenodes) sind also nicht wirklich statisch auf dem Root Filesystem sondern erst bei Zugriff vom Kernel dynamisch erstellt. Die betreffende Info stammt ebenfalls aus der oben erwähnten „Linux Device Tree“ Datenstruktur. Da devtmpfs gleich- zeitig auch eine RAM-Disk ist, können Einträge unter /dev beliebig geändert oder ergänzt werden.

Eine „permanente“ Konfiguration ist hingegen SysV Konform in /etc/network/interfaces einzutragen, wobei eine definierte Struktur einzuhalten ist. Diese sehen Sie auf dem Hostsystem mittels 'man interfaces' .
Aber Achtung, Busybox unterstützt nur die wichtigsten Optionen und leider ist die einzige „Dokumentation“ der entsprechende Busybox Quellcode (ifupdown.c) sodass auch hier googlen meist schneller zum Ziel führt.

1. 'ifup eth0' resp. 'ifdown eth0' .
2. Natürlich ist es auch möglich, die IP-Adresse statt statisch dynamisch per DHCP zu beziehen. Hierzu in /etc/network/interfaces einfach dhcp statt static definieren sowie address und netmask weglassen.

• Nein es klappt nicht - und zwar weil auf dem Zielsystem noch kein root-Passwort definiert ist, denn „kein Passwort-Eintrag“ (in /etc/passwd resp. /etc/shadow) ist nicht identisch mit einem „leeren Passwort“. Definieren Sie auf dem Zielsystem (also via picocom) mittels Command 'passwd' entweder ein eigenes Passwort oder durch zweimal <Enter> ein leeres Passwort.

1. Telnet ist aber ein äusserst unsicheres Protokoll (da alles, auch das Passwort im Klartext übertragen wird), weswegen hier keine „Werbung“ dafür gemacht werden soll.

2. Eine sichere Remote-Shellist hingegen via SSH möglich. Auf „ausgewachsenen“ Systemen wird hierzu normalerweise das Open-SSH Package verwendet. Für schlanke Embedded Systeme gibt es aber das einfach Crosscompilierbare „Dropbear“, welches wir bei der Buildroot menconfig ja schon zugefügt haben und gemäss 'ps' bereits auch läuft.

   Normalerweise benötigt ein SSH Daemon so genannte „Hostkeys“. Aufgrund der Option -R werden diese bei dropbear aber bei jedem Start neu generiert und nur im RAM gehalten.

muss anwendungsspezifisch rechtzeitig auf Ereignisse regieren − Unter „Ereignisse“ verstehen wir MCUinterne/externe HWSignalisation (z.B. Timer)

bei SoftRealtime meistens, bei “HardRealtime” immer!!

SoftRealtime („weiche“ Echtzeitbedingungen) Die anwendungsspezifischen zeitlichen Anforderungen werden

in der Regel eingehalten

HardRealtime („harte“ Echtzeitbedingungen)
Die anwendungsspezifischen zeitlichen Anforderungen werden

immer und unter allen Umständen immer eingehalten

1. Betriebsystemloses System
2. Echtzeit-Multitasking-Betriebssystem (RTOS)
3. Normales"Ausgewachsenes"Desktopbetriebsystem
4. "Abgespecktes" Desktopbetriebsystem

5. Desktop-Betriebssystem (“normal” oder “abgespeckt“) mit Echtzeit- Multitasking-Erweiterung (wie RT-Patch oder Co-Kernel)

Vorteile:

Kleinst möglichster CPU- und Memory- Ressourcenbedarf (im KB- Bereich)
(sofern optimal programmiert) deshalb speziell geeignet für kleine Mikrocontroller (AVR, PIC, MSP430, ARM Cortex-M,...) mit (nur) internem Flash und RAM Interrupt-gesteuert oder pollendes System

relativ kurze (Interrupt-) Latenzzeit relativ „deterministisch”

Nachteile

Problematik Hardware-Treiber... oft Eigenentwicklung nötig (Anpassung ab Application Notes oder Code-Fragmente) kaum geeignet für komplexe Projekte / Anford. − Andernfalls Entwicklungsaufwand zu hoch!

Vorteile:

Komfortable Entwicklungsumgebung,
Riesiges SW-Angebot...
Gute Security – aber auch verbreitete Angriffsziele Riesiges Schnittstellen- und Protokoll-Angebot

Gute “Soft-Realtime” Eigenschaften

Nachteile:

Schlechte “Hard-Realtime” Eigenschaften

Hoher CPU-/Memory-/Disk-Ressourcen-/Energie-bedarf (Läuft bestenfalls ab SSD –> Langzeit-Zuverlässigkeit)

ev. Komplex (sofern Treiber etc. entwickelt werden müssen) → lange Einarbeitungszeit etc.

ev. Lizenz- u. Supportkosten?

Weglassen nicht benötigter Betriebssystem- Mechanismen

−  Schlankerer Kernel: nur effektiv benötigte Treiber

−  Nur Minimum an Systemcommands

−  Reduzierter Bibliotheksumfang

Vorteil:

Wodurch weniger Prozessor- u. Speicherressourcen nötig...

Unterstützt trotzdem Standard-Libs (z.B. libc, POSIX...)

Immer noch grosses SW-Angebot

Ev. auf Ressourcenfressende x86-Architektur verzichten, statt dessen z.B. ARM-Architektur

Schnittstellen-Treiber i.d.R. direkt verwendbar

Nachteil:

Echtzeitfähigkeit dadurch kaum besser

ev. Lizenzkosten?

Ansatz:

gepatchtes Desktop-Betriebssystem läuft als niedrig priorisierter Prozess unter Kontrolle eines Echtzeit-Multitasking-Micro-Kernels

z.B. RTAI, RTLinux, Xenomai, ...

Vorteile

gute RT-Eingenschaften

Nachteiler

Abhängigkeiten zw. RTOS und gepatches Desktop-Betriebssystem...

meist werden nur wenige und rel. alte Kernelversionen unterstützt Upgrade / Security-Upgrade deshalb problematisch....

Ansatz

nur bei Multicore-CPUs möglich: eine CPU exclusiv für RT-Tasks reservieren...

Vorteile

unter Windows die einzige Möglichkeit um RT-Eigenschaften zu verbessern

Nachteile

Zugriff aus RT-Task auf Peripherieressourcen welche auch vom Desktop-OS genutzt werden

− z.B. separate Netzwerk-Interfaces nötig etc. RT-Eingenschaften im Vergleich zu vollwertigem

RTOS trotzdem recht begrenzt

Non-Preemtive Multitasking (== Cooperative M.T.)

- laufende Tasks können nur durch Interupts unterbrechen werden, nach der Interrupt-Behandlung läuft jedoch immer der zuvor unterbrochene Task weiter

→ kein Task-Rescheduling aufgrund von Interrupts möglich

−  Damit ein Taskswitch stattfinden kann, muss also jeder Task im System “kooperativ” sein

−  z.B. bis Windows 3.x

Preemtive Multitasking:

−  Der Kernel (resp. der Scheduler im Kernel) kann bei Eintreffen eines (Hardware-)Interrupts wenn nötig einen Tastswitch (Rescheduling) forcieren.

−  Tasks können somit aufgrund eines Interrupt-Ereignisses aktiviert werden

−  Als (Interrupt-)Ereignisquellen: Peripherie wie Schnittstellen, HW-Timer, ADC, ...

Voraussetzungen für Timeslicing:

Hardwaretimer, entweder welcher periodisch resp. bei Bedarf (Tickless) Interrupts generiert

Kernel mit Preemtive Multitasking
Aus der Timer-Interrupt-Routine kann dann bei Bedarf ein Rescheduling erfolgen

Funktion:

- aufgezwungenes Rescheduling in einem vordefinierten Zeitintervall (z.B. alle 10ms)

- Sofern das Betriebssystem streng prioritätsgesteuert ist, erfolgt das Rescheduling nur zwischen gleich priorisierten Prozessen niedriger priorisierte werden also komplett zurückgehalten, solange höhere die CPU verlangen

− Desktop-Betriebssysteme haben hingegen normalerweise “weiche” Prioritäten, d.h. niederiger priorisierte Prozesse erhalten auch etwas Rechenzeit, auch wenn höher priorisierte “ready” sind(vergleichsweise jedoch weniger).

Damit wird eine Blockieruen bei nicht kooperativen Prozessen verhindert Hingegen sind damit harte Echtzeitfähigkeiten erst recht nicht zu erfüllen!

System On Chip: Freescale i.MX6 Duallite → industrietauglich, auch Doku
CPU: Cortex-A9 Dual core, ink. FPU and NEON SIMD
Graphics Engine und reichlich Peripherie-Schnittstellen
alle Treiber Open Source bootet ab MicroSD (Booten via SD nicht ganz industrietauglich)
1GB DDR3 RAM

C sowie C++ Cross-Compiler

Target-Libraries + zugehörige Headerfiles

GNU Debugger (gdb)

sonstige “binutils” wie
Linker ld, assembler as, objcopy, objdump, ...

1. BIOS (Power On Self Test) oder EFI/UEFI − Ermittelt bootbare Devices sowie Bootreihenfolge ...

2. BIOS → lädt / startet Bootloader aus MBR (1. Sektor der Harddisk)

   UEFI-Partition → lädt / startet Bootloader aus EFI-Part.

   − Dieser Bootloader lädt den Bootmanager aus der Betriebssystem o. EFI-Partition ins RAM

3. Ein Bootmanager lässt eine (gewisse) Auswahl zu −  Lädt z.B. gewünschtes Linux-Kernel-Image und Bootparameter von der HD ins RAM−  lädt üblicherweise ein Initial RAM Disk Image (Initrd resp. initramfs) ins RAM
4. Kernel wird gestartet (per JMP auf Startadresse)...

• −  dekromprimiert sich selbst

• −  initialisiert CPU- und Memory Management

• −  startet die (wenigen) statisch fix im Kernelimage zugelinkten Treiber (z.B. für Memory u. CPU-Verwaltung, Console)

  Prüft, ob im RAM eine “Initial RAM Disk Image” geladen ist und mountet ggf. dieses temporär ; aus dieser Ramdisk werden die zum Booten nötigen Disk+FS-Treiber geladen

• −  Mountet darauf (gem. Bootparameter) die Rootpartition als Rootfilesystem '/' (zuoberst ins VFS)

• −  Der Kernel startet darauf den ersten Usermode-Prozess: /sbin/init

  Der Weitere Start des System erfolgt durch den init-Prozess entweder “SysV konform” (altes Konzept) oder via “Upstart” (Ubuntu) oder via “systemd” (anderen Linux Distributionen)

1. Partitionen sind auf Flash (SD, eMMC oder “raw” Flash)Bootloader ev. ausserhalb einer Partition z.B. an fixer Stelle
2. Bei “Reset” wird Bootloader ab Flash (resp. SD) gestartet

   − dieser lädt Linux-Kernel aus separater Flash-Partition ins RAM

   oder bei Netzerkboot z.B. von einem TFTP-Server ins RAM

   Bei Embedded Systemen wird meist kein “initrd” verwendet: Der Kernel wurde ja schon “customized” für das Zielsystem, d.h beim “Kernel-Build” wurden dem dem Kernel-Image alle zum Booten benötigten Treiber statisch zugelinkt

   Ein initrd kann verwendet werden für Rootfilesystem im RAM (statt auf Flash-Part.)

3. Nach Kernel-Start/-Dekompression/-Init ...

   − mountet der Kernel das Root-Filesystem gem. Kernel-Bootparameter 'root=' z.B. eine Flash-EEPROM-Partition oder eine NFS-Netzwerkfreigabe

   − und startet daraus den ersten (Usermode-)Prozess: /sbin/init

4. /sbin/init führt die Systeminitalisierung durch...

   bei sysV-konformer Initialisierung...
   interpretiert init-Prozess zuerst das File /etc/inittab ...

   in welchem z.B. auf das Start-Script /etc/init.d/rcS verweisen wird,
   gem. welchem dann weitere Scripts und Programme entweder direkt aus rcS oder indirekt

   z.B. über Verzeichniseinträge in /etc/rcS.d/* gestartet werden (keine Runlevels...)

1. Krenel:

   Modularer Kernel (ca. 2-10MB)
   + optional ladbare Treiber (/lib/modules/...) (bis ca. 100MB)

2. Unix-Commands(ls, cd, sh..)

   Normalerweise mehrere 100MB
   Mit “Busybox” hingegen nur ca. 1-2MB

   In Busybox jedoch nicht enthalten:
   Tools für WLAN, Bluetooth, GUI, IPC, ...

   − Müssten separat manuell oder z.B. mittels Build-Framework “Buildroot” übersetzt/zugefügt werden

3. C Standard Library

   glibc → C-Library aus GNU-Projekt: libc6 ca. 2MB, ganze GNU-C-Lib >50MB uClibc → eine auf geringe Grösse optimierte libc: ca. 300kB

4. Oft sind viele weitere Libraries nötig

   in GNU Library enthaltene (libm, libstdc++, libpthread, librt, ... )

   ➢ aus anderen Projekten (X11, gtk, ALSA, OpenSSL, ..., ..., ...)

1. Linux-Kernel

“Ausgewachsener” Linux-Kernel inkl. Speicherschutz
Virtual Memory, Paging, Memory Protection,... in Zusammenarbeit mit der MMU Mainline-Kernel (!) kaum ergänzt mit Patches für:
ohne keine uCLinux-Patches
ohne zusätzliche HW Treiber Patches
mittels einspielen der uCLinux-Patches wäre Linux auch ohne Virtual Memory lauffähig (→ “bare metal”)

1. glibc (volle LibC-Standard-Library)
2. Busybox (All-In-One standard Unix-Commands)
3. weiteren Hilfsprogramme z.B. ssh-Daeamon “dropbear”, Wireless-Tools, ...
4. kein Packet-Manager (!)
5. {noch} keine eigenen Programme

Geben Sie hierbei das aktuelle Ubuntu LTS 64-Bit (Multiarch) ISO-Image an, welches Sie vorgängig ganz vom Server auf Ihren PC herunterladen.
Anmerkung: Nur die „LTS“ Version (Long-Time-Support) garantiert längerfristig Sicherheitsupates!

1. Ubuntu basiert auf Debian und hat deshalb von diesem den Software- Update/Upgrade-Mechanismus geerbt: mit diesem kann Ubuntu einerseits übers Netz aktualisiert werden (für Security- und Bug-Fixes), andererseits können aber auch Programme bequem nachinstalliert werden.

2. Zigtausend OpenSource Programmpakete liegen auf dem Ubuntu-Pool – insbesondere der riesige Bereich „universe“ wird unverändert vom Debian-Pool übernommen, d.h. bloss für den Ubuntu-Release neu compiliert!

1. Statt mittels Programm apt-get kann sofern installiert ohne weiteres auch das Programm apt oder aptitude mit den gleichen Argumenten (update, upgrade, dist-upgrade install, remove, purge...) verwende werden (alle drei Programme sind in etwa gleichwertig und verwenden die gleiche Datenbasis).

2. Die Vorgänge update und upgrade oder auch das Aktivieren zusätzlicher Pool-Bereiche (universe, multiverse,...) kann jedoch auch bequem unter der grafischen Oberfläche erfolgen.

• Sofern mit dem Upgrade ein neues Kernel-Image installiert wurde, sollten Sie das Gastssytem nun rebooten, denn die Treiber der Gastsystemerweiterungen müssen nach jedem Kernel-Update neu kompiliert werden!

Nein

Die Ubuntu-Installation hat den „Administrator“-User sicherheitshalber deaktiviert, Ihnen jedoch glücklicherweise so genanntes „sudo-Recht“ vergeben, d.h. Sie können auf der Kommandozeile durch voranstellen von „sudo“ jedes beliebige Kommando auch unter den Rechten des Sysadmin-Users ausführen!

1. Die Konfigurations-Datei /etc/fstab enthält nötige Informationen, um das Einhängen von Partitionen ^[3] ganz oder teilweise zu automatisieren. Bei Systemen mit systemd als Init-System (kommt unter Ubuntu ab Version 15.04 zum Einsatz), werden auf Basis der Datei /etc/fstab die entsprechenden mount Units erstellt.

2. Hierzu /etc/fstab im Gasstsystem editieren mit: 'sudo gedit /etc/fstab' und folgende Zeile zufügen:

   hostdisk /media/hostdisk vboxsf uid=1000,gid=1000,rw 0 0

1. den „Mountpoint“ noch mittels 'sudo mkdir /media/hostdisk' erstellen und erstmalig manuell mittels 'sudo mount -a' einbinden oder das Gastsystem rebooten.

2. Das „Laufwerk“ sollte hiernach über den Dateimanager zugänglich sein.

1. Da der vorinstallierte graphische Ubuntu-Packagemanager wenig taugt, installieren Sie mit diesem oder per 'sudo apt-get install synaptic' zusätzlich den graphischen Packagemanager „Synaptic“

2. Wonach Sie diesen starten per: Synaptic-Paketverwaltung

1. „Multiarch“ bedeutet, dass Programme für unterschiedliche CPU-Architekturen unterstützt werden, voraus- gesetzt die CPU unterstützt diese und die erforderlichen Libraries sind installiert.

2. Um bei einem 64-bit Linux auch 32-bit Programme laufen zu lassen, müssen also die 32-bit Libraries nachinstalliert werden.

3. Auf aktuellen Ubuntu/Debian/Mint Systemen hierzu zuerst die 32-Bit Architektur aktiviert werden per:
   'sudo dpkg --add-architecture i386' wonach nach einem 'sudo apt-get update' die benötigten 32-Bit Libraries nach- installiert werden können: 'sudo apt-get install libc6:i386 libstdc++6:i386 libncurses5:i386 zlib1g:i386'

1. Da wir auf dem System auch Programme und den Kernel übersetzen möchten, installieren Sie das Metapackage 'build-essential',
2. welches diverse andere Packages installiert (u.a. die make Utility, Headerfiles, etc.) sowie das Package 'autoconf' (für die GNU autoconf Utility): $ sudo apt-get install build-essential autoconf

Zwecks Zugriff auf diese Windows-Freigaben

1. starten Sie den Gnome Dateimanager (nautilus) und lassen in diesem mittels Ctrl-L die Adresszeile anzeigen,
2. in welcher Sie dann folgendes eingeben: smb://fsemu18.edu.ds.fhnw.ch/e_18_data11$
3. Geben Sie auf Anforderung Ihre FHNW-Koordinaten ein und speichern diese am besten permanent im Linux „Schlüsselbund“ - natürlich nur sofern Sie wirklich an Ihrem persönlichen Notebook arbeiten

4. Hangeln Sie sich im Dateimanager zum Unterrichtsordner „ebssd“ durch und erstellen Sie danach ein „Lesezeichen“ per:

   (Click auf das Dateimanager-Zahnrad rechts oben) > Lesezeichen > Lesezeichen hinzufügen

   Das erstellte „Lesezeichen“ finden Sie zukünftig in der Schnellstartliste des Desktops unter Orte!

Nur sofern Sie Linux nativ als Hostsystem haben, benötigen Sie auch noch einen geeigneten VPN-Client für den Zugriff auf das AD von Zuhause:

die FHNW unterstützt wie Ihnen vermutlich bekannt ist das proprietäre „Cisco AnyConnect“ welches SSL-basiert ist.
Zum Glück existiert hierfür eine OpenSource Implementation namens „OpenConnect“, welche sich über das Package 'network-manager-openconnect' installieren lässt.
Das VPN lässt sich danach rechts oben via Netzwerk-Icon einrichten und verbinden..

Danach inspizieren Sie entweder mit 'cat /proc/partitions' oder noch besser mit 'lsblk', ob und unter

welchem Devicenode diese 'disk' eingebunden wurde (vgl. mit Grösse der SD-Karte!!)

• sudo dd if=*.img of=/dev/sdx bs=1M status=progress ; sudo sync

1. Zwischen Target und Host sollen zwei verschiedene Verbindungsarten eingerichtet werden:
   einerseits über die Serielle Schnittstelle (für die Text-Console) sowie übers Ethernet zwecks NFS-Mount (d.h. Netzwerk-Dateifreigabe) und optional TFTP (für das Laden des Kernels beim booten via Netzwerk).

1. Ja, embedded Linux-Systeme unterstützen normalerweise (auch) eine asynchrone serielle Schnittstelle, auf welcher einerseits der Bootvorgang angezeigt und beeinflusst werden kann, andererseits nach booten eine Shell-Console gestartet werden kann.

2. Um diese auf dem Hostsystem (Notebook) anzuzeigen, wird nebst dem USB-Serial Dongle ein geeignetes serielles Terminal-Emulationsprogramm für die Benutzer-Ein-/Ausgabe benötigt. Serielle Terminal- Emulationsprogramme gibt es diverse – sowohl einfache Console-Programme (minicom, picocom, cu,...) wie auch direkt unter der graphischen X11-Oberfläche lauffähige (gtkterm, sayon,...) oder z.B. unter Windows PuTTY. Viele sind jedoch „bucklig“ bis „bockig“.

• Kontrollieren Sie nun z.B. mittels: tail -100 /var/log/syslog
  ob und unter welchem Devicenamen das Interface von Linux erkannt wurde – ev. unter ttyUSB0

• Verbinden Sie das Interface via gekreuztes Nullmodem-Kabel oder Nullmodem-Adapter EMV-gerecht und korrekt mit dem Board: Achtung: beim direkten berühren des Boards immer zuerst eine Massefläche wie z.B. die Ethernet-Buchse berühren und nicht irgendwelche Signal-Pins berühren, in welchem Fall das Board durch die Elektrostatische Entladung Schaden nehmen könnte!!

• Starten Sie danach 'gtkterm' oder 'picocom' mit 115200 Baud sowie ohne Flow Control auf jener Schnittstelle, welche Sie oben ermittelt haben (vermutlich /dev/ttyUSB0 ). Bei picocom werden diese Parameter auf der Kommandozeile angegeben - die picocom-Kurzhilfe per 'picocom --help' zeigt wie Sie Baudrate und tty-Device setzen. (Die volle Hilfe würden Sie per 'man picocom' erhalten).

• picocom -b 115200 /dev/ttyUSB0