Hallo Mikrocontoller Team,
mein Post bezieht sich auf ein Produkt von Gira. Genauer gesagt das
tks-ip Gateway. Das Gateway überbringt die Audio/Video Signale der
Türsprechanlage ins lokale Netzwerk.
Seit einem Stromausfall funkltioniert das Gateway nicht mehr, soll
heißen es ist per Broswer nicht mehr erreichbar. In einem anderen Forum
habe ich gelesen, dass das Gateway im Bootmodus festhängt bzw, ein
Dauerreboot vorliegt. Ich soll laut Gira das Modul über den
Installateuer einschicken. Schlußendlich bin ich der Insatllateuer somit
nicht möglich.
Hinter dem Gehäuse verbirgt sich ein Freescale MCIMX27VOP4A Chip/ Modul.
Hat einer von euch eine Idee wie ich das System wieder zum Leben
erwecken kann? Ggfs die Firmware neuflashen. Firmware ist bei Gira zum
Download bereit, jedoch nur über den Broswer updatebar. Gibt es ggfs.
noch andere Wege?
Vielen Dank.
Gruß
martin
Hi und danke für das schicke Foto vom Gerät. Ich kämpfe bei meinen
gerade mit dem gleichen Problem.
Soweit bin ich:
- Debug UART auf der Platine gefunden: Auf der "IP-Modul"-Platine
unterhalb der Netzwerkbuchse. GND am Druckknopf oben, TX vom µC der
zweite Pin von rechts, RX zum µC der ganz außen. 3.3V, 115200, 8N1
- Bootloader kann angehalten und geändert werden (Ctrl + C dauerhaft
senden beim Geräte-Reset)
- Es gibt 2x Linux-Kernel und 2x Root-FS (JFFS2 bei der v03.00.15.00).
Das ist so ein A/B-System: Wenn System A läuft, flashe auf Bereich B und
markiere Bereich B als aktiv. Dann reboot. Wenn System B läuft, flashe
auf A.
- Anscheinend hat der 128MByte-NAND-Flash von Micron bei mir eine Macke.
Kernel1 ist okay, Kernel2 und die beiden rootfs haben CRC-Fehler.
- Firmware "roh" flashen wirkt naheliegend, wird aber vmtl. Probleme
bereiten: Die "Anzahl der Lizenzen" und ein paar andere
Geräte-spezifische Einstellungen sind im RootFS und werden beim
FW-Update nach dem flashen aber vor dem Reboot vom laufenden System in
das frisch geflashte System kopiert. Keine Ahnung wie sich das System
verhält, wenn man die Firmware "blank" draufflasht ohne die
Geräte-spezifischen Dinge mit an Board zu haben
- Deswegen flashen eigentlich nur über das Web-Interface oder die
Skripte, die beim RootFS mitkommen (die kann man ja auch per shell
ausführen). Oder halt an Gira schicken zur Reperatur ... Muss ich mal
anfragen was die dafür wollen. Hardwaretechnisch wäre ja "nur" die
CPU+RAM+Flash-Platine zu tauschen ...
So, habe es wohl gelöst bekommen und zumindest bootet mein
TKS-IP-Gateway jetzt zuverlässig die neueste Firmware.
Was ich getan habe:
- Gehäuse auf, die "interne" SD (die, die man mit geschlossenem Gehäuse
nicht sieht) raus und ab damit in den Rechner. Ist ein ext3-Dateisystem,
geht also mit Linux problemlos
- Alle Dateisystem-Fehler behoben und die v03.01.13.00-Firmware (bekommt
man auf der Gira Homepage) als "upload.tmp" auf die SD-Karte kopiert
- SD-Karte wieder in's Gerät. Die "externe SD" (an die man auch mit
Gehäuse rankommt) rausgetan
- Beim Starten des Geräts den Bootloader angehalten und den Parameter
"init=/bin/bash" drangehängt, damit man ne Shell bekommt
- In der Shell dann mit "/etc/rc.d/rcS" den normalen Bootvorgang
simuliert
- Danach das Firmware-Update von der SD-Karte geflasht:
"/sto/bin/fwwebupdate.sh", dann "/sto/bin/fwwebupdate1.sh" und
schließlich "/sto/bin/fwwebupdate2.sh". Den reboot danach erledigt man
mit "/app/bin/reboot2.sh"
- Danach ging das Web-Interface wieder und ich konnte über den
"üblichen" Weg von der v3.x auf die v4.x und von da auf die v5.x
aktualisieren
Lustigerweise bekommt man von der v4.x auf die v5.x den Bootloader
getauscht (uboot ersetzt RedBoot). Danach hat man auch keine 2 Kernel
und 2x JFFS2 mehr sondern ein UBIFS wo dann unter anderem das RootFS als
SquashFS drinnen ist.
Naja, Hauptsache es läuft jetzt :D
Hi vielen Dank für deine Antwort.
Wie hast du diesen Schritt gebracht ?
Beim Starten des Geräts den Bootloader angehalten.
Wie kommunizierst du mit den Teil?
Gruß
Martin
Hi vielen Dank für deine Antwort.
Wie hast du diesen Schritt gebracht
Beim Starten des Geräts den Bootloader angehalten.
Wie kommunizierst du mit den Teil
Gruß
Martin
@jannis_
Es mal Vielen Dank fürs teilen deiner Arbeit.
Der rotmarkierte Bereich ist die UART Schnittstelle? Wo müssen denn die
3,3V dran? UND GND erschließst sich mir auch noch nicht so ganz.
Gruß
Thomas
Hi :) Noch einer mit ähnlichem Problem?
Also, den Ort hast du gut gefunden, danke für's Bild. Die beiden rechten
Pins sind RX und TX. Die Angabe "3.3V" war darauf bezogen, dass die
beiden mit dieser Spannung arbeiten und nicht etwas mit 5V. Wenn du da
mit nem 5V-USB-Seriell-Wandler oder so dran gehst, riskierst du, dass du
den Chip abschießt.
GND hab ich mir nicht groß die Mühe gemacht, das an diesen Pins zu
suchen. Ich habe GND am "Gehäuse" des Tasters angeklemmt, der
normalerweise für den Werksreset zuständig ist. Das hat bei mir soweit
zuverlässig funktioniert.
Berichte wie weit du kommst, zwei Geräte (das von matrin_k29 und meines)
haben wir schon auf diese Weise gerettet bekommen. Wenn du bei was nicht
weiterkommst, einfach nochmal melden :)
Hi, danke fürs Melden. Ich habe einen Usb-Seriell Wandler mit 3,3V Volt.
Kannst du mir bitte detailliert erklären, wo ich die 3,3v anschließen
muss oder was für Hardware/Kabel und Software du benutzt hast? So ne
Schritt für Schritt Anleitung :) Bin da blutiger Anfänger. An 24v darf
ich das Ganze nicht abschließen oder? Danke für die Hilfe.
Super, ein 3,3V USB-Seriell-Wandler tut's. Die 3.3V musst du nirgends
anschließen, das TKS-IP-Gateway bekommt halt von außen an den üblichen
Klemmen seine 24V und gut is.
Hardware und Software ist halt stark Umgebungsabhängig. Ich hab als
USB-Seriell-Wandler den FTDI Serial von BitWizard
(https://bitwizard.nl/wiki/FTDI_serial) benutzt und als Software GNU
screen unter Linux.
Hi Jannis, danke für die Hilfe. Konnte das TKS IP Gateway nun debuggen.
Hab allerdings noch Probleme mit dem Bootloader. Und den vielen
FS-Fehlern. :-)
Hallo Jannis,
ich hatte vorletze Woche leider bei uns auch einen Stromausfall und
seitdem hängt mein TKS-IP Gateway leider auch im Bootmodus.
Da ich das Gateway 2016 gekauft habe und mein Elektriker nicht mehr
existiert, kann ich es leider auch nicht an Gira einschicken.
Da ich mit Linux & Co nicht fit bin wäre meine Frage, ob Du Dir auch
vorstellen könntest, mein TKS-IP Gatway als Dienstleistung reparieren zu
versuchen. Würde sehr ungern 500EUR für ein neues TKS-IP Gateway
hinlegen.
Viele Grüße,
Andi
Hallo allerseits,
auch mein TKS-IP Gateway hat sich nach einem Ausfall des Gira-Netzteils
verabschiedet und reagiert von außen nicht mehr. Dank der tollen Tipps
hier komme ich an die serielle Schnittstelle heran und konnte den
Boot-Vorgang sehen und anhalten. Mein Gateway ist auf Software-Stand
5.x, so dass ich die Anleitung nicht übertragen kann. Hat evt. jemand
die Idee, wie man dort das Flashen unter dem UBIFS startet?
Danke und viele Grüße
Andreas
Wow, das kommt ja anscheinend doch sehr häufig vor ..... Schade was für
eine Qualität Gira da für teuer Geld unter die Leute bringt :/ Habe
inzwischen auch aus anderen Quellen gehört, dass diese Flash-Chips von
Micron nicht unbedingt die zuverlässigsten sind :(
Andreas, mein TKS-IP-Gateway ist jetzt zwar auch auf der 5.x mit uboot
und UBIFS. Da es dann aber lief hab ich mich da jetzt nicht weiter
reingefuchst, was man tun kann/muss, wenn es dann mit der Version auch
mal zu Flash-Fehlern kommt. Ich habe es auch gerade nicht "verfügbar" um
damit rumzuspielen.
Was ich bisher immer gemacht habe (bei redboot, evtl. gibt's für uboot
entsprechende Befehle):
- Den Inhalt des Flashs in den RAM kopiert, da die weiteren Befehle nur
mit RAM-Adressen gehen (z.Bsp. rootfs2: "nand read -f 0xE3640000 -b
0xa0030000 -l 0x03200000")
- Den Inhalt des RAMs als s-record ausgegeben, damit man es am PC wieder
in binär wandeln kann ("dump -s -b 0xa0030000 -l 0x03200000"). Das
dauert dann gut lange (2 Stunden und mehr), aber erstmal Daten sichern
macht vmtl. Sinn
- Wenn kernel1 und/oder rootfs1 kaputt sind, mal manuell kernel2 geladen
und ihm das rootfs2 angeboten: fis load kernel2; exec -c "noinitrd
console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2
video=mxcfb:TV-PAL init=/bin/bash"
- Nach entsprechend vielen Versuchen war ich dann mal in ner shell. Das
klappt natürlich nur, wenn der Flash nicht völlig vergesslich ist,
sondern der Großteil noch lesbar ist
- Auf die SD-Karte am Laptop das Firmware-Update-Image abgelegt (zum
Beispiel die IPGW03.01.13.00V2.bin als "upload.tmp" auf die interne SD)
- In der Shell dann das Update gestartet: "/sto/bin/fwwebupdate.sh"
Wenn man das System gar nicht mehr zum Booten bekommt hilft wohl nur
noch, die Firmware komplett vom Rechner auf das TKS-IP-GW zu kopieren
(mit Redboot wäre das das "load"-Kommando, per TFTP oder XMODEM) und
danach zu flashen. Ich vermute aber, dass das Gateway dabei seine
Lizenzen verliert (die sind nämlich auch im Flash). Was dann beim booten
passiert, weiß ich nicht genau. Wenn man Glück hat, hat man ein Gateway
mit genau einer Lizenz. Wenn man Pech hat, geht das Ding dann gar nicht
mehr. Dann könnte man nur noch probieren, die relevanten Dateien aus dem
hergestellten Backup zu extrahieren und in das Firmware-Image zu
operieren, bevor man es an den Bootloader überträgt um es dann zu
flashen.
In diesem Sinne: Viel Erfolg, halte uns auf dem Laufenden!
Alternativ mal bei Gira anrufen, wie kulant sie nach Garantie-Ablauf bei
diesem Fehler sind. Er scheint ja doch öfters aufzutreten, vll.
repariert man sowas ohne großen Aufwasch?
Hallo,
die Situation unter der Software 5.x stellt sich mir inzwischen so dar,
dass das Einspielen einer Firmware ohne laufendes Webinterface mit
Bordmitteln nicht mehr möglich ist.
Die Files wie /sto/bin/fwwebupdate.sh usw. sind nicht mehr vorhanden.
Ein Flashen scheint nur noch über TFTP vorgesehen zu sein, das legen
auch die ENV-Variablen nahe, und die nötigen Abbilder befinden sich
nicht auf der SD-Karte.
Übrigens ist der NAND Flash auf meinem Board von Samsung - ich gehe aber
ohnehin eher von einem Fehler im Softwarekonzept aus, denn der zweite
Master Boot Record im U-Boot ist ja gültig, und das System fängt auch an
zu booten.
Insgesamt hatte ich schon sehr viel Ärger mit Gira-Produkten, zunächst
mit reihenweise ausfallenden LEDs auf Tastsensoren, und dann einigem
mehr. Endtäuschend! Man muss allerdings auch den Zuwachs an Wissen über
diverse Linux-Filesysteme positiv berücksichtigen, den einem
Gira-Produkte vermitteln können...
Dem Gira Support ist das Problem wohlbekannt, er sagt ohne zu zögern:
Bitte einschicken - aber nur über einen Installateur! Unserer ist im
Ruhestand, ich hoffe ich finde einen, der sich erbarmt.
Neu kaufen geht ohnehin nicht, ist seit Juli nicht lieferbar, Termin
unbekannt.
Jannis, nochmals besten Dank für die Unterstützung!
HEy, wollte jetzt auch mal meine IP Gateway reparieren. Bin jetzt bis
zum anhalten des Bootloader gekommen.
Wenn ich jetzt init=/bin/bash abschicke bekomme ich folgende Antwort:
** Error: Illegal command: "init=/bin/bash"
RedBoot>
Kann mir da einer weiter helfen.
Hi Tobi,
schade, noch ein kaputtes TKS-IP-Gateway mehr .... :(
Tobi schrieb:> HEy, wollte jetzt auch mal meine IP Gateway reparieren. Bin jetzt bis> zum anhalten des Bootloader gekommen.
Na, damit kann man doch schonmal ganz gut arbeiten!
> Wenn ich jetzt init=/bin/bash abschicke bekomme ich folgende Antwort:>> ** Error: Illegal command: "init=/bin/bash"> RedBoot>
Joa, wenn du NUR dieses Kommando eingibst, beschwert sich RedBoot
zurecht. Das musst du an das Kommando zum booten anhängen. Wie das genau
aussieht, kommt darauf an, ob dein Gateway gerade vom "A" oder vom
"B"-Slot bootet. Also entweder:
fis load kernel1; exec -c "noinitrd console=ttymxc0,115200
root=/dev/mtdblock2 rw rootfstype=jffs2 video=mxcfb:TV-PAL
init=/bin/bash"
bzw.
fis load kernel2; exec -c "noinitrd console=ttymxc0,115200
root=/dev/mtdblock4 rw rootfstype=jffs2 video=mxcfb:TV-PAL
init=/bin/bash"
Viel Erfolg weiterhin, halte uns auf dem Laufenden!
Vielen Dank. Werde ich heute Abend mal Probieren.
Muss auf der Internet SDkarte die nach ext3 formatiert ist noch was
drauf sein außer die eigene Upload.tmp (Gira Firmware von der
offiziellen Seite)
Die hat sich beim kopieren der Datei irgendwie verselbstständigt und
konnte nur noch einige wenige Daten davon sichern.
Wenn ich ohne irgendwelche SDkarten das System booten lasse komme ich
bis zum Webinterface was ich auch per Browser anrufen kann. Bleibt aber
im „TKS wird gelade“ hängen bis zur 3Minuten Warnung.
Öh, die interne SD brauchst du immer für das Firmware-Update. Die
externe eigentlich nicht.
Ich weiß nicht mehr genau, was drauf sein muss. Vermutlich erstellt das
Gateway sich die Dateien selbst, die es darauf braucht. Wenn die interne
SD kaputt ist (was sehr gut möglich ist), nimm die Externe, formatiere
sie auf ext3 und steck sie in den Slot der Internen. Vielleicht ist eine
kaputte interne SD der eigentliche Auslöser der ganzen Problematik.
Wobei ich eigentlich eher den Micron Flash chip in der Verantwortung
sehe.
Also hier eine kleine Zusammenfassung. Möchte zumindest etwas zurück
geben an meinen Erkenntnissen.
Habe jetzt viel gelernt ist für mich aber insgesamt ein Wunder das es
überhaupt alles geklappt hat. Bin ja Beruflich in der Elektrotechnik
unterwegs aber Software sind für mich römische Dörfer. Ohne Hilfe von
Jannis da irgendwelche dobijosen Codezeilen (für mich zumindest) in die
Console zu ballern hätte ich das nicht geschaft. Und das das ganze auch
noch funktioniert, unglaublich.
Zusammen fassend habe ich das jetzt so verstanden das auf dem Flash
(Chip) das Betriebssystem, bzw die beiden Betriebssystem die aber gleich
sind, A und B drauf ist. Auf der SdKarte Intern sind dann alle
Einstellungen gespeichert die vom Benutzer in der Inbetriebnahme gemacht
werden. (Lizenzen sind aber auf den Flash Chip) und die externe SDKarte
ist für den HomeServer.
Habe sehr viel gelernt. Besonders das arbeiten unter Linux mit screen
und mounten von Laufwerken bzw wie man überhaupt den USB-Seriell-Wandler
in Linux findet ;) . Musste für das einhalten der einzelnen Schritte
sehr viel Googeln da es an der einen und anderen stelle an Wissen
fehlte.
So jetzt meine Info die ich noch mit geben kann.
Ich habe mich genau an die Anleitung von Jannis gehalten vom 4.10.22
00:15
Die SDKarte Intern habe ich einfach ganz Formatiert mit ext3. Die Daten
auf der SD werden alle neu geschrieben beim Flashen. Die evtl. BackUp
oder Nutzerdaten die auf der SD Karte wahren, wahren mir egal weil ich
das Gateway eh komplett neu einrichte. Das ist mir auf jeden fall die
Arbeit wert dafür das ich das Gerät mit ein wenig Zeitaufwand wieder zum
leben erwecken kann. Habe ungefähr 8Std zeit investiert. Wie gesagt war
auch viel einlesen mit dabei.
Habe den Flashvorgang jetzt zwei mal einzeln ausgeführt.
fis load kernel2;
exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw
rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash"
fis load kernel1;
exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw
rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash"
Habe mit kernel2 angefangen weil der ersten nicht zugänglich war am
Anfang.
Habe das so verstanden das wenn man in den Kernel2 bootet Flasht man den
Kernel1 und umgekehrt.
Nach dem ganzen Vorgang habe ich dann noch mal im WebInterface die
Firmware per Update eingespielt.
Nicht wundern auch nach dem Flashvogang dauert das laden der WebSite
gute 20sek bis man aus dem Ladebildschirm von "Der Gira Assistent
startet." zur Anmeldeseite kommt.
Die frage ist jetzt ob man auf Version 4 und dann auf 5 Updaten soll.
Weil wie hier geschrieben hört sich das so an als wenn man auf Version5
nicht mehr diesen Trick anwenden kann falls sich das Problem mit der
Bootschleife wiederholen sollte nach einiger Zeit.
soo.... mehr fällt mir nicht wie ich so vorgegangen bin. Vielen dank
aber noch mal an alle Beitragsschreiber in diesem Post.
Hallo zusammen,
ich habe seit ein paar Tagen ebenfalls dasselbe Problem mit dem
"Dauerboot" meines TKS IP Gateways! Es lief nun seit der Bauphase 2016
perfekt durch und tat seinen Dienst. Jetzt muss wohl vor kurzem ein
Stromausfall in unseren Stadtteil gewesen sein (ein paar Waschmaschinen
hat es im Umfeld auch erwischt!) und seitdem leuchtet die LED nur noch
dauergelb und der Resetknopf ist wirkungslos :-(
Ich habe auch diverse "Stromlos" versuche gemacht, aber immer dasselbe!
Dabei bin ich auf Euren interessanten Chat gestoßen, der wirklich
bislang am informativsten ist - Respekt!
Ich weiß, dass ich das auch ohne fremde Hilfe mit den Linux Befehlen
nicht so ohne weiteres hinbekomme, aber mein Problem: ich scheitere
schon am Öffnen des Gehäuses :-(
Wie bekommt ihr das auf ohne es komplett zu zerstören???
Wenn man die Laschen vorsichtig zur Seite biegt, lässt sich die schwarze
Grundplatte auch mit einem Schraubendreher so gut wie nicht bewegen.
Gibt es dort einen Trick?
Ach ja, ich meine, ich hatte schon Version 4 oder 5 drauf ?!? Bin ich
dann verloren oder lässt es sich Eurer Meinung nach noch irgendwie
"retten"?
Einschicken ist auch keine Option, da ich ebenfalls der Installateur bin
und es damals online gekauft habe...
Viele Grüße
Frank
Hey Leute, im Zuge der aktuell häufig vorkommenden PV-Installationen
könnten hier noch weitere Fälle aufkommen, so wie meiner :)
Das schreiht schon fast mach einem youtube-tutorial :)
Ich habe mir jetzt erstmal den USB-Seriell-Wandler FTDI Serial von
BitWizard bestellt.
Ich sag mal bis die Tage :)
LG, Jürgen
Hi zusammen..
Ich gesell mich mal dazu :-)
Tatsächlich nach der Installtion der PV-Anlage.
TKS IP Gateway 2017 installiert und dann sowas.
Naja, ich hab bei all den KNX und TKS Komponenten hier im Haus
mittlerweile so meine Meinung, aber egal, ich freu mich ja, dass es
Hoffnung gibt - serielle hängt dran und ich werd mich die Tage dann auch
mal ransetzen. Passiert das beim nächsten Mal dann evtl. wieder?
Bis dann und ich bin gespannt, wieviele hier noch dazukommen :-)
Hi..
bei mir scheint es wohl nicht so "einfach" zu funktionieren. Ich hab
auch die neueste FW auf dem TKS IP Gateway und habe einmal die interne
SD Karte formatiert(ext3).
Über die serielle Schnittstelle bekomme ich folgende Ausgabe:
Ok,
- TFTP Server und DHCP server eingerichtet
- per
1
dhcp
die IP addresse zuordnen lassen
- per
1
tftpboot
versucht via tftp zu booten
-> es wird versucht die Datei cn27-linux.bin zu laden
- die "IPGW05.04.00.08V2.bin" in cn27-linux.bin umzubenennen wäre
tatsächlich zu einfach gewesen. Die Datei ist auch viel zu groß ->
1
TFTP error: trying to override reserved memory
Immerhin ist der Speicher dahinter geschützt.
Jetzt wäre die Frage, wo man die cn27-linux.bin bekommen kann, in der
Hoffnung, dass man auf diesem Weg das Gerät wieder flott bekommt.
Die IPGW05.04.00.08V2.bin beinhaltet doch sicher den Inhalt der
cn27-linux.bin, oder?
Hi,
zwischenzeitig war mein Gerät bei Gira, nachdem mir der Support
telefonisch eine Reparatur auf Kulanz zugesagt hat. Abwicklung ist nur
über Fachhändler möglich - zum Glück hat das ein Händler für mich
erledigt.
Fazit: Kein Support von Gira, da das Gerät außerhalb der Garantiezeit
ist und irreparabel sei. Grundsätzlich völlig verständlich, aber es
scheint ja so, als wenn das ein (weiteres) grundsätzliches Designproblem
von Gira ist und da könnte man bei einer Klingelanlage für ~3000€ dem
Kunden etwas weiter entgegenkommen. Kostenlose Entsorgung und
Ersatzgerät zum Sonderpreis von 375€ wurden angeboten - Lieferdatum zur
Zeit nicht bekannt.
Ich hab das Gerät jetzt wieder auf meinem Tisch und versuche weiter.
Neuer Versuch:
ich habe mir einmal den Adressbereich des Kernels (0xa0108000 -
0xa043ef9b) ausgeben lassen und mit dem Inhalt des 05er Gira-Images
(IPGW05.04.00.08V2.bin)verglichen - der Start ist im 05er Image
erkennabr und die Größe ist bekannt (0xa0108000 - 0xa043ef9b).
Gleiches hatte ich zuvor mit dem 04er Image gemacht, da der Header
größtenteils gleich war - hier hatte ich am Ende aber keinen Zugriff
mehr - eingefroren. Ich bin mir mittlerweile nicht mehr sicher, ob ich
damals die 04er oder 05er FW aufgespielt hab.
Ich habe aus dem heruntergeladenen 05er Image (IPGW05.04.00.08V2.bin)
den Speicherbereich mit gleicher Größe herauskopiert, der gleich anfängt
(0x00000834 - 0x33fecf) und dies als cn27-linux.bin für den tftp
Download bereit gelegt:
1
BIOS> dhcp
2
BOOTP broadcast1 1
3
*** Unhandled DHCP Option in OFFER/ACK: 46
4
*** Unhandled DHCP Option in OFFER/ACK: 46
5
DHCP client bound to address 192.168.55.10 (273 ms)
6
BIOS> tftp
7
Using FEC device
8
TFTP from server 192.168.55.1; our IP address is 192.168.55.10
10 cmdlinepart partitions found on MTD device NAND 128MiB 1,8V 8-bit
88
Creating 10 MTD partitions on "NAND 128MiB 1,8V 8-bit":
89
0x00000000-0x00020000 : "SPL"
90
0x00020000-0x00120000 : "u-boot1"
91
0x00120000-0x00220000 : "u-boot2"
92
0x00220000-0x00240000 : "tmp1"
93
0x00240000-0x03440000 : "rootfs1"
94
0x03440000-0x03640000 : "kernel2"
95
0x03640000-0x06840000 : "rootfs2"
96
0x06840000-0x07f80000 : "tmp2"
97
0x07f80000-0x07f81000 : "RedBoot config"
98
0x07f81000-0x08000000 : "FIS directory"
99
i.MX SDHC driver
100
i.MX SDHC driver
101
TCP cubic registered
102
Freeing init memory: 864K
103
mmc0: host does not support reading read-only switch. assuming write-enable.
104
mmc0: new SD card at address 59b4
105
mmcblk0: mmc0:59b4 USD 1.87 GiB
106
mmcblk0: unknown partition table
107
mmc_blk_put 1
108
HAVE INTERN SDCARD!
109
kjournald starting. Commit interval 5 seconds
110
EXT3 FS on mmcblk0, internal journal
111
EXT3-fs: mounted filesystem with ordered data mode.
112
Fallback System
113
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000000: 0x4255 instead
114
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000004: 0x0001 instead
115
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000003c: 0xd9d2 instead
116
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000200: 0x4255 instead
117
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000204: 0x0101 instead
118
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0000023c: 0x5d1c instead
119
Empty flash at 0x00000400 ends at 0x00000800
120
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000800: 0x1831 instead
121
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000804: 0xcd7f instead
122
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000808: 0x3973 instead
123
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00000810: 0x084f instead
124
Further such events for this erase block will not be printed
125
Old JFFS2 bitmask found at 0x00017bb8
126
You cannot use older JFFS2 filesystems with newer kernels
127
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020000: 0x4255 instead
128
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00020004: 0x0001 instead
129
..
130
gekürzt
131
..
132
133
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x031e003c: 0x50af instead
134
Cowardly refusing to erase blocks on filesystem with no valid JFFS2 nodes
135
empty_blocks 0, bad_blocks 0, c->nr_blocks 400
136
mount: mounting /dev/mtdblock4 on /mnt failed: Input/output error
137
mount: mounting proc on /mnt/proc failed: No such file or directory
138
mount: mounting sysfs on /mnt/sys failed: No such file or directory
139
mount: mounting rwfs on /mnt/app failed: No such file or directory
140
mknod: /mnt/dev/mtd8: No such file or directory
141
chroot: can't execute '/opt/lin/bin/fconfig': No such file or directory
142
sh: can't access tty; job control turned off
143
/ #
Interessant ist, dass der CRC-check nach dem Uncompressing nicht mehr
fehschlägt und ich an diesem Punkt mit normalen Linux-Befehlen
weiterarbeiten kann.
Mit dem 04er Image über TFTP kam ich wie gesagt nicht zu dem Punkt, dass
das System am Ende bedienbar war, mit dem 05er Image sehe ich vermehrt
den Hinweis
1
Old JFFS2 bitmask found at 0x01bfb598
2
You cannot use older JFFS2 filesystems with newer kernels
im Dateisystem finde ich die fallback.sh mit auszugsweise:
1
root=/dev/mtdblock2 rw rootfstype=jffs2 vi
Das ist jetzt nur leider nicht mein Spezialgebiet, daher würde ich mich
über weitere Ideen freuen.
Kann hier jemand weiterhelfen?
ich hätte noch die Hoffnung, dass man das System wieder in Gang bekommt,
da ich mittlerweile wieder Zugriff auf das Betriebssystem habe.
Viele Grüße
Hi, hui, das ist ja nicht so nett, was Gira da abzieht....Naja, müssen
wir halt schauen, ob wir das so wieder hinbekommen ...
Wenn deine Flash-Partitionen irgendwas mit "uBoot" im Namen haben, hast
du ziemlich sicher Firmware v5.xx.xx. Die v4 lief noch mit RedBoot.
Dein Log sieht mir sehr danach aus, dass dein Kernel-Image jetzt völlig
okay ist (naja gut, du lädst es ja auf das Gerät und dann aus dem RAM,
nicht aus dem Flash). Nur beim RootFS hängt es halt dann wieder ... Gut,
dass du da zwei davon hast, "rootfs1" und "rootfs2". Das ist so ein
A/B-System: Er hat immer eines der beiden "aktiv" und bei nem
Firmware-Update überschreibt er das "nicht aktive", schaltet um und
bootet. So kann man immer wieder "eins zurück", wenn mal was schief
geht.
Schau mal ob du deinen Kernel dazu bringen kannst, das andere der beiden
zu nehmen.
Bevor du jetzt eines der beiden mit dem aus der Firmware-Datei
überschreibst: Die Information, wie viele Lizenzen du hast, ist im
Dateisystem in einer SQLite-Datenbank gespeichert. Also am besten
erstmal den kompletten Flash (oder zumindest die beiden rootfs-Bereiche)
per seriell auf deinem Rechner sichern. Im Idealfall kannst du sie dort
auch mit binwalk oder so untersuchen und die SQLite-DB finden.
Es kann sein, dass man 1 "Testlizenz" bekommt, wenn man sich seine
"regulären" 5 oder 15 zerschießt. Dann kann man zumindest mal einen
Client verbinden. Aber ausprobiert hab ich das nie!
Viel Erfolg weiterhin!
Frank schrieb:> Wie bekommt ihr das auf ohne es komplett zu zerstören???> Wenn man die Laschen vorsichtig zur Seite biegt, lässt sich die schwarze> Grundplatte auch mit einem Schraubendreher so gut wie nicht bewegen.> Gibt es dort einen Trick?
Tatsächlich die schwarze Grundplatte an allen Seiten lösen (= Laschen
nach außen biegen) und dann die Platte nach unten weg bzw. eher den
weißen Deckel nach oben. Braucht ein bisschen Gewaltbereitschaft aber
kaputt isses ja eh schon ...
Was gibt's denn Neues von Frank, Jürgen und ARC? Alle wieder zum Laufen
bekommen?
VG, Jannis
Guten Morgen zusammen, bei mir leider nach 5 Jahren Nutzung das selbe
Problem.
Ich „spiele“ auch gerne, aber sagt mir bitte wie muss ich das Gateway an
was anschließen, damit ich damit kommunizieren kann?
Hi,
ehrlicherweise war ich nach den letzten Versuchen recht frustriert und
hab die weiteren Beiträge hier erst jetzt wieder gelesen.
Ich schau mir das Board nochmal wieder an, alleine schon weil ich es
nicht einsehe, ein neues Gerät zu kaufen. Das Auslesen des Flash dauert
über serielle Schnittstelle schon recht lange - ich versuch mal, den
Flash der beiden rootfs auszulesen.
@ad_a: im zweiten Beitrag sind die Pins erklärt ;-)
-------------------------------------------------------
OT
-------------------------------------------------------
Weshalb ich auf Gira etwas angespannt reagiere:
Ich hab rund 30k€ an Gira-Komponenten verbaut und folgende
Reklamationserfahrungen:
[1] KNX Dimmaktor: Firmware-Bug an Gira gemeldet inkl. Anleitung zur
Reproduzierbarkeit -> Keine Rückmeldung
[2] TKS Gateway: siehe oben
[3] KNX IP Router: Firmwareupdate von 2.x nicht möglich über GPA,
neueste FW mit Bugfixes nicht mit ETS4 kompatibel -> 1k€ für Umstieg
notwendig
[4] TKS Kamera System 106: Kleber löst sich, lt. Gira ein Chargenproblem
mit dem Kleber, Reklamation und Austausch zögerlich und nur über lokalen
Elektriker möglich.
Hi, so ich hab jetzt im Keller das TKS IP Gateway an einem freien
Rechner hängen weil das Auslesen doch aufwendiger ist als gehofft.
Um den kompletten NAND Flash auszulesen, muss ich mir leider noch ein
Script basteln.
Adressbereich lt. Terminalausgabe:
1
0x00000000-0x00020000 : "SPL"
2
0x00020000-0x00120000 : "u-boot1"
3
0x00120000-0x00220000 : "u-boot2"
4
0x00220000-0x00240000 : "tmp1"
5
0x00240000-0x03440000 : "rootfs1"
6
0x03440000-0x03640000 : "kernel2"
7
0x03640000-0x06840000 : "rootfs2"
8
0x06840000-0x07f80000 : "tmp2"
9
0x07f80000-0x07f81000 : "RedBoot config"
10
0x07f81000-0x08000000 : "FIS directory"
Mein erster Versuch über
1
md.b 0x....
funktionierte natürlich nicht, da der Speicher per nand-Befehl
ausgelesen werden muss.
1
BIOS> nand info
2
3
Device 0: nand0, sector size 128 KiB
4
Page size 2048 b
5
OOB size 64 b
6
Erase size 131072 b
7
subpagesize 512 b
8
options 0x40000000
9
bbt options 0x00008000
Ich kann den NAND Flash Page-weise auslesen, das muss aber automatisiert
werden. rootfs1 umfasst 25600 Pages à 2048Bytes
1
nand dump 240000
Bisher hab ich Putty im Logging Modus verwendet und mir die
Speicherausgabe mit HxD angeschaut.
Jetzt ist die Frage, wie ich hier am besten weitermache:
Script erzeugen, das Page-weise den Flash ausliest und daraus ein Image
erzeugen?
Bei dem Aufwand könnte es sich schon fast lohnen, den Flash extern (z.B.
Aardvark) auszulesen.
Alternativ hätte ich die Idee, über tftp-Server auf den Flash
zuzugreifen, bzw. den Speicher auf diesem Weg zu exportieren.
Oder eine Kopie des Flashs auf der vorhandenen SD anlegen? - wenn das
klappt, könnte das recht elegant sein.
Habt ihr eine Idee, welcher Weg hier am besten sein wird?
Viele Grüße..
Sehe ich das richtig, dass die Auswahl des rootfs per "mount" in dem
fallback.sh erfolgt (s.u.)?
Wäre "mtdblock6" das rootfs2 und "mtdblock4" das rootfs1?
Zuvor wird aufgeführt:
1
Creating 10 MTD partitions on "NAND 128MiB 1,8V 8-bit":
2
0x00000000-0x00020000 : "SPL"
3
0x00020000-0x00120000 : "u-boot1"
4
0x00120000-0x00220000 : "u-boot2"
5
0x00220000-0x00240000 : "tmp1"
6
0x00240000-0x03440000 : "rootfs1"
7
0x03440000-0x03640000 : "kernel2"
8
0x03640000-0x06840000 : "rootfs2"
9
0x06840000-0x07f80000 : "tmp2"
10
0x07f80000-0x07f81000 : "RedBoot config"
11
0x07f81000-0x08000000 : "FIS directory"
manuelles Ausführen von
1
mount -t jffs2 /dev/mtdblock6 /mnt
sowie
1
mount -t jffs2 /dev/mtdblock4 /mnt
wirft reihenweise Fehler und wird erfolglos beendet.
Kann ich davon ausgehen, dass beide rootfs beschädigt sind?
fallback.sh:
Hi, also zum Lesen von NAND brauchst du kein Script und musst das auch
nicht blockweise machen. Das erste Root-FS habe ich damals so
ausgelesen:
1. Vom Flash in den RAM lesen:
nand read -f 0xE0040000 -b 0xa0030000 -l 0x00200000
2. Vom RAM auf die Konsole schreiben lassen:
dump -s -b 0xa0030000 -l 0x00200000
Und dann von Konsole den kompletten Puffer in eine Datei speichern
lassen, am PC zurechtschneiden, umwandeln von "Hexprint" nach binär und
gut war. Dann konnte man auch wenn der Flash schon einen Schaden hatte
noch mit jefferson oder binwalk was retten.
Mir fällt aber gerade auf, dass dein TKS schon auf v5.x bzw. uBoot ist.
Da sind die Befehle, Flash-Adressen und Partitionsnummern leicht andere
... Bei mir waren damals die beiden root-fs auf /dev/mtdblock2 und
/dev/mtdblock4. Zumindest das scheint bei dir aber auch so zu sein, wenn
ich mir die "root="-Parameter von den Scripten, die du gepostet hattest
so ansehe ...
Wenn bei dir echt beide rootfs so kaputt sind, dass das Ding nicht mehr
bootet würde ich schon versuchen, den kompletten Flash mal auf den PC zu
bekommen. Wenn das nur blockweise geht, gerne auch mit Script. Dann
daraus die Einstellungen und Lizenzen sichern (sind alles
SQLite-Datenbanken, sollten sich also leicht finden lassen, wenn nicht
zu sehr fragmentiert). Dann aus den FW-Updates das rootfs extrahieren,
in den Flash prügeln und dann irgendwie die Einstellungen und Lizenzen
wiederherstellen. Evtl. geht's ja, wenn man in beiden Slots (A und B)
ein gültiges FW hat, zu booten, das RootFS vom ANDEREN/INAKTIVEN Slot zu
mounten, ändern und dann den Slot zu wechseln?
Achso, klar, wenn du den Flash-Chip auch ohne Bootloader ausgelesen
bekommst, geht's natürlich schneller. Ich hatte nix passendes da, um den
extern zu kontaktieren
Hi, hey cool, dass Du noch dabei bist.
Gibt es irgendein Problem wegen der folgenden Meldung?
1
Old JFFS2 bitmask found at 0x01bfb598
2
You cannot use older JFFS2 filesystems with newer kernels
Ist eigentlich genau bekannt, was das Problem mit dem Flash ist? Ist der
Flash ansonsten in Ordnung, gibt es Probleme mit dem ECC oder sind das
schon Ausfallerscheinungen?
Danke für den Tipp mit Flash -> RAM, ich hätte mit dem
Ziel-Adressbereich Sorgen gehabt, aber es hat geklappt:
ich habe aber evtl. ein Problem mit dem Buffer meiner seriellen
Schnittstelle oder am TKS - es gehen leider ab und an mal Daten verloren
- das fällt recht schnell auf wenn die Daten durchlaufen. Wäre da der
Flaschenhals am TKS oder eher am Windows-PC? Alternativ Baudrate
anpassen? Das Problem tritt nur auf wenn ununterbrochen Daten gesendet
werden, beim Seiten-weisen Auslesen z.B. nie.
Ansonsten läuft es sehr gut mit dem Auslesen ;-)
So sieht es zwischendurch aus wenn ich ununterbrochen Auslese (da fehlt
ab 0x680 ein bisschen was):
Könnte man auch mit 2x Auslesen mergen, aber das ist irgendwie nicht
sehr cool.
Ansonsten erstmal einen schönen Sonntag & vielen Dank- ich schau nachher
mal rein, was da runtergeladen wurde. Auf dem Weg kann ich dann auch den
kompletten Flash sichern - man weiß ja nie.
Erst einmal vielen Dank an Jannis, Tobi und auch ARC für die ganze
Arbeit.
Ich habe natürlich das gleiche Problem. Zum "Glück" noch eine 3er
Firmware mit RedBoot drauf.
Leider ist bei mir der Flash anscheinend nicht nur leicht beschädigt.
Beim booten von Kernel 1 bekomme ich folgendes:
Weist irgendwie darauf hin, dass die checksumme nicht passt und er nicht
booten will. (wäre mir ja eigentlich egal, so lange ich ne bash bekomme)
Will ich Kernel 2 booten kommt er schon weiter:
Advanced Linux Sound Architecture Driver Version 1.0.18rc3.
87
ALSA device list:
88
No soundcards found.
89
ip_tables: (C) 2000-2006 Netfilter Core Team
90
TCP cubic registered
91
NET: Registered protocol family 17
92
RPC: Registered udp transport module.
93
RPC: Registered tcp transport module.
94
dummy 0-0030: setting system clock to 2024-04-15 09:39:57 UTC (1713173997)
95
Empty flash at 0x02a9e458 ends at 0x02a9e800
96
VFS: Mounted root (jffs2 filesystem).
97
Freeing init memory: 112K
98
Warning: unable to open an initial console.
99
Kernel panic - not syncing: Attempted to kill init!
Soweit passt alles, wenn ich es richtig verstehe. Nur am Ende will er
die Konsole nicht laden. Auch wenn ich mit dem zweiten Kernel das
"erste" Root laden will bekomme ich folgende letzte Zeilen:
1
Warning: unable to open an initial console.
2
Failed to execute /bin/bash. Attempting defaults...
3
Kernel panic - not syncing: No init found. Try passing init= option to kernel.
Habt ihr Vorschläge was ich falsch mache oder noch testen könnte?
Viele Grüße Jan
So, nochmal ein kleines Update. Mittlerweile funktioniert mein
IP-Gateway wieder.
Irgendwie hat er nach einem Neustart noch einmal den Kernel 1 geladen
(mit dem Adressbereich vom Kernel 2) und dann gestartet. Danach hat sich
das GW selber mehrmals neu gestartet und sogar einen neuen RSA-key
generiert. (Das mit dem RSA-Key ist vermutlich weil er keinen auf der
internen SD-Karte gefunden hat.)
Dann ist das System sogar komplett hochgefahren und ich konnte die
FW-Updates über die Oberfläche starten.
Die Listings würden den Rahmen hier sicher sprengen. Auch will ich nicht
überall die MAC-Adresse rausnehmen und weiß nicht, was sonst noch für
Gerätespezifische daten in den Logs stehen.
Vielen Dank euch noch einmal. Jetzt werde ich erst einmal bei Gira
anrufen und schauen, ob ich den Fingerabdruckscanner zum Reset (mit
Schlüsselkarte) einsenden "darf". Ansonsten wird das das nächste
Projekt. :D
VG Jan
Hallo Leute,
ich sitze hier und bin gerade völlig enttäuscht. Nach viel Belesen und
ausprobieren habe ich es tatsächlich geschafft mir den Bootvorgang via
GNU Screen anzuschauen und musste leider UBIFS lesen, was demnach
bedeutet, dass ich bereiits die 5.X Version drauf habe, wofür es hier
noch offensichtlich keine Lösung gibt. Mega ärgerlich :/
Ich versuche mich jetzt noch einmal an Gira zu wenden, in der Hoffnung,
dass sie mir wenigstens den reduzierten Neupreis geben.
Vielen Dank trotzdem für die tolle Unterstützung.
LG, Jürgen
Hallo, noch ein kurzes Update zu meinem Gerät: Das lief jetzt eine gute
Zeit lang (ca 1.5 Jahre) wunderbar stabil. Da waren auch 3-4 Neustarts
dabei. Gestern hatten wir dann wieder einen (Der FI musste für Arbeit
mal kurz raus) und danach kam das TKS-IP-Gateway tatsächlich nicht mehr
hoch .....
Also wieder auf den Schreibtisch und aufgemacht. Mit der FW v5.x.x.x war
das aber recht fix lösbar, anscheinend wird eine Kopie der beiden
Dateisysteme (system und data) auf der internen SD-Karte vorgehalten.
Also das system-image von der SD-Karte auf den Flash kopiert und dann
lief das wieder.
Von den Bootmeldungen las es sich eigentlich so, als sollte diese Art
der Reperatur automatisch passieren, klappt aber irgendwie nicht. Ich
hatte auf jeden Fall Glück, dass das Gerät dieses mal in einer Art
Rescue-Shell war und das Kopieren auf den Flash recht leicht ging.
Das ist natürlich irgendwie keine Dauerlösung, wenn man alle paar Jahre
das Gerät aus dem Verteilerkasten holen muss, es aufmachen und
reparieren muss. Entweder muss ich mir mal die Serielle permanent nach
draußen löten oder mir echt das v2-Gerät von Gira kaufen. Irgendwie
widerstrebt es mir ja, diese Firma für den Mist, den sie verkauft haben
(und dessen Support sie verweigern zu scheinen) noch finanziell zu
belohnen, allerdings braucht man das Gerät halt aber dann irgendwie
doch.
Die Alternative wäre, sich die Verbindung zwischen beiden Platinen mal
genauer anzuschauen, ob man nicht den "Analogteil" (die untere Platine)
von Gira nimmt und dann selbst was als Digital/Netzwerkteil dranbastelt.
Das würde einem dann auch unbegrenzt SIP-Sessions erlauben ... Nur mal
laut gedacht ;)
Hi Leute,
ich würde auch gerne meinen Beitrag für die Mitleidenden hinterlassen,
auch wenn ich leider im Bootvorgang lesen musste, dass ich die Firmware
5.X habe und es im Thread hierzu offensichtlich noch keine Lösung gibt.
Den Weg bis zur Visualisierung des Bootvorgangs versuche ich euch gerne
etwas tiefer zu legen.
Folgende Hardware habe ich vorab besorgt:
1. [BitWizard UART to
USB](https://bitwizard.nl/shop/usb-boards/USB-to-UART) (wie bereits oben
im Thread empfohlen)
2. [Dupont Kabel
männlich/weiblich](https://ledtra.de/bastlerbedarf/kabel-und-verbinder/1365/dupont-kabel-10cm-20cm-30cm-mm-ww-mw-jumper-draht-dupont-kabel-arduino-diy-kit?number=LOG-BAS-KV-DUP-20CM-MW-0001)
Wie auf den Fotos zu sehen ist, konnte ich die männlichen Pins in die
Debug Schnittstellen-Löcher auf der Platine vorsichtig reinstecken, so
dass sie sich leicht verklemmten hatten. Kein Löten notwendig.
In der [Doku](https://www.bitwizard.nl/wiki/index.php/FTDI_serial_2) des
UART to USB Wandlers findet ihr einerseits beschrieben, wie ihr den
Wandler durch setzen eines Jumpers (schwarze 2-Pin Brücke) auf 3,3V
einstellen könnt und welche Pins auf der Platine Ground, Rx und Tx sind
(achtet hierbei auf die kleinen Zahlen auf der Platine).
Wenn ihr den kleinen Wandler mit der Debug Schnittstelle des IP-Gateways
verbindet, müsst ihr Rx des Wandlers an Tx der Debug-Schnittstelle
anschließen (nicht Rx an Rx)...
Hierzu fand ich dieses
[Video](https://www.youtube.com/watch?v=01mw0oTHwxg) sehr interessant.
An der Debug-Schnittstelle ist Rx ganz außen, gefolgt von Tx und das
vierte Loch vom Gehäuse aus gezählt ist Ground. Da die Pins der Kabel
etwas zu dick für den Lochabstand waren, habe ich einen Pin von der
Rückseite eingesteckt.
Meine zweite Herausforderung war die interne (über das geschlossene
Gehäuse nicht zugänglich) SD-Karte zu formatieren. Mein naiver Gedanke,
die einfach in meinen Windows PC zu stecken war natürlich nicht von
Erfolg gekrönt, da diese in dem Linux Dateisystem EXT3 formatiert ist.
Da mir die Suche nach einem Freeware tool, dass in der Lage wäre aus
Windows heraus die SD-Karte in EXT3 zu formatieren, zu mühselig war,
steckte ich diese in meinen Raspberry Pi (der über eine SSD bootet, was
evtl. nicht von Relevanz ist) und formatierte diese mit Hilfe von
folgendem [Video](https://www.youtube.com/watch?v=qnRLb8Z9gIs) (im Video
wird in EXT4 formatiert, an der Stelle müsst ihr dann EXT3 anstelle der
EXT4 schreiben). Hier lernt ihr auch, wie ihr die SD-Karte mountet.
Dann habe ich die auf der [Gira
Seite](https://download.gira.de/de_DE/download.html?type=V&id=3476)
erhältliche Firmware Version: 3.01.13 runtergeladen, dann die
IPGW03.01.13.00V1.bin aus dem Zip-File in "upload.tmp" umbenannt und mit
meinem Freewareprogramm [SFTP DRIVE](https://www.callback.com/sftpdrive)
auf die SD Karte rübergezogen.
Im nächsten Schritt hatte ich die SD-Karte wieder in das IP-Gateway
gesteckt, den kleinen Wandler mittels USB an meinen Raspberry Pi
gehangen und mich dann via Putty eingeloggt.
In meinem Raspberry Pi musste ich erstmal "GNU Screen" installieren. Die
Installation und die Benutzung ist in folgendem
[Video](https://www.youtube.com/watch?v=I4xVn6Io5Nw) sehr gut
beschrieben.
Anschließend musste ich noch herausfinden, an welchem USB Port mein
Wandler hängt, was ich mit Hilfe von ChatGPT gemacht hatte. Hier bekommt
man alle notwendigen Linux Befehle für den Raspberry Pi.
Mit dem Befehl "screen /dev/ttyUSB1 115200" war ich dann mit dem
betroffenen Chip im IP-Gateway verbunden. Daraufhin versorgte ich das
IP-Gateway wieder mit 24V, woraufhin ich plötzlich den Bootvorgang im
GNU Screen Programm sehen konnte.
Während ich mich im ersten Moment fühlte, als hätte ich das Feuer
erfunden, laß ich im zweiten Moment UBIFS auf dem Bildschirm und wusste,
dass damit die Firmware 5.X einher geht und es leider noch keine Lösung
dafür gibt.
Wünsche euch viel Erfolg, vielleicht hilft das ja dem ein oder anderen
weiter.
LG, Jürgen
Thread beobachten
Seitenaufteilung abschalten