Waere es u.U. nicht besser den nfsd nicht automatisch zu laden sondern, zumindest am Anfang, erst ueber die autoexec einzubinden? /etc/exports muss man ja sowieso erst noch passend vorbelegen.
Tes
Hi schufti
Ich denke das auch. Die Blöcke in den Firmware-Dateien haben Kennungen ("BH" = BlockHeader?) in denen steht, was das ist oder wohin das muss.
Ich kann mich (LEIDER!!!) aus Zeitmangel nicht intensiv mit der Sache befassen.
Oh! Mistversändnis Meinerseits!
@petgunCode:# cat /proc/mtd dev: size erasesize name mtd0: 00400000 00010000 "Physically mapped flash"
Ich konnte nfs noch nicht testen, mache ich aber wahrscheinlich heute Abend noch.
udrec ist bisher das Einzige, dass es schafft, von ARD/ZDF ohne Aussetzer aufzuzeichnen.
Bei nfs (WSFU 3.5/WinXP/PIV 2.4GHz) bekomme ich immer Aussetzer ab ca. 7MBit/s.
udrec kommt auch mit 9MBit/s super klar.
Die Reihenfolge ist falsch und die Kernel-Module musst Du Dir besorgen...wenn die nicht schon im image sind.
Bei mir funktioniert:
...aber ich nehme zur Zeit MacSats b7 mit HDD/USB-FS-Upgrade auf Festplatte...Code:insmod sunrpc insmod lockd insmod nfsd
Kay
Waere es u.U. nicht besser den nfsd nicht automatisch zu laden sondern, zumindest am Anfang, erst ueber die autoexec einzubinden? /etc/exports muss man ja sowieso erst noch passend vorbelegen.
Tes
hi,
ich muss eher sorry sagen, da ich so wenig Ahnung von Linux habe.
Mit der richtigen Reihenfolge kommen auch keine Fehlermeldungen mehr..
...exports werde ich wohl noch schaffen anzulegen..'/mnt/C/ (rw,async,no_root_squash)'...habe ich gemacht...Code:# insmod sunrpc Using /lib/modules/2.4.28/kernel/net/sunrpc/sunrpc.o # insmod lockd Using /lib/modules/2.4.28/kernel/fs/lockd/lockd.o # insmod nfsd Using /lib/modules/2.4.28/kernel/fs/nfsd/nfsd.o
...aber wie gehts jetzt weiter? Wie/wann wird der nfsd gestartet? Ich kann mich auch noch schwach an einen portmapper erinnern...was ist/war damit?
cu,
peter
Last edited by petgun; 28-06-2007 at 20:26.
Waere es hier nicht sinnvoller mit '/sbin/modprobe nfsd' zu arbeiten, oder ist im Image kein modprobe enthalten? Meines Wissens kann man sich dann das haendische Aufloesen der Abhaengigkeiten sparen.
Hm... Ich schau gerade mal auf meinem NFS-Server nach... Du brauchst /sbin/portmap, /usr/sbin/rpc.mountd, /usr/sbin/rpc.nfsd, /sbin/rpc.statd, /sbin/rpc.lockd und /usr/sbin/exportfs. Die Startreihenfolge hier ist portmap->exportfs->rpc.nfsd->rpc.mountd->rpc.statd->rpc.lockd....exports werde ich wohl noch schaffen anzulegen...aber wie gehts dann weiter? Wie/wann wird der nfsd gestartet? Ich kann mich auch noch schwach an einen portmapper erinnern...was ist/war damit?
Vielleicht hilfts...
Tes
Hi,
beim kernel-nfsd läuft das ab dem laden des nfsd.o, die /etc/exports muß schon davor angelegt sein! mit rmmod nfsd kann man stoppen/entladen.
schufti
gibt's nicht...sorry, ich warte dann mal lieber auf ein Image wo das enthalten ist.
wenn ich die /etc/exports anlege und mir dann mit 'cat /etc/exports' anzeigen lasse ist die so wie gewünscht vorhanden. Nach einem Neustart ist exports wieder in der ürsprünglichen Form ohne meinen zusätzlichen Eintrag..
..die letzte Zeile fehlt dann...???# See exports(5) for a description.
# This file contains a list of all directories exported to other computers.
# It is used by rpc.nfsd and rpc.mountd.
/mnt/C/ (rw,async,no_root_squash)
Last edited by petgun; 28-06-2007 at 20:57.
Ist klar, so wie ich das verstehe aenderst du nicht im Flash sondern in der RAM-Disk in die das Filesystem beim Boot kopiert wird. Das ist natuerlich nicht permanent. Deshalb auch mein Wunsch nach der Autoexec. Da kann man dann ein 'echo "/mnt/C (rw,async,no_root_squash)" >>/etc/exports' vor dem '/sbin/modprobe nfsd' einbauen. Da die autoexec auf der HD steht sind deren Eintraege permanent.
Tes
ich hab mir die Firmware des MGB100 mal angeschaut, die man von den einzelnen
Herstellern des MGB100 runterladen kann. Diese Datei (z.B. CHD2WLANU_R400b7.BIN)
besteht offensichtlich aus mehreren Segmenten (ich nenns mal so):
- Bootloader (16 bit code) (16448 Bytes)
- System Recovery Tool (32 bit code) (14368 Bytes)
- Linux kernel (1016168 Bytes)
- gzipped root filesystem (2475327 Bytes)
- unknown filesystem containing html files of admin tool (168552 Bytes)
Jedes dieser Segmente beginnt mit einem 80 Byte langen Header. Der des
Bootloaders sieht z.B. so aus:
0000000: 4c4c 4d5f 5255 5330 3031 0000 0000 857e LLM_RUS001.....~
0000010: 5175 6565 6e00 0000 0000 0000 11e1 6bc7 Queen.........k.
0000020: 00a0 3f00 0060 0000 10c0 3f00 f03f 0000 ..?..`....?..?..
0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
0000040: 4248 0101 5000 0001 00a0 3f00 0b00 0ab0 BH..P.....?.....
Darin haben die Felder folgende Bedeutung:
00..0D ASCII Kennung (je nach Hersteller anders)
10..14 ASCII Kennung
28..2b spätere Position im Flash
2c..2f Länge des Blocks
Den Rest kann ich noch nicht deuten.
Das heißt also, dass die Firmware folgendermassen im Flash angeordnet ist:
Offset (hex) Part
000010 Linux Kernel
100028 root fs
3b0010 filesystem of admin tool (HTML files)
3f0010 System recovery tool
3fc010 Bootloader
Das heißt, dass für den Linuxkernel und das root Filesystem ca. 3,8 MB zur
Verfügung stehen. Das bietet viel Möglichkeiten.
Ausserdem hab ich mal die Conceptronic Firmware neu kompiliert. Lief ohne
irgendwelche Probleme durch (auf einem Slackware 10.2 System). Bei dieser
Firmware ist auch dieses makebin Utility dabei, dass beim Build Vorgang dann die
Datei upgrade.bin aus dem Kernel und der Ramdisk baut. Das README, dass bei
Conceptronic dabei ist, beschreibt recht ausführlich, wie die Firmware aus den
Sourcen bauen kann. Andere Hersteller halten sich da mit Doku mehr bedeckt. Laut
Aussagen hier im Forum und bei MacSat kann man diese upgrade.bin Datei ab
Firmware Version R400b7 dann auch flashen. Man muß also bevor man was macht erst
mal auf die Herstellerfirmware (vermutlich) > R400b7 upgraden. Dann kann man
seine selbstgebauten Images flashen. Diese Images enthalten im Gegensatz zu den
Hersteller Firmwares nur Kernel und root Filesystem. Das sehe ich mal als großen
Vorteil an, da man dann anscheinend, falls man ein nicht lauffähiges Image
geflasht hat immer noch mit dem Recoverytool eine lauffähige Version flashen
kann. Ist aber bis jetzt nur meine Vermutung...
Naja, ich habe mir im Februar so ein Teil besorgt, wußte damals aber noch nicht,
dass man erst mal auf Version R400b7 updaten muß und habe meinen MGB100 somit
getötet. Recovery Mode geht auch nicht mehr. Jetzt habe ich mal versucht mit
einem selbstgebauten Wiggler JTAG Interface eine neue Firmware drauf zu
brennen. Aber mit openwince kommt ich da nicht weiter. Da kommt keine
Kommunikation zum MGB100 zustande. Mit dem Download Tool von RDC klappts auch
nicht. Ich vermute, dass dazu das Wiggler Interface nicht passt. D.h. ich bin
jetzt soweit wie schufti :-(
Hi laxan,
super, deine Analyse. Hilft sicher weiter sobald wir ein funktionierendes JTAG zusammenbringen. ABER: Hast du dir auch mal die orig. pearl FW angesehen? Dort scheint einiges anders zu sein.... zumindest der Aufbau im bin File.
Auf die Sicherheit durch die einfache Struktur der Upgrade-Files habe ich auch gesetzt, Pustekuchen. Das Recoverytool läuft scheinbar ohne funktionierende(n) Kernel(module) nicht.
Mittlerweile weiß ich auch, woran es lag: Beim Buildprozess wurde das Modulverzeichnis nicht angelegt. Der Kernel bootet zwar wunderbar, erkennt auch USB-Sticks, aber ohne die Netzwerkmodule is nichts zu wollen.
Das serielle Konsol-log sieht so aus:
leider scheint aber keine Shell hinter der seriellen Konsole zu hängen ...Code:üLinux version 2.4.32 (root@Build) (gcc-Version 3.3.5 (Debian 1:3.3.5-13)) #5 Mi Jun 27 23:56:44 CEST 2007 BIOS-provided physical RAM map: BIOS-e801: 0000000000000000 - 000000000009f000 (usable) BIOS-e801: 0000000000100000 - 0000000002000000 (usable) 32MB LOWMEM available. On node 0 totalpages: 8192 zone(0): 4096 pages. zone(1): 4096 pages. zone(2): 0 pages. DMI not present. Kernel command line: rw console=ttyS0,38400 a‹T‹AˆÕ‹TˆÖâ Initializing CPU#0 Calibrating delay loop... 50.79 BogoMIPS Memory: 27404k/32768k available (1077k kernel code, 4976k reserved, 717k data, 56k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Dentry cache hash table entries: 4096 (order: 3, 32768 bytes) Inode cache hash table entries: 2048 (order: 2, 16384 bytes) Mount cache hash table entries: 512 (order: 0, 4096 bytes) Buffer cache hash table entries: 1024 (order: 0, 4096 bytes) Page-cache hash table entries: 8192 (order: 3, 32768 bytes) CPU: Cyrix Cx486SLC Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Starting kswapd NTFS driver v1.1.22 [Flags: R/O] Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 7.00beta4-2.4 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx hda: C/H/S=20687/228/80 from BIOS ignored hdb: C/H/S=0/0/0 from BIOS ignored SCSI subsystem driver Revision: 1.00 kmod: failed to exec /sbin/modprobe -s -k scsi_hostadapter, errno = 2 physmap flash device: 400000 at ffc00000 CFI: Found no Physically mapped flash device at location zero kmod: failed to exec /sbin/modprobe -s -k jedec_probe, errno = 2 kmod: failed to exec /sbin/modprobe -s -k map_rom, errno = 2 usb.c: registered new driver usbdevfs usb.c: registered new driver hub ehci_hcd 00:0a.1: PCI device 17f3:6061 ehci_hcd 00:0a.1: irq 14, pci mem c2800000 usb.c: new USB bus registered, assigned bus number 1 ehci_hcd 00:0a.1: USB 2.0 enabled, EHCI 1.00, driver 2003-Dec-29/2.4 hub.c: USB hub found hub.c: 2 ports detected host/usb-ohci.c: USB OHCI at membase 0xc2802000, IRQ 15 host/usb-ohci.c: usb-00:0a.0, PCI device 17f3:6060 usb.c: new USB bus registered, assigned bus number 2 hub.c: USB hub found hub.c: 2 ports detected usb.c: registered new driver usbscanner scanner.c: 0.4.16:USB Scanner Driver usb.c: registered new driver usblp printer.c: v0.13: USB Printer Device Class driver Initializing USB Mass Storage driver... usb.c: registered new driver usb-storage USB Mass Storage support registered. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. NET4: Ethernet Bridge 008 for NET4.0 RAMDISK: Compressed image found at block 0 Freeing initrd memory: 2559k freed EXT2-fs warning: checktime reached, running e2fsck is recommended VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 56k freed init started: BusyBox v1.00-rc2 (2007.06.24-08:17+0000) multi-call binary Starting pid 16, console /dev/console: '/bin/mount' Starting pid 18, console /dev/console: '/etc/rc.d/rc.bridge' set path make dir hub.c: new USB device 00:0a.1-1, assigned address 2 scsi0 : SCSI emulation for USB Mass Storage devices Vendor: Kingston Model: DataTraveler 2.0 Rev: PMAP Type: Direct-Access ANSI SCSI revision: 02 Attached scsi removable disk sda at scsi0, channel 0, id 0, lun 0 SCSI device sda: 4030464 512-byte hdwr sectors (2064 MB) sda: Write Protect is off Partition check: sda: sda1 usb.c: USB disconnect on device 00:0a.1-1 address 2
naja, das neue Teil ist schon unterwegs und die Hoffnung stirbt ja angeblich zuletzt.
hi,
wie kommt man an den 'seriellen Konsol-log? Die Kiste hat doch keine serielle Schnittstelle?
Wieso nur '50.79 BogoMIPS'? Ich dachte die CPU wäre schneller als die der WL-HDD bei der '82.94 BogoMIPS' im kernellog angezeigt werden.
cu,
peter
Doch, hat sie, ist aber nicht rausgefuehrt. Schau mal hier (ca. in der Mitte der Seite):
http://www.routertech.org/viewtopic....sapur&start=15
Die Bogomips sind immer nur innerhalb einer CPU-Familie vergleichbar. Wenn die WL-HDD also nicht auch einen RDC R3210 (oder sehr ähnlich) benutzt kann man die Zahlen nicht vergleichen.Wieso nur '50.79 BogoMIPS'? Ich dachte die CPU wäre schneller als die der WL-HDD bei der '82.94 BogoMIPS' im kernellog angezeigt werden.
Tes
hi,
guter Link. An der Kiste rumlöten wollte ich eigentlich nicht...vielleicht baut die Softwarefraktion später mal einen 'klogd' ein ;-)
aha, ich habe mich schon gewundert weil das Teil wirklich schneller als die WL-HDD mit der 125MHz Broadcom-CPU ist.Die Bogomips sind immer nur innerhalb einer CPU-Familie vergleichbar. Wenn die WL-HDD also nicht auch einen RDC R3210 (oder sehr ähnlich) benutzt kann man die Zahlen nicht vergleichen.
cu,
peter