Installationsvarianten für Embedded Linux Systeme #

• "Normale" Linux Distros (für Zielplatform-Architektur)
• Vorteile
  • Breites Angebot Software (auch als Binary)
  • Einfaches nachinstallieren von Paketen
• Nachteile
  • RFS nicht readonly (Problematisch wegen Stromausfall)
  • oft keine Rolling Releases (LTS oft wenige Jahre)

Spezielle Embedded Distribution #

• z.B. Poky Link
  • sehr schlanke Distro für Embedded Systeme ...
  • ... aber leider keine langfristigen Updates / Security

Build Framework #

• Alles ab Source generieren
  • Buildroot
  • Yocto / OpenEmbedded
  • Android

Vorteile Buildframeworks #

• Spezifische Auswahl und punktuell viele Alternativen von Software
• Hohe Sicherheit gegen Stromausfall, Systemabsturz (Readonly Partition)
• Eigene Projekte in Buildprozess integrierbar
• Yocto: optional Package Management
  • selber verwaltetes Repository

Nachteile Buildframeworks #

• Keine automatische Security Updates
  • Eigenverantwortung
• Yocto: Hohe komplexität und erforder Einarbeitung
• Package Management ist DIY
  • z.B. System Updates mit A/B Partition und Recovery

Bootvorgang beim PC #

• Bootloader EFI / UEFI oder BIOS Flash
  • Power on Selftest
  • Init der erforderlichen Hardware
  • Boot Device ermitteln
  • Bootmanager laden
• Varianten
  • UEFI lädt den Bootmanager immer aus einer separaten EFI-Partition
  • legacy BIOS: lädt den Bootloader aus MBR
  • UEFI-Firmware / BIOS beinhalten ACPI (Advanced Config und Power Interface) während dem ganzen Betrieb

Bootmanager #

• GRUB2
  • lädt Kernel Image
  • lädt Initial RAM Disk Image (initrd / initramfs /boot/initrd.img) ins DRAM
  • startet das Kernel Image (mit Kernel cmdline aus Bootmanager Config)

Linux-Kernel start #

• Kernel dekomprimiert sich (selber) und initialisiert dannach CPU und Memory Management
• Startet alle statisch gelinkten Treiber (Memory, CPU Verwaltung, Console)
• Falls eine Initramdisk im RAM ist, wird diese temporär gemountet
  • ... und alle zum RFS benötigten Disk+FS Treiber geladen
• RFS wird gemountet nach / entsprechend cmdline
• Start des ersten Usermode Prozesses aus dem RFS: /sbin/init

Userspace Init #

• init ist zuständig für den weiteren Start des Systems
• heute häufig systemd welches als init und auch Service Management dient

Generell #

• Kein UEFI oder BIOS
  • ... statt dessen ein minimalister ROM Bootloader (auf SoC oder SPI Flash)
• RFS ist auf einem Flash-Datenträger
  • SD, eMMC, ...
  • ... oder alternativ auf einer "Initial Ramdisk", welche vom Flash ins RAM geladen wird.
• Bootmanager ist oft ausserhalb einer Partition an einem offset im Flashspeicher
  • ... daher lässt man beim Flash oft die ersten paar Megabyte Partitionsfrei

Abfolge #

1. ROM Loader
2. SPL (Secondary Program Loader)
   • ... auch häufig Preloader genannt.
3. U-Boot
4. Linux Kernel
5. User Space

ROM Loader #

• Je nach Hersteller des SoC
• Häufig Boot Flags via Pins
  • gewisse auf Ground für Medium selection
• typischerweise von MMC / eMMC / Block Device

GPU auf dem CM2711 #

• initialisiert das DRAM
• lädt den Bootloader ins externe DRAM
  • beim Raspi 4B + CM4 ist der Bootloader als Binary auf dem SPI-Flash
  • auf älteren Versionen auf der Bootpartition bootcode.bin.
• lädt die GPU Firmware (start*.elf / fixup*.dat) ab SD-Karte für init von
  • 2D/3D Grafik
  • Kamera
  • Codecs

Bootloader #

• lädt und interpretiert config.txt (FAT Partition).
• lädt Kernel image kernel*.img
  • abhängig von config.txt
• lädt den Device Tree Blob *.dtb
  • worin die HW Parameter definiert sind (Adressen, IRQ/DMA, Clock Config, ...)
  • und in config.txt angegebene Device Tree Overlays für opt. Peripherie (*.dto)
• Startet den Kernel mit der cmdline aus cmdline.txt
• Kernel entpackt sich und mountet RFS und startet /sbin/init

Weitere Config für Boot #

• https://www.raspberrypi.org/documentation/configuration/boot_folder.md

• https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md

• Rasp 4B / CM4

  • Boot ab USB
  • TFTP Boot für Kernel Image
  • rpi-eeprom-config

• SSH Daemon

  • via leere ssh Datei in auf Bootpartition
  • ... oder per raspi-config im Betrieb bei Raspberry Pi OS

Boot ab TFTP + NFS #

1. Bootloader bezieht IP-Adresse sowie Bootserver Params per DHCP
2. Bootloader lädt entsprechend per TFTP das Kernelimage und den Devicetreeblob sowie cmdline.txt.
3. Kernel startet mit cmdline
4. Kernel mountet RFS via NFS
   root=/dev/nfs nfsroot=10.42.0.211:/nfs/client1,vers=4.1,proto=tcp rw ip=dhcp rootwait
5. /sbin/init wird gestartet

Weiteres Beispiel: Cyclone V #

• Aus Application Note

Cyclone V: Layout des Flash #

• Aus Application Note
• Was ist der Nachteil von RAW Mode?

u-boot Bootloader #

• Typischer Bootloader für Embedded Systems
• Open Source
  • angeleht and den Linux Kernel
  • ... HAL, Treiber, dtb
• Teil des Board Support Packages
• Entwickelt von Denx DE

Secondary Program Loader (SPL) #

• Teil von u-boot
• Initialisieren der HW
• Insbesondere laden des DRAM.
• Muss ins SRAM passen!
• Auch First Stage Bootloader genannt (etwas ungünstug wegen Secondary)

u-boot-with-spl.sfp #

• Paket u-boot + SPL
• Bei andren Plattformen z.T. zwei separate Files

Kernel Commandline #

console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait init=/sbin/init

Schlanker Userspace + Init #

• Busybox hat zahlreiche GNU User Space Commands
• ... diese sind in der Regel recht eingeschränkt
• ... und bloss symlinks zu busybox.
• Mit menuconfig konfigurierbar.

Features #

• relativ kleines executable (~ 1.5 MB mit glibc)
• in fast allen schlanken Linux Distributionen für Embedded Systems dabei.
• in PC Distros im initrd dabei

Varianten von Init #

• SysVinit - POSIX-konform (Unix System V Release 4, Linux BSD)
  • Startet / Stoppt anhand Runlevel alle benötigten System-Dienste in einer geordneten Reihenfolge
  • jeder Dienst hat ein Init-Script (shell Script) in /etc/init.d/
• Busybox init (bestandteil von Busybox)
  • nur Grundfunktionalität von SysVinit (keine Runlevels)
• Systemd - auf aktuellen Desktop Linux Systemen
  • schneller systemstart dank parallelisierung
  • Event driven
  • viele Features
  • ... immer noch umstritten (bloat)
  • abwärtskompatibel

Programme Periodisch ausführen #

• mittels Busybox crond
• interpretiert /var/spool/cron/crontabs/<uid>
• crond selbst z.B. in /etc/inittab starten

Init System auf Host #

• systemctl - Steuerprogram für Systemd
• systemctl list-units
• systemctl list-unit-files | grep enabled
• ls /etc/systemd/system/*
• sudo systemctl enable --now ...
• journalctl Journal betrachten.

Buildroot Architektur #

• Open Source Tools / Apps
• ... + eigene Apps
• Makefiles / Config
• = RFS + Kernel + Bootloader
• Verglichen mit Yocto viel einfacher zu konfigurieren und verstehen.

glibc #

Library für Interaktion mit dem Linux Kernel

open, read, write, malloc, printf, getaddrinfo, dlopen
pthread_create, crypt, login, exit