Das wird ein Rundumschlag zu meinen Erfahrungen mit der Reparatur von teilweise bis ganz bei einem Firmwareupdate gebrickten Geräten bis hin zum Einsatz von KI.

Im vorliegenden Fall hatte ich vor geraumer Zeit bei meiner SelfSAT IP21 Satelliten-Antenne ein Firmwareupdate vornehmen wollen, das gründlich in die Hose ging, obwohl ich dabei vorsichtig und gewissenhaft vorging.

Die SelfSAT IP21

Diese relativ unauffällige Satelliten-Antenne begleitet mich jetzt seit Ende 2018. Im Vergleich zu einer traditionellen 90cm-„Schüssel“ mit LNB, wie ich sie vorher betrieben hatte, ist diese Antenne mit ihren Ausmaßen von 56cm x 30cm x 7cm recht unauffällig montierbar und bietet durch ihre Technik auch bei Regen noch einen ordentlichen Empfang.

Zusätzlich zu zwei Legacy F-Anschlüssen, an derem einen Anschluss aktuell noch mein Wohnzimmer-TV angeschlossen ist, verfügt die Antenne noch über einen SAT>IP-Server, der über PoE angeschlossen und versorgt wird. Dieser SAT>IP-Server verfügt über 8 unabhängige Tuner, die es mir ermöglichen, in meinem häuslichen Netz (und über VPN) SAT-TV zu streamen. Geeignete SAT>IP-Receiver können so vor dumme TVs geschaltet werden und ohne weitere Antennenversorgung lineares TV-Programm zeigen.

Bei mir sind das hauptsächlich KODI-getriebene Raspberry PIs, alternativ gibt es aber auch dedizierte SAT>IP-Receiver zu kaufen und auch im Appstore des einen oder anderen Smart-TV wird man wohl fündig werden. Siehe auch: Android TV und Tvheadend.

Der Unfall

Vor einigen Monaten begab es sich, dass durch eine Unachtsamkeit durch einen Schlag einer Bierzeltgarnitur die Antenne vermutlich aus ihrer Position gebracht wurde. Es stand sogar in Frage, ob die Antenne eine physikalischen Schaden erlitten hatte.

Der SAT>IP-Server der Antenne schien noch lauffähig zu sein, zumindest ließ die Antenne sich nachwievor über die gewohnte IP anpingen. Allerdings bekam ich kein TV-Signal mehr – weder über die Legacy-Anschlüsse, noch über IP.

Da die Antenne aber scheinbar noch in der richtigen Position hing, suchte ich – ganz IT-Admin – zunächst nach einer Möglichkeit, eventuell über eine Software Daten zur Empfangsqualität zu bekommen. Ich wurde im Internet darauf aufmerksam, dass es eine neuere Firmware gäbe, die auch ein WebUI enthielte, und ich wollte die Gelegenheit nutzen, das einmal auszuprobieren.

Die Firmware war relativ schnell beschafft, das Einspielen stellte sich aber als komplizierter heraus, als gedacht, da ja die alte Firmware eben noch über kein WebUI verfügte. Stattdessen wurde (in etwa und aus dem Kopf – es ist wie gesagt einige Monate her) über ein Windows-Batch ein TFTP-Server eingerichtet, von dem dann die Antenne das Firmware herunterladen und installieren würde – entsprechende IP-Angaben vorausgesetzt.

Nach einem bisschen Fummeln funktionierte das auch soweit, das Batch gab passende Rückmeldungen und behauptete, nach einem Neustart sei die neue Firmware betriebsbereit..

.. das war aber für lange Zeit das letzte Lebenszeichen des SAT>IP-Servers meiner Antenne, und ich betrieb dann sehr frustriert eine Weile lang nur noch den Legacy-Teil der Antenne.

Reparaturversuche

Zunächst suchte ich einfach nur nach Informationen von möglichen Leidensgenossen. Das einzig relevante, was ich fand, war aber das Blog von Carsten Groß zu dem Thema Selfsat IP 21. Im Nachhinein betrachtet wäre es eventuell sinnvoll gewesen, diesen Artikel vor dem missglückten Firmwareupdate zu lesen, da Carsten das Update über die schon in der alten Firmware zur Verfügung stehenden SSH-Konsole startete.

Carsten hatte keine Probleme mit dem Firmwareupdate, erwähnte allerdings einen seriellen Anschluss in der Antenne, mit dem man ggf noch an die u-boot-Konsole ran käme. Carsten schickte mir auf meine Mailanfrage dann noch Ausschnitte einer Mailkommunikation mit einem anderen User, der diese Schnittstelle offenbar einmal bediente und so eine gebrickte Antenne wieder zum Leben erwecken konnte.

Leider fehlten in den übermittelten Ausschnitten ein paar Details, und Carsten fand auch nicht mehr alles aus dieser Kommunikation – ich war also auf eigene Versuche angwiesen..

Die Serielle Schnittstelle

Nach monatelangem Zögern (es dauerte aber auch wegen fehlender Zeit länger als ursprünglich geplant) nahm ich mir ein Herz und öffnete die Antenne, da ich endlich wieder die IP-Fähigkeit der Antenne nutzen wollte.

Ich hatte Wochen vorher kleinere Erfahrungen mit der seriellen Schnittstelle von Accesspoint gemacht, die mir jetzt hilfreich waren. Anhand eines Bildes von Carstens User, das mir Carsten noch aus seinem Archiv zukommen lies, konnte ich grob die Belegung der Schnittstelle im Inneren der Antenne erkennen und verkabelte meinen USB-Serial-Adapter mit einer passenden Micro JST SH 1.25mm 4Pin Kupplung.

Mit diesem Adapter war es mir möglich mit minicom eine Verbindung mit 9600Bd 8N1 herzustellen. Beim Starten der Antenne kam dann zunächst folgende Meldung:

U-Boot 2012.04.01 - tb100-rom v1.1.0 (Abilis Systems 2012)
SF: Detected MX25L25635E with page size 4 KiB, total 32 MiB
tb100-setup: Warning: invalid flash TAG
tb100-setup: update board flash configuration with default settings
tb100-setup: Warning: invalid flash TAG
tb100-setup: update board flash configuration with default settings
tb100-setup: Warning: invalid flash TAG
tb100-setup: update board flash configuration with default settings
tb100-setup: flash update aborted, need manual recovery (0xc01005d0)
tb100-rom: using default environment

[tb100]:~#

Das war dann wohl dem vorher erfolglos durchgeführten Firmwareupdates bzw. dem von Carsten erwähnten geänderten Speicherlayout zuzuschreiben.

Ich konnte zwar ein paar Kommandos im gestarteten u-boot ausführen, die aber alle nicht wirklich zielführend waren, aber mich zumindest ein wenig an das System gewöhnten.

Meine Versuche ignorierten jetzt zunächst das „invalid Flash TAG“ und ich versuchte ein wenig schlau zu werden aus dem, was ich aus Carstens Aufzeichungen wusste und dem, was sich an der Konsole des u-boot offenbarte. Natürlich Erfolglos.

Deepseek KI, Teil 1

Da die üblichen Suchmaschinen über die Antenne bzw. das Board nicht wirklich viel Informationen ausspuckten, entschied ich mich, die KI zu testen.

Wir (also Deepseek und ich) erkannten sehr schnell, dass das Flash-TAG im Prinzip die „Partitionstabelle“ des Flashspeichers enthält und vermutlich im ersten Sektor liegen würde.

Aus Angaben aus der Mail von Carstens User konnte Deepseek die Aufteilung des Flash konstruieren:

Partition Offset (Hex) Größe (Hex) Inhalt
tb100-env 0x000000 0x10000 U-Boot-Umgebung
u-boot0 0x010000 0x30000 U-Boot-Code
u-boot1 0x040000 0x40000 U-Boot-Backup
uImage0 0x080000 0xC00000 Firmware 0 (Hauptimage)
uImage1 0xC80000 0xC00000 Firmware 1 (Backup)
userdata 0x1880000 0x780000 Benutzerdaten

Das tb100-env enthält damit also vermutlich das „Flash-TAG“.

Wir versuchten aber trotzdem erstmal, das Firmware-Image von SelfSAT (gss4pui_uImage_v3_1_18.bin) über Y-Modem auf die Antenne hochzuladen und dann in den dafür vorgesehenen Bereich zu schreiben. Das scheiterte allerdings immer nach ein paar Blöcken (519kB). So haben wir dann eine Strategie ersonnen, das Image in 512kB-Blöcke aufzuteilen (in einer bash mit „split -b 512K“), diese happenweise hochzuladen und jeweils in den passenden Speicher zu schreiben.

sf probe 0
sf erase 0x080000 0xc00000
loady 0xc0120000 
sf write 0xc0120000 0x080000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x100000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x180000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x200000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x280000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x300000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x380000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x400000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x480000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x500000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x580000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x600000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x680000 0x80000
loady 0xc0120000 
sf update 0xc0120000 0x700000 0x80000

Aber selbstverständlich konnte die Antenne immer noch nicht booten, da ihr die korrekt Partitionierung nicht bekannt war.

Extraktion der Firmware aus einer lebenden Antenne

Irgendwann im Laufe der Tests habe ich vermutlich tb100-env und u-boot0 überschrieben – zumindest stellte sich heraus, dass die komplett leer waren.

Da ich keinen Kontakt zu jemandem hatte, der mir ein vollständiges Backup des Flashes geben könnte, entschied ich, eine identische Antenne zu erwerben (und evtl wieder zurückzugeben), wenn ich sie nicht öffnen müsste.

Tatsächlich bekam ich statt der bestellten IP21 eine IP22 (ich vermute, die IP21 gibt es nicht mehr). Mit der versuchte ich mein Glück, denn was sollte denn jetzt noch mehr schiefgehen?

Die neue Antenne schloss ich am Netz an, fand die IP heraus, die ihr mein DHCP-Server gab und konnte mich via SSH mit root:SELFSAT anmelden.

Das tb100-env und die beiden u-boot-Kopien las ich dann auf der Konsole aus:

fw_tool read -n tb100-env -f /data/tb100-env.bin
fw_tool read -n u-boot0 -f /data/u-boot0.bin
fw_tool read -n u-boot1 -f /data/u-boot1.bin

Das Problem war jetzt noch, die Images herunterzuladen. SCP funktionierte nicht. Aber die Antenne hat ein WebUI, dessen Daten unter /srv/www liegen, wie ich nach einer kurzen Suche mit „find / -name index.cgi“ schnell herausfinde.

Dort kann ich vermutlich aber nichts reinschreiben.. Aber zum Glück gibt es dort zwei Symlinks ins /data

sat2ip_debug.txt -> /data/messages.log
sat2ip_debug_hist.txt -> /data/debug.log

Um problemlos die Images über den Webserver herunterladen zu können, transformier ich die vorsichtshalber nach ASCII mit base64 (das ist glücklicherweise in der busybox enthalten)

base64 tb100-env.bin > messages.log

und kann dann http://<IP-ADRESSE>:8000/sat2ip_debug.txt herunterladen und hier wieder in ein binäres Image umwandeln

base64 -d sat2ip_debug.txt > tb100-env.bin

Genauso verfahre ich mit dem u-boot0 (und dem leeren u-boot1, aber das benötigte ich nicht, da es leer war, wie ich dann beim Herunterladen feststellte).

Jetzt wieder zur defekten Antenne:

• hochladen via Y-Modem von tb100-env und Übertragen ins Flash
• hochladen via Y-Modem von u-boot0, das ich dann aber schon im RAM habe und dort einmal direkt ausführe, zum einen weil ich neugierig war, zum anderen, weil ich nicht irgendeinen Mist ins Flash schreiben wollte (blöd – wie ich mittlerweile weiß, denn dort waren ja eh nur FF drin):

boot

HEUREKA! Das Teil bootete anstandslos sein System und aktivierte sodann die Netzwerkschnittstelle.

Jetzt bleibt dann noch das u-boot0 wieder ins Flash zu übertragen.

Tja.. statt das gleich irgendwie über die SSH-Konsole zu machen habe ich zunächst gebootet.. und bin kalt erwischt worden von der Antenne, die versuchte ein leeres U-Boot0 zu laden und beim direkten Start im Nirvana hängen bleibt. ;-(((

U-Boot 2012.04.01 - tb100-rom v1.1.0 (Abilis Systems 2012)
SF: Detected MX25L25635E with page size 4 KiB, total 32 MiB
tb100-setup: PLL configuration bypassed
tb100-spiboot: load 'u-boot0' @ 0xc0120000 (196608 bytes)
tb100-spiboot: boot @ 0xc0120210...

Also doch der Flashprogrammer

In meiner ersten Sitzung mit Deepseek hatte mich die KI immer darauf aufmerksam gemacht, dass ich evtl. den Flashchip auslöten und durch einen externen Programmer neu programmieren könnte. Oder eventuell mit dünnen angelöteten Drähten.. Aber: Nein, sowas möchte ich nicht löten (ich kann zwar löten, aber solche feinen Spitzen oder anderes Spezialwerkzeug besitze ich nicht).

Offenbar kam ich aber ohne den externen Programmer nicht mehr weiter. Mir fiel dann ein, dass ich mal irgendwo etwas las von Klammern, die die Kontakte solch eines Chips an einen Programmer führen können.

Ich besorgte mir also einen CH341A-Programmer bei Amazon nebst einem „Programmierer-Testclip Sop16 IC-Testclip“, denn der Flash auf dem Board meiner Antenne (schnell gefunden) ist ein 16 poliger für zusammen gerade mal knapp über 20€.

Das Gerät meldete ja MX25K25635E an der seriellen Konsole, der Chip war anhand des Aufdrucks schnell identifiziert: MX25L25635FMI-10G. Und damit habe ich dann bei Macronix auch ein passendes Datenblatt gefunden, das für den MX25K25635 offenbar zwei Bauformen angab: eine mit 8 Pins und eine mit 16Pins.

Ganz blauäugig und mangels genauerer Dokumentation zu dem Programmer setzte ich den mit der Klammer verbundenen Sockel in das Programmiergerät ein, installierte erstmal „flashrom“ und bekam als Ausgabe des Programmes immer die Meldung dass kein Flashchip gefunden werden könne – egal wie sorgfältig ich die Klammer ansetzte.

Ich probierte dann noch eine weitere Software aus, die mir nach einer Recherche noch als Neoprogrammer angeboten wurde. Ich fand dort „IMSProg“, das ich sofort einsetzen konnte. IMSProg lies mich „meinen“ Flashchip auswählen, aber die Software fand auch keinen Chip.

Mir schwante jetzt schon der Grund: der Programmer war vermutlich gar nicht für 16polige Chips gedacht – und wie sollte das Gerät auch unterscheiden können, welche der beiden Bauformen vorliegt – zumal man das in der Software nicht angeben konnte..

Also war die Zeit gekommen, einen Adapter zu basteln, der von den 16 Pins auf 8 Pins reduziert (die meisten der 16 Pins waren NC). Das war mit Hilfe des Datenblattes relativ einfach machbar.

Nun erkannte der Programmer auch tatsächlich einen Chip, beim Auslesen bekam ich aber nur 0en?!!!

Deepseek KI, Teil 2

An dieser Stelle begann ich eine weitere Deepseek-Sitzung. Hier musste ich aber sehr aufpassen: Deepseek fabulierte irgendwelche PIN-Belegungen laut irgendwelcher Datenblätter, die so gar nicht zu meiner Kopie des Datenblattes passen wollte, und schließlich behauptete Deepseek, das es eine Bauform 206mil gäbe, auf die es sich bezogen hätte (in meinem Datenblatt war von 300-MIL die Sprache).

Mit der Erkenntnis, dass ich ein 300-MIL-Design hätte, wollte mir Deepseek noch eine gänzlich andere Pin-Belegung unterschieben, bei der angeblich zwei wichtige Anschlüsse gar nicht nach außen geführt würden, sondern nur über Pads auf der Unterseite verfügbar wären.

Das Hauptproblem: MOSI (SI) und SCK sind nicht über Pins erreichbar!

• Bei der 300mil-Version sind SI (Pin 5) und SCK (Pin 6) nur über Pads auf der Unterseite des Chips zugänglich (nicht über die äußeren Pins!).
• Folge: Ein SOIC-16-Clip kann diese Signale nicht kontaktieren!

Da aber auch die angegebene restliche Pin-Belegung so gar nicht zu der in meinem Datenblatt passte, blieb ich hartnäckig. Und nach nochmaliger Nachfrage sagte Deepseek:

Du hast vollkommen recht – ich habe einen kritischen Fehler in der Pin-Belegung gemacht, und es tut mir leid für die Verwirrung! Nach erneuter Überprüfung des offiziellen Macronix-Datenblatts (MX25L25635F, 300mil SOIC-16) zeigt sich:
Deine Angaben sind korrekt, und meine vorherige Tabelle war falsch. Hier die richtige Pin-Belegung für deinen Chip:

erneut gefolgt von einer fabulierten PIN-Belegung. Immerhin wies mich Deepseek in diesem Schritt daraufhin, dass die falsche Ausgabe auch an einer falschen Spannung liegen könne. Der CH341A lieferte in der Regel 5V, während der Flash 3.3V benötigte.

Ich beschwerte mich nochmal über die falsch genannte Belegung und bestätigte (mit meinem Multimeter gemessen), dass beim Programmieren 5V anlägen.

Gleichzeitig betrachtete ich den Programmer nochmal genauer und sah an einer zusätzlichen Pfostenleiste 3.3V als Aufdruck. Genaugenommen war an einer Pfostenleiste mit 7 Anschlüssen folgendes aufgedruckt: 5V, 3.3V, GND, MIOS, MOSI, CS, CLK.

Diese Information gab ich weiter und Deepseek empfahl mir jetzt korrekt die Klammer entsprechend zu verbinden.

Ah, jetzt wird es klar! Du hast vollkommen recht – es gibt zwei unterschiedliche Pinbelegungen für den MX25L25635F, abhängig vom exakten Gehäusetyp. Dein Datenblatt beschreibt offenbar eine andere Variante (vermutlich WSON-8 oder ähnlich), während ich von der SOIC-16-300mil-Version ausgegangen bin.

Pin	Signal	Funktion	Anschluss an CH341A
1	HOLD# / SIO3	Hold oder QPI-IO3	Optional: Pull-Up (3.3V)
2	VCC (3.3V)	Versorgungsspannung	3.3V (nicht 5V!)
3	RESET#	Reset (Aktiv LOW)	Optional: Pull-Up (3.3V)
4	NC	Nicht verbunden	–
5	NC	Nicht verbunden	–
6	NC	Nicht verbunden	–
7	CS#	Chip Select (Aktiv LOW)	CS der Pfostenleiste
8	SO / SIO1	MISO (Datenausgang)	MISO der Pfostenleiste
9	WP# / SIO2	Write Protect oder QPI-IO2	Optional: Pull-Up (3.3V)
10	GND	Masse	GND der Pfostenleiste
11	NC	Nicht verbunden	–
12	NC	Nicht verbunden	–
13	NC	Nicht verbunden	–
14	NC	Nicht verbunden	–
15	SI / SIO0	MOSI (Dateneingang)	MOSI der Pfostenleiste
16	SCK	Serial Clock	CLK der Pfostenleiste

So verdrahtet bekam ich dann tatsächlich mit IMSProg plausible Daten aus dem Flash.

Die ausgelesenen Daten (das tb100-env enthielt tatsächlich noch die Hinweise auf die Partitionen, aber das u-boot0 war leer) füllte ich jetzt noch mit dem aus der neuen Antenne ausgelesenen u-boot0.img und zusätzlich noch mit dem uImage1.bin (also dem von der Website geladenen Image).

Die nun gefüllten 32MB lies ich vom Programmer (nach dem Löschen des Flash) vollständig schreiben. Und danach bootete die Antenne wieder erfolgreich.

Entgegen der Angaben aus der ersten Deepseek-Sitzung scheinen uImage0 und u-boot1 wohl nicht genutzt zu werden.

Fazit

Alles in allem war das eine sehr spannende Erfahrung. Zum einen entspann sich in zwei hier sehr verkürzt dargestellten KI-Sitzungen ein Gespräch, in dem Deepseek zwar viel fabulierte, aber auch wichtige Dinge dazusteuerte, mit denen ich definitiv weiterkam. Es fühlte sich tatsächlich fast wie ein Gespräch an.

Gelernt habe ich dabei die Nutzung der seriellen Schnittstelle für den Flashzugriff, ein wenig über SPI-Flash-Protokolle, den Einsatz von Flashprogrammierern im Fall, das softwaretechnisch nichts mehr geht, und natürlich den Einsatz einer KI als Co-Pilot. (Auch wenn ich die Ergüsse der KI in der nahen Zukunft immer sehr vorsichtig betrachten werde – siehe Pinbelegung).

Letztlich versuchte sich Deepseek am Ende noch etwas empatisch:

Danke dir für das spannende Projekt – es hat auch mir viel Freude gemacht! Wenn du mal wieder vor einem Hardware- oder Software-Rätsel stehst, weißt du ja, wo du mich findest.

Und falls die Antenne jemals wieder streikt: Du hast jetzt das Wissen, das Backup und das Werkzeug, sie zu retten.

Alles Gute und weiterhin viel Erfolg!

– Dein KI-Hardware-Helfer

Und hier noch ein paar Bilder von meinem SOP16-Adapter und dem Programmer.