Forum: Haus & Smart Home Gira tks-ip Gateway Problem, Freescale MCIMX27VOP4A


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Martin K. (martin_k29)



Lesenswert?

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

: Verschoben durch Moderator
von Jannis A. (jannis_)


Lesenswert?

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 ...

von Jannis A. (jannis_)


Lesenswert?

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

von Martin K. (martin_k29)


Lesenswert?

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

von Martin K. (martin_k29)


Lesenswert?

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

von Thomas (eisibaerli)


Angehängte Dateien:

Lesenswert?

@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

von Jannis A. (jannis_)


Lesenswert?

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 :)

von Thomas (eisibaerli)


Lesenswert?

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.

: Bearbeitet durch User
von Jannis A. (jannis_)


Lesenswert?

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.

von Thomas (eisibaerli)


Lesenswert?

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. :-)

von Andi (andd)


Lesenswert?

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

von Andreas H. (andreas_h971)


Lesenswert?

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

von Jannis A. (jannis_)


Lesenswert?

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?

von Andreas H. (andreas_h971)


Lesenswert?

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!

von Tobi (mrgodt)


Lesenswert?

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.

von Jannis A. (jannis_)


Lesenswert?

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!

von Tobi (mrgodt)


Lesenswert?

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.

von Jannis A. (jannis_)


Lesenswert?

Ö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.

von Tobi (mrgodt)


Lesenswert?

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.

von Frank (Gast)


Lesenswert?

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

von Jürgen (deutz2016)


Lesenswert?

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

von ARC (gznw15)


Lesenswert?

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 :-)

von ARC (gznw15)


Lesenswert?

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:
1
U-Boot 2019.04-rc4-00071-g1111ff6-dirty (Nov 18 2019 - 09:42:41 +0100)TKSIPGW
2
3
MAIN CPU:   Freescale i.MX27 at 399.600 MHz
4
5
Board: TKS-IPGW revision 0
6
I2C:   ready
7
DRAM:  64 MiB
8
NAND:  128 MiB
9
MMC:   MXC MCI: 0, MXC MCI: 1
10
In:    serial
11
Out:   serial
12
Err:   serial
13
Net:   FECMMV set hwaddr
14
15
Hit any key to stop autoboot:  0
16
ubi0: attaching mtd4
17
ubi0: scanning is finished
18
ubi0: attached mtd4 (name "ubi", size 125 MiB)
19
ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 129024 bytes
20
ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 512
21
ubi0: VID header offset: 512 (aligned 512), data offset: 2048
22
ubi0: good PEBs: 1007, bad PEBs: 0, corrupted PEBs: 0
23
ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128
24
ubi0: max/mean erase counter: 858/288, WL threshold: 4096, image sequence number: 0
25
ubi0: available PEBs: 0, total reserved PEBs: 1007, PEBs reserved for bad PEB handling: 10
26
Loading file '/system/kernel' to addr 0xa0108000...
27
Done
28
Loading file '/system/uboot-env.txt' to addr 0xa0000000...
29
Done
30
## Info: input data size = 378 = 0x17A
31
32
Warning1: FEC MAC addresses don't match:
33
Address in SROM is    0000000:0a:b3:10:2b:f3
34
Address in environment is  d4:79:c3:00:00:02
35
MMV set hwaddr
36
## Info: input data size = 378 = 0x17A
37
MMV set hwaddr
38
Loading file '/system/kernel.md5' to addr 0xa0000200...
39
Done
40
## Info: input data size = 962 = 0x3C2
41
md5 for a0108000 ... a043ef9b ==> c877103c474e0d88087183d71b0a7114 != 4809ecefb5127fb243df3deb6e071248 ** ERROR **
42
ubi-kernel-md5 error
43
sd0-kernel not found
44
sd1-kernel not found
45
BIOS>

Checksumme fehlerhaft? Wie würde denn der Sotware Download über tftp 
aussehen? Welche Dateien werden benötigt?

von ARC (gznw15)


Lesenswert?

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?

von ARC (gznw15)


Lesenswert?

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
9
Filename 'cn27-linux.bin'.
10
Load address: 0xa0108000
11
Loading: *#################################################################
12
   #################################################################
13
   #################################################################
14
   #####################################
15
   10.6 MiB/s
16
done
17
Bytes transferred = 3405468 (33f69c hex)
18
BIOS> bootz
19
Kernel image @ 0xa0108000 [ 0x000000 - 0x1ec2d4 ]
20
21
Starting kernel ...
22
23
Uncompressing Linux........................................................................................................... done, booting the kernel.
24
Linux version 2.6.28cn (root@tkipgw) (gcc version 4.1.2) #300 PREEMPT Thu Jan 16 13:59:50 CET 2020
25
CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
26
CPU: VIVT data cache, VIVT instruction cache
27
Machine: Cameronet CN27 module (Freescale i.MX27)
28
Memory policy: ECC disabled, Data cache writeback
29
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
30
Kernel command line: console=ttymxc0,115200 mtdparts=mxc_nand.0:128K(SPL)ro,1M(u-boot1)ro,1M(u-boot2)ro,-(ubi) bootmode=0
31
MXC GPIO hardware
32
MXC IRQ initialized
33
PID hash table entries: 256 (order: 8, 1024 bytes)
34
Changing SPCTL0 from 06f22b33 to 0af32f33
35
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
36
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
37
Memory: 64MB = 64MB total
38
Memory: 61492KB available (2308K code, 249K data, 864K init)
39
Calibrating delay loop... 198.65 BogoMIPS (lpj=99328)
40
Mount-cache hash table entries: 512
41
CPU: Testing write buffer coherency: ok
42
net_namespace: 288 bytes
43
NET: Registered protocol family 16
44
M3IF_BASE1: 0x       0
45
M3IF_BASE2: 0x       0
46
NET: Registered protocol family 2
47
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
48
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
49
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
50
TCP: Hash tables configured (established 2048 bind 2048)
51
TCP reno registered
52
AUDMUX: probing
53
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
54
msgmni has been set to 120
55
alg: No test for stdrng (krng)
56
io scheduler noop registered
57
io scheduler anticipatory registered
58
io scheduler deadline registered
59
io scheduler cfq registered (default)
60
gpio_fs453_init
61
gpio_fs453_power_on
62
TV encoder present, ID=0x0045
63
mxc_sdc_fb mxc_sdc_fb.0: fb0: DISP0 BG fb device registered successfully.
64
mxc_sdc_fb mxc_sdc_fb.0: fb1: DISP0 FG fb device registered successfully.
65
Cameronet gira_reset driver version 1.0
66
/dev/gira_reset device number is: 254
67
gpio_btn_reset_init
68
Serial: IMX driver
69
imx-uart.0: ttymxc0 at MMIO 0x1000a000 (irq = 20) is a IMX
70
console [ttymxc0] enabled
71
imx-uart.1: ttymxc1 at MMIO 0x1000b000 (irq = 19) is a IMX
72
brd: module loaded
73
loop: module loaded
74
FEC ENET Version 0.2
75
fec: PHY @ 0x0, ID 0x00221513 -- unknown PHY!
76
eth0: ethernet 00:0a:b3:10:2b:f3
77
Linux video capture interface: v2.00
78
MMV cmdline_parser_init
79
Generic platform RAM MTD, (c) 2004 Simtec Electronics
80
MXC MTD nand Driver
81
MMV mxcnd_probe 1
82
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron NAND 128MiB 1,8V 8-bit)
83
Bad block table not found for chip 0
84
Bad block table not found for chip 0
85
RedBoot partition parsing not available
86
MMV parse_cmdline_partitions
87
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

: Bearbeitet durch User
von Jannis A. (jannis_)


Lesenswert?

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!

von Jannis A. (jannis_)


Lesenswert?

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

von Ad A. (ad_a)


Lesenswert?

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?

von ARC (gznw15)


Lesenswert?

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.

: Bearbeitet durch User
von ARC (gznw15)


Lesenswert?

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..

: Bearbeitet durch User
von ARC (gznw15)


Lesenswert?

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:
1
/ # cat fallbacksys.sh
2
#!/bin/sh
3
4
echo "Fallback System"
5
6
flashmtd=`cat /proc/cmdline | cut -d " " -f3 | cut -d "=" -f2`
7
8
rm -rf /app/sdintern/messages*
9
rm -rf /app/sdintern/data-bak
10
rm -rf /app/sdintern/checkwebui.result
11
rm -rf /app/sdintern/log
12
rm -rf /app/sdintern/wtmp
13
rm -rf /app/sdintern/sdcard.tar
14
15
if [ $flashmtd == "/dev/mtdblock2" ] ; then
16
        mount -t jffs2 /dev/mtdblock6 /mnt
17
else
18
        mount -t jffs2 /dev/mtdblock4 /mnt
19
fi
20
21
/bin/mount -t proc proc /mnt/proc
22
/bin/mount -t sysfs sysfs /mnt/sys
23
mount -t tmpfs rwfs  /mnt/app -o size=5M
24
mkdir -p /mnt/app/tmp
25
26
mknod /mnt/dev/mtd8 c 90 16
27
28
if [ $flashmtd == "/dev/mtdblock2" ] ; then
29
        chroot /mnt/ /opt/lin/bin/fconfig -w -v -d /dev/mtd8  -n boot_script_data -x "fis load kernel2\ exec -c \"noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 video=mxcfb:TV-PAL\"\ fis load kernel1\ exec -c \"noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 video=mxcfb:TV-PAL\"\ "
30
        ret=$?
31
        if [ $ret -eq 0 ] ; then
32
                chroot /mnt/ /usr/bin/flashcp -v /app/tmp/redconfig /dev/mtd8
33
                sync
34
                echo "Fallback System OK"
35
                reboot -f
36
        fi
37
else
38
        chroot /mnt/ /opt/lin/bin/fconfig -w -v -d /dev/mtd8  -n boot_script_data -x "fis load kernel1\ exec -c \"noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 video=mxcfb:TV-PAL\"\ fis load kernel2\ exec -c \"noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 video=mxcfb:TV-PAL\"\ "
39
        ret=$?
40
        if [ $ret -eq 0 ] ; then
41
                chroot /mnt/ /usr/bin/flashcp -v /app/tmp/redconfig /dev/mtd8
42
                sync
43
                echo "Fallback System OK"
44
                reboot -f
45
        fi
46
fi

von Jannis A. (jannis_)


Lesenswert?

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

: Bearbeitet durch User
von ARC (gznw15)


Lesenswert?

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:
1
BIOS> nand read a0030000 240000 03200000
2
3
NAND read: device 0 offset 0x240000, size 0x3200000
4
 52428800 bytes read: OK
5
BIOS>

für das Dumpen verwende ich
1
md.b a0030000 3200000

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):
1
00000640: 08 bc 18 47 03 b4 48 00 08 49 6b 46 40 18 19 78   ...G..H..IkF@..x
2
00000650: 01 70 59 78 41 70 02 b0 70 47 00 00 6c 2c 00 00   .pYxAp..pG..l,..
3
00000660: 00 8c 02 10 00 70 02 10 00 0e 00 d8 00 8c ff ff   .....p..........
4
00000670: 01 c0 8f e2 1c ff 2f e1 10 b5 ff f7 20 ed 1a 11 43 41 60 ....51.bAhnJ.CA`
5
000006f0: 41 68 ff 22 41 32 91 43 41 60 01 68 01 22 11 43   Ah."A2.CA`.h.".C
6
00000700: 01 60 70 47 68 48 01 6a 0f 22 12 03 91 43 01 62   .`pGhH.j."...C.b
7
00000710: 81 6b 91 43 81 63 01 68 05 22 12 03 11 43 01 60   .k.C.c.h."...C.`
8
00000720: 62 48 01 68 13 22 12 02 11 43 3b 22 92 02 91 43   bH.h."...C;"...C
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.

von Jan (jan_p42)


Lesenswert?

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:
1
RedBoot> fis load kernel1; exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash"
2
... Read from 0xa3ee0000-0xa3f00000 at 0xe7fa0000: .
3
... Read from 0xa0108000-0xa02f42d4 at 0xe0040000: ................
4
Checksum: 0xd72fe259
5
Checksum2: 0x0fcfc412 | 0x001ec2d4
6
** Warning - checksum failure.  stored: 0x0fcfc412, computed: 0xd72fe259
7
Can't execute Linux - invalid entry address
8
RedBoot>

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:
1
RedBoot> fis load kernel2; exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash"
2
... Read from 0xa3ee0000-0xa3f00000 at 0xe7fa0000: .
3
... Read from 0xa0108000-0xa02948d0 at 0xe3440000: .............
4
Checksum: 0x0f9151ff
5
Checksum2: 0x0f9151ff | 0x0018c8d0
6
Using base address 0xa0108000 and length 0x0018c8d0
7
Uncompressing Linux............................................................................................................ done, booting the kernel.
8
Linux version 2.6.28cn (root@mmv-laptop) (gcc version 4.1.2) #46 PREEMPT Thu Dec 20 18:42:24 CET 2012
9
CPU: ARM926EJ-S [41069264] revision 4 (ARMv5TEJ), cr=00053177
10
CPU: VIVT data cache, VIVT instruction cache
11
Machine: Cameronet CN27 module (Freescale i.MX27)
12
Memory policy: ECC disabled, Data cache writeback
13
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 16256
14
Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash
15
MXC GPIO hardware
16
MXC IRQ initialized
17
PID hash table entries: 256 (order: 8, 1024 bytes)
18
Changing SPCTL0 from 04082008 to 0af32f33
19
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
20
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
21
Memory: 64MB = 64MB total
22
Memory: 61344KB available (3096K code, 364K data, 112K init)
23
Calibrating delay loop... 198.65 BogoMIPS (lpj=99328)
24
Mount-cache hash table entries: 512
25
CPU: Testing write buffer coherency: ok
26
net_namespace: 424 bytes
27
NET: Registered protocol family 16
28
M3IF_BASE1: 0x       0
29
M3IF_BASE2: 0x       0
30
NET: Registered protocol family 2
31
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
32
TCP established hash table entries: 2048 (order: 2, 16384 bytes)
33
TCP bind hash table entries: 2048 (order: 1, 8192 bytes)
34
TCP: Hash tables configured (established 2048 bind 2048)
35
TCP reno registered
36
NET: Registered protocol family 1
37
AUDMUX: probing
38
JFFS2 version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
39
msgmni has been set to 119
40
alg: No test for stdrng (krng)
41
io scheduler noop registered
42
io scheduler anticipatory registered
43
io scheduler deadline registered
44
io scheduler cfq registered (default)
45
gpio_fs453_init
46
gpio_fs453_power_on
47
TV encoder present, ID=0x0045
48
mxc_sdc_fb mxc_sdc_fb.0: fb0: DISP0 BG fb device registered successfully.
49
mxc_sdc_fb mxc_sdc_fb.0: fb1: DISP0 FG fb device registered successfully.
50
Cameronet gira_reset driver version 1.0
51
/dev/gira_reset device number is: 253
52
gpio_btn_reset_init
53
Serial: IMX driver
54
imx-uart.0: ttymxc0 at MMIO 0x1000a000 (irq = 20) is a IMX
55
console [ttymxc0] enabled
56
imx-uart.1: ttymxc1 at MMIO 0x1000b000 (irq = 19) is a IMX
57
brd: module loaded
58
loop: module loaded
59
FEC ENET Version 0.2
60
fec mii: probed
61
eth0: ethernet 00:0a:b3:**:**:**
62
Linux video capture interface: v2.00
63
Generic platform RAM MTD, (c) 2004 Simtec Electronics
64
MXC MTD nand Driver
65
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xa1 (Micron NAND 128MiB 1,8V 8-bit)
66
Bad block table found at page 65472, version 0x01
67
Bad block table found at page 65408, version 0x01
68
Searching for RedBoot partition table in NAND 128MiB 1,8V 8-bit at offset 0x7fe0000
69
Searching for RedBoot partition table in NAND 128MiB 1,8V 8-bit at offset 0x7fc0000
70
Searching for RedBoot partition table in NAND 128MiB 1,8V 8-bit at offset 0x7fa0000
71
7 RedBoot partitions found on MTD device NAND 128MiB 1,8V 8-bit
72
Creating 7 MTD partitions on "NAND 128MiB 1,8V 8-bit":
73
0x00000000-0x00040000 : "RedBoot"
74
0x00040000-0x00240000 : "kernel1"
75
0x00240000-0x03440000 : "rootfs1"
76
0x03440000-0x03640000 : "kernel2"
77
0x03640000-0x06840000 : "rootfs2"
78
0x07f80000-0x07f81000 : "RedBoot config"
79
0x07fa0000-0x07fc0000 : "FIS directory"
80
dummy 0-0030: rtc core: registered rtc-s35390a as rtc0
81
device-mapper: uevent: version 1.0.3
82
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com
83
i.MX SDHC driver
84
i.MX SDHC driver
85
Sahara HW Version is 0x00000003
86
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

von Jan (jan_p42)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.