Community-Firmware für den TXT

[ski7777]

Das hatte ich wohl noch vergessen:

Code: Alles auswählen

git diff d64af4862105f1c2d20d9671221ed817f92fa17e...dae74311d5c833ff84edcfe3136a671364eaf708 -- fs/initramfs/initramfs.mk
diff --git a/fs/initramfs/initramfs.mk b/fs/initramfs/initramfs.mk
index 9d227205e0..02557fcfc3 100644
--- a/fs/initramfs/initramfs.mk
+++ b/fs/initramfs/initramfs.mk
@@ -25,10 +25,10 @@ ROOTFS_INITRAMFS_DEPENDENCIES += $(BINARIES_DIR)/initramfs.cpio
 # advertise that our dependency is on the rootfs-cpio rule, which is
 # cleaner in the dependency graph.
 
-rootfs-initramfs: linux-rebuild-with-initramfs
+rootfs-initramfs: $(ROOTFS_INITRAMFS_DEPENDENCIES) linux-rebuild-with-initramfs
 
 rootfs-initramfs-show-depends:
-       @echo rootfs-cpio
+       @echo $(ROOTFS_INITRAMFS_DEPENDENCIES)
 
 .PHONY: rootfs-initramfs rootfs-initramfs-show-depends

Es hat trotzdem leider nichts geändert.

Raphael

[ski7777]

okok, da waren doch noch ein paar Dateien, die Richard oder ich geändert haben. Ich habe eben das Python Modul semantic version aufgespürt, weil der store nicht mehr wollte. Wenn von euch noch jemand so eine Datei finden würde, wäre das super.

Raphael

[ski7777]

Ich habe da vor ein paar Tagen https://github.com/ftCommunity/ftcommunity-TXT/pull/124 aufgemacht. Hat sich noch keiner angeguckt. Geht nur darum Relikte von vor 2 Jahren zu löschen.

Gleichzeitig habe ich von buildroot-external noch buildroot-external-touchui-package abgezweigt. Da habe ich alles, was zur Touch-UI gehört, also die Touch-UI selbst und die System-Apps, aus dem rootfs-overlay entfernt und in separate Repositories verschoben: TouchUI und TouchUI-SystemApps
Mein Ziel ist es, das rootfs-overlay so leer es geht zu bekommen. Da sollen wirklich nur noch TXT-spezifische Änderungen drin sein. Selbst fischertechnik-spezifische Änderungen gehören da meiner Meinung nach nicht rein.
Ich denke hier schon an den TXTX. Mein Ziel ist es, dass wir so schnell es geht die CFW auf den TXTX portieren. Und das geht natürlich nur, wenn wir nur an Konfigurationsvariablen spielen müssen und keine größeren Mengen von Dateien in ein rootfs-overlay legen müssen.

Raphael

[ski7777]

Das hatte ich wohl noch vergessen:

Code: Alles auswählen

git diff d64af4862105f1c2d20d9671221ed817f92fa17e...dae74311d5c833ff84edcfe3136a671364eaf708 -- fs/initramfs/initramfs.mk
diff --git a/fs/initramfs/initramfs.mk b/fs/initramfs/initramfs.mk
index 9d227205e0..02557fcfc3 100644
--- a/fs/initramfs/initramfs.mk
+++ b/fs/initramfs/initramfs.mk
@@ -25,10 +25,10 @@ ROOTFS_INITRAMFS_DEPENDENCIES += $(BINARIES_DIR)/initramfs.cpio
 # advertise that our dependency is on the rootfs-cpio rule, which is
 # cleaner in the dependency graph.
 
-rootfs-initramfs: linux-rebuild-with-initramfs
+rootfs-initramfs: $(ROOTFS_INITRAMFS_DEPENDENCIES) linux-rebuild-with-initramfs
 
 rootfs-initramfs-show-depends:
-       @echo rootfs-cpio
+       @echo $(ROOTFS_INITRAMFS_DEPENDENCIES)
 
 .PHONY: rootfs-initramfs rootfs-initramfs-show-depends

Es hat trotzdem leider nichts geändert.

Raphael

Jetzt sieht es so aus:

Code: Alles auswählen

raphael@raphael-laptop:/mnt/data/home/raphael/github/buildroot$ git diff ftc/master origin/ftcommunity-TXT -- fs/initramfs/initramfs.mk
diff --git a/fs/initramfs/initramfs.mk b/fs/initramfs/initramfs.mk
index 5c6a4cb790..02557fcfc3 100644
--- a/fs/initramfs/initramfs.mk
+++ b/fs/initramfs/initramfs.mk
@@ -1,7 +1,6 @@
 ################################################################################
 #
-# Build a kernel with an integrated initial ramdisk
-# filesystem based on cpio.
+# Build a kernel with an integrated initial ramdisk filesystem based on cpio.
 #
 ################################################################################
 
@@ -12,6 +11,19 @@ endif
 ROOTFS_INITRAMFS_DEPENDENCIES += $(BINARIES_DIR)/initramfs.cpio
 
 # The generic fs infrastructure isn't very useful here.
+#
+# The initramfs image does not actually build an image; its only purpose is:
+# 1- to ensure rootfs.cpio is generated,
+# 2- to then rebuild the kernel with rootfs.cpio as initramfs
+#
+# Note: ordering of the dependencies is not guaranteed here, but in
+# linux/linux.mk, via the linux-rebuild-with-initramfs rule, which depends
+# on the rootfs-cpio filesystem rule.
+#
+# Note: the trick here is that we directly depend on rebuilding the Linux
+# kernel image (which itself depends on the rootfs-cpio rule), while we
+# advertise that our dependency is on the rootfs-cpio rule, which is
+# cleaner in the dependency graph.
 
 rootfs-initramfs: $(ROOTFS_INITRAMFS_DEPENDENCIES) linux-rebuild-with-initramfs

Heißt doch eigentlich, dass die Dateien abgesehen von den neuen Kommentaren 1:1 gleich sind, oder?
Ich verstehe das ganze nicht mehr.

Raphael

[ski7777]

So. Nach ein bisschen recherchieren kam ich dann zu dem: https://github.com/ftCommunity/ftcommun ... itramfs.mk und da tauchte dann auch https://github.com/ftCommunity/ftcommun ... 35cc35bda5 auf. Das hatte ich bisher übersehen. Nach einem großen Kampf mit git cherry-pick habe ich dann https://github.com/ski7777/buildroot/co ... 4ed938f2a4 hinbekommen. Ein erster relativ unsauberer Build ist mir dann auch geglückt und er hat gebootet.
Ich lasse jetzt Mal einen sauberen Build laufen. Der sollte in höchstens 1h fertig sein. Das lade ich dann gleich hoch.

Raphael

[ski7777]

Probierts aus: https://github.com/ski7777/ftcommunity- ... t-20180726

Raphael

[ski7777]

Also, ich gebe es zu. Ich hab bei diesem Build etwas getrickst. Nach dem eigentlichen Build ging es erst, wenn ich dann

Code: Alles auswählen

make linux-rebuild

gemacht habe und dann wieder den Build zu Ende gebracht habe. Woran das liegt weiß ich leider noch nicht. Eins ist mir aber aufgefallen: Von früher ist mir die Zeile "Rebuilding kernel with initramfs" bekannt. Diese tritt nicht mehr auf. Diese ist aktuell hier zu finden: https://github.com/ski7777/buildroot/bl ... ux.mk#L511
Ich kann wirklich nicht gut Makefiles schreiben, aber diese Zeile scheint nur ausgeführt zu werden, wenn diese spezielle Datei existiert. Leider konnte ich noch nicht herausfinden, wo diese Datei erstellt wird / erstellt werden soll und somoit leider auch nicht, warum das ganze nicht auf Anhieb läuft.
@Richard: Du hast dieses System entwickelt. Hast du da eine Idee?

Raphael

P.S. Vielleicht ist es doch nur ein Fehler, der beim cherry-picken passiert ist

[ski7777]

P.S. Vielleicht ist es doch nur ein Fehler, der beim cherry-picken passiert ist

Ok, ich werde Hellseher. Habs jetzt gefixt und jetzt läuft es rund:

https://github.com/ski7777/ftcommunity- ... t-20180727

Viel Spaß beim testen. Ich hoffe, es treten keine Probleme auf.
Wer selbst bauen will, checkt diesen Branch aus https://github.com/ski7777/ftcommunity- ... t-external und hält sich an die angepasste Doku: https://github.com/ski7777/ftcommunity- ... rom-source

Raphael

[ski7777]

Hier wäre testen auch cool: https://github.com/ski7777/ftcommunity- ... 0180727-01
Da habe ich die TouchUI aus dem rootfs-overlay ausgebaut und in ein Paket verpackt. Dann wird das overlay etwas leerer.

Raphael

[ski7777]

https://github.com/ski7777/ftcommunity- ... t-20180829
Diese Version unterstützt jetzt auch die neue Version 4.4.3. Ich konnte noch nicht alles teste, aber die Grundfunktionen funktionieren.

Raphael

[PHabermehl]

Sagt mal Bescheid, wenn der aktuelle Stand "weekly-build-tauglich" ist.
Ich habe leider momentan keine Zeit, die Entwicklung selbst zu verfolgen.

Gruß
Peter

[ski7777]

Sobald Richard das gemergt hat, ist das build tauglich.

[MasterOfGizmo]

Die 4.4.3.0 sollten wir in Zukunft als offizielle Basis nehmen. Die neue Möglichkeit, den SD-Boot einfach im Menü des TXTs zu aktivieren ist wirklich super und nimmt der CFW auch die letzte kleine Hürde aus dem Weg.

sdboot.png (4.94 KiB) 24191 mal betrachtet

Ähm, Raphael, Deinen Fix durchschaue ich auf die Schnelle nicht. Die Startskripte lagen früher im Originalrom und waren in der CFW unter /rom erreichbar und nun liegen sie auf einmal in der CFW selbst? Wie kommen die denn da hin?

Theoretisch könnte ft diese Situation sogar nutzen und den TXT bombensicher abschotten und z.B. SSH komplett deaktivieren. Wer dann doch hacken will muss halt den Umweg über die Community-Firmware nehmen. Das wäre m.E eine Win-Win-Situation. Uns würde das die fähigen Hacker in die Arme treiben und ft könnte sie im Ggeenzug komplett ignorieren und hätte nicht mehr das Risiko, dass irgendwer die Originalfirmware beschädigt und so Garantiefälle erzeugt etc,

[ski7777]

Die Startskripte liegen schon immer in der CFW, bloß bekam ich dann die Fehlermeldung, dass ich zum Beispiel auf /rom/run/txtcontrol-service nicht schreiben kann, dass es ro ist. Siehe fstab: https://github.com/ftCommunity/ftcommun ... c/fstab#L8 Diese Statusdateien machen m.E. auf dem ROM auch keinen Sinn.

Raphael

[ski7777]

In letzter Zeit passiert leider nichts rund um die CFW. Ich bin gerade dabei die CFW tauglich für Buildroot 2018.11 zu machen, was leider etwas komplizierter ist, da der Kernel 4.1 einfach sehr alt ist.
Können wir nicht Mal wieder etwas Schwung in die Bude bringen?
Vielleicht schafft es ja jemand einen aktuellen Kernel in die CFW einzubauen. Am Sicherheitssystem müssten wir auch noch etwas arbeiten und die Update-App könnte man auch einpflegen.

Gruß
Raphael

[ski7777]

Nachdem wir jetzt die CFW auf einem sehr aktuellen Stand haben, werde ich in den nächsten Tagen/Wochen die Touchscreen-Kalibrierung angehen und später auch noch die Netzwerkkonfiguration des TXT komplett neu machen. Folgende Features möchte ich umsetzen:

• Netwerk:
  • WLAN:
    • Mehrere WLAN-Netzwerke verwalten
    • versteckte SSIDs
    • 802.1X, vielleicht sogar mit Zertifikaten. Dafür brauche ich aber noch eine Testumgebung, da ich hier zu Hause nur mit 802.1X/PEAP arbeite
    • IP-Konfiguration pro Netzwerk
  • USB-Netzwerk:
    • Konfiguration der IP für eine USB-Netzwerkkarte (muss ich auch noch besorgen. Hier könnte ich vielleicht einfach die Grundumgebung bereitstellen und jemand von euch hilft mir das fertig umzusetzen.
    • Konfiguration des RNDIS. Vielleicht will man für zwei TXTs die Range ändern. Können wir vielleicht die Knobloch IDs nutzen? Das wäre für die Windows-Anwender einfacher.
      (insgesamt möchte ich hier etwa die gleichen Funktionen wie Android unterstützen)
    • Ein Daisy-Chain Mode. Hier würde ich den eingehenden und ausgehenden RNDIS einfach bridgen. Für die Adressierung lasse ich mir noch etwas einfallen. Aber das wird wohl mit einem DHCP Server und n DHCP-Clients funktionieren. Zusätzlich wird der "abgehende Ast" erst freigeschaltet, wenn man selbst eine IP hat. So hat man dann fortlaufende IPs. Das sollte gehen. @Torsten: Du hast doch so viele TXTs. Vielleicht kannst du mir dann beim Testen helfen oder falls verfügbar ca. 2 TXTs bereitstellen.
• Ein shutdown Menü. Beim Drücken des Power-Buttons für mehr als 2 Sekunden soll sich ein Popup öffnen und die App soll sich nicht schließen. Hier kann man verschiedene Funktionen abrufen:
  • Herunterfahren
  • Reboot
  • Screenshot und Protokoll der App speichern (kann man dann irgendwie laden und an den Entwickler schicken)
  • Einstellungen öffnen
  • Vielleicht etwas mit Multitasking. Vielleicht könnte man eine App in den Hintergrund verschieben und von dort aus wieder öffnen. (Ich weiß, der TXT ist lahm, aber ein Versuch wäre es wert und notfalls kann man das für die Masse auch wieder deaktivieren und erst auf den TXTX bringen)
    Aktuell kann man doch theoretisch schon mehrere Apps parallel ausführen? Die Fenster werden doch einfach nur gestapelt? Wir bräuchten einen Weg dieses Stapeln aktiv beeinflussen zu könenn.
• Allgemein bin ich mit dem aktuellen Design unzufrieden. Ein modernes Layout mit Material Design wäre schön. Zusätzlich würde ich gerne diese ganzen EInstellungsmöglichkeiten in einer App zusammenfassen.
• Eine API für Wake-On-RTC
• Eine API für den Autostart von Apps
• Plugins für alle Apps. Hier müssen wir auf Sandboxing achten. Am besten mit entsprechenden Rechten ausführen und die Daten z.B. per stdout auslesen.
• Ein funktionierendes Sicherheitssystem! Unser Schutz mit PAM ist sehr unsicher! (näheres dazu schicke ich später per Mail) Ich würde gerne die Apps sandboxen. hierfür am besten für jede App einen eigenen Nutzer und Gruppe. Wenn eine App trotzdem auf eine andere App zugreifen will, muss sie das anfragen und der Nutzer muss dem aktiv zustimmen.

Diese Liste darf gerne, eher soll, weiter ergänz werden. Vielleicht könnten wir auch eine kleine Roadmap draus machen und auf GitHub stellen. Hier würde sich das Projects Feature anbieten.
Ich weiß, das ist sehr viel. Einiges ist vielleicht auch einfach Müll, bei anderen Sachen besteht sicher noch deutlich Verbesserungspotential. Hier bin ich für objektive Kritik sehr dankbar.

Gruß
Rapahel

[richard.kunze]

Hallo Raphael,

das sind fast alles generell gute Ideen, und ich finde es sehr schön dass Du so aktiv an der CFW weitermachst.

Allerdings denke ich, wir sollten als ersten (und auch gar nicht mal so kleinen) Schritt das einzige noch offene Ticket abschließen (z.B. indem Du den PR hier auf den aktuellen Stand anpasst) und dann eine Version 1.0 herausbringen.

Vielleicht kriegen wir das ja sogar bis Weihnachten hin - das wäre denke ich ein passender Abschluss für die ersten drei Jahre CFW-Entwicklung (ja, so lange machen wir das tatsächlich schon).

Parallel dazu können wir ja anfangen, die Wunschliste für weitere Versionen aufzustellen (und ja, das mit den "Projects" von Github zu organisieren finde ich eine gute Idee).

Ich pack auch noch schon mal was drauf, wenn auch eher etwas Organisatorisches:

• Umzug nach oder mindestens Spiegelung des Projekts auf Gitlab, um nicht von einem Anbieter abhängig zu sein
• Automatisierte Erstellung von Releases. Und zwar sowohl von Snapshots (bei jeder Änderung, die durch die - ebenfalls zu automatsierenden - minimalen Tests durchkommt), als auch "echte" Releases (wenn von einem Entwickler ein neues Versionstag eingespielt wird).

[richard.kunze]

Hallo Raphael,

das sind fast alles generell gute Ideen, und ich finde es sehr schön dass Du so aktiv an der CFW weitermachst.

Allerdings denke ich, wir sollten als ersten (und auch gar nicht mal so kleinen) Schritt das einzige noch offene Ticket abschließen (z.B. indem Du den PR hier auf den aktuellen Stand anpasst) und dann eine Version 1.0 herausbringen.

Vielleicht kriegen wir das ja sogar bis Weihnachten hin - das wäre denke ich ein passender Abschluss für die ersten drei Jahre CFW-Entwicklung (ja, so lange machen wir das tatsächlich schon).

Parallel dazu können wir ja anfangen, die Wunschliste für weitere Versionen aufzustellen (und ja, das mit den "Projects" von Github zu organisieren finde ich eine gute Idee).

Ich pack auch noch schon mal was drauf, wenn auch eher etwas Organisatorisches:

• Umzug nach oder mindestens Spiegelung des Projekts auf Gitlab, um nicht von einem Anbieter abhängig zu sein
• Automatisierte Erstellung von Releases. Und zwar sowohl von Snapshots (bei jeder Änderung, die durch die - ebenfalls zu automatsierenden - minimalen Tests durchkommt), als auch "echte" Releases (wenn von einem Entwickler ein neues Versionstag eingespielt wird).

PS: Das Shutdown-Menü ist keine gute Idee. Der Mechanismus für "Langer Knopfdruck fährt den TXT sauber runter" ist ziemlich tief unten im System eingehängt, d.h. der funktioniert auch, wenn irgendeine Anwendung das Display und/oder den Touchscreen so verwurstelt, dass da gar nichts mehr tut (das wäre für das Shutdown-Menü fatal). Und zu lange Zeit lassen können wir uns auch nicht: Wenn man mit dem Finger länger als etwa 20 Sekunden auf dem Ausschaltknopf bleibt, dann dreht der kleine Steuercontroller im TXT hart den Strom ab. D.h. wir müssen bis zu dem Zeitpunkt dann alles sauber runtergefahren und selbst den Strom abgeschaltet haben, sonst riskieren wir dass durch den harten Shutdown was kaputtgeht (ist zwar nicht sehr wahrscheinlich, kann aber unter blöden Umständen - z.B. wenn ein durchdrehender Prozess gerade wie wild auf de SD-Karte schreibt - durchaus passieren).

[ski7777]

Für das Projektmanagement auf github bräuchte ich Schreibrechte. Vielleicht könne wir uns generell darauf einigen, dass Änderungen (außer an der Doku) nur über PRs und dann Zustimmung von anderen übernommen werden.

https://github.com/ftCommunity/ftcommunity-TXT/pull/138 ist soweit aktuell und kann direkt gemergt werden. Wenn du den testen willst empfehle ich dir an der Systemversion etwas rumzuspielen, da sich die App auf snapshots anders verhält https://github.com/ftCommunity/ftcommun ... te.py#L454

PS: Das Shutdown-Menü ist keine gute Idee. Der Mechanismus für "Langer Knopfdruck fährt den TXT sauber runter" ist ziemlich tief unten im System eingehängt, d.h. der funktioniert auch, wenn irgendeine Anwendung das Display und/oder den Touchscreen so verwurstelt, dass da gar nichts mehr tut (das wäre für das Shutdown-Menü fatal). Und zu lange Zeit lassen können wir uns auch nicht: Wenn man mit dem Finger länger als etwa 20 Sekunden auf dem Ausschaltknopf bleibt, dann dreht der kleine Steuercontroller im TXT hart den Strom ab. D.h. wir müssen bis zu dem Zeitpunkt dann alles sauber runtergefahren und selbst den Strom abgeschaltet haben, sonst riskieren wir dass durch den harten Shutdown was kaputtgeht (ist zwar nicht sehr wahrscheinlich, kann aber unter blöden Umständen - z.B. wenn ein durchdrehender Prozess gerade wie wild auf de SD-Karte schreibt - durchaus passieren).

Ich kenne die Integration genau. Deshalb folgender Vorschlag:

• Drücken unter 2s: App schließen oder halt anderes verhalten definiert in der App
• 2s-5s: Popup
• >5s: Holzhammer: Herunterfahren

Gruß
Rapahel

[richard.kunze]

Für das Projektmanagement auf github bräuchte ich Schreibrechte.

Hast Du jetzt (geh bitte sorgsam damit um).

Vielleicht könne wir uns generell darauf einigen, dass Änderungen (außer an der Doku) nur über PRs und dann Zustimmung von anderen übernommen werden.

Ja, das ist eine gute Idee. Sowas in der Art kann man per "protected branches" sogar erzwingen, eventuell wäre das auch keine schlechte Idee.

https://github.com/ftCommunity/ftcommunity-TXT/pull/138 ist soweit aktuell und kann direkt gemergt werden.

Technisch gesehen ja, aber als ich den vor einer Weile mal überflogen habe sind mir da noch ein paar Punkte aufgefallen die mir nicht so gut gefallen haben. Und für einen ordentlichen Code-Review besteht der PR aus zu vielen Commits, die Inhaltlich zum Teil auch etwas Kraut und Rüben sind. Vorschlag: Du machst den PR 138 zu, übernimmst die Inhalte des Branchs in einen einzelnen Commit auf Basis des aktuellen "master", und macht dafür einen neuen PR auf. OK?

PS: Das Shutdown-Menü ist keine gute Idee.
(...)

Ich kenne die Integration genau. Deshalb folgender Vorschlag:

• Drücken unter 2s: App schließen oder halt anderes verhalten definiert in der App
• 2s-5s: Popup
• >5s: Holzhammer: Herunterfahren

Ja, so könnte das funktionieren. Ist aber definitiv ein Thema für nach 1.0