Hallo,
mein Name ist Horst Scherer und ich bin neu hier im Forum.
Ich bin 64 Jahre alt und war die letzten 24 Jahre immer auswärts tätig. Daher hatte ich die letzten Jahre immer nur Weihnachten Zeit mich mit meinem Fischertechniker Kästen zu beschäftigen und so alle ein bis zwei Jahre gönnte ich mir einen neuen Kasten.
Aktuell bin ich arbeitslos und werde demnächst in Rente gehen. Daher habe ich mittlerweile Zeit und hatte mir zu Weihnachten den Fischertechniker Kasten "Robotic Hightech" mit dem TXT4.0 Controller gekauft.
Privat bin ich immer mit Linux unterwegs. Die anfänglichen Schwierigkeiten mit ROBOProCoding unter Linux und Verbindungsproblemen zu dem TXT4 Controller zu meinem Linux Laptop konnte ich noch recht schnell lösen. Allerdings konnte ich mich mit der graphischen Programmierung nicht anfreunden und bin dann auf Python Programmierung umgestiegen. Ich habe auf den Fischertechnik Web Seiten versucht, Information zu dem Python Interface zu bekommen. Was sehr zu meiner Verwunderung zu keinem Erfolg geführt hat. Bei meiner Suche in dem Fischertechnik Forum bin ich dann auf einen Link zu einer pdf-Datei von David Adams "fischertechnik TXT4.0 Controller" gestoßen. Nachdem ich mich damit einen Tag beschäftigt hatte, habe ich mir erst einmal das Buch gekauft. Das ist dann Anfang Januar angekommen und habe es direkt "verschlungen". Das Buch ist eine wirklich sehr gute und detaillierte Analyse des TXT4.0 Controllers (Hardware + Software).
Ich bin bestenfalls ein Programmier-Hobbyist. Während meiner Promotion habe ich in Fortran und C, später im Berufsleben nur noch Kleinigkeiten in C, sehr viel in IDL und zum Schluß nur noch in Python (auch privat) programmiert. Alle Programmiersprachen habe ich mir immer im Selbststudium beibringen müssen. Python dachte ich mittlerweile weitgehend vernünftig nutzen zu können. Aber meine eigenen Reverse Engineering Bemühungen des TXT4.0 Controller Python Codes waren doch recht kläglich. Daher war ich sehr glücklich über die Kommentare von Herrn Adams in seinem Buch, daß der Code doch "sehr zu wünschen übrig läßt". Ich hätte selbst nie solchen Code erzeugt und zweifelte an meinen Python Kenntnissen.
Aber lange Rede kurzer Sinn. Nach dem Studium von dem Buch von Herrn Adams habe ich eine Reihe von Fragen:
1. wenn man dem Link "https://git.fischertechnik-cloud.com/TXT4.0" folgt, findet man eine Reihe von Repositories mit den TXT4.0 Source Code Teilen.
Herr Adams beschreibt die unklare Situation bzgl. der OpenSource Lizenz(en) von Teilen des in den Repositories befindlichen Source Codes.
Hat hier schon jemand mit dem Service von Fischertechnik gesprochen, die Lizenz Situation eindeutig zu klären?
2. In der Analyse der TXT4.0 Software von Herrn Adams sind eine Reihe von leicht umzusetzenden Verbesserungen angesprochen (z.B.: Verbesserungen der C/C++-Header Dateien, löschen von "totem" Code im Python Interface).
Das sind alles Dinge die zwar mit Sorgfalt gemacht werden müssen, aber letztendlich "nur" Schreibarbeit sind.
Ist da schon jemand an den Fischertechnik Service herangetreten, doch zumindest diese "einfachen" Verbesserungen umzusetzen?
Wenn man dies selber macht, ist beim nächsten System update alles wieder verloren und man fängt von vorne an.
3. hat jemand schon einmal versucht mit den unter dem Link "https://git.fischertechnik-cloud.com/TXT4.0" befindlichen Repositories den TXT4.0 Kernel neu zu compilieren (erster Schritt nur den verwendeten 4er Kernel neu zu erstellen)?
Wenn ich die Repositories richtig verstehe wurde der Kernel mit Hilfe des Yocto Systems erstellt. Ich habe noch nie mit Yocto gearbeitet. Vor drei Tagen habe damit angefangen und kann mittlerweile einen Standard "x86 Kernel" damit erstellen (ist relativ simpel, da es das Default Beispiel ist).
Aber die Daten im Fischertechnik Repository "meta-ktn-stm32mp" sind etwas widersprüchlich. Wenn man das Repository entpackt und "yocto-check-layer" drüber laufen läßt, kommt es zu Fehlermeldungen:
INFO: Detected layers:
ERROR: meta-ktn-stm32mp-master: Can't be DISTRO and BSP type at the same time. Both conf/distro and conf/machine folders were found.
Ich interpretiere dies so, daß die Daten im Verzeichnis "distro" und "machine" nicht gleichzeitig erscheinen dürfen. Löscht man eines der beiden Verzeichnisse kommt es zur Fehlermeldungen
ERROR: Layer meta-ktn-stm32mp-master depends on stm-st-stm32mp and isn't found.
Was fehlt hier? Ich habe bei Kontron Electronics zwar auch meta Daten gefunden, die lösen aber das Problem nicht.
4. Hat schon jemand erfolgreich versucht eine Python Version (V3.11 oder V3.13) auf dem TXT4.0 zu compilieren?
Zu meiner Verwunderung ist der gcc/g++ und Entwicklungs-Tools auf dem TXT4.0 installiert. Ich habe daher einfach mal den Source Code von Python313 auf den TXT4.0 überspielt und dort entpackt. "configure" läuft einwandfrei durch und erste Teile des Sourcecodes werden nach dem Aufruf von "make" auch compiliert.
Dann steigt das System allerdings immer beim compilieren einer bestimmten Datei ohne Fehlermeldung aus. Ich habe parallel mit einer zweiten Konsole versucht zu klären, was beim compilieren passiert. Wenn ich Alles richtig verstehe, ist der Speicher des Systems zu klein, weshalb sich das System sang und klanglos beim Compilier-Versuch verabschiedet.
Da der eMMC Speicher knapp ist, ist der TXT4.0 Kernel ohne Swap Partition und auch ohne lokale Swap Datei aufgesetzt. Ich habe leider aktuell keine SD Karte (ist bestellt) zur Verfügung. Sobald ich die SD Karte habe, stecke ich diese in den TXT4.0, erstelle eine Swap Parttion oder eine lokale Swap Datei auf der Karte und versuche es nochmal. Dann wird alles zwar noch langsamer aber vielleicht läuft der Compiler durch.
Python 313 (oder V3.11/V3.12) bietet die Möglichkeit von Type Kontrolle, was ich mittlerweile sehr zu schätzen weiß.
Alles in Allem würde ich bevorzugen den Punkt 3 gelöst zu bekommen. Dann könnte ich mit einem update des Basis Systems anfangen, was sich hoffentlich als virtuelles System auf dem Laptop nutzen läßt. Das würde das compilieren deutlich einfacher machen und sicherlich beschleunigen. Aus Platzgründen wird das System dann allerdings wahrscheinlich auf der SD Karte installiert werden müssen zumindest, da das Image wahrscheinlich größer als 1,6 GB wird.
Vielen Dank und fröhliches coden auf dem TXT4.0
Horst
TXT4.0 Linux Kernel neu compilieren
Forumsregeln
Bitte beachte die Forumsregeln!
Bitte beachte die Forumsregeln!
Re: TXT4.0 Linux Kernel neu compilieren
Hallo alle zusammen,
da ich hier bisher keine Antwort erhalten habe, habe ich versucht den Fischertechnik Service zu kontaktieren. Leider ohne Erfolg.
Man kann auf der Kontakt Seite von Fischertechnik zwar eine Anfrage stellen, aber nicht abschicken. Ich vermute, daß dies an der fehlenden Möglichkeit liegt, die Datenschutzbestimmungen anzunehmen. Aber der entsprechende Link zu den Datenschutzbestimmungen läuft ins leere.
Wie kann man einen Kontakt zum Fischertechnik Service herstellen?
Frohes Schaffen
Horst
da ich hier bisher keine Antwort erhalten habe, habe ich versucht den Fischertechnik Service zu kontaktieren. Leider ohne Erfolg.
Man kann auf der Kontakt Seite von Fischertechnik zwar eine Anfrage stellen, aber nicht abschicken. Ich vermute, daß dies an der fehlenden Möglichkeit liegt, die Datenschutzbestimmungen anzunehmen. Aber der entsprechende Link zu den Datenschutzbestimmungen läuft ins leere.
Wie kann man einen Kontakt zum Fischertechnik Service herstellen?
Frohes Schaffen
Horst
-
PHabermehl
- Beiträge: 2525
- Registriert: 20 Dez 2014, 22:59
- Wohnort: Bad Hersfeld
Re: TXT4.0 Linux Kernel neu compilieren
Im Impressum der Homepage ist info@fischertechnik.de als Kontaktadresse angegeben, außerdem gibt's da eine Telefonnummer...hscherer hat geschrieben: ↑19 Jan 2025, 12:40Hallo alle zusammen,
da ich hier bisher keine Antwort erhalten habe, habe ich versucht den Fischertechnik Service zu kontaktieren. Leider ohne Erfolg.
Man kann auf der Kontakt Seite von Fischertechnik zwar eine Anfrage stellen, aber nicht abschicken. Ich vermute, daß dies an der fehlenden Möglichkeit liegt, die Datenschutzbestimmungen anzunehmen. Aber der entsprechende Link zu den Datenschutzbestimmungen läuft ins leere.
Wie kann man einen Kontakt zum Fischertechnik Service herstellen?
Frohes Schaffen
Horst
https://www.fischertechnik.de/de-de/rec ... /impressum
Da würde ICH es mal probieren.
VG
Peter
Re: TXT4.0 Linux Kernel neu compilieren
Hallo Horst,
ich gehe davon aus, dass hier noch niemand versucht hat, das Betriebssystem neu zu kompilieren. Als ich das letzte mal in GitLab geschaut habe (ist schon eine Weile her), gab es noch nicht alle Dateien, um das Betriebssystem komplett zu kompilieren.
Aber selbst wenn du das selbst kompilieren könntest, würde es dir vermutlich nicht viel bringen, weil, wie du schon gesagt hast, die Qualität nicht sonderlich überragend ist. Und das ändert sich nicht durch Neukompilation. Da wäre es vermutlich einfacher, über Yocto ein neues Betriebssystem zu bauen, und das zu kompilieren. Viele Komponenten, die für den Controller relevant sind, sind auf GitLab zu finden und könnten in das Yocto Projekt inkludiert werden.
Allerdings kannst du, mit dem nötigen Wissen, durchaus all diese Bereiche verbessern, und zwar ohne das Betriebssystem neu zu bauen.
Zum Beispiel das Python Interface. Der Grund, warum das Interface auf dem TXT 4.0 so „schlecht“ ist, liegt daran, dass es nicht von Hand geschrieben wurde, sondern mit SWIG automatisch generiert wurde. Und diese SWIG Interfaces sind in der Regel deutlich schlechter (und auch langsamer) als wenn man es von Hand programmiert, so wie es beispielsweise bei ftrobopy der Fall ist.
Dafür muss man natürlich Kenntnis der Python-C-Schnittstelle haben, aber dann kann man eine eigene Python Schnittstelle schreiben, die direkt auf das C/C++ Interface des TXTs zugreift.
Da wären wir beim nächsten Punkt. Auch die C/C++ Schnittstelle ist nicht optimal, um es mal vorsichtig auszudrücken. Sowohl wenn es um Geschwindigkeit, Latenz oder Sicherheit geht. Aber ganz ehrlich, selbst wenn du ein neues C/C++ Interface schreibst, dann bringt es dir nicht viel, wenn du von Python aus darauf zugreifst, weil Python einfach langsam ist.
Es ist allerdings möglich, ich habe beispielsweise mein eigenes C++ Interface geschrieben, das bedeutend schneller ist und vor allem eine deutlich geringere Latenz hat (werde ich auch im Laufe des Jahres veröffentlichen). Die maximale Performance des C++ Interfaces hängt natürlich von der Firmware auf dem M4 Prozessor ab. Und auch diese hat, wie in dem Buch beschrieben, auch noch einiges an Luft nach oben.
Allerdings ist das nicht das eigentliche Problem, sondern dass der Code unter Linux läuft, einem nicht-Echtzeit-Betriebssystem. Das bedeutet, selbst wenn die Firmware auf dem M4 zeitliche Auflösungen im Mikrosekundenbereich oder darunter bieten würde, dann würde dir das nichts bringen, weil einfach der Linux-Kernel es unmöglich macht, deutlich geringere Latenzen zu erreichen.
Aber selbst die M4 Firmware kannst du selbst entwickeln und auf dem TXT laufen lassen, ohne das gesamte Betriebssystem neu zu bauen. Einfach kompilieren und die elf-Datei auf den TXT kopieren und mit den richtigen Kommandos ausführen. Das ist natürlich eine andere Hausnummer als ein C/C++ oder Python Interface zu schreiben, aber wenn man das nötige Wissen hat, ist das kein Problem.
Und es gibt natürlich noch viele andere Verbesserungsmöglichkeiten. Beispielsweise kann man den REST API Server in C++ oder einer anderen Systemsprache anstatt in Python schreiben, was die CPU Auslastung reduzieren würde. Aber ich denke (müsste man mal messen), dass NodeRed einiges mehr an CPU Zeit beansprucht.
Zu deiner Frage mit dem Kompilieren einer neuen Python Version. Ich habe noch nicht versucht, Python auf dem TXT zu kompilieren, aber ich hatte es mal mit CMake versucht. Ich habe zwar keinen Error erhalten, aber der TXT ist wohl hängen geblieben. Selbst nach 6 Stunden war er nicht fertig. Und wenn ich mich recht entsinne ist Python 3 deutlich größer als CMake.
Daher würde ich empfehlen, das Ganze mit einem Crosscompiler auf deinem PC zu kompilieren. Da musst du gucken, welche Anforderungen Python an den Compiler hat. Da musst du dir gegebenenfalls einen Crosscompiler selbst bauen. Ich hatte mal eine Toolchain für Mac kompiliert, kann sogar sein, dass ich noch eine für Windows gemacht habe. Die war allerdings damals auf den TXT 4.0 zugeschnitten, wenn es um die gcc Version (8.3.0), die Linux Kernel Version (glaube 4.19) und glibc Version (müsste ich nachgucken) geht.
Falls das nicht für das moderne Python ausreicht, müsste man eine neue Toolchain bauen, und gegebenenfalls ein paar Bibliotheken, die nicht auf dem TXT vorhanden sind, statisch linken. Kann natürlich sein, dass das nicht geht, hängt davon ab, was genau auf dem TXT fehlt.
Fazit:
Wenn du Verbesserungen auf dem TXT 4.0 im Bereich Schnittstellen (Python, C/C++, etc) oder der M4 Firmware erreichen möchtest, brauchst du das Betriebssystem nicht neu zu kompilieren. Und selbst wenn du ein neues Betriebssystem baust, müsstest du trotzdem eigene Schnittstellen und eine M4 Firmware schreiben, wenn du eine Verbesserung haben möchtest.
Und wenn du eine neue Python Version haben möchtest, empfehle ich, Python mit einem Crosscompiler zu kompilieren und dann auf den TXT zu kopieren.
Ich hoffe, meine Einschätzung hilft dir weiter.
Gruß,
Cody
ich gehe davon aus, dass hier noch niemand versucht hat, das Betriebssystem neu zu kompilieren. Als ich das letzte mal in GitLab geschaut habe (ist schon eine Weile her), gab es noch nicht alle Dateien, um das Betriebssystem komplett zu kompilieren.
Aber selbst wenn du das selbst kompilieren könntest, würde es dir vermutlich nicht viel bringen, weil, wie du schon gesagt hast, die Qualität nicht sonderlich überragend ist. Und das ändert sich nicht durch Neukompilation. Da wäre es vermutlich einfacher, über Yocto ein neues Betriebssystem zu bauen, und das zu kompilieren. Viele Komponenten, die für den Controller relevant sind, sind auf GitLab zu finden und könnten in das Yocto Projekt inkludiert werden.
Allerdings kannst du, mit dem nötigen Wissen, durchaus all diese Bereiche verbessern, und zwar ohne das Betriebssystem neu zu bauen.
Zum Beispiel das Python Interface. Der Grund, warum das Interface auf dem TXT 4.0 so „schlecht“ ist, liegt daran, dass es nicht von Hand geschrieben wurde, sondern mit SWIG automatisch generiert wurde. Und diese SWIG Interfaces sind in der Regel deutlich schlechter (und auch langsamer) als wenn man es von Hand programmiert, so wie es beispielsweise bei ftrobopy der Fall ist.
Dafür muss man natürlich Kenntnis der Python-C-Schnittstelle haben, aber dann kann man eine eigene Python Schnittstelle schreiben, die direkt auf das C/C++ Interface des TXTs zugreift.
Da wären wir beim nächsten Punkt. Auch die C/C++ Schnittstelle ist nicht optimal, um es mal vorsichtig auszudrücken. Sowohl wenn es um Geschwindigkeit, Latenz oder Sicherheit geht. Aber ganz ehrlich, selbst wenn du ein neues C/C++ Interface schreibst, dann bringt es dir nicht viel, wenn du von Python aus darauf zugreifst, weil Python einfach langsam ist.
Es ist allerdings möglich, ich habe beispielsweise mein eigenes C++ Interface geschrieben, das bedeutend schneller ist und vor allem eine deutlich geringere Latenz hat (werde ich auch im Laufe des Jahres veröffentlichen). Die maximale Performance des C++ Interfaces hängt natürlich von der Firmware auf dem M4 Prozessor ab. Und auch diese hat, wie in dem Buch beschrieben, auch noch einiges an Luft nach oben.
Allerdings ist das nicht das eigentliche Problem, sondern dass der Code unter Linux läuft, einem nicht-Echtzeit-Betriebssystem. Das bedeutet, selbst wenn die Firmware auf dem M4 zeitliche Auflösungen im Mikrosekundenbereich oder darunter bieten würde, dann würde dir das nichts bringen, weil einfach der Linux-Kernel es unmöglich macht, deutlich geringere Latenzen zu erreichen.
Aber selbst die M4 Firmware kannst du selbst entwickeln und auf dem TXT laufen lassen, ohne das gesamte Betriebssystem neu zu bauen. Einfach kompilieren und die elf-Datei auf den TXT kopieren und mit den richtigen Kommandos ausführen. Das ist natürlich eine andere Hausnummer als ein C/C++ oder Python Interface zu schreiben, aber wenn man das nötige Wissen hat, ist das kein Problem.
Und es gibt natürlich noch viele andere Verbesserungsmöglichkeiten. Beispielsweise kann man den REST API Server in C++ oder einer anderen Systemsprache anstatt in Python schreiben, was die CPU Auslastung reduzieren würde. Aber ich denke (müsste man mal messen), dass NodeRed einiges mehr an CPU Zeit beansprucht.
Zu deiner Frage mit dem Kompilieren einer neuen Python Version. Ich habe noch nicht versucht, Python auf dem TXT zu kompilieren, aber ich hatte es mal mit CMake versucht. Ich habe zwar keinen Error erhalten, aber der TXT ist wohl hängen geblieben. Selbst nach 6 Stunden war er nicht fertig. Und wenn ich mich recht entsinne ist Python 3 deutlich größer als CMake.
Daher würde ich empfehlen, das Ganze mit einem Crosscompiler auf deinem PC zu kompilieren. Da musst du gucken, welche Anforderungen Python an den Compiler hat. Da musst du dir gegebenenfalls einen Crosscompiler selbst bauen. Ich hatte mal eine Toolchain für Mac kompiliert, kann sogar sein, dass ich noch eine für Windows gemacht habe. Die war allerdings damals auf den TXT 4.0 zugeschnitten, wenn es um die gcc Version (8.3.0), die Linux Kernel Version (glaube 4.19) und glibc Version (müsste ich nachgucken) geht.
Falls das nicht für das moderne Python ausreicht, müsste man eine neue Toolchain bauen, und gegebenenfalls ein paar Bibliotheken, die nicht auf dem TXT vorhanden sind, statisch linken. Kann natürlich sein, dass das nicht geht, hängt davon ab, was genau auf dem TXT fehlt.
Fazit:
Wenn du Verbesserungen auf dem TXT 4.0 im Bereich Schnittstellen (Python, C/C++, etc) oder der M4 Firmware erreichen möchtest, brauchst du das Betriebssystem nicht neu zu kompilieren. Und selbst wenn du ein neues Betriebssystem baust, müsstest du trotzdem eigene Schnittstellen und eine M4 Firmware schreiben, wenn du eine Verbesserung haben möchtest.
Und wenn du eine neue Python Version haben möchtest, empfehle ich, Python mit einem Crosscompiler zu kompilieren und dann auf den TXT zu kopieren.
Ich hoffe, meine Einschätzung hilft dir weiter.
Gruß,
Cody
Re: TXT4.0 Linux Kernel neu compilieren
Hallo Cody,
im Prinzip ist die gesamte Software auf dem TXT4.0 Controller veraltet. Aber nur einen update von dem ein oder anderen Paket zu machen, scheitert an Abhängigkeiten von anderen Paketen, die dann auch in der Version hochgezogen werden müssen. Aktuell bin ich dabei mit Yocto (Version "styhead") einen neuen Kernel zu bauen. Zum einen macht es mir Spaß mich in etwas für mich völlig neues einzuarbeiten (Yocto kannte ich bisher nur dem Namen nach) und ich habe Zeit.
Ich stimme dir zu, daß Python313 auf dem TCT4.0 Controller zu compilieren, keine so tolle Idee ist. Fischertechnik hat den Yocto Teil veröffentlicht, aber der basiert auf der Yocto Version "thun". Diese Version von Yocto kann ich nicht mehr verwenden, da diese zwingend Python2.7 fordert, was ich nicht mehr installiert habe. Aber nur mit einem virtuellen System mit Linux Kernversion 4.19, wie es auf dem TXT4.0 Controller installiert ist, wäre das Compilieren auf dem Laptop in einer virtuellen Maschine sinnvoll. Das könnte ich mit einem Docker System mit Ubuntu 16.04 lösen. Das wäre möglich, ist für mich aber nur die absolute Notlösung, wenn ich es überhaupt nicht schaffe einen neueren Linux Kernel für den TXT4.0 Controller zu erstellen.
Die restliche Software ist dann erst der Schritt drei(!). Schritt zwei ist der update des RTOS Kernel vom M4 Prozessor.
Aktueller Stand von meiner Seite:
Trotzdem werde ich mal den Fischertechnik Service anschreiben, ob es nicht doch einen update gibt, der zumindest die vielen "Kleinigkeiten" (e.g. C/C++ Header) verbessert (vielen Dank Peter für den Hinweis. Den Link zu info@fischertechnik.de hatte ich nicht gesehen).
Ich habe früher viel in C programmiert und die Konstruktion "void *" ist des Teufels. Der Code compiliert und führt zu extrem schwer zu findenden Fehler, bei fehlerhafter Verwendung des "void" Zeigers. Wenn jemand mit den TXT4.0 Controller versucht C zu lernen, wird er schneller frustriert als dies nötig ist. Der Compiler schreit bei korrekter Deklaration und falscher Verwendung von Zeigern laut auf und zwingt zur Korrektur bevor der Code überhaupt läuft.
Frohes coden
Horst
im Prinzip ist die gesamte Software auf dem TXT4.0 Controller veraltet. Aber nur einen update von dem ein oder anderen Paket zu machen, scheitert an Abhängigkeiten von anderen Paketen, die dann auch in der Version hochgezogen werden müssen. Aktuell bin ich dabei mit Yocto (Version "styhead") einen neuen Kernel zu bauen. Zum einen macht es mir Spaß mich in etwas für mich völlig neues einzuarbeiten (Yocto kannte ich bisher nur dem Namen nach) und ich habe Zeit.
Ich stimme dir zu, daß Python313 auf dem TCT4.0 Controller zu compilieren, keine so tolle Idee ist. Fischertechnik hat den Yocto Teil veröffentlicht, aber der basiert auf der Yocto Version "thun". Diese Version von Yocto kann ich nicht mehr verwenden, da diese zwingend Python2.7 fordert, was ich nicht mehr installiert habe. Aber nur mit einem virtuellen System mit Linux Kernversion 4.19, wie es auf dem TXT4.0 Controller installiert ist, wäre das Compilieren auf dem Laptop in einer virtuellen Maschine sinnvoll. Das könnte ich mit einem Docker System mit Ubuntu 16.04 lösen. Das wäre möglich, ist für mich aber nur die absolute Notlösung, wenn ich es überhaupt nicht schaffe einen neueren Linux Kernel für den TXT4.0 Controller zu erstellen.
Die restliche Software ist dann erst der Schritt drei(!). Schritt zwei ist der update des RTOS Kernel vom M4 Prozessor.
Aktueller Stand von meiner Seite:
- Compilieren Yocto Version "styhead" für STM32MP157A funktioniert (Linux Kernel V6.x, Pxthon3.13, gcc14.2, qt6.8) für den ARM Cortex 7 Teil ist gelungen
- offen: Start dieser Version als virtuelles System auf dem Laptop --> da bin ich gerade dabei
- offen: Versuche diese Kernel Version auf einer Flash Karte zu installieren und mit dem TXT4.0 zu starten.
Aktuell habe ich noch nicht alle Einstellungen des TXT4.0 Controller verstanden. Steht daher etwas hinten an, da dies einfacher ist, wenn das System parallel in der virtuellen Maschine läuft. - parallel versuche ich den Python Code für mich zu verbessern (und das ein oder andere Modell ans Laufen zu bringen --> etwas "handfestere" Spielerei muß auch sein). Aber ich habe hier ein um das andere mal Probleme, da ich auf meinem Laptop Python3.13 installiert habe. Trotz Hinweisen im Netz ist es mir noch nicht gelungen die PyCharm IDE zu überreden die Python Version auf dem TXT4.0 Controller als Basis zu verwenden, der über ssh eingebunden ist --> arbeite ich aktuell auch noch dran.
Trotzdem werde ich mal den Fischertechnik Service anschreiben, ob es nicht doch einen update gibt, der zumindest die vielen "Kleinigkeiten" (e.g. C/C++ Header) verbessert (vielen Dank Peter für den Hinweis. Den Link zu info@fischertechnik.de hatte ich nicht gesehen).
Ich habe früher viel in C programmiert und die Konstruktion "void *" ist des Teufels. Der Code compiliert und führt zu extrem schwer zu findenden Fehler, bei fehlerhafter Verwendung des "void" Zeigers. Wenn jemand mit den TXT4.0 Controller versucht C zu lernen, wird er schneller frustriert als dies nötig ist. Der Compiler schreit bei korrekter Deklaration und falscher Verwendung von Zeigern laut auf und zwingt zur Korrektur bevor der Code überhaupt läuft.
Frohes coden
Horst
-
PHabermehl
- Beiträge: 2525
- Registriert: 20 Dez 2014, 22:59
- Wohnort: Bad Hersfeld
Re: TXT4.0 Linux Kernel neu compilieren
Hallo Horst,
großen Respekt, das hört sich gut an. Aus den Zeiten der TXT Community Firmware weiß ich, dass es einigen Nachdrucks bedurft hat, bis ft den Quellcode offengelegt hat, obwohl sie von Anfang an aus lizenzrechtlichen Gründen dazu verpflichtet waren. Das ist jetzt sicher nicht anders.
Ich freue mich auf Fortschrittsberichte. Da ich selbst eigentlich immer außerhalb der ft-IDE programmiere, wird auch der TXT4 erst interessant, wenn es problemlos ohne Robo Pro Coding geht...
VG Peter
großen Respekt, das hört sich gut an. Aus den Zeiten der TXT Community Firmware weiß ich, dass es einigen Nachdrucks bedurft hat, bis ft den Quellcode offengelegt hat, obwohl sie von Anfang an aus lizenzrechtlichen Gründen dazu verpflichtet waren. Das ist jetzt sicher nicht anders.
Ich freue mich auf Fortschrittsberichte. Da ich selbst eigentlich immer außerhalb der ft-IDE programmiere, wird auch der TXT4 erst interessant, wenn es problemlos ohne Robo Pro Coding geht...
VG Peter
Re: TXT4.0 Linux Kernel neu compilieren
Hallo Horst,
ich habe vor circa 2 Jahren Python 3.11 erfolgreich auf einem TXT4.0 kompilieren können. Anstelle einer Swap Partition anzulegen, habe ich nur den Source Code auf die SD-Karte kopiert und alles so konfiguriert, dass die gebauten Artefakte dort abgelegt werden. An die Details kann ich mich leider nicht mehr erinnern. Das Kompilieren ist zwar im ersten Durchlauf abgestürzt, in einem zweiten (identischen) Versuch aber überraschend nach circa 1-2 Stunden doch geglückt. Seither habe ich keine Probleme mit Python 3.11.
Dein Projekt klingt sehr spannend und ambitioniert. Ich wünsche dir viel Erfolg und bin wie Peter auf weitere Erfahrungsberichte gespannt.
Beste Grüße
David
ich habe vor circa 2 Jahren Python 3.11 erfolgreich auf einem TXT4.0 kompilieren können. Anstelle einer Swap Partition anzulegen, habe ich nur den Source Code auf die SD-Karte kopiert und alles so konfiguriert, dass die gebauten Artefakte dort abgelegt werden. An die Details kann ich mich leider nicht mehr erinnern. Das Kompilieren ist zwar im ersten Durchlauf abgestürzt, in einem zweiten (identischen) Versuch aber überraschend nach circa 1-2 Stunden doch geglückt. Seither habe ich keine Probleme mit Python 3.11.
Dein Projekt klingt sehr spannend und ambitioniert. Ich wünsche dir viel Erfolg und bin wie Peter auf weitere Erfahrungsberichte gespannt.
Beste Grüße
David
Re: TXT4.0 Linux Kernel neu compilieren
Hallo alle zusammen,
kurzer Überblick über meinen aktuellen Stand:
Aufgrund von Problemen mußte ich einen Schritt zurückgehen. Aktuell erzeugtes Image für den ARM Cortex A7 Prozessor:
Ich habe auch Fischertechnik angeschrieben, ob von Ihrer Seite ein Software update geplant ist. Wie erwartet, bisher ohne
Antwort. Allerdings hat Fischertechnik ein Problem. Der im TXT4.0 verwendete Linux Kernel 4.19 incl. aller installierten
Software Teilen und der qt5.15 läuft aus der Pflege heraus (als letztes die qt5.15 für Embedded System Ende März diesen Jahres).
Heißt ab April verkauft Fischertechnik ein System mit nicht mehr gewarteter Software. Veraltet war die Software schon
vorher, da keine Patches zur Verfügung gestellt wurden. Auch wenn es "nur" ein Spielzeug ist, das ist rechtlich zumindest grenzwertig.
----------------------------------------------------------------------------------------------------------
Hier folgt jetzt ein kleiner Erfahrungsbericht (falls jemand auch versucht einen neuen Kernel für den TXT4.0 Controller zu bauen):
(falls ich damit nerve, bitte kurze Info geben. Dann melde ich mich erst wieder wenn ich es geschafft oder frustriert aufgegeben habe.)
Zum Bilden des Linux Kernels verwende ich, wie Fischertechnik, das Yocto System.
Meine Versuche basieren alle auf Yocto Branch "styhead" (Fischertechnik hat den Branch "thun" verwendet) und der sehr guten Beschreibung von dem Repository https://github.com/jumpnow/meta-stm32mp1.
Der erste Versuch mit "bitbake" (Yocto Programm zum erstellen des Kernel) war zwar erfolgreich, aber es kam unter OpenSuSE Tumbleweed (meine normalerweise verwendete Linux Distribution) zu gelegentlichen Abstürzen, die aber nach erneutem Aufruf von "bitbake" verschwunden waren (Speicher Problem siehe unten). Mit dem Compiler gcc14 kam es zu Problemen, wenn dieser für das Image verwendet werden sollte (Problem ist gelöst siehe unten). In einem ersten Schritt habe ich daher auf den gcc13 für das Image umgestellt (ggc14 hat zwei geänderte Parameter beim Aufruf z.B. "-V" wurde durch "-v" ("v" klein geschrieben) ersetzt. SWIG3.4 hatte ich durch SWIG3.2 ersetzt. SWIG3.4 hat in einem der verwendeten Marcos einen neuen Parameter eingeführt, der zu Problemen führt (Problem ist aber auch gelöst siehe unten).
Beim Ergänzen von zusätzliche Python Paketen, kam es bei diesem Versuch immer wieder zu Fehlermeldungen mit Python3.13.
Testweise habe ich dann alles in meine Ubuntu Installation transferiert (Ubuntu wird als Standard System für Yocto empfohlen). Unter Ubuntu 24.10 stürzte der "bitbake" Prozess reproduzierbar ab und riß das Terminal mit in den Abgrund. Mit einem zweiten geöffneten Terminal konnte ich als Fehler Speicherplatz Probleme identifizieren. Auch Starten von "bitbake" als root mit vergrößertem SWAP Bereich brachte keine Lösung.
Daher habe ich mir neuen Speicher für meinen Laptop besorgt (2x 8GB durch 2x 32 GB ersetzt). Damit lief "bitbake" unter Ubuntu fehlerfrei durch. Parallel wieder mit zweitem Terminal den Speicherbedarf kontrolliert. In der Spitze ca. 13 GB. Das hätte eigentlich auch vorher mit dem 16 GB Speicher funktionieren sollen. Ich vermute, daß es hier zu Problemen kommt, wenn der Speicher auf zwei verschiedene Bänke aufgeteilt wird (sollte eigentlich kein Problem sein) --> nicht weiter untersucht.
Daher wieder zurück auf mein OpenSuSE Tumbleweed Installation. Dort alles gelöscht (60 GB!!) und alles neu aus dem Netz gezogen (Yocto mit Metadaten sind "nur" ~ 700 MB groß) den Rest zieht der "bitbake" Prozeß aus dem Netz (alle benötigten Source Code Teile, um den Kernel und die anderen Pakete zu erstellen). Dann den "bitbake" Prozeß neu gestartet. Keine Abstürze mehr (das dürfte das Speicherplatz Problem gewesen sein) und -- da ich vergessen hatte die gcc und SWIG Version zu ändern -- auch gcc14.2 und SWIG3.4 (allerdings mit Python3.12.8). Um zu verstehen, wieso dies jetzt funktioniert, einen "diff" auf die unter Ubuntu liegenden Metadaten und die neu gezogen Metadaten gemacht. Ein Blick in das neu gezogene "Changelog" war aber hinreichend. In der Woche zwischen dem ersten Klonen des Git Repository und dem neuen herunterladen hatte der Maintainer einen update gemacht, der die Probleme mit gcc14.2 und SWIG3.4 löst. Im Falle von Problemen lohnt es sich daher immer mal wieder in das Repository rein zuschauen, da dort aktuell dran gearbeitet wird.
Ein sporadisch auftauchendes Problem ist ein "md5sum" Fehler nach dem herunterladen der benötigten Software von dem "bitbake" Prozeß. In diesem Fall muß man die "bblayer.conf" Datei öffnen, die den Fehler erzeugt (ist in der Fehlermeldung angegeben) und in dem Aufruf "git clone git://repository.what.ever";protocol=http;branch=master" den Teil "protocol=https;" löschen. Dies führt zwar zu einem Warnhinweis, daß man doch das http Protokoll verwenden soll, lädt aber alles herunter und das "md5sum" Problem verschwindet. Hierzu hatte ich einen Kontakt zu einem der Maintainer des Git Repository. Das war zwar der falsche Ansprechpartner, aber er war so freundlich trotzdem zu Antworten. Daß das "md5sum" Problem sporadisch auftritt, ist bekannt. Die Ursache ist wahrscheinlich ein Problem mit einem zwischengeschalteten "proxy". Mein gefundene Lösung das https Protokoll abzuschalten ist die aktuell gängige Lösung.
Nach all den Irrungen und Wirrungen läuft jetzt alles durch. Der "bitbake" Prozeß, wie in dem oben erwähnten Git Repository beschrieben, ist viergeteilt. Man startet mit einem Basis Image und geht dann immer ein Image weiter bis zum Schluß das Image mit der qt6 Bibliothek dran ist. Man kann das Bilden des qt6 Image auch direkt starten, dann werden aber trotzdem zuerst die anderen drei Images gebildet. Zur Fehlerkontrolle ist es wirklich einfacher mit den "bitbake" Befahl Image für Image vorzugehen.
Problem mit dem SDK Kits:
nur wen man die SDK Kits installiert, werden der gcc14.2 und die benötigten Header Dateien (z.B. der qt6) auf dem Image mit installiert. Anfänglich hatte ich dies manuell in der "local.conf" Datei eingetragen. Aber in der Zeit, in der ich auf meinen CPU Speicher gewartet hatte, habe ich mich mit dem Yocto System beschäftigt. Man kann dem "bitbake" Kommando einen Parameter mitgeben, der automatisch die SDK Tools mit installiert: (z.B.: bitbake console-image -c populate_sdk).
Das vergrößert das Image noch mehr, ist aber unerheblich, da aktuell die 1.6 GB Größe ohnehin gerissen ist. Aber aktuell führt dies zu einem Fehler beim Bilden des Kernel.
Es hat etwas länger gedauert, zu verstehen, daß es sich nicht(!!) um ein Problem des Yocto Systems handelt, sondern um ein Problem meiner "Standard" OpenSuSE Tumbleweed Installation. Der gleiche Fehler tritt aber auch unter Ubuntu 24.10 auf.
Das System Kommando "file -b <Dateiname>" (Version 5.46) stürzt mit einer "Buffer overflow" Meldung ab, wenn es auf eine für den ARM Prozessor erstellte Datei angewendet wird. Durch diese Fehler verabschiedet sich der "bitbake" Prozess (kontrolliert --> alle parallel gestarteten Prozesse werden noch ordnungsgemäß beendet).
In dem Error Tracking System vom Kommando "file Version5.46" ist schon einer "Buffer Overflow" vermerkt. Ich kann mit dem Error Tracking System nicht umgehen und habe daher den Maintainer des "file" Programms per email angeschrieben. Insbesondere kann ich nicht zuordnen, ob der schon vermerkte Fehler das gleiche Problem ist, daß bei mir auftaucht.
Hier mache ich aktuell nicht weiter. Da sich der Fehler in einem produktiv genutzten Linux System befindet (Ubuntu 24.10), gehe ich davon aus, daß es hierfür zeitnah eine Lösung gibt (Priorität von dem schon vermerkten Buffer Overflow Fehler ist in dem Error Tracking System auf "hoch" gesetzt).
Ich nutze die Zeit bis zur Lösung des Kommando "file" Problems mich mit dem "qemu" System zu beschäftigen. Es ist mir immer noch nicht gelungen, ein erstelltes ARM Image mit "qemu" zu starten.
Was geht ist mit z.B. "losetup --show -f -P ARM_Cortex.img" alle im Image befindlichen Partitionen als Loop Device einzubinden und dann mit mount /dev/LoopXpY einzubinden (X ist die Nummer des nächsten freien Loop Device, das das System verwendet hat und Y die Nummer ein der Partitionen.
Aktuell insgesamt 10 Partitionen --> warum dies so viele sind ist mir noch nicht klar, ich hatte 4 erwartet!
Nach dem mounten, kann man sich anschauen, was da so alles installiert ist. Bei mir ist in der Partition 10 das Linux rootfs System mit allen installierten Paketen (wie schon erwähnt, aktuell ohne die SDKs) installiert. Falls ich da auch nicht weiter komme, schaue ich mir mal den Cortex M4 Teil an, den Fischertechnik veröffentlicht hat.
Frohes coden
Horst
kurzer Überblick über meinen aktuellen Stand:
Aufgrund von Problemen mußte ich einen Schritt zurückgehen. Aktuell erzeugtes Image für den ARM Cortex A7 Prozessor:
- Linux kernel 6.x
- gcc14.2 (zum compilieren + libs auf dem Image. SDK Tools siehe unten)
- Python 3.12.8
- SWIG 3.4
- qt6.8.2
- Software Developer Kit (SDK) --> compilieren schlägt aktuell fehl, wegen Problem mit dem Kommando "file"
(sowohl unter OpenSuSE Tumbleweed als auch kubuntu 24.10 --> siehe unten) - Image Größe > 1.6 GB --> Installation nur noch auf SD Karte möglich
(aktuelle Image Größe mit qt6 Bibliothek aber ohne SDKs: 5 GB --> kann man wahrscheinlich noch verkleiner, aber
1.6 GB ist unrealistisch)
Ich habe auch Fischertechnik angeschrieben, ob von Ihrer Seite ein Software update geplant ist. Wie erwartet, bisher ohne
Antwort. Allerdings hat Fischertechnik ein Problem. Der im TXT4.0 verwendete Linux Kernel 4.19 incl. aller installierten
Software Teilen und der qt5.15 läuft aus der Pflege heraus (als letztes die qt5.15 für Embedded System Ende März diesen Jahres).
Heißt ab April verkauft Fischertechnik ein System mit nicht mehr gewarteter Software. Veraltet war die Software schon
vorher, da keine Patches zur Verfügung gestellt wurden. Auch wenn es "nur" ein Spielzeug ist, das ist rechtlich zumindest grenzwertig.
----------------------------------------------------------------------------------------------------------
Hier folgt jetzt ein kleiner Erfahrungsbericht (falls jemand auch versucht einen neuen Kernel für den TXT4.0 Controller zu bauen):
(falls ich damit nerve, bitte kurze Info geben. Dann melde ich mich erst wieder wenn ich es geschafft oder frustriert aufgegeben habe.)
Zum Bilden des Linux Kernels verwende ich, wie Fischertechnik, das Yocto System.
Meine Versuche basieren alle auf Yocto Branch "styhead" (Fischertechnik hat den Branch "thun" verwendet) und der sehr guten Beschreibung von dem Repository https://github.com/jumpnow/meta-stm32mp1.
Der erste Versuch mit "bitbake" (Yocto Programm zum erstellen des Kernel) war zwar erfolgreich, aber es kam unter OpenSuSE Tumbleweed (meine normalerweise verwendete Linux Distribution) zu gelegentlichen Abstürzen, die aber nach erneutem Aufruf von "bitbake" verschwunden waren (Speicher Problem siehe unten). Mit dem Compiler gcc14 kam es zu Problemen, wenn dieser für das Image verwendet werden sollte (Problem ist gelöst siehe unten). In einem ersten Schritt habe ich daher auf den gcc13 für das Image umgestellt (ggc14 hat zwei geänderte Parameter beim Aufruf z.B. "-V" wurde durch "-v" ("v" klein geschrieben) ersetzt. SWIG3.4 hatte ich durch SWIG3.2 ersetzt. SWIG3.4 hat in einem der verwendeten Marcos einen neuen Parameter eingeführt, der zu Problemen führt (Problem ist aber auch gelöst siehe unten).
Beim Ergänzen von zusätzliche Python Paketen, kam es bei diesem Versuch immer wieder zu Fehlermeldungen mit Python3.13.
Testweise habe ich dann alles in meine Ubuntu Installation transferiert (Ubuntu wird als Standard System für Yocto empfohlen). Unter Ubuntu 24.10 stürzte der "bitbake" Prozess reproduzierbar ab und riß das Terminal mit in den Abgrund. Mit einem zweiten geöffneten Terminal konnte ich als Fehler Speicherplatz Probleme identifizieren. Auch Starten von "bitbake" als root mit vergrößertem SWAP Bereich brachte keine Lösung.
Daher habe ich mir neuen Speicher für meinen Laptop besorgt (2x 8GB durch 2x 32 GB ersetzt). Damit lief "bitbake" unter Ubuntu fehlerfrei durch. Parallel wieder mit zweitem Terminal den Speicherbedarf kontrolliert. In der Spitze ca. 13 GB. Das hätte eigentlich auch vorher mit dem 16 GB Speicher funktionieren sollen. Ich vermute, daß es hier zu Problemen kommt, wenn der Speicher auf zwei verschiedene Bänke aufgeteilt wird (sollte eigentlich kein Problem sein) --> nicht weiter untersucht.
Daher wieder zurück auf mein OpenSuSE Tumbleweed Installation. Dort alles gelöscht (60 GB!!) und alles neu aus dem Netz gezogen (Yocto mit Metadaten sind "nur" ~ 700 MB groß) den Rest zieht der "bitbake" Prozeß aus dem Netz (alle benötigten Source Code Teile, um den Kernel und die anderen Pakete zu erstellen). Dann den "bitbake" Prozeß neu gestartet. Keine Abstürze mehr (das dürfte das Speicherplatz Problem gewesen sein) und -- da ich vergessen hatte die gcc und SWIG Version zu ändern -- auch gcc14.2 und SWIG3.4 (allerdings mit Python3.12.8). Um zu verstehen, wieso dies jetzt funktioniert, einen "diff" auf die unter Ubuntu liegenden Metadaten und die neu gezogen Metadaten gemacht. Ein Blick in das neu gezogene "Changelog" war aber hinreichend. In der Woche zwischen dem ersten Klonen des Git Repository und dem neuen herunterladen hatte der Maintainer einen update gemacht, der die Probleme mit gcc14.2 und SWIG3.4 löst. Im Falle von Problemen lohnt es sich daher immer mal wieder in das Repository rein zuschauen, da dort aktuell dran gearbeitet wird.
Ein sporadisch auftauchendes Problem ist ein "md5sum" Fehler nach dem herunterladen der benötigten Software von dem "bitbake" Prozeß. In diesem Fall muß man die "bblayer.conf" Datei öffnen, die den Fehler erzeugt (ist in der Fehlermeldung angegeben) und in dem Aufruf "git clone git://repository.what.ever";protocol=http;branch=master" den Teil "protocol=https;" löschen. Dies führt zwar zu einem Warnhinweis, daß man doch das http Protokoll verwenden soll, lädt aber alles herunter und das "md5sum" Problem verschwindet. Hierzu hatte ich einen Kontakt zu einem der Maintainer des Git Repository. Das war zwar der falsche Ansprechpartner, aber er war so freundlich trotzdem zu Antworten. Daß das "md5sum" Problem sporadisch auftritt, ist bekannt. Die Ursache ist wahrscheinlich ein Problem mit einem zwischengeschalteten "proxy". Mein gefundene Lösung das https Protokoll abzuschalten ist die aktuell gängige Lösung.
Nach all den Irrungen und Wirrungen läuft jetzt alles durch. Der "bitbake" Prozeß, wie in dem oben erwähnten Git Repository beschrieben, ist viergeteilt. Man startet mit einem Basis Image und geht dann immer ein Image weiter bis zum Schluß das Image mit der qt6 Bibliothek dran ist. Man kann das Bilden des qt6 Image auch direkt starten, dann werden aber trotzdem zuerst die anderen drei Images gebildet. Zur Fehlerkontrolle ist es wirklich einfacher mit den "bitbake" Befahl Image für Image vorzugehen.
Problem mit dem SDK Kits:
nur wen man die SDK Kits installiert, werden der gcc14.2 und die benötigten Header Dateien (z.B. der qt6) auf dem Image mit installiert. Anfänglich hatte ich dies manuell in der "local.conf" Datei eingetragen. Aber in der Zeit, in der ich auf meinen CPU Speicher gewartet hatte, habe ich mich mit dem Yocto System beschäftigt. Man kann dem "bitbake" Kommando einen Parameter mitgeben, der automatisch die SDK Tools mit installiert: (z.B.: bitbake console-image -c populate_sdk).
Das vergrößert das Image noch mehr, ist aber unerheblich, da aktuell die 1.6 GB Größe ohnehin gerissen ist. Aber aktuell führt dies zu einem Fehler beim Bilden des Kernel.
Es hat etwas länger gedauert, zu verstehen, daß es sich nicht(!!) um ein Problem des Yocto Systems handelt, sondern um ein Problem meiner "Standard" OpenSuSE Tumbleweed Installation. Der gleiche Fehler tritt aber auch unter Ubuntu 24.10 auf.
Das System Kommando "file -b <Dateiname>" (Version 5.46) stürzt mit einer "Buffer overflow" Meldung ab, wenn es auf eine für den ARM Prozessor erstellte Datei angewendet wird. Durch diese Fehler verabschiedet sich der "bitbake" Prozess (kontrolliert --> alle parallel gestarteten Prozesse werden noch ordnungsgemäß beendet).
In dem Error Tracking System vom Kommando "file Version5.46" ist schon einer "Buffer Overflow" vermerkt. Ich kann mit dem Error Tracking System nicht umgehen und habe daher den Maintainer des "file" Programms per email angeschrieben. Insbesondere kann ich nicht zuordnen, ob der schon vermerkte Fehler das gleiche Problem ist, daß bei mir auftaucht.
Hier mache ich aktuell nicht weiter. Da sich der Fehler in einem produktiv genutzten Linux System befindet (Ubuntu 24.10), gehe ich davon aus, daß es hierfür zeitnah eine Lösung gibt (Priorität von dem schon vermerkten Buffer Overflow Fehler ist in dem Error Tracking System auf "hoch" gesetzt).
Ich nutze die Zeit bis zur Lösung des Kommando "file" Problems mich mit dem "qemu" System zu beschäftigen. Es ist mir immer noch nicht gelungen, ein erstelltes ARM Image mit "qemu" zu starten.
Was geht ist mit z.B. "losetup --show -f -P ARM_Cortex.img" alle im Image befindlichen Partitionen als Loop Device einzubinden und dann mit mount /dev/LoopXpY einzubinden (X ist die Nummer des nächsten freien Loop Device, das das System verwendet hat und Y die Nummer ein der Partitionen.
Aktuell insgesamt 10 Partitionen --> warum dies so viele sind ist mir noch nicht klar, ich hatte 4 erwartet!
Nach dem mounten, kann man sich anschauen, was da so alles installiert ist. Bei mir ist in der Partition 10 das Linux rootfs System mit allen installierten Paketen (wie schon erwähnt, aktuell ohne die SDKs) installiert. Falls ich da auch nicht weiter komme, schaue ich mir mal den Cortex M4 Teil an, den Fischertechnik veröffentlicht hat.
Frohes coden
Horst
Re: TXT4.0 Linux Kernel neu compilieren
Hallo alle zusammen,
kurze Zusammenfassung vom aktuellen Stand
Details:
Yocto:
Mit Yokto kann ich einen Linux Kernel 6.x erzeugen mit Python 3.12 und qt6. Das Image (mehrere Partitionen wie für ARM Prozessor nötig) habe ich auf die eine Flash Karte aufgespielt, diese in den TXT40 Controller gesteckt und gestartet. Es passiert irgend etwas aber ich bekomme keinerlei Zugriff darauf. Nicht verwunderlich, da ich nur den Device Tree vom STM32mp157A Eval Board habe (Device Tree siehe buildroot unten). Leider bekomme ich auch keinen Zugriff über ein Terminal. Der Touch Screen kann nicht gehen, da das Yocto Image den stm32mp157A Ausgang benutzt, der Touch Screen aber über I2C angeschlossen ist (keinen Treiber dafür installiert).
--> Alle weiteren Versuche abgebrochen (siehe buildroot unten)
Ich hatte mit Yocto angefangen, da ich als erstes das Repository https://git.fischertechnik-cloud.com/txt40/yocto-ktn gefunden hatte. Aber Ft oder deren Software Auftragnehmer sind wohl zweigleisig gefahren oder hatten sich nicht abgesprochen:
Yocto für die SDKs (gcc, etc.) und buildroot (siehe unten) für den Linux Kernel
Cortex M4 + zugehöriger Cortex A7 Source Code
Repositiory: https://git.fischertechnik-cloud.com/txt40/txt-rt-core/
Den Source Code vom Cortex M4 Teil mit Verbindung zum Cortex A7 habe ich so modifiziert, daß er compiliert.
Hier gab es zwei Probleme.
Auch die benötigten Cortex M4 Dateien: für Revision 0: txt2-M4-rt-core-rev0.bin (+elf) und für Revision 1: txt2-M4-rt-core-rev1.bin (+elf) lassen sich erstellen (die benötigte Revision hängt vom Alter der Hardware ab --> ich habe noch nicht herausbekommen, wie man die Revision des Boards mit Software abfragen kann) --> alles bisher noch nicht getestet
Achtung:
bisher habe ich den eigentlichen C-Source Code noch nicht angefaßt. Ich habe nur solche Änderungen vorgenommen, die nötig waren den Compilier zufrieden zustellen --> Austausch des (CMSIS) RTOS Systems (RTOS für ARM) und des openAMP Systems (standardisierte Schnittstelle zwischen Cortex M4 und Cortex A7) steht noch aus. Ebenso, den Ft Code zu verbessern. Ebenfalls noch offen die SWIG Datei zu erzeugen um die Library libTxtControlLib.so von Python aus erreichbar zu machen.
buildroot:
Bis zur Beschäftigung mit dem Cortex M4 Teil für den TXT Controller kannte ich nur Teile der Source Code Repositories von Ft unter https://github.com/fischertechnik. Aber bei der Fehlersuche von dem "_Aotmic_init()" Problem habe ich ein weiteres Repository von Ft gesehen.https://github.com/fischertechnik/FT-TXT (das hatte ich vorher übersehen).
Bei diesem Repository handelt es sich um die Erstellung des TXT40 Controller Linux Kernel mit dem buildroot System. Das Repository ist Kraut und Rüben sortiert und völlig unübersichtlich. Aber die wichtigsten Teil sind dann doch vorhanden: Konfiguration zum Erstellen der Kernel Version (Version 4.19) mit buildroot, die interne Kernel Konfiguration und alle System Konfigurationsdateien (sudoers Datei, DHCP Konfiguration, ...). Insbesondere ist in diesem Repository auch der für die TXT40 Controller Hardware spezifische Kernel Tree vorhanden.
Ich habe diese Konfigurationsdateien von buildroot als Startpunkt genommen. Damit kann man einen Kernel erstellen, der auf dem TXT40 Controller laufen sollte (noch nicht ausprobiert --> siehe gcc Problem unten). ich kannte buildroot bisher noch nicht und habe damit ein wenig herumprobiert. Es kommt beim erstellen des Kernel von den Zusatzpaketen zu ein Paar Fehlermeldungen, die man aber mit Hilfe des Internets und ein wenig eigenen Gehirnschmalz alle beseitigen kann.
Aber ....
Fehlender Source Code:
Alle Python Teile von Ft habe ich mir noch nicht angeschaut (controllerapi-stable.zip, controllerlib-stable.zip). Alles zu finden unter Repository https://git.fischertechnik-cloud.com/txt40
Frohes Coden
Horst Scherer
kurze Zusammenfassung vom aktuellen Stand
- Problem mit Yocto (System Kommando "file" Version 2.46 erzeugt "Buffer Overflow") --> aktuell unverändert keine Lösung
- Versuch Yokto erzeugtes Image auf TXT40 Controller zu starten ist fehlgeschlagen (Details siehe unten) (eventuell neuer Versuch mit TXT40 Controller Konfigurationsdateien (siehe unten))
- Source Code vom Cortex M4 mit zugehörigem Cortex A7 Teil läßt sich compilieren (Details siehe unten)
- weiteren Source Code von Fischertechnik gefunden (hatte ich übersehen) --> System für "buildboot" + System Konfigurationsdateien + TXT40 Controller Kernel Device Tree!!!
mit diesem Source Code von Ft kann ein Linux Kernel 6.x erstellt werden, aber mit Einschränkungen (siehe unten) - Source Code von Programm "TXTControlMain.c" und Teil fehlt!!!--> muß und werde ich bei Ft Nachhaken. Ohne Source Code von diesem Programmen, wird es schwierig
- ftGUI Programme fehlen --> ich bin aber noch nicht durch alle Repositories in https://github.com/fischertechnik durch
- der Ft spezifische Teil von Scratch fehlt (ist in den Daten mit den Konfigurationsdateien zwar angelegt aber leer)
- Versuch Yocto Image die Ft Konfigurationsdateien unter zuschieben (DHCP, etc. ist simple aber wie ich dies mit dem TXT40 Controller Device Tree geht, habe ich keine Ahnung)
- buildroot Linux Kernel 6.x erzeugen aber mit gcc Compiler von 2018 mit Qt5 aber ohne numpy (siehe unten) --> Test ob Kernel auf TXT40 Controller läuft
- Cortex M4 / Coprtex A7 Kommunikationsteil: Versuchen CMSIS-RTOS und openAMP durch neue Version zu ersetzen
Details:
Yocto:
Mit Yokto kann ich einen Linux Kernel 6.x erzeugen mit Python 3.12 und qt6. Das Image (mehrere Partitionen wie für ARM Prozessor nötig) habe ich auf die eine Flash Karte aufgespielt, diese in den TXT40 Controller gesteckt und gestartet. Es passiert irgend etwas aber ich bekomme keinerlei Zugriff darauf. Nicht verwunderlich, da ich nur den Device Tree vom STM32mp157A Eval Board habe (Device Tree siehe buildroot unten). Leider bekomme ich auch keinen Zugriff über ein Terminal. Der Touch Screen kann nicht gehen, da das Yocto Image den stm32mp157A Ausgang benutzt, der Touch Screen aber über I2C angeschlossen ist (keinen Treiber dafür installiert).
--> Alle weiteren Versuche abgebrochen (siehe buildroot unten)
Ich hatte mit Yocto angefangen, da ich als erstes das Repository https://git.fischertechnik-cloud.com/txt40/yocto-ktn gefunden hatte. Aber Ft oder deren Software Auftragnehmer sind wohl zweigleisig gefahren oder hatten sich nicht abgesprochen:
Yocto für die SDKs (gcc, etc.) und buildroot (siehe unten) für den Linux Kernel
Cortex M4 + zugehöriger Cortex A7 Source Code
Repositiory: https://git.fischertechnik-cloud.com/txt40/txt-rt-core/
Den Source Code vom Cortex M4 Teil mit Verbindung zum Cortex A7 habe ich so modifiziert, daß er compiliert.
Hier gab es zwei Probleme.
- alte Header Struktur --> die alten gcc Versionen waren etwas laxer mit der Definition in Header Dateien. Alle Header so umgeschrieben, daß die Funktion- und globalen Variablendefinition als "extern" deklariert sind. In den zugehörigen c Programmen die globalen Variablen ergänzt.
--> dies habe ich schon einmal machen müssen, um alten c-Code wiederzubeleben. Das ist nichts Ft spezifisches sonder war früher so üblich, auch wenn diese heutzutage verpönt ist und zu Problemen vom Linker führt. - Atomic_"xxxx" Funktionen. Diese Funktionen arbeiten auf der untersten Hardware Ebene. Diese Funktionen sind in den System Header Dateien als Preprocessor Macro definiert. Unter OpenSuSE Tumbleweed ist es mir nicht gelungen das als fehlerhaft angemerkte Macro _Atomic_init() ans Laufen zu bekommen. Aber die zu initialisierende Struktur ist in der gleichen Datei definiert in der der Fehler mokiert wird.
Ich habe die Variable manuell statt mit dem Macro umgesetzt (mit entsprechender cast Anweisung um die Datenbreite sicherzustellen). Dann compiliert der Code aber der Linker meldet "declared twice". In den neueren ARM Bibliotheken sind diese Funktionen integriert. Die entsprechenden Definitionen einfach gelöscht --> löst das Problem vom Linker, aber ...
Ich weiß nicht, ob die in den Bibliotheken vorhanden Funktionen exakt genauso funktionieren, wie die in dem C-Code von Ft. Gegebenenfalls muß man die Macros umbenennen und die zugehörigen Stellen in den Source Code Dateien entsprechend anpassen, sodaß die von Ft vorgesehen Marcos auch verwendet werden.
Auch die benötigten Cortex M4 Dateien: für Revision 0: txt2-M4-rt-core-rev0.bin (+elf) und für Revision 1: txt2-M4-rt-core-rev1.bin (+elf) lassen sich erstellen (die benötigte Revision hängt vom Alter der Hardware ab --> ich habe noch nicht herausbekommen, wie man die Revision des Boards mit Software abfragen kann) --> alles bisher noch nicht getestet
Achtung:
bisher habe ich den eigentlichen C-Source Code noch nicht angefaßt. Ich habe nur solche Änderungen vorgenommen, die nötig waren den Compilier zufrieden zustellen --> Austausch des (CMSIS) RTOS Systems (RTOS für ARM) und des openAMP Systems (standardisierte Schnittstelle zwischen Cortex M4 und Cortex A7) steht noch aus. Ebenso, den Ft Code zu verbessern. Ebenfalls noch offen die SWIG Datei zu erzeugen um die Library libTxtControlLib.so von Python aus erreichbar zu machen.
buildroot:
Bis zur Beschäftigung mit dem Cortex M4 Teil für den TXT Controller kannte ich nur Teile der Source Code Repositories von Ft unter https://github.com/fischertechnik. Aber bei der Fehlersuche von dem "_Aotmic_init()" Problem habe ich ein weiteres Repository von Ft gesehen.https://github.com/fischertechnik/FT-TXT (das hatte ich vorher übersehen).
Bei diesem Repository handelt es sich um die Erstellung des TXT40 Controller Linux Kernel mit dem buildroot System. Das Repository ist Kraut und Rüben sortiert und völlig unübersichtlich. Aber die wichtigsten Teil sind dann doch vorhanden: Konfiguration zum Erstellen der Kernel Version (Version 4.19) mit buildroot, die interne Kernel Konfiguration und alle System Konfigurationsdateien (sudoers Datei, DHCP Konfiguration, ...). Insbesondere ist in diesem Repository auch der für die TXT40 Controller Hardware spezifische Kernel Tree vorhanden.
Ich habe diese Konfigurationsdateien von buildroot als Startpunkt genommen. Damit kann man einen Kernel erstellen, der auf dem TXT40 Controller laufen sollte (noch nicht ausprobiert --> siehe gcc Problem unten). ich kannte buildroot bisher noch nicht und habe damit ein wenig herumprobiert. Es kommt beim erstellen des Kernel von den Zusatzpaketen zu ein Paar Fehlermeldungen, die man aber mit Hilfe des Internets und ein wenig eigenen Gehirnschmalz alle beseitigen kann.
Aber ....
- buildroot erstellt prinzipiell keine dev-Kits. Also gcc und andere Dinge fehlen.
- der Linux Kernel kann erstellt werden, wenn der gcc Compiler von 2018 verwendet wird (wahrscheinlich gcc7.2.1) (Einstellparameter von buildroot Konfigurationsmenü biete nur Jahreszahl aber keine Version an)
- buildroot funktioniert aktuell nicht, wenn man den Compiler gcc 14.2.1 als Crosscompiler für den Kernel verwenden möchte
--> das impliziert auch, das nur die qt5 und nicht die qt6 compiliert werden kann. Auch numpy geht nur mit dem Compiler gcc Version14 (führt aber auch da zu Problemen beim Erstellen).
Aber gcc Complier Version 14 wird schon in der buildroot Community diskutiert --> Lösung kommt hoffentlich bald. Da kann ich aber nicht mithalten. Da kommen Fehlermeldungen zuhauf beim Bilden des Linux Kernel, die ich nicht mal im Ansatz verstehe). Aber die Qt Version 5.15 für embedded System ist abgekündigt (Ende März diesen Jahres). Daher wird der Zwang in der Industrie auf die Qt6 umzusteigen entsprechend groß werden. Die Qt6 läßt sich aber nur mit dem Compiler gcc Version 14 compilieren.
Fehlender Source Code:
- In dem Ft Repository https://github.com/fischertechnik/FT-TXT ist nur eine binary Version "TXTControlMain" vorhanden.
Dieses Programm verwendet dynamisch und nicht statisch gelinkte Bibliotheken. Wenn man den Kernel und alle Libraries erneuert, muß man wohl oder Übel auch diese Datei neu compilieren, sonst wird dieses Programm nicht laufen - alle FtGUI Programmteile noch nicht gefunden.
Alle Python Teile von Ft habe ich mir noch nicht angeschaut (controllerapi-stable.zip, controllerlib-stable.zip). Alles zu finden unter Repository https://git.fischertechnik-cloud.com/txt40
Frohes Coden
Horst Scherer
Re: TXT4.0 Linux Kernel neu compilieren
Hallo alle zusammen,
wie beim letzten mal schon angekündigt, hatte und habe ich aktuell wenig Zeit mich mit dem TXT40 Controller zu beschäftigen.
Aber gestern habe ich eine Antwort auf meine Anfrage beim Fischertechnik Service erhalten, ob von Fischertechnik Seite ein update geplant ist.
Die Antwort ist "ja!!!"
Herr Steiger vom Fischtechnik Service hat geschrieben, daß Sie aktuell dabei sind einen Software update für den TXT40 Controller zu erstellen. Allerdings gibt es derzeit noch keinen Release Termin.
Frohes Coden
Horst
wie beim letzten mal schon angekündigt, hatte und habe ich aktuell wenig Zeit mich mit dem TXT40 Controller zu beschäftigen.
Aber gestern habe ich eine Antwort auf meine Anfrage beim Fischertechnik Service erhalten, ob von Fischertechnik Seite ein update geplant ist.
Die Antwort ist "ja!!!"
Herr Steiger vom Fischtechnik Service hat geschrieben, daß Sie aktuell dabei sind einen Software update für den TXT40 Controller zu erstellen. Allerdings gibt es derzeit noch keinen Release Termin.
Frohes Coden
Horst
Re: TXT4.0 Linux Kernel neu compilieren
Hallo alle zusammen,
nach einer etwas längeren Pause möchte ich mich dann mal wieder melden.
Leider mit schlechten Nachrichten. Mit "Yocto" und "buildroot" gelingt es mir einen neuen Kernel für den TXT40 Controller zu erzeugen. Aber ich schaffe es nicht eine bootfähige SD Karte zu erstellen.
Daher habe ich per email bei Herrn Adams (Author des exzellenten Buchs "Fischertechnik TXT4 Controller Internals and Programming") um Hilfe gebeten.
Herr Adams war so freundlich, sich das Ganze anzuschauen und hat mich dann darauf aufmerksam gemacht, das der TXT40 Controller Device Tree nicht paßt und von Fischertechnik nicht veröffentlicht ist.
Ich habe mir dies daraufhin noch einmal angeschaut. Tatsächlich ist der im Fischertechnik Repositories "FT-TXT" und "txt-rt-core" vorhanden Device Tree nur für das von Fischertechnik benutzte Eval Board und nicht (!!) für den TXT40 Controller.
Herr Adams hat mal versucht ein Reverse Engineering zu machen und den auf dem TXT40 Controller vorhandenen Device Tree decompiliert. Dabei kommt es aber zu einer Reihe von Fehlermeldungen, die auf das Alter des Device Trees zurückzuführen sein dürften. Kontron der Lieferant/Hersteller des im TXT40 Controller verwendeten ARM Prozessors hat den Standard Device Tree von ARM für den Boot Loader stark modifiziert und dies leider nicht als Patch in den von ARM gepflegten Standard Boot Loader eingepflegt. Das macht die Fehleranalyse sehr kompliziert, da nicht klar ist, ob Kontron in der letzten veröffentlichten Version ihres Device Trees alle Verbesserungen/Änderungen von AMD mit eingepflegt hat. Zusätzlich hat Fischertechnik den Device Tree von Kontron verändert, um die Spezifika des TXT40 Controller zu berücksichtigen. Das verkompliziert die Analyse noch weiter.
Wenn Herr Adams Zeit hat, schaut er mal ob es nicht doch noch einen Weg gibt einen anderen Kernel zu booten. Das wird aber dauern, da Herr Adams natürlich auch seiner regulären Beschäftigung nachgehen muß.
Für mich endet dieser Versuch leider hier, da ein Reverse Engineering eines Device Trees auf Binary Ebene bei weitem meine Fähigkeiten übersteigt.
Zusätzlich hat Fischertechnik nicht den direkten am STM32mp157 Prozessor vorhandenen TFT Treiber Ausgang für das Display genutzt sondern das Display über einen I2C Treiber angeschlossen. Das ist für mich völlig unverständlich da es Geld gespart hätte, der Ausgang am STM32MP157 Prozessor ohnehin vorhanden ist und ein zusätzlicher I2C Treiberbaustein hätte entfallen können. Das eigentliche Problem mit der Anbindung des Displays über einen I2C Treiber ist aber, daß dies das Debuggen des Boot Loaders erschwert. Ausgaben auf dem Display sind erst möglich wenn der Linux Kernel mit seinem I2C Subsystem gestartet sind. Damit ist es aber unmöglich Fehlermeldungen vom Boot Loader zu sehen, dessen Arbeit mit dem Start des Linux Kernels endet.
Außerdem fehlen noch mehr Software Sourcen als nur der Device Tree. Alles Software Teile, die mit der Grafikausgabe auf dem Display zu tun hat (Qt-Programme) fehlen. Die Software Sourcen von dem Programm "ftconfig", mit dem der Fischertechnik spezifische Teil vom TXT40 Controller gestartet bzw. kontrolliert wird und der Siource Code von "ftcalib" fehlen.
Anderseits bin ich auf Python Dateien gestoßen, von deren Existenz ich nirgendwo einen Hinweis gefunden habe (z.B. "ft_axisrobot" oder "ft_ikpy").
Der Zweck dieser Dateien läßt sich nur durch Analyse des Python Codes herausfinden (leider dürftig im Code dokumentiert).
Zusammenfassend kann ich nach mehreren Wochen Beschäftigung mit den Fischertechnik Repositories nur sagen, daß Fischertechnik eigentlich nichts vom Source Code des TXT40 Controllers wirklich veröffentlicht hat. Die veröffentlichten Repositories sind eigentlich nur Nebelkerzen, mit denen man nur sehr wenig anfangen kann, wenn man nicht gerade das von Fischertechnik benutzte Eval Board verwendet. Zusätzlich fehlen nahezu alle Beschreibungen zu den vorhandenen Python Programmen.
Wie oben schon erwähnt, übersteigt ein Reverse Engineering des Device Trees meine Fähigkeiten. Einen direkten Anschluß eines externen Terminals an den STM32MP157 Prozessor TFT Ausgang bekäme ich zwar hin, aber das würde einen
massiven Eingriff in die Hardware, den ich mir verkneifen kann.
Damit enden meine Bemühungen leider vorerst.
Herr Steiger von Fischertechnik hatte mir auf email Nachfrage mitgeteilt, daß eine neue Software Version für den TXT40 Controller geplant ist und das nach der Veröffentlichung der Software, auch diese Version in den Fischertechnik Repositories eingepflegt wird. Bis dahin werde ich nichts weiter machen. Sobald die neue Software veröffentlicht ist, schaue ich mir das Ganze wieder an. Aber ohne Device Tree werde ich definitiv nicht weiter machen. Verbesserungen an dem Python Code machen aktuell aber auch keine Sinn, da ich nicht weiß was Fischertechnik selber in der neuen Version für Änderungen am Python Code plant. Je nachdem sind alle jetzt gemachten Änderungen umsonst.
Sobald die neue Software für den TXT40 Controller veröffentlicht ist, melde ich mich wieder. Je nach verwendeter Kernel Version und Python Version erübrigt sich aber weitere Arbeit an eine neuen Kernel und man kann sich auf den Python Code konzentrieren.
Frohen Coden
Horst
nach einer etwas längeren Pause möchte ich mich dann mal wieder melden.
Leider mit schlechten Nachrichten. Mit "Yocto" und "buildroot" gelingt es mir einen neuen Kernel für den TXT40 Controller zu erzeugen. Aber ich schaffe es nicht eine bootfähige SD Karte zu erstellen.
Daher habe ich per email bei Herrn Adams (Author des exzellenten Buchs "Fischertechnik TXT4 Controller Internals and Programming") um Hilfe gebeten.
Herr Adams war so freundlich, sich das Ganze anzuschauen und hat mich dann darauf aufmerksam gemacht, das der TXT40 Controller Device Tree nicht paßt und von Fischertechnik nicht veröffentlicht ist.
Ich habe mir dies daraufhin noch einmal angeschaut. Tatsächlich ist der im Fischertechnik Repositories "FT-TXT" und "txt-rt-core" vorhanden Device Tree nur für das von Fischertechnik benutzte Eval Board und nicht (!!) für den TXT40 Controller.
Herr Adams hat mal versucht ein Reverse Engineering zu machen und den auf dem TXT40 Controller vorhandenen Device Tree decompiliert. Dabei kommt es aber zu einer Reihe von Fehlermeldungen, die auf das Alter des Device Trees zurückzuführen sein dürften. Kontron der Lieferant/Hersteller des im TXT40 Controller verwendeten ARM Prozessors hat den Standard Device Tree von ARM für den Boot Loader stark modifiziert und dies leider nicht als Patch in den von ARM gepflegten Standard Boot Loader eingepflegt. Das macht die Fehleranalyse sehr kompliziert, da nicht klar ist, ob Kontron in der letzten veröffentlichten Version ihres Device Trees alle Verbesserungen/Änderungen von AMD mit eingepflegt hat. Zusätzlich hat Fischertechnik den Device Tree von Kontron verändert, um die Spezifika des TXT40 Controller zu berücksichtigen. Das verkompliziert die Analyse noch weiter.
Wenn Herr Adams Zeit hat, schaut er mal ob es nicht doch noch einen Weg gibt einen anderen Kernel zu booten. Das wird aber dauern, da Herr Adams natürlich auch seiner regulären Beschäftigung nachgehen muß.
Für mich endet dieser Versuch leider hier, da ein Reverse Engineering eines Device Trees auf Binary Ebene bei weitem meine Fähigkeiten übersteigt.
Zusätzlich hat Fischertechnik nicht den direkten am STM32mp157 Prozessor vorhandenen TFT Treiber Ausgang für das Display genutzt sondern das Display über einen I2C Treiber angeschlossen. Das ist für mich völlig unverständlich da es Geld gespart hätte, der Ausgang am STM32MP157 Prozessor ohnehin vorhanden ist und ein zusätzlicher I2C Treiberbaustein hätte entfallen können. Das eigentliche Problem mit der Anbindung des Displays über einen I2C Treiber ist aber, daß dies das Debuggen des Boot Loaders erschwert. Ausgaben auf dem Display sind erst möglich wenn der Linux Kernel mit seinem I2C Subsystem gestartet sind. Damit ist es aber unmöglich Fehlermeldungen vom Boot Loader zu sehen, dessen Arbeit mit dem Start des Linux Kernels endet.
Außerdem fehlen noch mehr Software Sourcen als nur der Device Tree. Alles Software Teile, die mit der Grafikausgabe auf dem Display zu tun hat (Qt-Programme) fehlen. Die Software Sourcen von dem Programm "ftconfig", mit dem der Fischertechnik spezifische Teil vom TXT40 Controller gestartet bzw. kontrolliert wird und der Siource Code von "ftcalib" fehlen.
Anderseits bin ich auf Python Dateien gestoßen, von deren Existenz ich nirgendwo einen Hinweis gefunden habe (z.B. "ft_axisrobot" oder "ft_ikpy").
Der Zweck dieser Dateien läßt sich nur durch Analyse des Python Codes herausfinden (leider dürftig im Code dokumentiert).
Zusammenfassend kann ich nach mehreren Wochen Beschäftigung mit den Fischertechnik Repositories nur sagen, daß Fischertechnik eigentlich nichts vom Source Code des TXT40 Controllers wirklich veröffentlicht hat. Die veröffentlichten Repositories sind eigentlich nur Nebelkerzen, mit denen man nur sehr wenig anfangen kann, wenn man nicht gerade das von Fischertechnik benutzte Eval Board verwendet. Zusätzlich fehlen nahezu alle Beschreibungen zu den vorhandenen Python Programmen.
Wie oben schon erwähnt, übersteigt ein Reverse Engineering des Device Trees meine Fähigkeiten. Einen direkten Anschluß eines externen Terminals an den STM32MP157 Prozessor TFT Ausgang bekäme ich zwar hin, aber das würde einen
massiven Eingriff in die Hardware, den ich mir verkneifen kann.
Damit enden meine Bemühungen leider vorerst.
Herr Steiger von Fischertechnik hatte mir auf email Nachfrage mitgeteilt, daß eine neue Software Version für den TXT40 Controller geplant ist und das nach der Veröffentlichung der Software, auch diese Version in den Fischertechnik Repositories eingepflegt wird. Bis dahin werde ich nichts weiter machen. Sobald die neue Software veröffentlicht ist, schaue ich mir das Ganze wieder an. Aber ohne Device Tree werde ich definitiv nicht weiter machen. Verbesserungen an dem Python Code machen aktuell aber auch keine Sinn, da ich nicht weiß was Fischertechnik selber in der neuen Version für Änderungen am Python Code plant. Je nachdem sind alle jetzt gemachten Änderungen umsonst.
Sobald die neue Software für den TXT40 Controller veröffentlicht ist, melde ich mich wieder. Je nach verwendeter Kernel Version und Python Version erübrigt sich aber weitere Arbeit an eine neuen Kernel und man kann sich auf den Python Code konzentrieren.
Frohen Coden
Horst