Community-Firmware für den TXT

[ski7777]

Ich würde eure Fortschritte gerne "live" mitverfolgen. Also ich möchte eure aktuelle Firmware testen. Jetzt würde mich interessieren, wie ich diese kompilieren kann (Ubuntu-VM vorhanden) und dann booten kann (root-pw vom TXT vorhanden). Ich würde mich auch um ein tool zum konfiegurieren von uboot kümmern.

Raphael

[ski7777]

Zusatz:
Ich würde lieber von einem USB-Stick booten, um den Slot zu schonen.

Raphael

[bo911]

Zusatz:
Ich würde lieber von einem USB-Stick booten, um den Slot zu schonen.

Raphael

Hallo Raphael,

aktuell ist die Phase Kernel (hier 4.1.18) bauen angesagt, mit soweit ich weiss, nach wie vor buildroot Umgebung, um zu prüfen,
dass die originalen Programme (gebaut gegen eben diese buildroot - Umgebung) noch funktionieren, und z.T durch neue
z.B Konfigurations - Dialoge zur ergänzen. Danach steht wahrscheinlich der Umstieg auf debian jessie armhf an ...
Im Moment sieht der Setup so aus, das im U-Boot die Konfiguration so geändert wurde, das im Falle einer verfügbaren SD-Karte,
von der man auch einen Kernel laden kann, primär gebootet wird, sonst boot vom nand also eingebauten Flash (in der Regel das originale System)
Via Serial TTL - Konsole kann hier aber immer eingegriffen werden, so dass am SD-karten Slot eigentlich nichts gemacht werden muss...
Da der Kernel bereits Network via USB, WLAN eigentlich sehr gut und wie bekannt unterstützt, werden in der Regel die Firmware Updates
direkt via ssh / tar ohne SD-Kartenwechsel durchgeführt (z.B Nat des PC's für das USB - Netzwerk erlaubt weltweiten Zugriff auf den Kernel)
Bei mir ist die SD-Karte eigentlich immer gesteckt, und im Falle des Prüfens im originalen System wird halt mittels Serial Konsole im U-Boot
interveniert. Ich denke, es sollte ein SD-Image erstellt werden, damit erst einmal alle ohne Umstände direkt die Umgebung ausprobieren können..
Im 2-ten Schritt sind natürlich Versuche den Kernel selbst zu bauen und zu modifizieren sehr willkommen ...
Die Frage die sich mir stellt, ist die, ob wir nicht auch eine VM (KVM, VirtualBox, lxc - container ??) als build - Maschine verfügbar machen sollten,
um auch hier eine definierte, reproduzierbare Umgebung zu haben ??

[richard.kunze]

Im Ernst: WLAN ist nicht für Echtzeitanwendungen gemacht. CSMA/CA hat nunmal unverhersehbare Verzögerungen. Mein Ziel ist auch, mögoichst viel Intelligenz auf den TXT zu verschieben. Wenn man z.B. Richards SNAP auf den TXT verlegt stellt sich die Frage nach der WLAN-Latenz ja gar nicht mehr.

Jein. Im Moment laufen die Snap!-Programme noch komplett im Browser, d.h. alle TXT-Befehle laufen immer übers Netz. Grob vergleichbar mit dem Online-Mode bei RoboPro.

Was das Ganze etwas entschärft: Anders als bei der Original-Schnittstelle hab ich da keine Schleife drin, die im Idealfall präzise getaktet alle paar Millisekunden einmal Daten austauscht, sondern ein von vornherein auf Asynchronität ausgelegtes Protokoll.

Aber die Latenzen gehen davon natürlich nicht weg - ganz im Gegenteil. Ein Snap!-Befehl wird schließlich erst mal im Browser von der (in javaScript geschriebenen) Snap!-Engine interpretiert, in eine Protokoll-Nachricht verpackt (JavaScript), nach JSON serialisiert (ebenfalls JavaScript), über einen Websocket an den TXT geschickt (Netz), auf der anderen Seite wieder deserialisiert (diesmal Python), ins ROBOPro-Format umgehubert (wieder Python), an TxTControlMain verschickt (nochmal serialisieren-Netz-deserialisieren, aber immerhin diesmal lokal und wenigstens beim Deserialisieren in C/C++), von TxTControlMain (wieder C/C++) in was-auch-immer-für-ein-Format umgestrickt das die Firmware auf der I/O-Platine redet, über die serielle Schnittstelle an eben diese geschickt, und da dann nochmal deserialisiert und interpretiert (vermutlich ebenfalls C) bevor tatsächlich mal ein Ausgang geschaltet wird.

Und für die Rückmeldungen/Inputs dann das ganze andersrum.

Die Latenzen kann man mit bloßem Auge sehen. Und das Netz - auch WLAN - ist das kleinste Problem.

Erstaunlicherweise funktioniert das trotzdem schon ganz gut.

[richard.kunze]

Hallo Raphael,

Ich würde eure Fortschritte gerne "live" mitverfolgen. Also ich möchte eure aktuelle Firmware testen.
Jetzt würde mich interessieren, wie ich diese kompilieren kann (Ubuntu-VM vorhanden) und dann booten kann (root-pw vom TXT vorhanden).

Beim aktuellen Stand der Entwicklung brauchst Du als allerwichtigste Voraussetzung Zugang zur Konsole des TXT. Sprich: Einen seriell-nach-USB-Konverter, der auf der seriellen Seite mit 3.3V-Signalen umgehen kann, und ein passendes Terminal-Programm auf Deinem Rechner. Ohne hättest Du zwar eine wunderschön bootende Community-Firmware, aber Du kommst da nicht ran weil die nur auf der Konsole einen Login bietet.

Wenn Du so einen Konverter in der Bastelkiste liegen hast sag Bescheid, dann poste ich eine Anleitung wie man die Community-Firmware übersetzt und bootet. Wenn nicht, hast Du die Wahl einen passenden Konverter zu bestellen (die sind recht günstig, der den ich hier habe hat inklusive Versand knapp 4,- € gekostet) und zu warten bis der geliefert wird (kann leider dauern, die günstigen kommen normalerweise aus Übersee) oder zu warten, bis die Firmware soweit ist dass sie beim Booten automatisch über USB einen SSH-Login anbietet. Da bin ich zwar dran, aber das wird wohl auch noch ein paar Tage dauern.

Ich würde mich auch um ein tool zum konfiegurieren von uboot kümmern.

Steck da mal zum aktuellen Zeitpunkt nicht zuviel Energie rein. Für Leute, die sich auf dem TXT als Root einloggen können, haben wir schon eine passende Lösung, und für alle anderen ist die Community-Firmware ganz definitiv noch nichts.

[richard.kunze]

Wie/wo wollen wir denn zusätzliche Dateien ablegen? Also z.B. ein paar rudimentäre Webseiten für den lighttpd? Wieder wie Knobloch in einen vorgefertigten root tree und dann per post.sh rüberkopieren?

Dürfte für den Moment wohl die beste Lösung sein.

Das via Patch gegen z.B. lighttpd zu machen ist m.E: etwas Overkill und auf Dauer auch recht lästi.

Nee, wenn dann als eigenständige Pakete.

Aber das ist definitiv was für später.

Und bevor wir damit anfangen müssen wir uns auch noch mal überlegen ob wir mittel- bis langfristig bei Buildroot als (einziger?) Basis bleiben wollen oder alternativ (zusätzlich?) noch ein Userland auf Basis eines "großen" Linux (Debian? Arch? ...?) haben wollen. Und wie wir die ganze Umgebung um das Projekt so organisieren, dass möglichst viele Leute möglichst gut mitmachen können. Und und und...

Für den Moment will zumindest ich aber erstmal eine funktionierende und vorzeigbare erste Version der Community-Firmware hinbekommen, die vom Funktionsumfang der Original-Firmware entspricht (nur halt etwas besser ). Danach haben wir dann denke ich genug Erfahrungen und Ideen gesammelt um zu entscheiden wie wir mittel- und langfristig weitermachen wollen.

[MasterOfGizmo]

Ich finde buildroot prima. Da kommt ein echt schlankes und schnelles System raus.

Ich würde auch sagen, dass wir erstmal irgendwas brauchbares auf Basis von buildroot bauen. Ein erster echter Meilenstein wäre m.E::

- alles was wir bisher haben
- minimale GUI auf dem TXT um den ins Heim-WLAN zu bringen
- Snap/Sketch oder was vergleichbares via http

Damit könnte man bequem vom Handy oder Tablet aus mit dem TXT spielen. Das wäre m.E. ein echter Mehrwert.

[MasterOfGizmo]

Danach steht wahrscheinlich der Umstieg auf debian jessie armhf an ...

Siehste, da gehen die Wünsche schon auseinander. Mir reicht Buildroot

Ich würde hier gar nicht so großartig planen. Es macht doch eh jeder wozu er Lust hat und genau so soll es bei einem Spielzeug doch auch sein. Wenn einer eine Debian-Varinate baut ist das absolut cool. Aber das muss ja die Buildroot-Varinate nicht ablösen. Das entsteht halt parallel und ggf. setzt sich irgendwann eines durch und eines schläft ein. Oder so.

[MasterOfGizmo]

Bei mir reagiert der Touchscreen etwas zickig und der Mauscursor springt regelmäßig 1-2cm nach links.

Und wisst ihr was? Das habe ich in der Originalfirmware nie gemerkt, denn da sind die Buttons so breit wie der Bildschirm. Zufall?

[richard.kunze]

Siehste, da gehen die Wünsche schon auseinander. Mir reicht Buildroot

Und ich weiß noch nicht, was ich langfristig lieber hätte. Sowohl Buildroot als auch Debian haben Vor- und Nachteile...

Ich würde hier gar nicht so großartig planen. Es macht doch eh jeder wozu er Lust hat und genau so soll es bei einem Spielzeug doch auch sein. Wenn einer eine Debian-Varinate baut ist das absolut cool. Aber das muss ja die Buildroot-Varinate nicht ablösen. Das entsteht halt parallel und ggf. setzt sich irgendwann eines durch und eines schläft ein. Oder so.

Sehe ich genauso.

Aber eine Sache dürfte dafür sehr nützlich sein: Den fertig angepassten Kernel (inklusive DTS und Patches) in ein eigenes Git-Repository auszulagern. Das kann man dann sowohl für Buildroot nehmen (so wie wir es aktuell mit dem TI-Repository machen) als auch für Debian (oder was auch immer) verwenden ohne sich den ganzen Buildroot-Overhead ans Bein binden zu müssen.

Das werde ich mal angehen sobald wir einen komplett laufenden Kernel haben (momentan versuche ich Bluetooth zum Laufen zu bringen) und das Userland soweit ist dass unsere eifrigen Alphatester (hallo Raphael ) loslegen können...

[richard.kunze]

Ich finde buildroot prima. Da kommt ein echt schlankes und schnelles System raus.

Dafür muss man sich bei Debian kein eigenes Update-System inklusive Paketmanager zusammenfrickeln, und man hat tausende Helfer, die sich darum kümmern die einzelnen Pakte auf einem halbwegs aktuellen Stand zu halten.

Ich sag ja, ich bin noch unentschlossen

Ich würde auch sagen, dass wir erstmal irgendwas brauchbares auf Basis von buildroot bauen.

Fürs erste Release auf jeden Fall.

Ein erster echter Meilenstein wäre m.E::

- alles was wir bisher haben
- minimale GUI auf dem TXT um den ins Heim-WLAN zu bringen
- Snap/Sketch oder was vergleichbares via http

Ich leg noch "Kompatibilität mit RoboPro" drauf, dafür wäre ich für die Konfiguration auch mit einer Weboberfläche zufrieden. Und für diejenigen, die ihre Programme eher nicht so gerne als bunte Puzzleteile zusammenschieben vielleicht noch sowas wie iPython (http://ipython.org/) - das hatte Torsten mal erwähnt und das sieht eigentlich auch ganz nett aus (und sollte problemlos zu integrieren sein - Python brauchen wir eh schon für Snap!, und der Rest ist aus TXT-Sicht einfach nur statischer Webkrams).

Die C-Fraktion muss halt erstmal weiter Crosscompilieren, aber die sind ja eh Schmerzen gewohnt

[ski7777]

Ich habe keinen Adapter.
Kann ich den mit dem Raspberry Pi basteln?
Sollte das nicht gehen, würde ich auf SSH warten.

Raphael

P.S.: Man könnte dich einfach eine Tastatur anschließen und auf tty2 zugreifen.

[MasterOfGizmo]

Jein. Im Moment laufen die Snap!-Programme noch komplett im Browser, d.h. alle TXT-Befehle laufen immer übers Netz. Grob vergleichbar mit dem Online-Mode bei RoboPro.

Oh, ah. Stimmt, Denkfehler ...

[MasterOfGizmo]

Ich leg noch "Kompatibilität mit RoboPro" drauf

Es sieht nicht so aus, als würde FT, Knobloch oder der RoboPro-Entwickler da den nötigen Input liefern wollen. Was bedeutet, dass wir lediglich das Original-Binary verlinken können wodurch wir aber auch alle anderen Dinge wieder dabei haben (dieses ganze Root-Passwort-Gebastel, die etwas simple SDL-basierte GUI, ...).

dafür wäre ich für die Konfiguration auch mit einer Weboberfläche zufrieden

Sicher. Aber beim WLAN hast Du ein Henne-Ei-Problem, wenn Du nicht USB-Net vorher laufen hast. Wenn man wenigstens für die WLAN-Config eine GUI hat kann man auf den PC komplett verzichten.

Und für diejenigen, die ihre Programme eher nicht so gerne als bunte Puzzleteile zusammenschieben vielleicht noch sowas wie iPython (http://ipython.org/)

Mich irritieren immer Projekte etwas, die auf ihrer Einstiegsseite nicht in wenigen Worten schreiben, was sie eigentlich sind. Das ist quasi ein Python-IDE via Web-Interface, oder?
[/quote]

Die C-Fraktion muss halt erstmal weiter Crosscompilieren, aber die sind ja eh Schmerzen gewohnt

Solange die die Buildroot-Umgebung einmal durchgebaut auf der Festplatte liegen haben beschränken sich die Schmerzen aber auch auf ein paar korrekt gesetzt Makefile-Einträge.

[richard.kunze]

Ich habe keinen Adapter.
Kann ich den mit dem Raspberry Pi basteln?

Sollte eigentlich gehen - der RasPi hat ja auch einen zugänglichen seriellen Port und arbeitet ebenfalls mit 3.3V-Leveln.

Verschaltung wäre dann "über Kreuz", d.h. tx vom RasPi an rx vom TXT und umgekehrt. Und Du musst auf dem RasPI dafür sorgen, dass der keine serielle Konsole auf dem Port startet (siehe z.B. https://github.com/lurch/rpi-serial-console).

Probiers halt mal aus.

Sollte das nicht gehen, würde ich auf SSH warten.

Ich zieh das mal vor - SSH-Zugang direkt nach dem Booten hätte ich auch ganz gerne, und mehr als ein bisschen Konfig-Kram fehlt dafür auch nicht mehr.

P.S.: Man könnte dich einfach eine Tastatur anschließen und auf tty2 zugreifen.

Dafür müsste man in der Community-Firmware auch erstmal Support einbauen. Und ganz ehrlich, das Fitzel-Display auf dem TXT ist doch arg klein zum Arbeiten.

[MasterOfGizmo]

Dafür müsste man in der Community-Firmware auch erstmal Support einbauen. Und ganz ehrlich, das Fitzel-Display auf dem TXT ist doch arg klein zum Arbeiten.

Nützt dann vor allem bei Problemen nix, weil man den UBoot auf die Weise nicht ansprechen kann.

[richard.kunze]

Ich leg noch "Kompatibilität mit RoboPro" drauf

Es sieht nicht so aus, als würde FT, Knobloch oder der RoboPro-Entwickler da den nötigen Input liefern wollen.

Mal abwarten.

Was bedeutet, dass wir lediglich das Original-Binary verlinken können wodurch wir aber auch alle anderen Dinge wieder dabei haben (dieses ganze Root-Passwort-Gebastel, die etwas simple SDL-basierte GUI, ...).

Das "Root-Passwort-Gebastel" würde ich abklemmen (sprich, TxTControlMain darf in seinem Jail gerne am Root-Passwort rumfuhrwerken wie es will, dem eigentlichen System ist das dann egal), die GUI kann man wahlweise auch per SDL-Dummy-Treiber ins Nirwana schicken, und (wenn man die Original-GUI anzeigen will) die Schalter für WLAN und Bluetooth lassen sich per Script auf vernünftige Aktionen umbiegen.

Was wohl eher nicht funktionieren wird sind Updates der Original-Firmware per RoboPro - aber da kann man denke ich drauf verzichten, bzw. wenn da eins ansteht kann man auch mal die SD-Karte rausnehmen und die Original-Firmware booten.

dafür wäre ich für die Konfiguration auch mit einer Weboberfläche zufrieden

Sicher. Aber beim WLAN hast Du ein Henne-Ei-Problem, wenn Du nicht USB-Net vorher laufen hast.

USB-Net per Default bau ich grade ein. Ist so oder so ganz praktisch.

Mich irritieren immer Projekte etwas, die auf ihrer Einstiegsseite nicht in wenigen Worten schreiben, was sie eigentlich sind. Das ist quasi ein Python-IDE via Web-Interface, oder?

Webinterface ja, aber eher sowas wie ein Mathematica-Workbook für Python-Code als eine klassische IDE. Kommt wenn ich mich nicht irre auch aus der Akademiker-Ecke.

Bei http://www.nature.com/news/ipython-inte ... mo-7.21492 gibts eine Demo.

[Markus Burkhardt]

Ich leg noch "Kompatibilität mit RoboPro" drauf

Es sieht nicht so aus, als würde FT, Knobloch oder der RoboPro-Entwickler da den nötigen Input liefern wollen. Was bedeutet, dass wir lediglich das Original-Binary verlinken können wodurch wir aber auch alle anderen Dinge wieder dabei haben (dieses ganze Root-Passwort-Gebastel, die etwas simple SDL-basierte GUI, ...).

Ganz und gar nicht, es ist nur leider so, dass wir das nicht aus dem Ärmel schütteln können. Da wird aber noch was von uns kommen.

Viele Grüße
Markus

[MasterOfGizmo]

Ganz und gar nicht, es ist nur leider so, dass wir das nicht aus dem Ärmel schütteln können. Da wird aber noch was von uns kommen.

Ok falsche Formulierung: Bisher ist da nichts gekommen. Da sollten wir m.E. der Einfachheit halber zunächst davon ausgehen, dass es auch so bleibt. Falls doch was kommt werden wir es sicher einbinden. Aber damit sollten wir nicht planen. Ist nicht böse gemeint, aber bisher waren die Zusagen zum TXT halt auch nicht sehr verlässlich.

[MasterOfGizmo]

Was wohl eher nicht funktionieren wird sind Updates der Original-Firmware per RoboPro - aber da kann man denke ich drauf verzichten, bzw.

Da sollte man definitiv drauf verzichten. Wenn die Community-Firmware beim Versuch die NAND-Firmware zu aktualisieren auf die Nase fällt sind wir an gebrickten TXTs Schuld. Da wollen wir sicher nicht.