Community-Firmware für den TXT

Community-Firmware (cfw), Selbstbaucontroller (TX-Pi, ftduino, usw.), usw.
Forumsregeln
Bitte beachte die Forumsregeln!
richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Community-Firmware für den TXT

Beitrag von richard.kunze » 16 Feb 2016, 22:34

Hallo zusammen,

um das spätestens seit letztem Wochenende spürbar in der Luft liegende Thema mal aufzugreifen hier der passende Thread.

Mein Ziel dabei ist, zum einen alle Informationen zum Thema an einem Ort zusammenzutragen und zum anderen, zusammen mit dem Rest der ft-Community herauszufinden
  • was wir bisher zum Thema haben,
  • was die Community-Firmware können soll und - genauso wichtig - was sie *nicht* tun sollte und
  • wie wir vom ersten Punkt zum zweiten kommen.
Weil das doch recht umfangreich werden kann, möchte ich diesen Beitrag hier als eine Art Inhaltsverzeichnis benutzen und im Lauf der Diskussion immer wieder an den aktuellen Stand anpassen.

Als Diskussionsgrundlage hier in Stichpunkten meine bisherigen Ideen zum Thema:

Was haben wir
Wie soll die Community-Firmware aussehen
  • Kompatibel zur Original-Firmware - insbesondere soll wenn irgendwie möglich alles, was mit RoboPro und der Original-Firmware geht, auch mit der Community-Firmware gehen.
  • Die Original-Firmware soll so wenig wie möglich modifiziert werden.
  • Die Community-Firmware soll leicht zu installieren und ebenso leicht zu deinstallieren sein
  • Die Community-Firmware soll so wenig proprietäre Software enthalten wie möglich. Im Idealfall überhaupt keine
  • ... und natürlich soll die Community-Firmware alles können, was wir uns wünschen und was mit der Original-Firmware nicht geht:
    Wunschliste für die Community-Firmware
    • Webfrontend für die Konfiguration
    • Unterstützung für andere Programmierumgebungen als RoboPro :-)
    • ROS-Support (http://www.ros.org/)
    • TXT als Client in ein bestehendes WLAN einbinden
    • ...
Wie kommen wir da hin

Die Punkte oben geben eigentlich schon den Aufbau der Community-Firmware in groben Zügen vor:
  • Die Community-Firmware kommt auf eine SD-Karte, die Original-Firmware bleibt im internen Speicher des TXT. Installation der Community-Firmware ist dann einfach "SD-Karte einstecken", Deinstallation "SD-Karte entfernen".
  • Die proprietären Komponenten, für die wir keine Alternativen haben, liefern wir nicht mit sondern binden sie aus der Original-Firmware ein.
Der zweite Punkt ist technisch recht einfach zu lösen, dafür bietet Linux ein sogenanntes "Overlay-Filesystem" (https://git.kernel.org/cgit/linux/kerne ... rlayfs.txt) an. Damit kann man mehrere Dateisysteme so "stapeln", dass das Resultat nach außen wie ein einziges, beschreibbares Filesystem aussieht, aber Änderungen ausschließlich in einem der Dateisysteme landen. Die anderen Dateisysteme werden nur gelesen. In unserem Fall würden wir den Flash-Speicher mit der Original-Firmware read-only einbinden (damit haben wir Zugriff auf alle nötigen proprietären Komponenten) und die SD-Karte mit der Community-Firmware beschreibbar machen.

Der erste Punkt ist leider nicht ganz so einfach, weil der TXT im Originalzustand nicht von einer SD-Karte booten kann. Im Thread nebenan (viewforum.php?f=8) haben wir zwar eine Methode gefunden wie man das hinbekommt, aber dafür muss man in der Original-Firmware die Boot-Einstellungen ändern (ist zwar kein schwerer Eingriff, aber ganz ohne wäre schöner) und die bisher "einfachste" Methode, das zu tun, erfodert Root-Zugriff auf dem TXT. Aber machbar ist es auf jeden Fall.

Weitere Einzelheiten wie ich mir das technisch und organisatorisch vorstelle gleich noch in einem eigenen Beitrag.

Richard
Zuletzt geändert von richard.kunze am 17 Feb 2016, 11:06, insgesamt 2-mal geändert.

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Organisatorisches, Details zur Architektur, Erste Schritte

Beitrag von richard.kunze » 16 Feb 2016, 23:28

Organisation

Meiner Meinung nach sollten wir die Community-Firmware in einem eigenen, von https://github.com/ftCommunity/ft-TXT getrennten Projekt entwickeln (Namensvorschlag: community-TXT), weil wir damit Technik

Für den technischen Aufbau sind aktuell zwei Möglichkeiten in Diskussion:
  1. So wie die Originalfirmware, d.h. die Basis ist Buildroot (https://buildroot.org/), dazu kommen notwendige Ergänzungen von TI (von denen kommen das SOC und der Chip für WLAN und Bluetooth) und Fischertechnik/Knobloch oder
  2. Debian als Basis, mit eigenem Kernel und Anpassungen für die Kompatibilität mit der Originalfirmware
Für Variante 1 spricht, dass es näher an der Original-Firmware ist. Das macht es insbesondere leichter, die proprietären Komponenten aus der Originalfirmware einzubinden. Außerdem ist das System schön schlank und ressourcensparend. Nachteil ist, dass viel Wartungsaufwand bei uns hängen bleibt.

Für Variante 2 spricht in erster Linie der riesige Pool an fertiger Software für Debian und die große Entwickler-Community, die Debian auf dem neuesten Stand hält. Nachteil ist, dass Debian mehr Resourcen braucht als ein speziell auf Kleingeräte getrimmtes System,

Die Basis in der offiziellen Firmware inzwischen auch schon wieder zwei Jahre alt. Insbesondere auch der Kernel, und das ist aus zwei Gründen schlecht:
  • Zum einen ist der verwendete Kernel (3.16.1) kein "LTS-Kernel" (LTS steht für "Long Term Support"). Das heißt, für diesen Kernel gibt es von den Linux-Entwicklern keinen Support mehr
  • Zum anderen ist das Overlay-FS (das wir für die Community-Firmware in Variante 1 brauchen), erst ab Version 3.18 offiziell im Linux-Kernel
Deshalb würde ich hier wenn es irgendwie geht auf einen moderneren Kernel aufsetzen. Am sinnvollsten ist dafür wohl der aktuell neueste von TI für das im TXT verwendete SOC angebotene Kernel 4.1 (LTS, mit Support bis Mitte 2017).

Nächste Schritte zu Version 0.1

Wenn es hier keinen lauten Protest gibt, lege ich morgen oder übermorgen das Repository https://github.com/ftCommunity/community-TXT an und fange auf der oben skizzierten Basis an zu entwickeln.

Erstes Ziel ist Version 0.1 mit den folgenden Eigenschaften:
  • Gleicher Funktionsumfang wie Version 4.3.2.0 der offiziellen Firmware (bzw. genauer: wie die Version der offiziellen Firmware, die auf dem jeweiligen TXT installiert ist)
  • Kernel 4.4.x (Mainline) oder 4.1.x (TI)
  • Startet (nach passender Modifikation der U-Boot-Konfiguration auf dem TXT) von der SD-Karte und bindet nötigen Komponenten aus dem Flash ein.
Releasedatum: Wenns fertig ist :-)
Zuletzt geändert von richard.kunze am 17 Feb 2016, 18:25, insgesamt 2-mal geändert.

Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

Re: Community-Firmware für den TXT

Beitrag von Defiant » 17 Feb 2016, 08:16

Da ich kein TXT habe dürft ihr mich gern ignorieren, aber hier meine 2 cent:
- Einen aktuellen Kernel von kernel.org ist meiner Erfahrung nach bei ARM-Prozessoren aufgrund der delikaten Treiberlage unüblich, normalerweise nimmt man die aktuellen Kernel von TI
- Ein Betriebssystem schwenk auf z.B. Debian oder Ubuntu (ja, man kann den jetzigen Kernel/Devicetree weiter verwenden) eröffnet die einfache Möglichkeit zusätzliche Software/Bibliotheken zu verwenden ohne kompilieren des Buildroots und auch die einfache Installation von http://www.ros.org
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 17 Feb 2016, 10:10

Defiant hat geschrieben: Einen aktuellen Kernel von kernel.org ist meiner Erfahrung nach bei ARM-Prozessoren aufgrund der delikaten Treiberlage unüblich, normalerweise nimmt man die aktuellen Kernel von TI
Das wäre Plan B. Ich will es vorher trotzdem mal mit einem Mainline-Kernel versuchen.

Für AM33xx-basierte Boards sollte das nach dem was ich bisher so gesehen habe auch halbwegs gehen. Wenn ich nichts Essentielles übersehen habe, dann liegt da die Hauptarbeit im DTS, und den haben wir ja schon.

Defiant hat geschrieben:Ein Betriebssystem schwenk auf z.B. Debian oder Ubuntu (ja, man kann den jetzigen Kernel/Devicetree weiter verwenden) eröffnet die einfache Möglichkeit zusätzliche Software/Bibliotheken zu verwenden ohne kompilieren des Buildroots und auch die einfache Installation von http://www.ros.org
Prinzipiell ja.

Mein letzter Versuch mit Debian auf einem halbwegs vergleichbaren System (ARM Kirkwood, 256MB RAM) war allerdings nicht so toll. Ich habe ewig daran gebastelt, Debian soweit abzuspecken dass es da vernünftig drauf läuft, aber am Ende ging dann immer noch ein Gigabyte Massenspeicher und ein ordentlicher Batzen RAM nur fürs System drauf. Der Massenspeicher wäre für den TXT mit SD-Karte egal, aber der RAM-Verbrauch dürfte auch auf dem TXT weh tun.

Auf der Kirkwood-Kiste hab ich den Versuch mit Debian am Ende aufgegeben und OpenWRT als Basis genommen. Und wenn Du dich so umschaust, dann haben die ganzen (oder zumindest die prominenten) ARM-Kleinsysteme die mit Debian laufen (RasPI, BeagleBone, ...) auch alle mindestens 512MB RAM.

PS: Ich hab ROS-Support mal in die Wunschliste aufgenommen. Wenn das für Lego Mindstorm geht, sollten wir das eigentlich auch hinkriegen :-)

Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

Re: Community-Firmware für den TXT

Beitrag von Defiant » 17 Feb 2016, 12:02

Hatte Debian schon auf dem Neo Freerunner mit 128MB ;) Daran sollte es nicht scheitern. Ein System mit Busybox belegt natürlich weniger RAM, ist dafür auch weniger flexibel. Zusätzlich müssen alle Pakete von der kleinen Community gepflegt werden.

Zum Thema Kernel: Du müsstest halt auch an die Peripherie denken (Memory Controller, W-Lan etc)

-

Ich find das Super wenn sich hier eine Community entwickelt die sich darum kümmert.
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 17 Feb 2016, 14:36

Defiant hat geschrieben:Hatte Debian schon auf dem Neo Freerunner mit 128MB ;) Daran sollte es nicht scheitern.
War das wirklich benutzbar, oder eher in der Art "laufen tuts zwar, aber..."?
Defiant hat geschrieben:Ein System mit Busybox belegt natürlich weniger RAM, ist dafür auch weniger flexibel. Zusätzlich müssen alle Pakete von der kleinen Community gepflegt werden.
Ja - grade was Wartung und Benutzung angeht wäre Debian natürlich schon klasse. Fast alles was man will nur ein apt-get weit weg, und tausende Leute die sich mit um die Wartung kümmern...

Nun ja, probieren geht über spekulieren - ich nehms mal als Alternative mit in die Liste und probiers aus. Ein minimales Debian-System zusammen mit dem FT-Kernel auf eine SD-Karte packen sollte für einen ersten Eindruck reichen, und das ist ja schnell zusammengestöpselt.
Defiant hat geschrieben:Zum Thema Kernel: Du müsstest halt auch an die Peripherie denken (Memory Controller, W-Lan etc)
Fürs WLAN muss man wohl die Kröte "TI-Treiber" schlucken und den halt selbst integrieren. Der Rest sollte eigentlich gehen.
Und selbst wenns nicht geht: TI ist momentan bei 4.1.x (ebenfalls LTS), da kann man auch mit leben.

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Organisatorisches, Details zur Architektur, Erste Schrit

Beitrag von MasterOfGizmo » 17 Feb 2016, 16:11

richard.kunze hat geschrieben: Wenn es hier keinen lauten Protest gibt, lege ich morgen oder übermorgen das Repository https://github.com/ftCommunity/community-TXT an und fange auf der oben skizzierten Basis an zu entwickeln.
Genau das wäre auch mein Plan gewesen. Das sollte aber als Branch von ft-TXT abzweigen, so dass man Änderungen vom ft-TXT übernehmen kann.

In ft-TXT würde ich dann all die Änderungen gut finden, die dessen generelle Benutzbarkeit sicherstellen oder echte Bugs beheben. Meine gcc-5.1-Patches habe ich deswegen dort rein getan. Die haben keinen funktionalen Einfluss auf das Build-Target, aber erlauben eben, dass es auch auf einem aktuellen Ubuntu geht.

Ebenso würde ich dort z.B. ein paar Sicherungsnetze in die ganzen MakeSD-Shell-Scripte einbauen, die sich verweigern, wenn es Grund zur Annahme gibt, dass man gerade dabei ist, seine Festplatte statt der SD-Karte zu formatieren. Also z.B. wenn die Mediengröße > 20GB ist.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 17 Feb 2016, 16:12

Ansonsten: Ja, alles war Du im ersten Posting geschrieben hast kann ich voll und ganz unterschreiben! Go!
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Organisatorisches, Details zur Architektur, Erste Schrit

Beitrag von MasterOfGizmo » 17 Feb 2016, 16:20

richard.kunze hat geschrieben: Für den technischen Aufbau sind aktuell zwei Möglichkeiten in Diskussion:
...
Das sollten wir durch separate Branches regeln. Sonst besteht die Gefahr, dass so ein Komplettumbau sich als zu aufwändig rausstellt und dann wird nix draus.

Ein community-TXT wäre in der Tat ein toller erster Schritt. Zum Beispiel die fehlenden dhcpcd-Hooks nachzuliefern und wenn möglich die TXT-GUI (ja, den Source-Code haben wir noch nicht) so zu erweitern, dass man AP auswählen und Passphrase eingeben kann wäre m.E. ein erster Zwischenschritt, der vielen hier den lange gehegten Wunsch, den TXT ins Heim-WLAN zu hängen, erfüllen würde.

Ein TXT-Debian wäre wohl eh nicht sinnvoll als Branch des ft-TXT zu realisieren, sondern eher als Branch eines bestehenden Arm-Debian.

Was etwas nervig ist ist, dass wir nicht wissen, wo wir hier gerade Arbeit doppelt machen, weil Knobloch/FT im stillen Kämmerlein an der gleichen Baustelle flickt. Da wäre wieder die Kooperation von FT sehr hilfreich. Am coolsten wäre natürlich, wenn wie sie dazu bewegen könnten ihren dev-Version ebenfalls als Branch von ft-TXT anzulegen und dann bei Release zurück zu pullen ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Organisatorisches, Details zur Architektur, Erste Schrit

Beitrag von richard.kunze » 17 Feb 2016, 16:57

MasterOfGizmo hat geschrieben: Das sollten wir durch separate Branches regeln. Sonst besteht die Gefahr, dass so ein Komplettumbau sich als zu aufwändig rausstellt und dann wird nix draus.
Die Gefahr besteht natürlich immer - aber man kann ja in Variante 1 auch schrittweise zurückgehen, bis man irgendwann bei "Original-Firmware plus Patches" landet.
MasterOfGizmo hat geschrieben: Ein TXT-Debian wäre wohl eh nicht sinnvoll als Branch des ft-TXT zu realisieren, sondern eher als Branch eines bestehenden Arm-Debian.
Ja, ein Debian wäre auf jeden Fall ein eigenständiges Projekt. Und eher noch nicht mal ein komplettes Repository, sondern eher nur ein Sammlung von ein paar Scripten, die ein passendes Image bauen, plus Source für die Pakete die wir dafür selbst bauen müssten (Kernel, Integration der ft-Software, ...).

Aber erst mal abwarten ob das überhaupt ordentlich geht - ich bastel da grade einen Quick-and-Dirty Proof of Concept zusammen.

Markus Burkhardt
Beiträge: 171
Registriert: 12 Jan 2016, 09:13

Re: Community-Firmware für den TXT

Beitrag von Markus Burkhardt » 17 Feb 2016, 17:18

Hallo zusammen,

die Möglichkeit, den TXT ins Heim-WLAN zu hängen, wird es demnächst von uns geben. Und wenn ich meinen Senf dazugeben darf: ich finde es auch sinnvoll, den Kernel, den TI anbietet, zu nehmen.

Viele Grüße
Markus

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 17 Feb 2016, 17:40

Markus Burkhardt hat geschrieben: die Möglichkeit, den TXT ins Heim-WLAN zu hängen, wird es demnächst von uns geben. Und wenn ich meinen Senf dazugeben darf: ich finde es auch sinnvoll, den Kernel, den TI anbietet, zu nehmen.
Klingt gut. Zeigt aber auch, dass wir in der jetzigen Situation Gefahr laufen, zwei seperate Zweige zu bekommen, was ich persönlich demotiviernd fände. Mein Ziel wäre schon, den TXT einen ordentlichen Schritt voran zu bringen.

Die aktuelle Aufbruchstimmung wird sicher nicht ewig vorhalten. ich hoffe FT nutzt die Gunst der Stunde ...
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 17 Feb 2016, 18:06

richard.kunze hat geschrieben:Aber erst mal abwarten ob das überhaupt ordentlich geht - ich bastel da grade einen Quick-and-Dirty Proof of Concept zusammen.
OK, mein schnell und dreckig zusammengefrickelter Bastard aus einem fertigen Debian ARM EABIhf Userland und Kernel, DTB und Modulen vom TXT macht zwar irgendwas, bootet aber nicht so weit durch dass es per USB-net erreichbar wäre. Seufz. Muss ich wohl doch warten bis der bestellte Seriell-nach-USB-Konverter endlich hier eintrudelt...

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 17 Feb 2016, 18:19

Markus Burkhardt hat geschrieben:die Möglichkeit, den TXT ins Heim-WLAN zu hängen, wird es demnächst von uns geben.
Fein.
Markus Burkhardt hat geschrieben:Und wenn ich meinen Senf dazugeben darf: ich finde es auch sinnvoll, den Kernel, den TI anbietet, zu nehmen.
OK, überzeugt. Einfacher dürfte es allemal sein.

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 19 Feb 2016, 16:24

Ich habe mal den kernel and uboot-Zweig aus dem Archiv unter knobloch/TXT eingecheckt. Damit fehlt nur noch board/knobloch/TXT/rootfs mit den FT/Knobloch-Binaries.

Der uboot-Zweig enthielt eine ganze Menge Object-Files etc. Müsste man mal schauen, ob er die nicht doch alle automatisch neu baut und ob die daher wieder von github entfernt werden können.

Wenn alles auf github ist sollte man wohl eh einmal schauen, was davon wirklich nötig ist, und ggf. ein wenig aufräumen.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 20 Feb 2016, 11:19

Hallo zusammen,

Ich sitze gerade an einer ersten Version von ftcommunity-TXT. Nach etwas Überlegung denke ich, es ist wohl doch am besten erstmal bei Variante 1 (also Buildroot-basiert) zu bleiben. Debian für den TXT klingt zwar ebenfalls sehr interessant, aber das ist was für später.

Falls niemand hier noch eine bessere Idee hat, baue ich ftcommunity-TXT wie folgt auf:
  • Basis ist ein aktuelles Buildroot (https://git.busybox.net/buildroot). Für den Moment sogar der Master-Branch, sobald die neueste Version (2016.2) fertig ist (sollte demnächst passieren, aktuell sind sie da bei rc2) dann der passende Stable-branch.
  • Kernel wird der aktuelle Kernel 4.1.y von TI (http://git.ti.com/ti-linux-kernel/ti-linux-kernel)
  • Boardspezifische Anpassungen und die Konfiguration kommt von ftCommunity/ft-TXT
In ftcommunity-TXT gibt es drei langlebige Branches:
  • master: Hier findet die eigentliche Entwicklung statt
  • buildroot: Trackt den Branch auf https://git.busybox.net/buildroot, auf dem wir aufsetzen (zunächst mal "master", später dann "2016.02.x")
  • ft-TXT: Trackt ft-TXT/master - hier landen dann auch eventuelle Änderungen, die wir aus ftcommunity-TXT nach ft-TXT zurückspielen wollen
Wie ich den TI-Kernel einbinde weiß ich noch nicht genau - so wie in ft-TXT einfach einen Schnappschuss nach board/knobloch/board-support kippen möchte ich eigentlich nicht. Und die etwas besser in Git handhabbaren Alternativen (als "subproject" oder "subtree") haben auch ihre Nachteile.

Weitere Branches (sowohl kurzlebige für Features als auch langlebige für Releases) dann je nach Bedarf.

Viele Grüße,

Richard

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 20 Feb 2016, 11:51

Klingt ausgezeichnet.

Ursprünglich dachte ich, dass wir eine erste Version direkt vom ft-TXT abzweigen und von dort aus weiter machen. Aber das ist in der Tat eine Sackgasse ...

Und da wir wohl davon ausgehen können, dass Fischertechnik keine grundlegenden Aktualisierungen mehr vornimmt ist ein komplett frischer Buildroot-Branch wohl tatsächlich eine sehr sinnvolle Sache, bei der wir uns mit FT nicht in die Quere kommen.

Ja, wie man hübsch den Kernel einbindet ist tatsächlich die Frage. Da wir den TXT wohl kaum dazu bringen werden, direkt von SD-Karte (also ohne den Umweg über UBoot aus dem NAND) zu booten stellt sich aber zumindest die gleiche Frage beim UBoot nicht.

Was ist das Problem mit sub-Projekten/Trees? Sind die nicht für genau sowas gedacht?
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 20 Feb 2016, 12:34

MasterOfGizmo hat geschrieben:Ja, wie man hübsch den Kernel einbindet ist tatsächlich die Frage.
Ich werde das wahrscheinlich so machen wie beim BeagleBone (das benutzt dasselbe SOC, und dafür ist eine passende Konfiguration direkt in Buildroot mit dabei): Eine passende Konfiguration unter configs/ anlegen und da dann URL/Revison vom TI-Repository eintragen. Eventuell noch notwendige Anpassungen am Kernel (hoffentlich keine) landen dann als Patches in board/knobloch/TXT/patches.
MasterOfGizmo hat geschrieben:Was ist das Problem mit sub-Projekten/Trees? Sind die nicht für genau sowas gedacht?
Bei Subprojekten steht im Hauptrepositroy nur die URL und die passende Revision für das eingebundene Verzeichnis, auschecken und updaten muss man sie separat. Das ist unbequem für den "nur-Benutzer", der sich einfach die Community-Firmware bauen will.

Bei Subtrees kommt zwar alles direkt beim initialen "clone" mit, aber man muss als Entwickler aufpassen, dass man seine Commits sauber trennt damit nicht später ein Commit sowohl Dinge aus dem "normalen" Teil des Repositories als auch aus einem "fremden" Subtree enthält - sonst wird es später frickelig, die Subtree-Commits an das externe Projekt zurückzuspielen.

Wenn ich nur die Wahl zwischen subtree und subproject habe, würde ich für ein öffentliches Projekt trotzdem eher subtrees vorziehen (Beispiel findest Du in ft-robo-snap - da hab ich die nötigen externen Projekte als Subtrees eingebunden). Für ein privates "nur-Entwickler-Repository" eher subproject.

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: Community-Firmware für den TXT

Beitrag von MasterOfGizmo » 20 Feb 2016, 13:18

Ich kannte nur Subprojects. Da man aber eh ein wenig Anleitung mitliefern muss und der User diverse Schritte per Hand ausführen muss bis er eine fertige SD-Karte vor sich liegen hat wäre m.E. ein "und hier bitte noch ein git clone xyz machen" absolut vertretbar und würde die potenziellen User m.E. nicht einschränken.

Aber das Zurückspielen eigener Commits ist für uns wohl eh kaum ein Tnema. Interessanter wäre es eher, wie gut man Updates aus den Master-Repositories nachziehen kann.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

richard.kunze
Administrator
Beiträge: 583
Registriert: 26 Dez 2015, 23:49
Wohnort: Rhein-Main-Gebiet

Re: Community-Firmware für den TXT

Beitrag von richard.kunze » 20 Feb 2016, 15:16

MasterOfGizmo hat geschrieben:Da man aber eh ein wenig Anleitung mitliefern muss und der User diverse Schritte per Hand ausführen muss bis er eine fertige SD-Karte vor sich liegen hat wäre m.E. ein "und hier bitte noch ein git clone xyz machen" absolut vertretbar und würde die potenziellen User m.E. nicht einschränken.
Ich hätte es gern so simpel wie möglich. Im Idealfall einfach git clone, make, warten, fertiges Image per dd oder dem passenden Windows-Äquivalent auf die SD-Karte packen.
MasterOfGizmo hat geschrieben:Interessanter wäre es eher, wie gut man Updates aus den Master-Repositories nachziehen kann.
Aus Buildroot und ft-TXT: Einfach per git fetch / git merge. Bei ft-TXT wirds (zumindest initial) noch etwas mehr Handarbeit, um die für uns interessanten Dateien aus dem großem Gesamtcommit rauszuziehen. Kann man sich dann überlegen, auf welcher Seite (ft-TXT oder ftcommunity-TXT) man das in passende Commits aufdröselt, ist aber eigentlich egal. Ich machs wohl auf der ftcommunity-TXT-Seite, das hält dann das ft-TXT-Repository sauberer.

Für den Kernel: Eintrag im Config-File ändern, neu bauen. Schlimmstenfalls noch die eigenen Patches nachziehen - aber da hoffe ich wie gesagt, dass keine nötig sind.

Antworten