Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
knb:firmware [2021/05/01 17:01] – [Build Parameter] goligo | knb:firmware [2023/04/26 16:18] (aktuell) – [Schnelleinstieg] awickert | ||
---|---|---|---|
Zeile 13: | Zeile 13: | ||
Das hier sind ohne viel Erklärung die Schritte aufgelistet um einmal die Quelltexte herunterzuladen und ein Firmware-Image zu erzeugen. Weiter unten wird dann genauer erklärt wie alles aufgebaut ist und zusammen spielt. So wie es hier steht ist es getestet auf Ubuntu 20.04 Desktop, sollte aber genauso auf anderen Linux-Distributionen funktionieren. | Das hier sind ohne viel Erklärung die Schritte aufgelistet um einmal die Quelltexte herunterzuladen und ein Firmware-Image zu erzeugen. Weiter unten wird dann genauer erklärt wie alles aufgebaut ist und zusammen spielt. So wie es hier steht ist es getestet auf Ubuntu 20.04 Desktop, sollte aber genauso auf anderen Linux-Distributionen funktionieren. | ||
- | Dependencies | + | Git installieren: |
<code bash> | <code bash> | ||
- | sudo apt install git make python2 libncurses5-dev libncursesw5-dev gcc g++ gawk | + | sudo apt-get update |
+ | sudo apt-get install -y git | ||
</ | </ | ||
Zeile 26: | Zeile 27: | ||
<code bash> | <code bash> | ||
cd site-ffm | cd site-ffm | ||
+ | </ | ||
+ | |||
+ | Dependencies installieren: | ||
+ | <code bash> | ||
+ | ./ | ||
</ | </ | ||
Zeile 39: | Zeile 45: | ||
Natürlich kann die Freifunk-Community in München nicht selber eigene Software für so viele verschiedene Routermodelle schreiben, sondern greift auf bestehende Opensource-Projekte zurück, die entsprechend den Anforderungen konfiguriert, | Natürlich kann die Freifunk-Community in München nicht selber eigene Software für so viele verschiedene Routermodelle schreiben, sondern greift auf bestehende Opensource-Projekte zurück, die entsprechend den Anforderungen konfiguriert, | ||
- | Die Grundlage der Firmware ist **OpenWRT**, eine Linux-Distribution um die Standardfirmware von Endkunden-Routern zu ersetzen. Diese wird von **Gluon** erweitert und konfiguriert, | + | Die Grundlage der Firmware ist **OpenWrt**, eine Linux-Distribution um die Standardfirmware von Endkunden-Routern zu ersetzen. Diese wird von **Gluon** erweitert und konfiguriert, |
- | ==== OpenWRT | + | ==== OpenWrt |
- | [[https:// | + | [[https:// |
- | [[https:// | + | [[https:// |
- | OpenWRT | + | OpenWrt |
- | [[https:// | + | [[https:// |
Da es sich um eine Linux-Distribution handelt ist eine große Menge Software-Pakete verfügbar, der auf der Geräten installiert werden kann. Es gibt einen Paketmanager namens " | Da es sich um eine Linux-Distribution handelt ist eine große Menge Software-Pakete verfügbar, der auf der Geräten installiert werden kann. Es gibt einen Paketmanager namens " | ||
- | [[https:// | + | [[https:// |
- | Der OpenWRT-Build ist umfangreich und komplex, aufgrund der Unterstützung vieler verschiedener Hardware-Plattformen. Da der Build in der Regel auf einem x86-64-System läuft, muss zunächst für jede Plattform eine entsprechende Cross-Compile-Toolchain aufgebaut werden, mit der dann der Linux-Kernel, | + | Der OpenWrt-Build ist umfangreich und komplex, aufgrund der Unterstützung vieler verschiedener Hardware-Plattformen. Da der Build in der Regel auf einem x86-64-System läuft, muss zunächst für jede Plattform eine entsprechende Cross-Compile-Toolchain aufgebaut werden, mit der dann der Linux-Kernel, |
==== Gluon ==== | ==== Gluon ==== | ||
Zeile 63: | Zeile 69: | ||
Gluon wird von vielen Freifunk-Communities genutzt. Es bietet genug Funktionalität in der Grundausstattung, | Gluon wird von vielen Freifunk-Communities genutzt. Es bietet genug Funktionalität in der Grundausstattung, | ||
- | [[https:// | + | [[https:// |
- | Der Gluon-Build funktioniert so, dass zunächst die Git-Repositories von OpenWRT | + | Der Gluon-Build funktioniert so, dass zunächst die Git-Repositories von OpenWrt |
==== FFMUC ==== | ==== FFMUC ==== | ||
Zeile 84: | Zeile 90: | ||
===== Branches & Tags ===== | ===== Branches & Tags ===== | ||
- | Es gibt im GitHub-Repository diverse Branches. | + | Es gibt im GitHub-Repository diverse Branches. |
+ | Wenn man das erste Mal einen anderen Remote-Branch auschecken will, so muss man ihn explizit mit angeben: | ||
<code bash> | <code bash> | ||
- | git checkout -b experimental | + | git checkout -b stable |
</ | </ | ||
- | Zurück, oder zu anderen Branches die man schon hat, geht es dann einfach mit | + | Wenn man zwischen |
- | + | ||
- | <code bash> | + | |
- | git checkout stable | + | |
- | </ | + | |
- | + | ||
- | Wenn man zwischen Branches wechselt, der ein anderes Gluon-Release verwendet, so sollte man vorher "make clean" machen, damit es nicht zu Komplikationen kommt. Momentan nutzen unsere Branches das gleiche Gluon-Release, | + | |
Für jeden Release gibt es einen Tag im Git-Repository. Um einen bestimmten Stand nochmal zu bauen, muss man also einen Checkout auf den gewünschten Tag machen, das geht so: | Für jeden Release gibt es einen Tag im Git-Repository. Um einen bestimmten Stand nochmal zu bauen, muss man also einen Checkout auf den gewünschten Tag machen, das geht so: | ||
<code bash> | <code bash> | ||
- | git checkout -b release tags/v2020.3.3.7 | + | git checkout -b release tags/v2022.10.5 |
</ | </ | ||
Zeile 110: | Zeile 111: | ||
**GLUON_TARGETS** | **GLUON_TARGETS** | ||
- | Hier kann man ein oder mehrere Targets angeben, für die Images gebaut werden sollen. Zum Testen empfiehlt sich eine VM zu benutzen, in der man x86-64 Images laufen lassen kann. Wenn man Firmware für ein bestimmtes Gerät bauen will, so muss man erst herausfinden, | + | Hier kann man ein oder mehrere Targets angeben, für die Images gebaut werden sollen. Zum Testen empfiehlt sich eine VM zu benutzen, in der man x86-64 Images laufen lassen kann. Wenn man Firmware für ein bestimmtes Gerät bauen will, so muss man erst herausfinden, |
<code bash> | <code bash> | ||
Zeile 124: | Zeile 125: | ||
</ | </ | ||
- | Gluon bietet eine Menge Umgebungsvariablen an, mit denen man den Build weiter konfigurieren kann. Eine davon ist zum Beispiel | + | **GLUON_DEVICES** |
+ | |||
+ | Erlaubt | ||
+ | |||
+ | [[https:// | ||
+ | |||
+ | Im unten stehenden Beispiel baut man nur das Image für den TP-Link WR841 v13, es können auch mehrere Devices und mehrere Targets angegeben werden. | ||
<code bash> | <code bash> | ||
- | GLUON_DEVICES=" | + | make GLUON_TARGETS=" |
</ | </ | ||
+ | |||
+ | **WEITERE** | ||
+ | |||
+ | Gluon bietet eine Menge Umgebungsvariablen an, mit denen man den Build weiter konfigurieren kann, die vollständige Liste findet sich in der Gluon-Dokumentation: | ||
[[https:// | [[https:// | ||
Zeile 157: | Zeile 168: | ||
</ | </ | ||
+ | ===== Neue Geräte ===== | ||
+ | |||
+ | Die Motivation selber ein Firmware-Image zu bauen liegt oft darin, dass man ein Gerät hat, für das FFMUC keine Firmware anbietet. Da gibt es unterschiedliche Schwierigkeitsgrade, | ||
+ | |||
+ | === Kein OpenWrt Support === | ||
+ | |||
+ | Als erstes ist zu prüfen, ob OpenWrt das Gerät schon unterstützt. Sollte dies nicht der Fall sein, sieht es schlecht aus. Ein neues Gerät in OpenWrt zu supporten ist aufwendig und verlangt tiefgehendes Wissen über den verwendeten SoC, den Boot-Prozess, | ||
+ | |||
+ | === Kein Gluon Support === | ||
+ | |||
+ | Wenn OpenWrt-Support vorhanden ist, aber kein Gluon-Support, | ||
+ | |||
+ | [[https:// | ||
+ | [[https:// | ||
+ | |||
+ | === Kein FFMUC Support === | ||
+ | |||
+ | Das sollte eigentlich gar nicht passieren - die Liste der FFMUC-Geräte ist generiert aus Gluon, mittels contrib/ | ||
+ | |||
+ | [[https:// | ||
+ | [[https:// | ||