TXT von SD-Karte booten

[MasterOfGizmo]

Hat schon einmal jemand das "TXT Controller Open Source Archiv" tatsächlich benutzt? Ich habe irgendwann vor einer Weile mal alles gebaut und jetzt vor zwei Tagen mit den MakeSD und CopyToSD-Skripten eine SD-Karte gebaut. Sieht auch soweit alles sinnvoll aus. Allerdings ignoriert der TXT die Karte beim Booten.

Hat sich jemand damit mal beschäftigt und den TXT ggf. sogar von einer SD-Karte booten lassen?

[chehr]

Hallo MOG,
falls du das noch nicht gelesen hast, vielleicht hilft dir folgender Link weiter.
http://forum.ftcommunity.de/viewtopic.php?f=8&t=3365
Dort ist beschrieben wie man die microSD Karte einbindet.

Gruß
Christian

[MasterOfGizmo]

Danke. Aber dort wird lediglich erklärt,wie man die SD-Karte am laufenden TXT mountet. Das ist was anderes.

Man kann mit dem Source-Package von der Fischertechnik-Seite ein Image auf der SD-Karte bauen. Und das macht nur dann Sinn, wenn der TXT auch davon booten kann. Aber das scheint so einfach nicht zu klappen und dieses Source-Package enthält auch keinerlei Dokumentation oder ähnlich. Das ist schade, denn das wäre ein Anfang, damit die Community den TXT weiter entwickeln kann.

Es gibt sicher irgendeinen Trick (SD-Karte muss eine bestimmt Größe haben, es muss irgendein Jumper im Geräte gesetzt werden, ...). Der ist aber nicht doumentiert bzw ich bin nicht in der Lage ihn zu finden.

[ski7777]

Also ich habe mal gehört man müaste den internen Flash lösche. Bloß wie, wenn man nur von ihm booten kann und Linux ist bestimmt so schlau wie Windows:

format c:
Zugriff Verweigert

Raphael

P.s.: Ich glaub Linux antwortet auf Englisch.

[Torsten]

Hallo,

Beim Stöbern in diversen Systemdateien auf dem TXT ist mir aufgefallen, dass es offenbar so etwas wie ein Boot-Menu gibt, das auch ein Hochfahren des TXT von einer externen SD-Karte vorsieht. In diesem Boot-Menu gibt es auch Hinweise auf die Verwendung eines seriellen Terminals (115k, 8, N, 1). Ich habe daraufhin mal ein serielles Terminal über RS232 an den Expansion Port des TXT angeschlossen (RX, TX, GND) und verschiedene Tasten ausprobiert dabei ist mir folgendes aufgefallen:
Wenn man innerhalb der ersten Sekunde nach dem Einschalten des TXT auf der seriellen Konsole eine Taste drückt, dann bootet der TXT nicht weiter, sondern wartet auf irgendwas. Was das ist, weiss ich noch nicht. Um wieder normal zu booten, muss man den TXT ausschalten (10 Sekunden lang den Ein/Aus Taster druecken) und wieder einschalten. Mehr weiss ich bisher noch nicht, hatte aber auch noch nicht genügend Zeit mich näher damit zu beschäftigen. Aber vielleicht hilft das ja schon etwas weiter.
(Ich habe ja immer noch die Hoffnung, das es dazu auch irgendwann mal eine Dokumentation von fischertechnik gibt)

Viele Grüße
Torsten

[richard.kunze]

Hallo,

Bei mir sieht das Layout der Flash-Partitionen auf dem TXT so aus:

Code: Alles auswählen

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00020000 00020000 "SPL1"
mtd1: 00020000 00020000 "SPL2"
mtd2: 00020000 00020000 "SPL3"
mtd3: 00020000 00020000 "SPL4"
mtd4: 00040000 00020000 "dtb"
mtd5: 00100000 00020000 "U-boot"
mtd6: 00020000 00020000 "U-boot-env"
mtd7: 00020000 00020000 "U-boot-env-backup"
mtd8: 00500000 00020000 "uImage"
mtd9: 00040000 00020000 "bootlogo"
mtd10: 078c0000 00020000 "rootfs"

Das deutet stark darauf hin, daß der TXT U-Boot (http://www.denx.de/wiki/U-Boot/) als Bootloader benutzt (wie eigentlich so ziemlich alles ARM-basierte rechnende Linux-Kleinzeug, das mir in den letzten paar Jahren so untergekommen ist). U-Boot gibt normalerweise beim Booten auf der seriellen Konsole recht detailliert Auskunft darüber, was es macht, und es bringt eine recht mächtige Shell mit, in der man entweder interaktiv oder per Script diverse Hardware (USB, MMC-Geräte, SATA, Netzwerk-Schnittstellen) initialisieren und Bootimages von allen möglichen Quellen (Flash, SD-Karten, Festplatten, BOOTP-Servern, ...) laden und starten kann.

Die Einstellungen für U-Boot sind normalerweise in einer eigenen MTD-Partition gespeichert ("U-boot-env" oben), die kann man mit als root mit "fw_printenv" (ist auf dem TXT dabei) auslesen (und mit "fw_setenv" verändern - das sollte man aber nur tun, wenn man genau weiß was man da macht und auch weiß, wie man ein kaputtkonfiguriertes U-Boot wieder flott kriegt).

"fw_printenv" liefert bei mir einen Haufen Zeug, relevant dürfte vor allem Folgendes sein:

Code: Alles auswählen

bootcmd=run nandboot

nandboot=run reset_wl18xx; mtdparts default; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; fdt addr 0x80F00000; run opp;setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 ubi.mtd=10 root=ubi0:rootfs rootfstype=ubifs rootwait quiet; bootm 0x80200000 - 0x80F00000

sdboot=run reset_wl18xx; fatload mmc 0 0x80200000 uImage; fatload mmc 0 0x80F00000 am335x-kno_txt.dtb; fdt addr 0x80F00000; run opp;setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 root=/dev/mmcblk0p2 rw rootwait quiet;bootm 0x80200000 - 0x80F00000

"bootcmd" ist der Befehl, den U-Boot bei einem Start ohne Benutzerinteraktion ausführt - in diesem Fall "run nandboot" , d.h. 'mach das, was in "nandboot" abgelegt ist'. In "nandboot" steht eine Reihe von Kommandos zur (Re-?)Initialisierung des WLAN-Subsystems ("reset_wl18xx", was das im Detail macht findet man ebenfalls in der Ausgabe von fw_printenv), Initialisierung der MTD-Partitionen (warum das da zweimal drin steht weiß ich auch nicht), Einlesen von Kernel und DTB ("Device Tree Block", eine Beschreibung der Hardware für den Kernel) ins RAM, noch ein paar Einstellungen, und schließlich der Start von Linux ("bootm 0x80200000 - 0x80F00000" - d.h. "starte das Linux-Image an Adresse 0x80200000 und übergib ihm die Adresse 0x80F00000 als den Speicherort des DTB).

Und in "sdboot" steht jetzt ein ziemlich ähnliches Script, nur dass hier Linux-'Image und DTB eben von eine mit FAT formatierten SD-Karte geladen werden (aus den Dateien "uImage" bzw. "am335x-kno_txt.dtb")...

Wenn man innerhalb der ersten Sekunde nach dem Einschalten des TXT auf der seriellen Konsole eine Taste drückt, dann bootet der TXT nicht weiter, sondern wartet auf irgendwas.

Das ist eigentlich U-Boot-Standardverhalten: Wenn man früh im Bootvorgang etwas über die serielle Schnittstelle schickt, dann stoppt U-Boot den normalen Bootvorgang und gibt dir eine serielle Konsole, in der Du dann interaktiv arbeiten kannst. Allerdings solltest Du in dem Fall eigentlich auch jede Menge Meldungen von U-Boot auf der seriellen Schnittstelle sehen...

Was Du relativ gefahrlos probieren kannst: Tipp mal nach dem Anhalten des Bootvorgangs blind "run nandboot" ("Enter/Return" am ende nicht vergessen). Wenn der TXT dann wie normal weiter bootet, hast Du Zugang zur U-Boot-Konsole. Dann sollte eigentlich auch ein "run sdboot" funktionieren und eben von der SD-Karte booten.

Viele Grüße,

Richard

[ski7777]

Dann könnte die Community ja auch einfach eine kleine GUI programmieren die beim booten gestartet wird als Bootmenü und dort soll man dann auswählen, ob man von der SD-Karte oder vom Flash bootet.

[richard.kunze]

Dann könnte die Community ja auch einfach eine kleine GUI programmieren die beim booten gestartet wird als Bootmenü und dort soll man dann auswählen, ob man von der SD-Karte oder vom Flash bootet.

Direkt in U-Boot dürfte das etwas fricklig werden - U-Boot bringt zwar von Haus aus eine Menge Werkzeuge mit, um Massenspeicher und Netzwerk anzusprechen, aber für Interaktion mit dem Benutzer gibts da eigentlich nur die serielle Schnittstelle.

Was man auf jeden Fall machen kann ist, U-Boot aus dem laufenden Linux-System heraus umzukonfigurieren und dann mit den neuen Einstellungen neu zu booten. Das ist aber ohne sicheren Zugriff auf die interaktive Shell von U-Boot äußerst riskant: Wenn man dabei einen Fehler macht, dann hat man den TXT ziemlich sicher "gebrickt", d.h. in einen äußerst teuren, nur noch als Briefbeschwerer nutzbaren "Ziegelstein" verwandelt (mit Zugang zur U-Boot-Shell sieht das anders aus - da kann man Konfigurationsfehler meistens interaktiv wieder ausbügeln).

Deshalb will ich hier jetzt auch keine ausführliche Anleitung geben, wie man an den U-Boot-Einstellungen rumwursteln kann.

Viele Grüße,

Richard

[MasterOfGizmo]

Oh, ja, eine serielle Console mit 115200 bit/s auf dem EXT-Port. Da hätte ich ja auch selbst drauf kommen können

Code: Alles auswählen

U-Boot SPL 2013.10 (Jul 04 2015 - 08:30:17)
>>> I2C0 On
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
>>> setup_dplls vor do_setup_dpll
>>> setup_dplls nach do_setup_dpll
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
>>> Setting MUX Start
>>> Setting MUX End
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
>>>Start TXT-Mode - V2
LCD-Init_4: 
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
---> MPU 600 VDD 46 


U-Boot 2013.10 (Jul 04 2015 - 08:30:17)

I2C:   ready
DRAM:  256 MiB
NAND:  128 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Could not probe the EEPROM; something fundamentally wrong on the I2C bus.
Could not get board ID.
Net:   usb_ether

NAND read: device 0 offset 0x700000, size 0x40000
 262144 bytes read: OK
CopyToLcd
LCD Command called
Hit ENTER key to stop autoboot:  0 
U-Boot# 

Im U-boot kann man dann z.B. "help" eingeben. Das Kommando printenv zeigt das Environment an, das Richard auch schon aus Linux raus angezeigt hat:

Code: Alles auswählen

U-Boot# printenv
arch=arm
baudrate=115200
board=TXT
board_name=
board_rev=|�0@
bootcmd=run nandboot
bootdelay=3
cpu=armv7
ethact=usb_ether
filesize=13036
flash_all=run flash_erase; run flash_u-boot; run flash_spl; run flash_rootfs; run flash_dtb; run flash_uImage; run flash_bootlogo; setenv bootcmd run nandboot; setenv prv
flash_bootlogo=mtdparts default; nand erase.part NAND.bootlogo; mw.b 0x80200000 0xff 0x40000; fatload mmc 0:1 0x80200000 bootlogo.bmp; nand write 0x80200000 NAND.bootlog}
flash_dtb=mtdparts default; nand erase.part NAND.dtb; mw.b 0x80200000 0xff 0x40000; fatload mmc 0:1 0x80200000 am335x-kno_txt.dtb; nand write 0x80200000 NAND.dtb 0x${fil}
flash_erase=nand erase.chip
flash_rootfs=mtdparts default;nand erase.part NAND.rootfs; fatload mmc 0:1 0x80200000 rootfs.ubi; nand write 0x80200000 NAND.rootfs 0x${filesize}
flash_spl=mtdparts default; nand erase.part NAND.SPL1; nand erase.part NAND.SPL2; nand erase.part NAND.SPL3; nand erase.part NAND.SPL4; mw.b 0x80200000 0xff 0x200000; fa}
flash_u-boot=mtdparts default; nand erase.part NAND.U-boot; mw.b 0x80200000 0xff 0x100000; fatload mmc 0:1 0x80200000 u-boot.img; nand write 0x80200000 NAND.U-boot 0x${f}
flash_uImage=mtdparts default; nand erase.part NAND.uImage; mw.b 0x80200000 0xff 0x500000; fatload mmc 0:1 0x80200000 uImage; nand write 0x80200000 NAND.uImage 0x${files}
mtddevname=NAND.SPL1
mtddevnum=0
mtdids=nand0=nand.0
mtdparts=mtdparts=nand.0:128k(NAND.SPL1),128k(NAND.SPL2),128k(NAND.SPL3),128k(NAND.SPL4),256k(NAND.dtb),1m(NAND.U-boot),128k(NAND.U-boot-env),128k(NAND.U-boot-env-backup)
nandboot=run reset_wl18xx; mtdparts default; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; fdt addr 0x80F00000; run opp;setenv boota0
nandpreboot=mtdparts default; nand read 0x80200000 NAND.bootlogo; lcd l
opp=fdt set /cpus/cpu@0 operating-points <0x000927c0 0x0012b128 0x0007a120 0x00112a88 0x000493e0 0x00112a88 0x00043238 0x00112a88>
partition=nand0,0
preboot=run nandpreboot
ramboot=run reset_wl18xx; fatload mmc 0 0x80200000 uImage; fatload mmc 0 0x80F00000 am335x-kno_txt.dtb; fdt addr 0x80F00000; run opp;fatload mmc 0 0x81000000 initrd.gz; 0
reset_wl18xx=gpio clear 97; gpio clear 98
sdboot=run reset_wl18xx; fatload mmc 0 0x80200000 uImage; fatload mmc 0 0x80F00000 am335x-kno_txt.dtb; fdt addr 0x80F00000; run opp;setenv bootargs fbtft_device.name=txt0
soc=am33xx
stderr=serial
stdin=serial
stdout=serial
usbflash_all=run flash_erase; run usbflash_u-boot; run usbflash_spl; run usbflash_rootfs; run usbflash_dtb; run usbflash_uImage; run usbflash_bootlogo; setenv bootcmd ruv
usbflash_bootlogo=mtdparts default;usb start; nand erase.part NAND.bootlogo; mw.b 0x80200000 0xff 0x40000; fatload usb 0:1 0x80200000 bootlogo.bmp; nand write 0x80200000}
usbflash_dtb=mtdparts default;usb start; nand erase.part NAND.dtb; mw.b 0x80200000 0xff 0x40000; fatload usb 0:1 0x80200000 am335x-kno_txt.dtb; nand write 0x80200000 NAN}
usbflash_rootfs=mtdparts default;usb start;nand erase.part NAND.rootfs; fatload usb 0:1 0x80200000 rootfs.ubi; nand write 0x80200000 NAND.rootfs 0x${filesize}
usbflash_spl=mtdparts default;usb start; nand erase.part NAND.SPL1; nand erase.part NAND.SPL2; nand erase.part NAND.SPL3; nand erase.part NAND.SPL4; mw.b 0x80200000 0xff}
usbflash_u-boot=mtdparts default;usb start; nand erase.part NAND.U-boot; mw.b 0x80200000 0xff 0x100000; fatload usb 0:1 0x80200000 u-boot.img; nand write 0x80200000 NAND}
usbflash_uImage=mtdparts default;usb start; nand erase.part NAND.uImage; mw.b 0x80200000 0xff 0x500000; fatload usb 0:1 0x80200000 uImage; nand write 0x80200000 NAND.uIm}
usbnet_devaddr=6c:ec:eb:af:75:d1
vendor=knobloch
ver=U-Boot 2013.10 (Jul 04 2015 - 08:30:17)

Environment size: 4959/131067 bytes

Lauter tolle Dinge. Manche sollte man wohl besser nicht ausprobieren. Alles was da "flash" im Namen hat schreibt ins Flash und kann den TXT ggf. bricken. Aber das "sdboot" klingt doch nach genau dem was ich will.

Also ,mal geschwind "run sdboot" eingegeben. Und was soll ich sagen? Er bootet von SD-Karte ...

Das ließe sich wahrscheinlich auch permanent einstellen. Mit "setenv bootcmd=run sdboot" und folgendem "saveenv" ist das recht wahrscheinlich möglich. Aber auch von USB scheint er booten zu können.

[MasterOfGizmo]

Da stellt sich natürlich die Frage nach den aktuellen Sourcen. Das was da dann bootet meldet sich in den Settings mit Version 4.1.5.0.

Aber das ist ja immerhin ein Anfang.

[MasterOfGizmo]

Hmmm ... auf einem aktuellen Ubuntu sind wohl ein paar zusätzliche Patches nötig wie z.B. der für ncurses unter gcc 5.1. Wenn das Source-Archiv nicht schon längst wieder veraltet wäre würde ich es ja mal auf github ablegen.

Zu schade, dass da auf FT/Knobloch-Seite eher im stillen Kämmerlein dran gearbeitet wird. Wäre doch cool, wenn die das z.B. auf github pflegen würden und ich dann einfach forken und patchen könnte ...

Kleiner Hinweis an die Kollegen von Fischertechnik: Wenn ihr es uns Usern einfacher macht, an dem TXT mitzuarbeiten, dann würde das auch eher mal jemand tun. Das wäre dermaßen in Eurem Sinne, das könnt ihr euch gar nicht vorstellen

Achja, in diesem ganzen Code-Haufen müsste dann ja auch das Programm dabei sein, das das Root-Passwort für den TXT erzeugt, verschlüsselt und speichert ... zumindest wenn sie nicht von irgendwo Binärcode importieren.

[MasterOfGizmo]

Ah, nee. Da ist haufenweise Closed-Source dabei.

Sie scheinen nur das im Source-Code zu verteilen, was schon TI im Original dabei hatte. Alles was sie selbst dazu gebaut haben liegt in Binärform schon im Source-Archiv von FT drin. Damit ist der Name "TXT Controller Open Source Archiv" ja ziemlich irreführend und sie halten sich in vielen Dingen nach wie vor nicht an die Lizenzbestimmungen. Seufz ...

[richard.kunze]

Das ließe sich wahrscheinlich auch permanent einstellen. Mit "setenv bootcmd=run sdboot" und folgendem "saveenv" ist das recht wahrscheinlich möglich.

Ja, sollte genau so gehen. Eventuell sogar noch etwas besser - probier mal Folgendes einmal mit und einmal ohne SD-Karte aus:

Code: Alles auswählen

setenv loadsduimg=fatload mmc 0 0x80200000 uImage
setenv loadsddtb=fatload mmc 0 0x80F00000 am335x-kno_txt.dtb
setenv setsdargs=setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 root=/dev/mmcblk0p2 rw rootwait quiet
setenv bootboth=run reset_wl18xx; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 ubi.mtd=10 root=ubi0:rootfs rootfstype=ubifs rootwait quiet; run loadsduimg loadsddtb setsdargs; fdt addr 0x80F00000; run opp; bootm 0x80200000 - 0x80F00000
run bootboth

(Alle "setenv"-Befehle und das abschliessende "run bootboth" jeweils auf einer Zeile, auch wenn das hier im Forum umgebrochen wird)

Wenn das so funktioniert wie es nach meinem Verständnis der U-Boot-Doku sollte, dann müsste das mit eingelegter SD-Karte von der SD-Karte booten und ohne vom NAND-Flash (also die Original-Firmware).

Wenn es das tatsächlich tut, dann spricht eigentlich nichts dagegen das ganze permanent einzurichten:

Code: Alles auswählen

setenv loadsduimg=fatload mmc 0 0x80200000 uImage
setenv loadsddtb=fatload mmc 0 0x80F00000 am335x-kno_txt.dtb
setenv setsdargs=setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 root=/dev/mmcblk0p2 rw rootwait quiet
setenv bootboth=run reset_wl18xx; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 ubi.mtd=10 root=ubi0:rootfs rootfstype=ubifs rootwait quiet; run loadsduimg loadsddtb setsdargs; fdt addr 0x80F00000; run opp; bootm 0x80200000 - 0x80F00000
setenv bootcmd=run bootboth
saveenv
run bootcmd

Kostet dann zwar sowohl mit als auch ohne SD-Karte etwas mehr Zeit beim Booten (mit SD-Karte, weil das - in dem Fall überflüssige - Original-Kernel-Image aus dem NAND gelesen wird, ohne, weil vergeblich versucht wird ein Kernel-Image von SD-Karte zu lesen), aber das sollte zu verschmerzen sein.

Ich kann das selber leider gerade nicht ausprobieren, weil ich keinen seriell-nach-USB-Konverter zur Hand habe - und blind ist mir das dann doch etwas zu riskant...

Viele Grüße,

Richard

[MasterOfGizmo]

Geht! Aber die Syntax ist etwas anders:

Code: Alles auswählen

setenv loadsduimg "fatload mmc 0 0x80200000 uImage"
setenv loadsddtb "fatload mmc 0 0x80F00000 am335x-kno_txt.dtb"
setenv setsdargs "setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 root=/dev/mmcblk0p2 rw rootwait quiet"
setenv bootboth "run reset_wl18xx; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 ubi.mtd=10 root=ubi0:rootfs rootfstype=ubifs rootwait quiet; run loadsduimg loadsddtb setsdargs; fdt addr 0x80F00000; run opp; bootm 0x80200000 - 0x80F00000"
run bootboth

[richard.kunze]

Geht! Aber die Syntax ist etwas anders:

Klasse.

Tut mir leid wegen den Syntax-Fehlern, da hab ich wohl (Unix-)Shell- und U-Boot-Syntax etwas durcheinandergewürfelt...

Viele Grüße,

Richard

[MasterOfGizmo]

Und saveenv ins Flash geht auch so:

Code: Alles auswählen

setenv loadsduimg "fatload mmc 0 0x80200000 uImage"
setenv loadsddtb "fatload mmc 0 0x80F00000 am335x-kno_txt.dtb"
setenv setsdargs "setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 root=/dev/mmcblk0p2 rw rootwait quiet"
setenv bootboth "run reset_wl18xx; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 ubi.mtd=10 root=ubi0:rootfs rootfstype=ubifs rootwait quiet; run loadsduimg loadsddtb setsdargs; fdt addr 0x80F00000; run opp; bootm 0x80200000 - 0x80F00000"
setenv bootcmd "run bootboth"
saveenv
run bootcmd

Ohne SD-Karte bootet mein TXT vom internen Flash wie üblich. Mit SD-Karte bootet er von der.

Für die nicht-Linuxer hier: Das ganze ist damit permanent. Sobald man das einmal gemacht hat braucht man die Konsole nicht mehr. Ab jetzt kann der TXT ohne weiteres Zutun von SD-Karte booten wenn eine eingelegt ist. Ist keine eingelegt bootet er niemal vom internen Flash. Damit kann man völlig gefahrlos auf der SD-Karte komplett neue Linux-Images bauen und testen. Dabei riskiert man nichts, denn man kann die SD-Karte einfach entfernen und alles ist wieder beim alten. Außerdem hat man auf der SD-Karte natürlich viel mehr Platz und kann da alle möglichen zusätzlichen Packages installieren. Zum Beispiel des python für den Kollegen mit dem Scratch ...

Äußerst cool!!

[chehr]

Hallo MOG,
das hört sich sehr gut an, bin gespannt was du damit alles machen wirst.
Gruß
Christian

[MasterOfGizmo]

Das hängt tatsächlich vor allem von Fischertechnik ab und der Frage, ob sie die noch fehlenden Komponenten ebenfalls freigeben.

Was man jetzt schon machen könnte wäre ein Script/Programm/wasauchimmer, das die hier beschriebenen Änderungen am TXT/UBoot so weit automatisch vornimmt, dass auch reine User das können. Das ist eine Voraussetzung dafür, dass man später SD-Karten-Images mit zusätzlichen Funktionen zum Download anbietet. Das könnte der Endbenutzer dann mit einem Tool wie http://www.heise.de/download/image-writ ... ndows.html auf eine SD-Karte schreiben und dann den TXT damit füttern.

Was zum Beispiel recht einfach machbar sein dürfte wäre eine SD-Karte zu bauen, mit der der TXT sich direkt ins Heim-WLAN einwählt und einen lokalen Web-Server startet. Und über den könnte man dann z.B. den TXT per Handy oder Tablet steuern.

[MasterOfGizmo]

Zur Zeit verwende ich einen selbstgebauten Adapter, um an die serielle Komsole auf dem EXT-Verbindern zu kommen.

Ich habe mir aber mal den hier bestellt:
http://www.amazon.de/gp/product/B00YMJVSIS

Ich werde berichten, wie gut das mit dem klappt.

[richard.kunze]

Das hängt tatsächlich vor allem von Fischertechnik ab und der Frage, ob sie die noch fehlenden Komponenten ebenfalls freigeben.

Das wäre zwar äußerst wünschenswert, ist aber eigentlich kein Hindernis für eine Community-Firmware - schließlich sind die fehlenden Komponenten auf jedem TXT eh schon vorhanden.

Es sollte also für einen ersten Schritt eigentlich reichen, das Flash zusätzlich einzubinden (Eintrag in/etc/fstab) und auf der SD-Karte an den passenden Stellen Symlinks auf die Komponenten aus dem Flash zu setzen.

Was man jetzt schon machen könnte wäre ein Script/Programm/wasauchimmer, das die hier beschriebenen Änderungen am TXT/UBoot so weit automatisch vornimmt, dass auch reine User das können.

Script sollte reichen. Auf dem TXT ist fw_setenv mit bei, und mehr braucht es nicht:

Code: Alles auswählen

#!/bin/sh
fw_setenv loadsduimg "fatload mmc 0 0x80200000 uImage"
fw_setenv loadsddtb "fatload mmc 0 0x80F00000 am335x-kno_txt.dtb"
fw_setenv setsdargs "setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 root=/dev/mmcblk0p2 rw rootwait quiet"
fw_setenv bootboth "run reset_wl18xx; mtdparts default; nand read 0x80200000 NAND.uImage; nand read 0x80F00000 NAND.dtb; setenv bootargs fbtft_device.name=txt_ili9341 fbtft_device.fps=10 console=ttyO0,115200 ubi.mtd=10 root=ubi0:rootfs rootfstype=ubifs rootwait quiet; run loadsduimg loadsddtb setsdargs; fdt addr 0x80F00000; run opp; bootm 0x80200000 - 0x80F00000"
fw_setenv bootcmd "run bootboth"

Gegebenenfalls hintendran noch mal mit "fw_printenv" überprüfen ob auch alles sauber im Flash steht und das abschließende "setenv bootcmd" nur ausführen wenn alles passt.

Ich kanns selber grad nicht ausprobieren (mein Software-Bastel-TXT nebst seriell-nach-USB-Konverter kommt erst nächste Woche hier an, und an dem von meinem Sohn mach ich sicherheitshalber nur harmlose Änderungen), deshalb hab ich es noch nicht gleich ins Wiki auf Github gepackt.

Was zum Beispiel recht einfach machbar sein dürfte wäre eine SD-Karte zu bauen, mit der der TXT sich direkt ins Heim-WLAN einwählt

Geht definitiv. Alles nötige dafür ist schon bei der Original-Firmware dabei (dhcpcd und wpa_supplicant), alles was man noch braucht ist ein passendes Startscript. Der Funkchip auf dem TXT hat sogar zwei Radios dabei, d.h. man kann den TXT gleichzeitig ins Heim-WLAN hängen und das "normale" TXT-WLAN aus der Original-Firmware starten.

Einziges Problem ist die etwas geringe WLAN-Reichweite. Zumindest bei mir hat der TXT zwar im Scan so ziemlich alle APs hier in der Gegend gesehen, aber eine stabile Verbindung hat nur bei direktem Sichtkontakt geklappt - eine Leichtbauwand zwischendrin war schon zuviel.

Viele Grüße,

Richard