WL-HDD Alternative

[Tes]

Gibt es Source zum Ethernettreiber fuer den R3210 (also R6040), oder sind das auch nur Binary-Module wie zum WLAN? Wäre mal interessant zu sehen ob das zu irgendwas kompatibel ist oder RDC das Interface komplett selber gestrickt hat.

Tes

[schufti]

Hi,

@ Tes: ja, es gibt die Sourcen für den R6040. Und ich habe gerade gesehen, dass eine neuere Version im RDC-Devkit ist. Werde die mal in mein image kompilieren...

@ marobo: habe das Konzept des x-upgrade verlassen und stelle Files zum "Rebranden" der Box bereit. So kann sich jeder aussuchen, was seine Box sein soll... Anleitung liegt bei.

schufti

[marobo]

@schufti:
Vielen Dank schon einmal! Ich konnte mich noch nicht weiter um meine Box kümmern, aber vielleicht kann ich das File nachher mal ausprobieren.

[Tes]

Hi,

@ Tes: ja, es gibt die Sourcen für den R6040. Und ich habe gerade gesehen, dass eine neuere Version im RDC-Devkit ist. Werde die mal in mein image kompilieren...

Schoen. Welche Version haben sie denn beigelegt? Im 400b7 war die 0.12 drin, bei deinem 2.4.35 lag die 0.15 bei. Hast du die Platine zum Devkit? Wenn ja, was für Hardware hat RDC denn dort drauf verbaut?

BTW: Wer eine grosse HD verbaut hat die auch noch ziemlich voll ist braucht zwingend swap wenn er ein e2fsck machen will. Swap is langsamer als RAM was den e2fsck leider 'etwas' langsam werden lässt. Eine Speichererweiterung wäre schön (Löten von SMD... Ok, besser nicht). Ich bin versucht beim nächsten Mal Swap auf den USB-Stick zu legen.

Tes

[schufti]

Hi,

die neue Version ist 0.16.

Nein, ich habe das Ev-Kit nicht (aber Bilder davon gibts genug im Netz).

Ev. kann man mit großer HD ja ext3 verwenden, da sollte man sich das fscheck ja sparen können. Treiber ist im Kernel.

schufti

[Tes]

Hi,

die neue Version ist 0.16.

Nein, ich habe das Ev-Kit nicht (aber Bilder davon gibts genug im Netz).

Wenn man sich das Bild so ansieht hat Amit nicht wirklich viel gemacht sondern einfach das Devkit nachgebaut und dabei weggelassen was sie nicht brauchten, ansonsten aber genau die auch im Devkit verbauten Chips verwendet.

Ev. kann man mit großer HD ja ext3 verwenden, da sollte man sich das fscheck ja sparen können. Treiber ist im Kernel.

Hin und wieder sollte man auch mit ext3 einen fsck machen. Ich hatte bisher noch keine Probleme, auch mit ext2, es bleibt aber unschön. Der Shutdown beim autobootfs fährt zwar die HD runter, macht aber vorher keinen sauberen umount. Müsste man eigentlich ändern können, aber wohl nur im Flash.

Tes

[schufti]

Hi Tes,

leider hat der neue Treiber

(0.16 02-14-2007 Support mii-tool to R/W phy & fix the bug which the dhcp client can not get IP
)

nicht wirklich was genützt. Sowohl das angeführte mii Tool als auch ethtool bringen keine brauchbaren Ergebnisse. Letzteres meldet immerhin die korrekte Treiberversion

Mittlerweile habe ich eine V0.17 gefunden. Wenn die auch nicht läuft, werde ich mich mal an den Author wenden. Eventuell probier ich ihn auch mal in einem 2.6er Kernel, denn interessanterweise läuft das beigepackte make für den 2.4er eh nicht durch, da mii nicht eingebunden (aber im Treiber ja verwendet) wird.... also dürfte die Funktion auf 2.4 nur theoretisch getestet worden sein.

umount/shutdown
Man müßte mal schauen, wieweit Halt/Rebbot in der initab vorgesehen ist und dazu dann ein halt/reboot skript basteln . Im Kernel (Flash) gibts da nix zu ändern. Da is nur der Kernel und dem ist schnurzpiepegal was vor dem Runterfahren gemacht wird.

schufti

[Tes]

Hi Tes,


umount/shutdown
Man müßte mal schauen, wieweit Halt/Reboot in der initab vorgesehen ist und dazu dann ein halt/reboot skript basteln .

Leider steht weder in der inittab des autobootfs noch in der inittab im Flash was zum Thema shutdown und 'halt' ist ein Teil der busybox. Irgendwas passiert aber, denn ein 'halt' schiesst mir alle Prozesse ab und hält die HD an. Leider passiert aber kein sauberer Unmount von autobootfs und HD.

Seit ich vor dem 'halt' immer noch ein oder zwei 'sync' schicke hatte ich bei den e2fsck keine Fehler mehr, der saubere umount müsste also nicht sein, wäre nur ein weiteres Detail.

Tes

[schufti]

Hi Tes,

habe gerade gesehen, dass BB je nach Alter gar keine runlevel unterstützt. Da gibts nur die init_actions. Also müßte ein initab Eintrag etwa so aussehen:

sh::shutdown:/etc/init.d/rc.shutdown

Das Vorgehen ist hier etwas diffiziler, da ja das root-fs ein loop ist. Ausserdem müssen natürlich etwaige Prozesse (samba, nfs,...) die fs verwenden terminiert (oder gekillt) werden.

Generell würde ich starten mit nfs stop, smb stop oder was das kk so zu bieten hat, dann 1,2 sync, (swapoff -a falls aktiviert) danach wird es haarig. Ein umount -a ist sicher nicht optimal. Zuerst sollten alle unnötigen fs (nicht das mit autobootfs und loop) unmounted werden. Dann das loop ro remounted, danach das mit autobootfs ro remounten. Am Ende das proc umounten.

tja, so oder so ähnlich.

Nach dem Skript killt die BB die restlichen Prozesse und macht ein Reset (aus meiner Sicht hat Amit das auch noch an der falschen Stelle implementiert).

schufti

[Tes]

Hi Tes,

habe gerade gesehen, dass BB je nach Alter gar keine runlevel unterstützt. Da gibts nur die init_actions. Also müßte ein initab Eintrag etwa so aussehen:

sh::shutdown:/etc/init.d/rc.shutdown

Ich hab inzwischen etwas rumgespielt... Er sieht so aus:

::shutdown:/etc/init.d/shutdown

/etc/init.d/shutdown sieht dann so aus:

#!/bin/sh

swapoff -a
/etc/init.d/nfsd stop
/etc/init.d/samba stop
/etc/init.d/pure-ftpd stop
killall -q udhcpc
killall -q dropbear
sync
umount -a -r

Generell würde ich starten mit nfs stop, smb stop oder was das kk so zu bieten hat, dann 1,2 sync, (swapoff -a falls aktiviert) danach wird es haarig. Ein umount -a ist sicher nicht optimal. Zuerst sollten alle unnötigen fs (nicht das mit autobootfs und loop) unmounted werden. Dann das loop ro remounted, danach das mit autobootfs ro remounten. Am Ende das proc umounten.

Tja... Ich schaffe es ueber 'umount -a -r' fast alle Partitionen und das loop-device (also das autobootfs) zumindest nach read-only zu bekommen. Das ist schon die halbe Miete, damit sind diese Partitionen stabil und produzieren beim naechsten Boot keine Warnungen. Leider war es mir nicht möglich, auch nicht mit schmutzigen Tricks wie einem temporären root in einer ramdisk, die Partition auf der das autobootfs liegt nach read-only zu bekommen. 'umount -f' geht auch nicht. Scheint ein echter Deadlock zu sein.

Bis mir was besseres einfällt und um den möglichen Schaden minimal zu halten (und den Zeitaufwand fuer den fsck der sonst eine knappe Stunde braucht) habe ich umpartitioniert. hda1 ist jetzt eine kleine Partition auf der nur das autobootfs und ein paar Backups davon liegen, hda2 ist swap und hda3 ist die Datenpartition. Ich bin noch am Überlegen ob ich hda1 nach ext3 umbauen soll.

BTW: In deinem Image mit 2.4.35 funktioniert das Disk-Util wieder einwandfrei. Ersparte mir den Ausbau der Platte.

BTW2: Bei wirklich grossen Platten (160GB scheint das Maximum fuer 2.5" und IDE zu sein, alles drüber finde ich nur in SATA) reicht der Speicher für e2fsck nicht aus. Mit aktivem Swap geht es, aber es dauert ewig.

BTW3: Es ist übrigens keine gute Idee die Datenpartition mit ext3 zu formatieren. Die doch etwas beschränkte CPU-Leistung schlägt dann gnadenlos zu und die Performance des NFS-Servers bricht auf knapp 2MB/sec ein (Schreibzugriffe).

Tes

[schufti]

Hi,

@Tes: schön, dass ein paar Dinge in meinem Image Anklang finden.
Leider ist es mir noch nicht gelungen, das mii-/ethertool zur Zusammenarbeit mit dem Treiber zu bekommen. Aber ich habe im neuen Treiber das NAPI aktiviert, das einen besseren Rx Durchsatz haben soll. Ein neues Image gibts weiter hinten.

Falls es im Forum noch echte Desperados gibt, habe ich im Anhang ein update-file, das einen RedBoot ins Flash schreibt. Dieser liegt ab 0xFFFE0000 im ROM, überschreibt also das original BIOS und den Recovery-Loader. Wer nicht weiß, was er da tut, sollte die Finger davon lassen, die Anderen sollten sich davor auf alle Fälle über

cat /dev/mtd0 > myImage.bin

eine Sicherung ihres ROM auf den USB machen. Trotzdem könnt ihr euch damit ganz einfach die Box zerschießen!!!! Dann hilft nurmehr JTAG

!!!Serielle Konsole absolut notwendig !!!

RAM: 0x00000000-0x000f0000, 0x00072390-0x000a0000 available
MGB100-RB by Schufti 07/08/07
<press Ctrl+C to enter prompt mode>

RedBoot> ^C
RedBoot>
RedBoot> ip_address -l 192.168.22.108
IP: 192.168.22.108, Default server: 0.0.0.0
RedBoot> load -r -v -m tftp -h 192.168.22.55 -b 0x400000 orig_bl.bin
|
Raw file loaded 0x00400000-0x0040ffff, assumed entry at 0x00400000
RedBoot> fl -s 0x400000 -d 0xffff0000 -l 0x10000
NOR Flash ID = 22a7

[First Sector=3fh,Last Sector=46h]

Erase sector........
Programming...

Ich habe im Beispiel nur den Bereich des orig. BL überschrieben (nein, eigentlich auch den des GUI), den Kernel habe ich nicht angetastet. Daher genügt es, den Bereich 0xfffe0000-0xffffffff zurückzuschreiben um den Recoveryloader wieder verwenden zu können. Wie gesagt, in dem Bereich liegt auch eure MAC, also verwendet EURE Sicherung.

schufti

[Tes]

Hi,

@Tes: schön, dass ein paar Dinge in meinem Image Anklang finden.
Leider ist es mir noch nicht gelungen, das mii-/ethertool zur Zusammenarbeit mit dem Treiber zu bekommen.

Es gibt auch keine Möglichkeit dem Treiber zumindest mal debug Output beizubringen? Also das er ins dmesg schreibt wenn er den Link verliert bzw. meldet wenn er einen Link bekommt und was fuer einen. Mit nur einer LED für Lnk/Act ist das ganze etwas sparsam bestückt wenn es mal Probleme gibt.

Aber ich habe im neuen Treiber das NAPI aktiviert, das einen besseren Rx Durchsatz haben soll. Ein neues Image gibts hier.

Werde ich mir mal ansehen, aber ich kann nicht versprechen, dass ich das in den nächten Tagen gleich reinflashe. Mehr Tx Durchsatz wäre mir lieber.

Tes

[schufti]

Hi!

Ich habe mich mal sehr zusammengerissen und - entgegen meiner Gewohnheit - alle Erkenntnisse geordnet in einem WiKi-Beitrag zusammengefasst.

schufti

[wengi]

DAS IST EINEN APPLAUS WERT
Danke schön.
Ich bin in diesem Thread zwar nicht sehr aktiv, verfolge das Ganze aber mit großem Interesse. Immerhin liegt hier auch noch eine Perle, die bearbeitet werden will

wengi

[marobo]

Hi,

@ Tes: ja, es gibt die Sourcen für den R6040. Und ich habe gerade gesehen, dass eine neuere Version im RDC-Devkit ist. Werde die mal in mein image kompilieren...

@ marobo: habe das Konzept des x-upgrade verlassen und stelle Files zum "Rebranden" der Box bereit. So kann sich jeder aussuchen, was seine Box sein soll... Anleitung liegt bei.

schufti

Ich konnte mich jetzt mal wieder mit der Box beschäftigen und habe versucht, die Pearl.bin aus Deinem Archiv im Recovery-Modus zu flashen.

Also:
- Recovery-Modus bei der Box gestartet
- Per TFTP die Pearl.bin hochgeladen (tftp -i 192.168.123.254 PUT Pearl.bin)
- Ca. eine Minute gewartet
- Dann Strom gezogen, um neu zu booten

Jetzt ist die Box allerdings leider gar nicht mehr zu erreichen - weder über die 192.168.123.254, noch über die 192.168.2.1. Ein Ping geht nicht und ein Zugriff auf das Webinterface schon gar nicht, um die Firmware zu flashen.

Was kann ich nun machen? Wenn ich die Box versuche nochmal im Recovery-Modus zu starten, kommt zwar noch das schnelle Blinken der linken LEDs. Aber auch dann ist die Box nicht mehr unter der 192.168.123.254 erreichbar. Habe ich meine Box nun endgültig geschrottet?