OpenWrt Buildroot

Aus wiki.freifunk.net
Wechseln zu: Navigation, Suche

Inhaltsverzeichnis

Offizielle Dokumentation

Kamikaze selbst bauen

Eine veraltete Version vom OpenWrt wird unter dem Namen Kamikaze entwickelt. Die aktuelle Version heißt Backfire. Um sich eine eigene Version des OpenWrts zusammen zu stellen, muss ein sogenanntes Buildroot angelegt werden. Dieses Buildroot bildet einen abgeschlossenen Bereich, eine Art Werkstatt, in der alle benötigen Werkzeuge bereit stehen, die zur Erstellung von Images und Software-Pakete notwenig sind. Images beinhalten ein Grundsystem dass direkt auf den Router geflasht werden kann. Nach der Installation kann mit Paketen der Softwareumfang des Routers erweitert werden.

Systemvoraussetzungen

Aktuell lässt sich OpenWrt nur unter Linux oder MacOS compilieren. Wer kein Linux oder MacOS hat, kann sich Linux in einer Virtuellen Maschine installieren. Am schnellsten kommt man zum Ziel, wenn man den kostenlosen VMWare-Player verwendet und dafür ein vorbereitetes VM-Image (z.B. für Debian 5.0 minimal) herunterlädt.

System vorbereiten

Linux

Falls noch nicht vorhanden, müssen einige Pakete nachinstalliert werden. Je nach Distribution können die Paketnamen leicht variieren.

Ubuntu:

sudo aptitude install subversion build-essential binutils flex bison autoconf gettext texinfo sharutils subversion ncurses-dev zlib1g-dev rsync gawk unzip screen mc rsync tcpdump net-tools tftpd wget

Debian:

sudo aptitude install subversion build-essential binutils flex bison autoconf gettext texinfo sharutils subversion libncurses5-dev zlib1g-dev rsync gawk unzip screen mc rsync tcpdump net-tools tftpd wget

Fedora:

yum -y install subversion flex gcc gcc-c++ patch wget zlib-devel ncurses-devel

Alle Pakete installiert? Weiter gehts!

MacOS

Es wird ein Mac OS Extended (Groß-/Kleinschreibung und Journaled) - Partition benötigt. Auf einer HFS+ Partition, die Groß/Kleinschreibung nicht unterscheidet, kann OpenWrt nicht gebaut werden. Sollte diese noch nicht vorhanden sein, legt bitte eine solche Partition an oder erstellt eine Kontainerdatei mit Hilfe des Festplattendienstprogramms, und mountet diese.

Case-Sensitive - Image anlegen

Anleitung zum Erstellen eines Images: Festplattendienstprogramm öffnen -> Neues Image -> Folgende Einstellungen Treffen: Speicherort: selbst wählen (z.b. ~/openwrt ), Volumengröße: 3 - 10 GB (je nachdem wie viele Pakete gebaut werden müssen), Volumenformat: Mac OS Extended (Groß-/Kleinschreibung und Journaled), Verschlüsselung: ohne, Partitionen: Einfache Partition - Apple-Partitonstabelle, Image-Format:Mitwachsendes Image -> Sichern ... Nun wird ein Image erstellt, das ihr als buildroot verwenden könnt. Es sollte nun im Finder erscheinen, und normalerweise nun unter "/Volumes/Image" erreichbar sein.

System für builtroot vorbereiten/ Benötigte Programme installieren

System vorbereiten: Ihr benötigt folgende Software: Xcode Developer Tools (findet ihr auf eurer MacOS - Installations-DVD), SVN (schon im MacOS 10.5 installiert), MacPorts zur installation der Pakete getopt, coreutils, getopt, gawk. (dies bekommmt ihr einfach mittels Aufruf von

 sudo port install getopt;
sudo port install coreutils;
sudo port install getopt;
sudo port install gawk;
sudo port install md5sha1sum;
sudo port install git-core;
sudo port install wget;
sudo port install findutils

in einem Terminal, nachdem macports installiert wurde)

Bitte wechselt nun in dem Terminal in das neu angelegte Image, um dort den Download mittels SVN zu starten, dies könnt ihr mit dem Befehl

   cd /Volumes/Image

Das Basissystem bauen

Am besten legt man dafür ein extra Arbeitsverzeichnis an.

mkdir openwrt
cd openwrt

Nun kann der Sourcecode von OpenWrt aus dem Repository heruntergeladen werden (mehr Infos dazu auf der Entwickler-Webseite)

svn co svn://svn.openwrt.org/openwrt/trunk/

Jetzt wird der "trunk" also der neueste Stand der OpenWrt-Quellen ausgecheckt. Der trunk ist inzwischen sehr stabil geworden und sollte bevorzugt werden. Falls man lieber einen definierten Stand haben möchte, kann man auch ein Release auswählen. Dazu muss lediglich eine andere URL ausgecheckt werden, z.B. OpenWRT Backfire

svn co svn://svn.openwrt.org/openwrt/branches/backfire/

Jetzt kann man ins Wurzelverzeichnis des Buildroot wechseln, also gibt man entweder

cd trunk

oder

cd backfire

ein. Als nächstes startet man mit

make menuconfig V=99

die Konfiguration des Targets. Falls hier ein Fehler auftritt, sind möglicherweise nicht alle notwendigen Softwarepakete installiert. Ansonsten startet eine ncurses-Oberfläche, in der man sein "Target" - also die Hardware, für die man OpenWrt compilieren will, auswählt.

Hier noch Grunsätzliches zur Verwendung dieser Oberfläche: zur Auswahl der Kkategorien drückt man die Entertaste, zur Auswahl der Unterkategorieren bzw. späteren Pakete die Leertaste.

Gehe zum Menüpunkt Target System und wähle Dein gewünschtes aus. Typische Zielsysteme sind:

  • Atheros AR231x/AR5312 [2.6] - Fonera, Ubiquiti Nanostation, DIR-300 und andere ältere Atheros-Systeme
  • Atheros AR71xx/AR7240/AR913x - neuere Atherossysteme wie der TPLink oder Ubiquiti Nanostation M5
  • Broadcom BCM947xx/953xx - Linksys WRTs, Buffelo WHR 54, Asus 500 de Lux/Premium
  • Broadcom BCM947xx/953xx [2.4] - Linksys WRTs, Buffelo WHR G54, Asus 500 de Lux/Premium (alter Kernel 2.4 Treiber, funktioniert sicher für Ad-Hoc-Modus)
  • Intel IXP4xx - Avila Boards
  • RMI/AMD AU1x00 - meshcube
  • TI AR7 - fritzboxen der älteren generation
  • x86 - Soekris, Wrap board, Alix board und ähnliche x86-basierte Systeme

Bei einigen Zielsystemen lässt sich unter Target Profile das Zielsystem näher spezifizieren. Ansonsten sind die vom Buildsystem erstellten Images generisch, d.h. für alle unterstützten Zielsysteme verwendbar. Nach dem Wählen des Zielsystems kann das mit Exit menuconfig verlassen und die Konfiguration gespeichert werden. Nun lässt sich mit

  make

das erste Image kompilieren. Wenn das Host-System über mehrere Prozessoren (oder Prozessorkerne) verfügt, kann das Kompilieren auch mit der Option -j2 oder -j4 (usw.) ausgeführt werden, je nach Anzahl der Prozessorkerne.

Wird das Kompilieren mit einem Fehler unterbrochen, fehlt zumeist vorausgesetzte Software. Man kann die Meldungen des Compilers mit

 make V=99

anzeigen lassen, das sollte man im Fehlerfall tun, um herauszufinden, wo das Problem steckt.

Nach erfolgreichen Kompilieren liegen die Images im Verzeichnis bin/, mit opkg install auf dem Zielsystem nachinstallierbare Pakete unter bin/packages/<architektur>/. Ein Image kann im Regelfall mit tftp geflashed werden. Siehe hierzu auch Freifunk Firmware installieren.

Mehr Software mit Feeds

Bis zu diesem Zeitpunkt kommt das Buildroot nur mit der Minimalaustattung daher. Außer dem System selbst gibt es kaum Pakete, die nachinstalliert werden können. Für ein lauffähiges System nicht unbedingt notwendige Systeme, werden unabhängig von dem (Basis-)Buildroot in sog. feeds gewartet. Mit der datei feeds.conf werden die Quellen für diese zusätzlichen Pakete definiert. Es gibt schon eine Vorlagedatei. diese kann man zunächst umkopieren um sie zu aktivieren:

cp feeds.conf.default feeds.conf

Um die aktuellsten Entwicklungen von Luci einzubinden muss die feeds.conf.default angepasst werden: statt der Zeile

src-svn luci http://svn.luci.subsignal.org/luci/tags/0.8.6/contrib/package

muss dort

src-svn luci http://svn.luci.subsignal.org/luci/trunk/contrib/package

oder besser

src-svn luci http://svn.luci.subsignal.org/luci/tags/0.9.0/contrib/package


stehen. Nun kann man die Feeds aus der feeds.conf in das Buildroot integrieren. Zunächst müssen die Definitionen geupdatet werden (feeds update) und dann kann zusätzliche Software in das Buildroot integriert werden (feeds install). Wenn man in sein OpenWrt Image die LuCI-Oberfläche integrieren möchte, geht das so:

./scripts/feeds update -a                                      # Definitionen ziehen
./scripts/feeds install -a -p luci                           # alles von LuCI + Depends holen
./scripts/feeds install tcpdump nano openvpn  # ein paar andere dazu
make package/symlinks  # erzeugt symlinks in package/feeds/x/y auf feeds/x/y

Danach stehen die neuen Pakete unter make menuconfig zur Auswahl bereit. Mit der Leertaste lassen die Pakete zum kompilieren auswählen. Hierbei bedeutet:

  • [ ] Das Paket wird nicht kompiliert
  • [*] Das Paket wird kompiliert und ins Image übernommen. Es muss nicht mit opkg install nachinstalliert werden.
  • [M] Das Paket wird kompiliert, aber nicht ins Image übernommen. Es kann mit mit opkg install <Paketname> nachinstalliert werden.

Mit dem Slash-Zeichen ('/') kann nach Strings in Paketnamen gesucht werden.

Für Freifunk gibt es ein sogenanntes "Meta-Package", das beinhaltet viele andere Pakete (z.B. olsr), die in Summe zu einem Freifunk-Image führen. Diese Meta-Package findet man unter dem punkt LuCI -> Freifunk:

<*> luci-freifunk-community.................. Freifunk Community Meta-Package

Wichtig ist, es mit <*> auszuwählen, damit es fest ins Image compiliert wird. Per Hand kann man nun noch ein paar andere auswählen, wie z.b tcpdump, net-tools, screen, mtr, und so weiter, was das Herz begehrt. Nach Abschluss der Auswahl kann man die Konfiguration beenden (das Speichern der Konfiguration wieder bestätigen). Nun kann das Image gebaut werden, dazu genügt das Kommando

make

Das dauert wieder eine ganze Weile, dann findet man im Verzeichnis bin/ die Firmware-Images für die gewählte Plattform und unter bin/packages finden sich die ipkg pakete zum Nachinstallieren.

Kamikaze Schmierzettel

Allgemein Nützliches - Tips & Tricks

  • downloaden, aber nicht bauen: make download
  • Kernel konfigurieren: make kernel_menuconfig
  • Kernelsource neu patchen und Kernel neu kompilieren: make target/linux/{clean,compile} V=99
  • einzelnes Core-Package (neu-)kompilieren: make package/<packagename>/{clean,compile} V=99
  • einzelnes Package aus Feed (neu-)kompilieren: make package/feeds/<feedname>/<packagename>/{clean,compile,install} V=99
  • Paket kompilieren auch wenn es nicht in menuconfig gewählt ist: make package/... V=99 DEVELOPER=1
  • manuelles Aktualisieren des Package Index packages/Packages, manuell erstellte Pakete tauchen vorher nicht im opkg index auf: cd bin/<arch>/packages ; ../../../scripts/ipkg-make-index.sh . > Packages ; gzip -c Packages > Packages.gz
  • Paket-feeds updaten (Änderungen an Packeten neu einlesen) : ./scripts/feeds update
  • evtl. neue Programme aus den Paket-feeds installieren (erst hiernach tauchen die Programme im make menuconfig auf): ./scripts/feeds install -a
  • Target- und Paketlisten neu einlesen: rm -rf tmp
  • Buildroot auf den aktuellen Stand der Entwicklung aktualisieren: svn up
  • make bei Fehlern nicht unterbrechen, wenn ein Programm nur als Paket kompiliert wird: make IGNORE_ERRORS=m
  • spicken bei anderen Paketen z.B. finde und zeige vorhandene DEPENDS:= statements in allen Makefiles im packages feed (feeds/packages): grep -Hr --include=Makefile --exclude-dir=.svn -e 'DEPENDS:=' ./feeds/packages
Selbst Pakete entwickeln
  • Meldungen eines einzelnen Packages sehen (bei ERROR: please fix package/pps-tools/Makefile): TOPDIR=$PWD make -C package/pps-tools DUMP=1
  • Makefile variablen in Paketen:
    • Kernel: $(LINUX_DIR)
    • $(KERNEL_BUILD_DIR)
    • $(PKG_BUILD_DIR)
    • $(STAGING_DIR)
  • svn-Konfikte im Buildroot
    • Untersuchen mit svn status
    • Eigene Änderungen zurücknehmen mit svn revert <datei>
    • Konflikt als gelöst markieren: svn resolved <datei>
  • Buildroot aktualisieren: svn up
  • Paket index-datei neu erstellen: make package/index
  • ./staging_dir/toolchain-armeb_gcc4.1.2/bin/armeb-linux-nm file.o: zeigt die Symboltabelle eines Objektfiles an (Kleinbuchstaben = undefinierte Symbole, t|T - Textsegment)

Debuggen mit gdbserver und gdb

Um mit dem Gnu Debugger gdb ein Programm bei Abstürzen o.ä. genauer analysieren zu können, bedarf einiger Handgriffe im Buildroot. Am einfachsten ist es bei einem frischen Buildroot, bei dem die Toolchain noch nicht gebaut wurde. Hier genügt es unter make menuconfig den Eintrag Advanced configuration options (for developers)->Toolchain Options->Build gdb zu markieren. Wurde die Toolchain bereits erstellt (was der Fall ist, wenn ein make ausgeführt wurde), muss sie mit make toolchain/install neu erstellt werden. Dies erstellt einen gdb, der Binaries des eingestellten Zielsystems auf dem Rechner des Buildsystems debuggen kann.

Desweiteren wird das Paket gdb-server benötigt. Dieses findet sich unter Utilities.

Nach dem Bauen der neuen Toolchain und -bei einem frischen Buildroot- des Systems, muss das Programm, das unter gdb-Kontrolle laufen soll, mit Debug-symbolen neu übersetzt werden. Hierzu ist unter make menuconfig der Eintrag Advanced configuration options (for developers)->Build Options->Enable Debugging auszuwählen.

Für weiteres siehe:

Eigene Initscripte

siehe hier