Community-Firmware für den TXT

[richard.kunze]

Naja, mit etwas tricksen geht es trotzdem. Man nehme einfach ein altes initramfs und dann bootet er auch...

Spaß beiseite. Ich habe keine Ahnung, was da schief läuft und ich habe auch keine Ahnung, wo ich gucken müsste, was da schief läuft.

Im Zweifelsfall auf der seriellen Konsole beim Booten zuschauen.

Und wenn da auch nichts Erhellendes bei rauskommt board/fischertechnik/TXT/initramfs/init mit ein paar passenden Debug-Ausgaben würzen und neu bauen (aber dafür muss dann halt auch der Custom-Initramfs-Kram funktionieren).

Ansonsten scheint alles bis auf den Ladebalken zu gehen. psplash hat da scheinbar etwas im Syntax geändert und sagt jetzt:

Code: Alles auswählen

Usage: psplash [-n|--no-console-switch][-a|--angle <0|90|180|270>][-f|--fbdev <0..9>]

<

In psplash gibts ein paar CFW-spezifische Patches, die muss man eventuell anpassen wenns davon eine neue Version gibt. Schau mal in die History, da müsstest Du die sehen.

[ski7777]

Were keine Lust auf einen ewig langen Monolog hat, springt einfach hier her: viewtopic.php?f=33&t=3429&start=820#p35546
Da gibt es die Lösung des Problems und eine zweite Testversion.

Im Zweifelsfall auf der seriellen Konsole beim Booten zuschauen.

Das mache ich ja. Und da steht dann nur Starting Kernel.

Und wenn da auch nichts Erhellendes bei rauskommt board/fischertechnik/TXT/initramfs/init mit ein paar passenden Debug-Ausgaben würzen und neu bauen (aber dafür muss dann halt auch der Custom-Initramfs-Kram funktionieren).

Super. Wenn ich soweit wäre... Der Fehler liegt halt irgendwo vorher. Und wie ich da debuggen soll, weiß ich nicht. Warscheinlich habe ich mich einfach "vercherry-picked". Vielleicht kannst du den Cherry-Pick bei dir Mal machen. Da habe ich sicher was entscheidendes übersehen.

Ansonsten scheint alles bis auf den Ladebalken zu gehen. psplash hat da scheinbar etwas im Syntax geändert und sagt jetzt:

Code: Alles auswählen

Usage: psplash [-n|--no-console-switch][-a|--angle <0|90|180|270>][-f|--fbdev <0..9>]

<

In psplash gibts ein paar CFW-spezifische Patches, die muss man eventuell anpassen wenns davon eine neue Version gibt. Schau mal in die History, da müsstest Du die sehen.

Also den Patch habe ich drin, bloß wird er wohl einfach nicht übernommen. Das sollte sich aber lösen lassen.

Raphael

[richard.kunze]

Im Zweifelsfall auf der seriellen Konsole beim Booten zuschauen.

Das mache ich ja. Und da steht dann nur Starting Kernel.

Das klingt nach einem Fehler beim Kernel-bauen.

Doofe Frage: Wie groß ist denn das uImage, das bei Dir aus dem Build kommt? Größer als 6-7MB? Falls ja: Dann hat das Custom-Initramfs-bauen nicht geklappt, und Buildroot hat das komplette Root-Filesystem als Initramfs da drangepappt. Und das bootet ziemlich sicher nicht.

[ski7777]

5,2MB. Sollte also passen

[ski7777]

Falls noch jemand eine Idee hat, kann er mir die auch gerne per IRC schicken. https://www.ftcommunity.de/ftcomm.php?file=chat

Raphael

[richard.kunze]

5,2MB. Sollte also passen

Das wiederum ist etwas zu klein - da scheint dann wohl das initramfs zu fehlen (oder es ist leer).

[ski7777]

Ansonsten scheint alles bis auf den Ladebalken zu gehen. psplash hat da scheinbar etwas im Syntax geändert und sagt jetzt:

Code: Alles auswählen

Usage: psplash [-n|--no-console-switch][-a|--angle <0|90|180|270>][-f|--fbdev <0..9>]

In psplash gibts ein paar CFW-spezifische Patches, die muss man eventuell anpassen wenns davon eine neue Version gibt. Schau mal in die History, da müsstest Du die sehen.

Also den Patch habe ich drin, bloß wird er wohl einfach nicht übernommen. Das sollte sich aber lösen lassen.

Gelöst https://github.com/ski7777/ftcommunity- ... 85b8146a7d Das war der Übeltäter.

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

[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) 11076 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,