eva_ramboot.py tcp_check_ack wrong ack 2354 wenn firmware > 9 MB?

[gaebler]

Hallo,

ich experimentiere gerade mit openwrt und einer fritzbox. Wenn die Images größer als 9 MB werden, dann klappt immer der upload ins RAM nicht. Über die serielle Konsole kann man dann die Fehlermeldung [tcp_check_ack] <wrong ack> 2354 sehen. Hat jemand irgendeine Idee, was man da machen kann, damit man auch größere initramfs images ausprobieren kann? eva_ramboot.py und der EVA-FTP-Client.ps verhalten sich gleich.

Danke.

 

[eisbaerin]

Um welche FB geht es denn?

 

[Foren-Tom]

7490

 

[gaebler]

Also ein 31MB ram image von freetz geht problemlos. Die Openwrt images sind nicht auf 1k Grenzen aligned. Allerdings hat mit hex null auffüllen nur dahingehend geholfen, daß die Fehlermeldung von eva weg ist, gebootet wird das image nicht. Eventuell muß da noch ne Prüfsumme hin, im freetz ram image sieht das aus wie 4 byte. Aber vielleicht stammt das auch noch vom Filesystem im ram image. Jedenfalls reicht mit hex null auffüllen auf 1k Grenze nicht. Das image2ram script macht aber kein padding.
Warum das allerdings bis zu einer bestimmten Größe (weiß nicht genau aber ca. 8-9MB funktioniert) und dann nicht mehr?!
Aber weiter komme ich mit meinem Wissen hier nicht.

 

[PeterPawn]

Ich habe hier immer noch nichts von @gaebler gelesen, was die Antwort auf die Frage nach dem Modell betrifft.

Außerdem wäre ein Hex-Dump der ersten 256 Byte des Images und die (komplette) Ausgabe von "stat" für die Image-Datei hilfreich - das File braucht einen passenden Header, damit der Bootloader erst mal den Kernel überhaupt entpacken kann. Und der Kernel muß dann (zumindest wenn's analog zu AVM laufen soll) auch noch den passenden Parser für das "mtdram"-Device benutzen ... zumindest würde "EVA-FTP-Client.ps1" ja versuchen, "mtdram1" als Kernel-Parameter passend zu konfigurieren.

Daher wäre es auch hilfreich, wenn man den kompletten FTP-Dialog mit dem Bootloader mal als Protokoll und nicht nur in Prosa sehen würde ....

Und wenn das keine VR9-Box ist, sieht das alles noch einmal ganz anders aus, weil bei GRX-Boxen der Bootloader noch anders arbeitet und diese Boxen eigentlich zwei laufende Systeme benutzen (einmal "bootcore" als "bare metal hypervisor" und einmal ein "echtes" FRITZ!OS).

Eine Prüfsumme interessiert den Bootloader nicht - ja, die kann (je nach Dateisystem-Scanner im Kernel) sogar kontraproduktiv sein, wenn dadurch das Alignment an integralen Grenzen nicht mehr stimmt.

Wenn ein Freetz-Image (auch bei dieser Box) problemlos funktioniert, liegt es ja offensichtlich am OpenWRT-Image ... also macht die Suche dort ja am ehesten Sinn - daher auch der Hex-Dump und vor allem die Frage, um welches Modell es nun wirklich geht. Selbst wenn die Antwort in #3 stimmen sollte, sollte schon der eigentliche Fragesteller solche Nachfragen beantworten - dazu gab es schon zuviel Unsinn hier zu lesen, als daß man da alles für bare Münze nehmen würde/sollte.

 

[gaebler]

Hallo, ja es ist eine 7490, deshalb hab ich das so stehenlassen.
Also das Openwrt Image funktioniert, wenn es kleiner als ? MB ist. Sprich, ich erstelle ein Image mit z.B. 6MB und eva_ramboot.py bootet es erfolgreich. Füge ich eine große Datei hinzu zu Testzwecken (6MB), dann ist das Image insgesamt 12MB groß und es bootet nicht mehr. Das Skript bleibt dann beim STOR hängen, so als würde nach dem Ende der Datei noch irgendwas fehlen:

> SETENV memsize 0x074fe000
< 200 SETENV command successful
> SETENV kernel_args_tmp mtdram1=0x874fe000,0x88000000
< 200 SETENV command successful
> MEDIA SDRAM
< 200 Media set to MEDIA_SDRAM
> STOR 0x874fe000 0x88000000

Die Datei hat dabei diese Größe:

15228683 -rw-r--r-- 1 root root 11538764 Dec 14 20:25 initramfs-kernel.bin

Der hexdump der ersten 256 Bytes eines großen, nicht funktionierenden Images sieht so aus:

0000000 1281 feed 1134 00b0 2000 8000 0201 075a
0000010 111c 00b0 579b 0101 dbbd 871d 006d 8000
0000020 0000 0000 0000 fd6f ffff b7a3 4c7f d73c
0000030 2c25 ca46 0e65 8b23 f46c 5270 e516 0531
0000040 efb0 7ac2 04a6 8b70 f42e e72d c1b6 95ae
0000050 9f66 f950 36ed b206 1876 09d9 3eba d548
0000060 3ae6 b8c8 51da 763e c49d 9c5c 0826 d5c7
0000070 988a c996 216a edfe 489b b605 74f5 5aff
0000080 edad c5b0 5143 cb24 898e f64c a325 7f92
0000090 0191 cab6 48b6 592e 0b28 3eb3 065d d3e2
00000a0 8a4c c61c 666e 012a 999e 5799 1f6a 4e20
00000b0 ed49 a5f2 d917 3320 ed67 6a33 022c fce4
00000c0 fa3b b884 b45d e385 8b08 ec50 e8d1 c2cb
00000d0 76cd 2431 9649 4f8c 5fcd 99eb b24a 5bbd
00000e0 3ad1 7962 a7d6 b5b0 ccaf c14d 77d4 9da7
00000f0 a27d 20ae d435 881f 5073 462d 202e d9b4

Der Hexdump der ersten 256 Bytes eines kleinen, funktionierenden Images sieht so aus:

0000000 1281 feed f561 0058 2000 8000 0201 075a
0000010 f549 0058 679b 00ab f770 9061 006d 8000
0000020 0000 0000 0000 fd6f ffff b7a3 4c7f d73c
0000030 2c25 ca46 0e65 8b23 f46c 5270 e516 0531
0000040 efb0 7ac2 04a6 8b70 f42e e72d c1b6 95ae
0000050 9f66 f950 36ed b206 1876 09d9 3eba d548
0000060 3ae6 b8c8 51da 763e c49d 9c5c 0826 d5c7
0000070 988a c996 216a edfe 489b b605 74f5 5aff
0000080 edad c5b0 5143 cb24 898e f64c a325 7f92
0000090 0191 cab6 48b6 592e 0b28 3eb3 065d d3e2
00000a0 8a4c c61c 666e 012a 999e 5799 1f6a 4e20
00000b0 ed49 a5f2 d917 3320 ed67 6a33 022c fce4
00000c0 fa3b b884 b45d e385 8b08 ec50 e8d1 c2cb
00000d0 76cd 2431 9649 4f8c 5fcd 99eb b24a 5bbd
00000e0 3ad1 7962 a7d6 b5b0 ccaf c14d 77d4 9da7
00000f0 a27d 20ae d435 881f 5073 462d 202e d9b4

So wird das Image zusammengefügt, was eva-image ist und wie es erzeugt wird, hab ich noch nicht rausgefunden:

define Device/AVM
  DEVICE_VENDOR := AVM
  KERNEL := kernel-bin | append-dtb | lzma | eva-image
  KERNEL_INITRAMFS := $$(KERNEL)
  IMAGE/sysupgrade.bin := append-kernel | pad-to 64k | append-avm-fakeroot | \
    append-rootfs | pad-rootfs | append-metadata | check-size
endef

Wenn ich eva-image weglasse, bekomme ich von eva die Fehlermeldung: ftp_data_poll <ERROR: no RAM address>

-- Zusammenführung Doppelpost gemäß Boardregeln by stoney

Mein manueller Versuch auf 1k Grenze aufzufüllen war wohl falsch, folgende Änderung beim Erzeugen des Images behebt das Problem und größere Images werden auch erfolgreich geladen und gestartet:

KERNEL := kernel-bin | append-dtb | lzma | eva-image | pad-to 1k

 

[PeterPawn]

Also erledigt?

 

[Chatty]

Interessant. @gaebler Wirst du auch das Wiki aktualisieren (Logs, was geht, etc.)?

 

[gaebler]

@PeterPawn Ja, das Problem ist damit erledigt.
@Chatty Da bin ich noch am Anfang, die meiste Arbeit hat ein Andreas Böhler für die 3490 gemacht und im wesentlichen kann man auch die 7362SL Images nehmen bzw. seinen Fork für 3490 selbst compilieren, damit Openwrt startet. Es funktioniert natürlich vieles nicht, aber der Boot funktioniert.

 

[Foren-Tom]

Hallo, ja es ist eine 7490

sag ich doch, aber mir glaubt ja mal wieder keiner

 

[PeterPawn]

mir glaubt ja mal wieder keiner

Warum wohl?

 

[Foren-Tom]

na, weil ich immer Recht habe

 

[PeterPawn]

Siehste ... und jetzt kannst Du das sogar beweisen.

 

[gaebler]

@PeterPawn Ich war da leider zu früh mit der Erfolgsmeldung. Spätere Versuche waren dann wieder nicht mehr erfolgreich.
OpenWRT macht das rootfs als initramfs mit in den Kernel hinein und packt das dann nochmal mit lzma und lzma2eva. Dieses initramfs lädt man dann.
Da die OpenWRT builds zwei Images erstellen, habe ich mal versucht, das sysupgrade.bin auf die gleiche Weise zum RAM Image zu machen, wie beim image2ram script. Das Ergebnis ist, daß das eva_ramboot.py funktioniert und der Kernel bootet, egal wie groß das RAM Image ist, allerdings sein rootfs nicht findet und es auch nicht im /dev/ram0 sucht. Er zeigt dann nur die mtd devices als Möglichkeiten fürs rootfs an.
Ich bin aber in den make files vom freetz bisher nicht dahintergekommen, was man mit dem Kernel machen müßte, damit ein dahinter positioniertes rootfs verwendet wird?!
Bei Gelegenheit werde ich mal im DTB chosen ausprobieren, mit dem man die Kernel command line vorgeben kann, allerdings ist mir nicht klar, mit welchen Methoden beim Parameter root=/dev/ram0 das dahinterliegende Squashfs rootfs ohne z.B. eine Adresse anzugeben, vom Kernel gefunden werden soll.