Gira tks-ip Gateway Problem, Freescale MCIMX27VOP4A

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.

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:

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?

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

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

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:

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

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:

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.

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

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 (wie bereits oben im Thread empfohlen)
2. Dupont Kabel männlich/weiblich

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

Noch ein defektes IP-Gateway.

Auch meins hängt im Botmodus fest (Orange Led dauerhaft an)

Leider bin ich was das aufspielen der firmware nicht so fit.

Daher die Frage an einen User der es schon hinbekommen hat ob dieser das für mich machen könnte.

Gerne alles weiter per pn .

Hallo zusammen, auch bei mir ist die PV Anlage schuld :-( Mein IP Gateway will ebenfalls nicht mehr booten... orange LED und schluß. Mit der Beschreibung von Jürgen bin ich zwar schon bis zum booten des Gateways gekommen. Ich kann ihm also dabei zusehen, wie es schiefgeht, weiß aber nicht wirklich, wie ich jetzt voran komme... Hat vielleicht jemand von denen, die es können Zeit / Lust sich dem Kandidaten anzunehmen ? ? Gern eine PN ... Dank euch allen. Zum einen bin ich froh, das es so eine coole Infosammlung gibt, zum andere aber echt erschrocken was GIRA da für die Menge an Geld für eine Qualität verkauft :-(

VG Jörg

Hallo, ich würde mich auch gerne einmal dranhängen und um Hilfe bitten. Mein TKS-IP-Gateway hat sich nach einem Stromausfall auch gehimmelt. UART Wandler sind vorhanden, Linux Wissen fast nicht.

Ich sehe per Putty die seriellen Ausgaben, und kann dort auch eingeben. Ich sehe einiege CRC Fehler. Wie beseitig man die? Ich habe beide Karten formatiert und sicherheitshalber die V3 draufkopiert und eine Kipie als update.tmp. (Die äußere mit Fat32, die innere mit ext3.)

Keine Änderung... Im Webserver kommt nach 3 MInuten der Abbruch, CRC Fehler werden in der Konsole gemeldet. Nach einem anhalten per STRG-C gebe ich fis load kernel2; exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock4 rw rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash" ein.

Nach kurzer Zeit steht da "exec -c "noinitrd console=ttymxc", was ich per Enter bestätige. Es endet in einer Kernel Panic. Nun klappt nicht mal mehr der Resettaster. bestätige ich den Befghel nicht, habe ich eineBash, aber die kann anscheinen nur fis und help. Aber nichts mit TFTPBOOT zB..

Probiere ich den anderen "Bashstartbefehl" mit Kernel1, sieht es so aus:

RedBoot> fis load kernel1; exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock2 rw rootfstype=jffs2 video=mxcfb:TV-PAL init=/bin/bash" ... Read from 0xa3ee0000-0xa3f00000 at 0xe7fa0000: . ... Read from 0xa0108000-0xa02948d0 at 0xe0040000: ..** Error: uncorrectable ECC error in flash at addr 0x00084000 page 264, col 0: ECC status=0x8:0x0:0x0:0x0

Checksum: 0x78262787 Checksum2: 0x0f9151ff | 0x0018c8d0 ** Warning - checksum failure. stored: 0x0f9151ff, computed: 0x78262787 Can't execute Linux - invalid entry address

Hat jemand eine Idee, was ich tun kann? Kennt jemand das Root Passwort?

VG, brandse

Moin Leute,

jetzt habe ich mich hier extra angemeldet um erstmal danke für die vielen hilfreichen Informationen zu sagen.

Ich habs geschafft mein Gateway erfolgreich per UART zu reparieren. Zum Glück hatte es noch die V3. Habe mir dann noch ein defektes besorgt um das ganze zu verifizieren bei dem bereits die V5 installiert war.

Und ich muss euch sagen, diese konnte ich ebenfalls wiederherstellen. Als ich das Dateisystem ein wenig gefixt hatte hat das Gateway angefangen den Kernel zu booten und sich dann anschließend selbst repariert. (Sogar wesentlich einfacher als bei der V3).

Bei meine V3 Gateway war es tatsächlich so das Kernel1 total korrupt war, und Kernel2 zwar sporadisch noch lief, die ersten Sektoren in denen der Kernel geschrieben ist jedoch anscheinend wirklich auf dem NAND defekt waren und somit oft nur FF FF FF ausgegeben haben.

Ich habe es dann erfolgreich geschafft den Anfang vom Kernel um ein paar Byte weiter nach hinten zu verschieben (Speicher für den Kernel reicht aus, für diesen sind 2MB reserviert, der Kernel hat aber nur 1.6MB). Hiermit konnte ich das System dann booten, das rootfs reparieren und anschließend per Firmware Update Kernel1 und rootfs1 reparieren.

Es gibt also auch Hoffnung für die V5. Saubere Datensätze kann man aus den FW Updates extrahieren, hier fehlt dann aber natürlich die Lizenzdatei die man unbedingt vom Gateway per UART sichern muss um diese anschließend zurück zu spielen.

Leider kann man hier kein HOWTO schreiben da die Fehler oft sehr individuell sind und das Gateway doch ein relativ komplexes System ist. Aber zumindest kann ich euch sagen eine Reparatur ist möglich. Ich bin auch gern noch auf der Suche nach Testobjekten falls noch jemand was im Müllcontainer liegen hat.

Achja, und wie lange das System dann wirklich läuft weiss leider auch nur der liebe Gott :)

Hi wo liegt die Lizenz Datei ?

hi ich habe mal wieder ein Thema.

U-Boot 2019.04-rc4-00071-g1111ff6-dirty (Nov 18 2019 - 09:42:41 +0100)TKSIPGW

MAIN CPU: Freescale i.MX27 at 399.600 MHz

Board: TKS-IPGW revision 0 I2C: ready DRAM: 64 MiB

dann passiert nichts

Wie hast du die Daten kopiert ?

So ich habe tatsächlich die v5 wieder beleben können und eine Kopie der System.sqfs datei. Leider lasst es sich nicht im Gerateportal anmelden. Es erscheint immer ein Fehler. Hatte das schon jmd?

Und irgendwie kriege ich es nicht mehr hin in die Shell zukommen. Warum auch immer. Wie macht ihr es ?

Hi und guten Abend. Den heute hätte ich gerne anders verbracht, aber nachdem mein TKS-IP-Gateway sich nach einem (unfreiwilligen) FI-Test entschlossen hatte, mal wieder nicht mehr zu booten, musste es halt mal wieder repariert werden.

Inzwischen ist meines auch auf der v5. Die externe SD hab ich schon lange nicht mehr drinnen. Die v5 hat ja einen "automatischen Reparaturmodus": Wenn er den Kernel nicht vom internen Flash laden kann, lädt er ihn von der internen SD und setzt eine Flag in der Kernel comamndline. Die bewirkt, dass er (statt zu booten), den Kernel und das SquashFS "system" von der internen SD nochmal in den Flash schreibt und dann neu startet. Hilft nur nix ...

Die Symptome heute:

1

Loading file '/system/kernel.md5' to addr 0xa0000200...

2

Done

3

## Info: input data size = 962 = 0x3C2

4

md5 for a0108000 ... a043ef0f ==> 25bb8680dbcfbe6ff1b0291dbb56a350 != 54619ecd75a946d3dcceb07f67d4ec02 ** ERROR **

5

ubi-kernel-md5 error

6

7

...

8

9

SYSTEM RESTORE

10

/app/sdintern/system/kernel: OK

11

RESTORE FLASH KERNEL

12

sending incremental file list

13

sending incremental file list

14

/app/sdintern/system/system.sqfs: OK

15

RESTORE FLASH SYSTEM

16

17

... 

18

19

Reboot und das gleiche von Vorne

Das Problem: Der Kernel wird im Flash nicht besser, der lädt IMMER mit ner anderen MD5 als er sollte. Ich hab auch mal versucht ihn TROTZDEM zu booten und er meldete CRC-Fehler.

In die Shell kommt ich mit dem 'init=/bin/bash'-Trick auch nicht mehr, anscheinend mag Gira nicht, dass wir selber rumdoktorn und ignorieren das einfach.

Wenn ich den Kernel von der internen SD lade, aber das Flag für die automatische Reparatur NICHT setze (also bootmode=1 statt bootmode=2), versucht er KEINE automatisch Reparatur und bootet "ganz normal") in's System.

Nach langem Hin und Her (naja, 2h), folgende Lösung:

• Wenn der Kernel aus dem Flash nicht laden kann, lädt er ihn von der internen SD
• Danach lädt er das uboot-env ebenfalls von der internen SD (Variable "load_sd0_env")
• Danach lädt er die MD5 des Kernels auf der internen SD, um sie mit dem Kernel im RAM zu vergleichen (Variable "load_sd0_kernel_md5")
• Da die automatische Reparatur bei mir nicht funktioniert, muss ich irgendwie das Bootverhalten ändern
• Das kann ich machen, wenn ich beim Laden des Environments von der internen SD (weil über die habe ich Kontrolle) eine Variable ändere, die er (direkt) danach ausführt
• In der "/system/uboot-env.txt" auf der internen SD wird normalerweise nur eine Variable gesetzt, nämlich die Mac-Addresse
• Nach dem Laden des Environments wird der Code in der Variable "load_sd0_kernel_md5" ausgeführt, der die Kernel-Soll-MD5-Summe lädt

Also habe ich die "/system/uboot-env.txt" auf der internen SD ergänzt um diese Zeile:

1

load_sd0_kernel_md5=setenv bootargs 'console=ttymxc0,115200 mtdparts=mxc_nand.0:128K(SPL),1M(u-boot1),1M(u-boot2),-(ubi) video=mxcfb:TV-PAL bootmode=1'; bootz;

Ich überspringe damit bewusst die MD5-Prüfung des Kernels auf der internen SD-Karte.

Das System bootet, lädt den Kernel vom internen Flash, schlägt bei der MD5-Prüfung fehl, lädt den Kernel von der internen SD in den RAM, lädt das (manipulierte) uboot-env von der internen SD, und führt dann "load_sd0_kernel_md5" aus, was den Kernel im "normalen" Modus bootet.

Martin K. schrieb:

So ich habe tatsächlich die v5 wieder beleben können und eine Kopie der System.sqfs datei. Leider lasst es sich nicht im Gerateportal anmelden. Es erscheint immer ein Fehler. Hatte das schon jmd?

Und irgendwie kriege ich es nicht mehr hin in die Shell zukommen. Warum auch immer. Wie macht ihr es ?

Das Geräteportal nutze ich nicht. Aber was sind denn die Ausgaben deines Gerätes auf der Seriellen? Lädt der Kernel? Lädt das System/Rootfs?

Hat es vll. die Werkseinstellungen übernommen und kommt deswegen nicht mehr in's Internet?

Also das System boot normal.

Ich erreich den intern Webserver zum konfgurieren. Leider bekomme ich das System nicht im gerateportal registriert.

Es meldet aber nach kurzer Zeit invalid Query Paket uber serial.

Es ist aber auch kein TKS System angeschlossen.

Moin,

erstmal Danke für die ganzen Infos die man hier bekommen hat.

Habe mein IP Gateway mit der Hilfe hier, wieder zu laufen bekommen. Hat alles sehr gut funktioniert.

Die TK Anlage ist wieder in Betrieb. Die Einbindung für den Homeserver hat auch funktioniert.

Nur wie bei (Martin_k44), kann ich mich nicht im Gira Geräteportal mit dem Gateway registrieren. Ich besitze zwar noch die Registrierungs-ID als Notiz, habe aber festgestellt das die ID nicht mehr in der Geräteinformation hinterlegt ist.

Hat vllt jemand eine Idee, wie man die Registrierungs-ID wieder erstellen kann?

Vielen Dank

Sebastian