ADMIN 03/14 stellt Erste-Hilfe-Tipps zu Windows-Rettung, Backup und Recovery bei Datenbanken vor und verrät wie man Linux-Systeme vollständig sichert und ... (mehr)

Speicherteilung

Als nächstes steht die Zuweisung von Arbeitsspeicher an. GPU und CPU teilen sich das RAM, man berechnet also deren jeweiligen Anteil. Wie viel Speicher die GPU benötigt, hängt vom angedachten Anwendungsfall ab: Bei grafikintensiven Applikationen sollte man ihr 64 oder 128 MByte reservieren, bei textlastigem Betrieb genügen 16 oder 32 MByte. Die Differenz vom insgesamt verfügbaren Speicher, also je nach Modell 256 oder 512 MByte, ergibt das für die CPU verbleibende RAM. Der folgende Shell-Aufruf berechnet sie und gibt direkt den anschließend benötigten Hexadezimalwert aus. RPI und GPU stehen für die Gesamtgröße des Arbeitsspeichers und den für die GPU zu reservierenden Anteil, beide Angaben jeweils in MByte:

# printf "%X\n" $(((RPI-GPU)*1024*1024))

Den so ermittelten Wert, trägt man in die Konfigurationsdatei »rpi.dts« im Verzeichnis »sys/boot/fdt/dts« ein. Darin sucht man diese Zeilen:

memory {
 device_type = "memory";
 reg = <0 0x08000000>; /* 128 MByte */
};

Den vorgegebenen Wert »08000000« (128 MByte) ersetzt man durch den oben berechneten Hexadezimalwert.

Um den Kernel des Betriebssystems anzupassen, findet man in »sys/arm/conf/RPI-B« die passende Konfigurationsdatei. Unter [2] stellt der Autor ein funktionierendes Beispiel zur Verfügung. Grundsätzlich gilt aufgrund des im Vergleich zu modernen PCs sehr eingeschränkten Arbeitsspeichers, dass man nur wirklich notwendige Funktionen aktivieren sollte. Die Monitorausgabe über den HDMI-Anschluss aktiveren beispielsweise die folgenden Zeilen:

device sc
options SC_DFLT_FONT
makeoptions SC_DFLT_FONT=cp850

Außerdem kommentiert man diese Zeile aus:

device vt

Wer eine Maus an den Raspberry anschließen möchte, aktiviert den Treiber für USB-Mäuse:

device ums

Crosscompiling

Nach der Konfiguration des gewünschten Kernels geht es nun zum Kompilieren. Da die Zielplattform eine andere als die des kompilierenden Systems ist, kommt Crosscompiling zum Einsatz. In diesem Beispiel läuft FreeBSD auf einem 32- oder 64-Bit-System von Intel oder AMD, während der Zielplattform Raspberry eine ARM-CPU zugrunde liegt. Deshalb setzt man zunächst die folgende Umgebungsvariable:

# export TARGET_ARCH=armv6

Der nächste Befehl generiert die fürs Crosscompiling nötigen Tools wie Compiler und Linker:

# make kernel-toolchain

Nun erfolgt die Übersetzung des Kernels. Die Option »WITH_FDT=yes« ist hierbei nötig; sie aktiviert den Flattened Device Tree, über den der FreeBSD-Kernel den einzelnen Geräten Treiber zuweist.

# make KERNCONF=RPI-B WITH_FDT=yes buildkernel

Dieser Schritt dauert je nach Hardware etwa eine halbe Stunde. Es folgt der gleiche Prozess fürs Userland, der noch etwa viermal soviel Zeit in Anspruch nimmt:

# make MALLOC_PRODUCTION=yes buildworld

Ist die Kompilierung fehlerfrei durchgelaufen, ermittelt der folgende Befehl die restlichen Umgebungsvariablen für die spätere Installation:

# buildenv=`make buildenvvars | sed 's/MACHINE_ARCH=armv6/MACHINE_ARCH=arm/'`

Nun geht es weiter mit dem Raspberry-spezifischen Bootloader:

# cd sys/boot
# eval $buildenv make MK_NAND=no UBLDR_LOADADDR=0x2000000 clean obj all
# cd /home/raspberry/fbsd

Ähnliche Artikel

comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2019