FreeBSD-Current auf Raspberry Pi

B

blabber

Active Member
Ich habe mir heute die Nacht um die Ohren geschlagen um FreeBSD-Current auf einem Raspberry Pi zum Laufen zu bringen.

Mit den beaglebsd Skripten von kientzle@ lassen sich relativ einfach Images für die SD Karte erstellen (ich musste mir einen auditdistd User anlegen um die Installation von Kernel und World in das Image durchführen zu können).

Wenn man dann ein Image hat sollte das Booten des Raspberry kein Problem darstellen. Um den Bootvorgang zu überwachen solltet ihr einen Monitor anschließen. Ich habe es mit der seriellen Konsole versucht und mehrere Stunden mit der Suche nach einem nicht vorhandenen Fehler verschwendet. FreeBSD verwendet die serielle Konsole nicht per default. Der geübte Nutzer kommt natürlich auf die Idee ein
Code: 
console="comconsole"
in die loader.conf zu schreiben. Das funktioniert leider nicht, da die loader.conf gar nicht erst ausgewertet wird (dazu später mehr). Die einzige Möglichkeit die serielle Konsole zu nutzen war das auskommentieren von syscons und Freunden aus der Kernelkonfiguration. Das ist zwar auch mit einem Kommentar in der Kernelkonfiguration so dokumentiert, aber da muss man auch erstmal hinschauen.

Ein weiterer Stolperstein ist die Tatsache, dass in der Kernelkonfiguration das Bauen von Modulen per
Code: 
MODULES_OVERRIDE
unterbunden wird. Das ist blöd, wenn ihr nachträglich einen WLAN Stick oder ähnliches verwenden wollt. Die Zeile habe ich entsprechend auch auskommentiert.

Das Laden der Module zur Bootzeit gestaltet sich leider auch etwas schwierig, da wie bereits erwähnt die loader.conf nicht ausgewertet wird. Ich habe die Klippe durch einen hässlichen rc.local Hack umschifft, bin aber für Vorschläge, wie man das sauberer lösen kann dankbar.

Code: 
#/etc/rc.local

/sbin/kldload wlan_amrr
/sbin/kldload if_run
/etc/rc.d/netif restart
/sbin/dhclient wlan0

Ansonsten lässt sich das FreeBSD wie gewohnt konfigurieren.
 
Zum Laden der Module kannst du so was hier in die rc.conf eintragen:
Code: 
kld_list="smb ichsmb hwpmc coretemp acpi_dock sem cuse4bsd i915 drm snd_uaudio uhci ohci ehci uftdi"
 
Die Option ist der in loader.conf vorzuziehen, weil die Kernelmodule viel schneller geladen werden, wenn der Kernel einmal im Speicher ist.
 
Naja, der Spaß wird leider durch die beschränkte Anzahl an Packages eingeschränkt. Ports auf dem Raspberry Pi zu bauen macht jedenfalls keinen Spaß. Mann kann wohl qemu überreden den Job für einen zu erledigen, aber eine richtig tolle Lösung ist das auch nicht.

Das Basissystem lässt sich ja wirklich einfach crosscompilen, aber die Ports versagen da auf ganzer Linie.
 
blabber schrieb:
Das Basissystem lässt sich ja wirklich einfach crosscompilen, aber die Ports versagen da auf ganzer Linie.
Zum Vergrößern anklicken....
Das wäre mal ein geiles Projekt.

Das erfordert eine klare Trennung von BUILD und RUN Dependencies (die ist ja teilweise schon da). Über diverse Env-Variablen sollten sich viele Standardtools wie Compiler, Linker und Make-Varianten pauschal auf so etwas einstimmen lassen.

Es bedarf sicher einer Menge Eingriffe in individuelle Ports. Aber die Aufgabe die nötigen Grundlagen zu schaffen scheint mir prinzipiell überschaubar.
 
Kamikaze schrieb:
Das wäre mal ein geiles Projekt.

Das erfordert eine klare Trennung von BUILD und RUN Dependencies (die ist ja teilweise schon da). Über diverse Env-Variablen sollten sich viele Standardtools wie Compiler, Linker und Make-Varianten pauschal auf so etwas einstimmen lassen.

Es bedarf sicher einer Menge Eingriffe in individuelle Ports. Aber die Aufgabe die nötigen Grundlagen zu schaffen scheint mir prinzipiell überschaubar.
Zum Vergrößern anklicken....

Ja, die Grundlagen sind schon da: http://matrossi.blogspot.se/2011/08/cross-compiling-ports-for-arm-under.html
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben