SMT-G3XXX zusaetzlicher Speicherplatz (Forschung)

[xor16rox]

Ich hab mal ein wenig mit jffs2 rumgespielt, um die bisher ungenutzten 6.5 MB Speicherplatz zu aktivieren (Bisher alles kaum getestet, Benutzung auf eigene Gefahr, etc., wie gehabt). Vorausgesetzt ist ein Image mit Telnet/SSH-Zugang. Die Befehle sind an der Kommandozeile der Box einzugeben.

Erstmal sehen, von welchem Speicherblock die Kiste bootet:
dmesg | grep mtdblock

Bei mir kommt dann:
++mount_root: root_device_name = mtdblock3

D.h., mtdblock4 ist der ungenutzte Bereich. Das kann auch umgekehrt sein (Booten von mtdblock4, dann ist mtdblock3 ungenutzt), also aufpassen. Wenn man beim folgenden dd-Befehl einen Fehler macht, kann man es sein, dass die Box nicht mehr bootet).

Test-jffs2-Image runterladen

Test-Image mit wget oder scp auf den Router hochladen, z.B. nach /ramdisk/tmp/

Test-Image in den freien Speicherbereich schreiben:
cd /ramdisk/tmp
dd if=myjffs2.img of=/dev/mtdblock/4

Die Partition mounten:
mount -t jffs2 /dev/mtdblock/4 /mnt

Ergebnis ansehen:
cd /mnt; ls -l
(Die Dateien und Verzeichnisse sind nur zum Testen und koennen nach Belieben geloescht werden)

df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 6.3M 6.3M 0 100% /
/dev/mtdblock/5 1.5M 848.0k 688.0k 55% /configs
/dev/mtdblock/1 192.0k 192.0k 0 100% /firmware
/dev/mtdblock/4 6.5M 1.3M 5.2M 21% /ramdisk/mnt

Nachbemerkung: Der ungenutzte Speicherblock ist nicht strikt ungenutzt. Normalerweise liegt dort die vorherige Firmware-Version. D.h., in gewisser Weise nimmt man sich damit eine von mehreren Moeglichkeiten zur Recovery, falls was schiefgeht. Aber wenn man nicht mit selbsterstellten Firmwares experimentiert, ist die Chance, dass man die Partition braucht, gering. Allerdings bedeutet das, dass man sich durch ein Firmware-Update vermutlich alle Dateien loescht, die man in der freien Partition hinterlegt hat.

(Habe bisher kaum Erfahrung mit jffs2. Ich schliesse nicht aus, dass ich irgendwas voellig falsch mache, aber bisher funzt alles. Feedback welcome. )

 

[syncBit]

Die Gelegenheit den Staub von der Testschachtel zu pusten und sie mal wieder anzuwerfen.

Erstmal sehen, von welchem Speicherblock die Kiste bootet:
dmesg | grep mtdblock

Funktioniert nur bei relativ frisch gebooteter Box, sonst ist dieser Teil längst wieder überschrieben.

Noch ne Warnung:
Das mit dem aufpassen ist absolut ernst zu nehmen!
Wenn man hier Mist baut z.B. falsche (also aktuell genutzte) Partition angibt, dann boote die Kiste ziemlich sicher nicht mehr. Das lässt sich mit Zugriff auf die serielle Schnttstelle, nem tftp server und etwas Basteln wieder geradebiegen.
Und wenn man die Partition mit dem Bootloader oder dem Kernel erwischt, dann hat man einen Haufen Elektroschrott. Ohne Programmieradapter (jtag) und Wissen über den Aufbau der Kiste, das ich hier noch nicht gelesen habe ist dann nix mehr zu wollen!

Wer sich bis jetzt immer noch nicht abschrecken liess: Nur zu, es funktioniert. Habe es gerade getestet.

Kiste bootet noch und die Partition lässt sich auch wieder mounten. Mit allen Daten.

Beim ersten mount dauert es ne Weile, weil der Flash-Bereich erstmal initialisiert wird, (gibt nen Haufen Meldungen auf der Console / in dmesg) aber beim nächsten Mal geht es schon viel schneller.

...
Allerdings bedeutet das, dass man sich durch ein Firmware-Update vermutlich alle Dateien loescht, die man in der freien Partition hinterlegt hat.

Dem ist so! Ich habe es gerade mal ausprobiert. Nach der Aktion einfach mal die Firmware neu geladen. Folge:
Boot-Partition gewechselt; Daten überschrieben (logischerweise, ist ja jetzt die Bootpartion).

P.S.: Wenn man nicht nach /mnt mountet sondern z.B. nach /mnt/daten dann kann man auch gleichzitig noch den USB-Stick verwenden.
P.P.S: Nette Dateien im Image

 

[nbx2001]

xor16rox:

Du hattest doch mal ein Image mit einen selbstkompilierten Kernel, der auch bootete. Wenn man da die properitären teile entfernen könnte bzw. Stück für Stück ersetzt (Atheros WLan-Treiber) könnte man hier ein legales Firmwareimage anbieten.

Mich würde dabei interessieren, ob man den bootloader so hinbiegen kann, das er eventuell ein image von einen USB-Stick liest, was dann gebootet wird. Da schon beim experementieren die Schreibzyklen des Flashs, zumindest den, der in der Box ist.

 

[xor16rox]

Du hattest doch mal ein Image mit einen selbstkompilierten Kernel, der auch bootete. Wenn man da die properitären teile entfernen könnte bzw. Stück für Stück ersetzt (Atheros WLan-Treiber) könnte man hier ein legales Firmwareimage anbieten.

Im Prinzip schon, ist halt ein Haufen Arbeit. Und im Fruehstadium wuerde so ein Image eh keiner haben wollen...

Mich würde dabei interessieren, ob man den bootloader so hinbiegen kann, das er eventuell ein image von einen USB-Stick liest, was dann gebootet wird. Da schon beim experementieren die Schreibzyklen des Flashs, zumindest den, der in der Box ist.

Meinst du sowas? Die NFSRoot - Option hatte ich schon mal irgendwann fuer die dbox2 am Laufen.

Das Build-Script im U-boot Directory erstellt per Default kein u-boot.img. Das
mk_ubootimg.sh-Skript nimmt glaub ich head.bin und u-boot.limg als Parameter, und dann noch eine Wert fuer Pad_Length. Wenn ich da willkuerlich 21000 nehme (weil das iirc in einem der Skripte vorkommt, und der alternative Wert 19936 als zu klein moniert wird) krieg ich ein u-boot.img, das um 2 Bytes kleiner ist als das offizielle. FWIW. Woher weiss man dann den richtigen Pad-Wert?
(Aber am besten spielt man da wohl eh erst ein ein wenig an der u-boot-Konsole mit den Parametern.)

Hat jetzt aber alles im engeren Sinne nix mit dem urspruenglichen Thread-Thema zu tun