mikrocontroller.net

Forum: PC Hard- und Software Alles Rund um den MEDION LIFE P89626 NAS


Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Kernel von den Medion-Sourcen baut auch ohne Probleme, allerdings 
konnte ich noch nicht alle anderen Tools bauen. Laut Konfiguration 
unterstützt der Kernel Multi-Core. Die Frage ist nur: ist dieses der 
gleiche, der mit dem NAS ausgeliefert wurde. Leider habe ich noch keine 
UART-Möglichkeit und kann den Kernel leider nicht mittels uboot 
ausprobieren :(

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk S. schrieb:
> Der Kernel von den Medion-Sourcen baut auch ohne Probleme, allerdings
> konnte ich noch nicht alle anderen Tools bauen. Laut Konfiguration
> unterstützt der Kernel Multi-Core. Die Frage ist nur: ist dieses der
> gleiche, der mit dem NAS ausgeliefert wurde. Leider habe ich noch keine
> UART-Möglichkeit und kann den Kernel leider nicht mittels uboot
> ausprobieren :(

Vermutlich ist es schon der gleiche Kernel. Ich habe ihn gebaut, mit 
unwesentlich geänderter Konfig, und doch für Jens D hochgeladen, er hat 
ihn auch ausprobiert, er bootet zwar nicht richtig, aber aktiviert trotz 
SMP-Konfiguration doch nur einen Kern. Der vom Pogoplug hingegen, der 
auch nicht zu Ende bootet, aktiviert beide, steht alles in diesem Thread 
weiter oben...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ElektronAm schrieb:
> Wieso nimmst du nicht den Kernel von ArchLinux, der ist im RootFS von
> denen.
> Es gibt einen mit und einen ohne PCI.

Hatte ich ja gemacht, booten aber nicht durch, siehe: 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Dirk S. schrieb:
> Leider habe ich noch keine
> UART-Möglichkeit und kann den Kernel leider nicht mittels uboot
> ausprobieren :(

Dann pack den irgendwo hin und ich teste ihn...

Erstmal wäre es ja schon was, wenn man dem Kernel ein anderes rootfs 
mitgeben könnte...

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, der Kernel liegt unter http://dl.dropbox.com/u/9870397/P89626/uImage

Was das rootfs angeht, bin ich auch noch nicht weitergekommen. Ich hätte 
erwartet, dass es irgendwo in den bootargs definiert wäre ...

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

habe gerade von Arch den nopic-Kernel gebootet, das funktioniert auch 
bis zu dem Zeitpunkt, dass er kein Rootfs findet, was mich auch nicht 
wirklich wundert.

Zum einen wird das Flash anders partitioniert als bei unserem Kernel, 
aber er akzeptiert die option root=/dev/sda2.
Problem dabei ist, dass dieser Kernel kein XFS kann und deshalb die 
Platte nicht mounten kann. NFS klappt leider auch nicht, da er auch 
keinen NFS-Support drinne hat. D.h. ich müsste sda2 umformatieren.

Jetzt habe ich aber das Problem, dass ich beim normalen Boot erst sda2 
aushängen muss. Habe mal alle möglichen User-Prozesse gekillt aber dann 
bleibt da noch das Raid-System übrig. Bisher habe ich es noch nicht 
geschafft, dass das Raid die die Partition hergibt. Da ich mich mit Raid 
überhaupt nicht auskenne könnt Ihr mir erklären wie ich da so ein 
'umount' bzw release hin bekomme?

Kann ich feststellen welche Prozesse auf diese Partition zugreifen?

Tschüss Dimpflmoser

Autor: ElektronAm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens D.

Ohh habe ich erst durch dmesg Ausgabe gesehen.

Mann. Mann, Mann, war für verf*cktes Design.

Wenn ich den Code vom dem SATA Treiber richtig lese, haben die folgendes 
bei SATA gemacht :
Sie haben einen Teil vom USB2/Firewire nach SATA Controller genommen und 
in den SoC verpflanzt. Dort wird RAID0/1 und Spanning (Anhängen von 
HDDs) in HARDWARE gemacht. Das ganze SATA Interface (soweit es man im 
Kernel sieht) bekommt von der Sache nichts mit. Die Unterstützung ist 
logischerweise nur auf der Ebene einer ganzen HDD möglich. Da wird auch 
noch ein Mikrocode in den "Controller" geladen.

Die müssen da eine ganze Reihe Sonderfälle abfangen. Daher auch die 
Meldung
ox820sata_qc_issue: Core busy, returning an error.
Da ist das DING (HW RAID Controller) glaube ich noch am Booten.

Auch wird beim ändern der Config zum Teil der Mikrocode neu geladen.

Hier mal die Beschreibung
http://www.plxtech.com/products/consumer/oxuf934dsa
Zu alledem ist dort auch noch eine ARM7 CPU

Dazu gibt es noch einen lustigen DMA Controller
Wenn ich das richtig verstehe kenne ich das Design aus den 90'ern PC 
XT/AT
Der ganze Transfer für SATA und Gigabit geht darüber. Da gibt es keinen 
PCI-DMA, und ARM DMA keine ich jetzt noch nicht.
Zitat /arch/arm/plat-oxnas/include/mach/dma.h
 * We have a generic DMAC that is a two port, memory to memory design, supporting
 * multiple channels, each of which can transfer between any pair of memory
 * regions. This DMAC architecture does not sit well with the std. ARM DMA
 * architecture, thus we define a custom way of acquiring and operating on the
 * available channels of the DMAC


Autor: ElektronAm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Dimpflmoser

was für ein RAID ??

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe mich mal etwas eingelesen.
http://www.landley.net/writing/rootfs-howto.html
So wie es aussieht nutzt der Kernel von Medion initramfs.
Im Abschnitt conclusion steht:

" The four different ways to populate rootfs all have the same result: a 
set of files are extracted into rootfs during the kernel's boot process, 
and if one of those files is an executable "/init" then the kernel runs 
that instead of mounting whatever root= points to."

In den Medion Quellen findet man das Verzeichnis basicfs.initrd mit 
einen script, das init heisst. Dort werden einige interessante Dinge 
gemacht (mount, netzwerk konfiguriert, ...) und am ende /linuxrc 
aufgerufen. Das kommt wiederum von busybox. Ob es wirklich 
/etc/init.d/rcS aufruft, wie in /init steht, weiss ich noch nicht. 
Weiter hab jetzt noch nicht geguckt, aber ich denke das könnt hilfreich 
sein, den Kernel richtig zu booten.

Viel Spass beim weiterhacken
N8

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ElektronAm schrieb:
> Kernel sieht) bekommt von der Sache nichts mit. Die Unterstützung ist
> logischerweise nur auf der Ebene einer ganzen HDD möglich. Da wird auch
> noch ein Mikrocode in den "Controller" geladen.

Wohl die hier:
htpc2 linux-2.6.31.14 # grep -R gmac_copro_firmware *
drivers/net/gmac/gmac-napi.c:        if (request_firmware(&firmware, "gmac_copro_firmware", priv->device)) {
zu finden unter
build_NSA212/basicfs.initrd/lib/firmware/gmac_copro_firmware
 sollte also auch in einem "alternativen" Linux übernehmbar sein...

Was ich komisch finde, unter */lib/modules/2.6.31.14_SMP_820/* auf der 
Box finde ich nur ntfs.ko, aber keine Module mii.ko und gmac.ko, und 
auch kein Mikrocode-Verzeichnis  */lib/modules/firmware/*, habt ihr die 
auf Euren Boxen denn?

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab auch nur ntfs.ko.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach, ich glaube die sind nur im initrd welches aus dem NAND gestartet 
wird, was hinterher im finalen "/" alles gemountet wird ist eh' 
abgefahren "manipuliert", daher haben sie nur Das ntfs-Modul gelassen 
weil es nötig sein könnte beim Mounten einer USB-HDD, die 
Hardware-spezifischen Module haben sie versteckt...

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe Arch-Rootfs auf sda2 & Arch Kernel mit 2 cores am laufen!!!!

Ohje, das was Medion mit uns macht grenzt ja schon fast als Schlafentzug 
und sollte als Körperverletzung verfolgt werden. ;-)

Um halbwegs einen Überblick zu behalten erst mal die groben Schritte:

- Normales Medion System booten
  - /dev/sda2 bzw /dev/md4 umounten
  - mke2fs /dev/sda2
  - /dev/sda2 mounten
  - Arch-Paket auf USB-Dongle laden
  - USB-Dongle mounten
  - Arch-Paket auf sda2 auspacken
  - reboot
- U-Boot Konsole
 - setenv bootargs console=ttyS0,115200 root=/dev/sda2 mem=128M
 - tftp 61000000 uImage.nopci
 - bootm 61000000

Jetzt kommt arch hoch, Username/Passwd: root/root

TODO:
- Rootfs als ext3/4
- Kernel & bootcmd in Flash laden
- die restliche Feinarbeit, die viel mehr Zeit benötigt....

dmesg:
[root@alarm ~]# dmesg
[    0.000000] Linux version 2.6.31.6_SMP_820 (root@ProDev) (gcc version 4.6.0 20110429 (prerelease) (GCC) ) #100 SMP Sun May 29 04:53:45 EDT1
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS
[    0.000000] 1 memory region
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] On node 0 totalpages: 32768
[    0.000000] free_area_init_node: node 0, pgdat c04008e0, node_mem_map c0426000
[    0.000000]   Normal zone: 256 pages used for memmap
[    0.000000]   Normal zone: 0 pages reserved
[    0.000000]   Normal zone: 32512 pages, LIFO batch:7
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 mem=128M
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 128MB = 128MB total
[    0.000000] Memory: 125496KB available (3692K code, 291K data, 124K init, 0K highmem)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:96
[    0.000000] OX820_RPS_init_irq: interrupts 64 to 96
[    0.010000] Console: colour dummy device 80x30
[    0.010000] console [ttyS0] enabled
[    0.020000] Calibrating delay loop... 299.00 BogoMIPS (lpj=1495040)
[    0.250000] Security Framework initialized
[    0.250000] Mount-cache hash table entries: 512
[    0.260000] CPU: Testing write buffer coherency: ok
[    0.260000] Calibrating local timer... 374.49MHz.
[    0.330000] CPU1: Booted secondary processor
[    0.430000] Calibrating delay loop... 299.82 BogoMIPS (lpj=1499136)
[    0.640000] Brought up 2 CPUs
[    0.650000] SMP: Total of 2 processors activated (598.83 BogoMIPS).
[    0.660000] NET: Registered protocol family 16
[    0.660000] Number of DMA channels = 4, version = 4
[    0.670000] Reserving a DMA channel for DirectRAID
[    0.670000] Allocating 389 SRAM generic DMA descriptors
[    0.690000] bio: create slab <bio-0> at 0
[    0.700000] SCSI subsystem initialized
[    0.700000] libata version 3.00 loaded.
[    0.700000] usbcore: registered new interface driver usbfs
[    0.710000] usbcore: registered new interface driver hub
[    0.710000] usbcore: registered new device driver usb
[    0.740000] NET: Registered protocol family 2
[    0.740000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.750000] Switched to NOHz mode on CPU #0
[    0.750000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.750000] Switched to NOHz mode on CPU #1
[    0.760000] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.770000] TCP: Hash tables configured (established 4096 bind 4096)
[    0.770000] TCP reno registered
[    0.780000] NET: Registered protocol family 1
[    0.780000] Create fragment cache
[    0.790000] fuse init (API version 7.12)
[    0.790000] msgmni has been set to 245
[    0.800000] alg: No test for stdrng (krng)
[    0.800000] io scheduler noop registered
[    0.810000] io scheduler anticipatory registered (default)
[    0.810000] io scheduler deadline registered
[    0.820000] io scheduler cfq registered
[    0.840000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.850000] serial8250: ttyS0 at MMIO 0x44200000 (irq = 55) is a 16550A
[    0.860000] brd: module loaded
[    0.870000] loop: module loaded
[    0.880000] ox820sata: OX820 sata core.
[    0.880000] scsi0 : oxnassata
[    0.880000] scsi1 : oxnassata
[    0.890000] ata1: SATA max UDMA/133 irq 50
[    0.890000] ata2: SATA max UDMA/133 irq 50
[    0.890000] ox820sata: reseting SATA core
[    1.420000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.420000] ata1.00: ATA-8: ST1500DL003-9VT16L, CC4A, max UDMA/133
[    1.430000] ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[    1.440000] ata1.00: configured for UDMA/133
[    1.440000] ox820sata: reseting SATA core
[    2.150000] ata2: SATA link down (SStatus 0 SControl 300)
[    2.150000] scsi 0:0:0:0: Direct-Access     ATA      ST1500DL003-9VT1 CC4A PQ: 0 ANSI: 5
[    2.160000] sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
[    2.170000] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    2.170000] sd 0:0:0:0: [sda] Write Protect is off
[    2.180000] tun: Universal TUN/TAP device driver, 1.6
[    2.180000] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    2.180000] NAND: Page read time 40ms
[    2.180000] NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit)
[    2.180000] Scanning device for bad blocks
[    2.210000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.210000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.250000]  sda:
[    2.250000] Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit":
[    2.250000] 0x000000000000-0x000000e00000 : "boot"
[    2.260000] 0x000000e00000-0x000008000000 : "rootfs"
[    2.270000]  sda1 sda2
[    2.270000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.280000] oxnas-ehci oxnas-ehci.0: OXNAS EHCI Host Controller
[    2.280000] oxnas-ehci oxnas-ehci.0: new USB bus registered, assigned bus number 1
[    2.290000] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.320000] oxnas-ehci oxnas-ehci.0: irq 39, io mem 0x00000000
[    2.340000] oxnas-ehci oxnas-ehci.0: USB 0.0 started, EHCI 1.00
[    2.340000] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.350000] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.350000] usb usb1: Product: OXNAS EHCI Host Controller
[    2.360000] usb usb1: Manufacturer: Linux 2.6.31.6_SMP_820 ehci_hcd
[    2.370000] usb usb1: SerialNumber: usb
[    2.370000] usb usb1: configuration #1 chosen from 1 choice
[    2.380000] hub 1-0:1.0: USB hub found
[    2.380000] hub 1-0:1.0: 2 ports detected
[    2.390000] Initializing USB Mass Storage driver...
[    2.390000] usbcore: registered new interface driver usb-storage
[    2.400000] USB Mass Storage support registered.
[    2.400000] mice: PS/2 mouse device common for all mice
[    2.410000] TCP cubic registered
[    2.410000] NET: Registered protocol family 10
[    2.420000] NET: Registered protocol family 17
[    2.420000] RPC: Registered udp transport module.
[    2.420000] RPC: Registered tcp transport module.
[    2.500000] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
[    2.510000] VFS: Mounted root (ext2 filesystem) on device 8:2.
[    2.520000] Freeing init memory: 124K
[    2.700000] usb 1-2: new high speed USB device using oxnas-ehci and address 2
[    2.850000] usb 1-2: New USB device found, idVendor=0718, idProduct=0534
[    2.860000] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.860000] usb 1-2: Product: Atom USB Device
[    2.870000] usb 1-2: Manufacturer: Imation
[    2.870000] usb 1-2: SerialNumber: 07B104030AAE06F4
[    2.880000] usb 1-2: configuration #1 chosen from 1 choice
[    2.880000] scsi2 : SCSI emulation for USB Mass Storage devices
[    2.890000] usb-storage: device found at 2
[    2.890000] usb-storage: waiting for device to settle before scanning
[    4.510000] Probing for Synopsis GMAC, unit 0
[    4.550000] eth0: Tuning GMAC 0 RGMII timings
[    4.550000] eth0: Unknown PHY, type 0x001cc915
[    4.610000] eth0: GMAC ver = 53, vendor ver = 18 at 0xed400000, IRQ 40
[    4.610000] eth0: Found PHY at address 7, type 0x001cc915 -> 10/100/1000
[    4.620000] eth0: Ethernet addr: 00:30:e0:00:00:00
[    4.630000] probe() eth0: Leon x2 clock
[    7.840000] eth0: Unknown PHY, type 0x001cc915
[    7.840000] CoPro offload is active on eth0
[    7.850000] Alloc'ing ARM descs 8192 bytes
[    7.850000] Alloc'ing CoPro parameters 36 bytes
[    7.860000] gmac gmac.0: firmware: requesting gmac_copro_firmware
[    7.890000] scsi 2:0:0:0: Direct-Access     Imation  Atom USB Device  PMAP PQ: 0 ANSI: 0 CCS
[    7.910000] usb-storage: device scan complete
[    7.910000] sd 2:0:0:0: [sdb] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
[    7.920000] CoPro: Programming start address as 0xd000e000
[    8.000000] sd 2:0:0:0: [sdb] Write Protect is off
[    8.000000] sd 2:0:0:0: [sdb] Mode Sense: 03 41 00 00
[    8.000000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[    8.030000] eth0: Resetting GMAC
[    8.030000] eth0: GMAC reset complete
[    8.040000] eth0: Setting Rx flow control thresholds for LAN port
[    8.050000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[    8.060000]  sdb: sdb1
[    8.090000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[    8.090000] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[    8.590000] eth0: Unknown PHY, type 0x001cc915
[    9.090000] eth0: link down
[   11.050000] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.090000] eth0: link up, 100Mbps, full-duplex, using pause, lpa 0x45E1
[   11.090000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

Damit dieser Post nicht zu lange wird schicke ich ihn mal ab, die 
genauere Beschreibung kommt im nächsten Post.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schonmal zwischendurch ein Rieeesen-Jucheeeee!!!!!! Glückwunsch 
Dimpflmoser!

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mii.ko und gmac.ko sind vielleicht direkt in den Kernel kompiliert und 
nicht als Module. Müsste man in der Config vom Kernel sehen.

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
[ 2.250000] Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit": 
[ 2.250000] 0x000000000000-0x000000e00000 : "boot" 
[ 2.260000] 0x000000e00000-0x000008000000 : "rootfs" 

Hmm, wird der nand speicher nicht richtig erkannt?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> mii.ko und gmac.ko sind vielleicht direkt in den Kernel kompiliert und
> nicht als Module. Müsste man in der Config vom Kernel sehen.

Na eben aus der Config weiss ich daß es Module sein sollten.

@Dimpflmoser:
Wäre interessant herauszufinden wieso der Pogoplug-Kernel doch beide 
Cores aktiviert. Leider sind die Kernel-Sourcen sehr schlecht 
minteinander vergleichbar.

Wäre es denn möglich, wenn man eine gescheite uBoot bootcmd setzt, daß 
immer versucht wird, kernel + rootfs (optional auch ein initrd) von der 
internen Platte geladen wird, und falls diese nicht da sind, kernel und 
original-FW aus dem NAND?

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So jetzt versuche ich mal zusammen zu fassen was notwendig ist um den 
Arch-Kernel zu booten und das Rootfs auf sda2 zu packen:

- sda2 wird mit xfs ausgeliefert, was der Arch-Kernel nicht ohne 
zusätzliche Module bootet. Es wäre wahrscheinlich ein begrenzter aufwand 
ein neues Image mit XFS-support zu bauen, dann kann man sich die 
Umformatierung von sda2 sparen.
- sda2 wird durch einen Raid-Manager eingebunden. Siehe:
md: bind<sda2>
raid1: raid set md4 active with 1 out of 2 mirrors
md4 using HW RAID-1
HW-RAID1 sda2, is read/write.
HW-RAID1 using disk sda2 on port 0 mirror 0
md4: detected capacity change from 0 to 1499772813312
 md4: unknown partition table
Filesystem "md4": Disabling barriers, trial barrier write failed
XFS mounting filesystem md4

- Jetzt muss zunächst der mount von /dev/md4 weg. Ich bin mir nicht 
sicher welche Prozesse auf /dev/md4 zugreifen, deshalb habe ich per 'ps 
w' und 'kill <pid>' alle verdächtigen Prozesse gekillt. Den Prozess 
'init' nicht killen (führt zum reboot), die Prozesse in eckigen klammern 
gehören AFAIK dem Kernel, die können wir nicht killen.

/dev/md4 ist mehrmals gemounted. deshalb mehrmals folgendes Kommando 
ausführen:
umount /dev/md4
Der Mountpunt /i-data/<devId> konnte nicht freigegeben werden, da er 
immer busy war. Deshalb ein lazy unmount durch:
umount -l /dev/md4

- Damit ist das Gerät frei und wir können /dev/sda2 neu formatieren per
mke2fs /dev/sda2
- Jetzt wäre es eine gute Gelegenheit einen Kaffe oder ein Bier zu 
holen.
- Es bleibt bestimmt auch genügend Zeit für eine Pizza.
- Alternativ könnte man auch ext3 probieren aber dafür muss man sich ein 
mke3fs bzw tune2fs auf's Gerät bzw USB-Stick packen.

- Nach der Formatierung müssen dir Rootfs-Daten auf die Partition.
Ich konnte sda2 immer noch nicht Mounten weil es busy war. Ich hatte 
mein System neu gestartet mit der selben Wirkung. Man muss den 
Raid-Manager stoppen, damit sda2 frei gegeben wird. (Geht bestimmt auch 
ohne reboot)
# mdadm --manage -S /dev/md4
md: md4 stopped.
md: unbind<sda2>
md: export_rdev(sda2)
md4: detected capacity change from 1499772813312 to 0
mdadm: stopped /dev/md4
- Jetzt kann man aber mounten, in diese Partion wechseln und Arch-Archiv 
auspacken
mkdir /mnt/tmp
mount /dev/sda2 /mnt/tmp
cd /mnt/tmp/
tar zxvf /e-data/3F49-BDA4/NAS/ArchLinuxARM-oxnas-latest.tar.gz
- Vielleicht noch ein schnelles Bier?

Jetzt ist das System soweit vorbereitet für einen Neustart
reboot

- U-Boot unterbrechen und folgende Kommandos absetzen:
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)

U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0 
$ 
$ setenv bootargs console=ttyS0,115200 root=/dev/sda2 mem=128M
$ setenv ipaddr 192.168.178.19
$ setenv serverip 192.168.178.26
$ tftp 61000000 uImage.nopci
Wait GMAC to reset
Wait for PHY reset.
PHY is Realtek RTL8211E
Wait for link to come up.......Link up
Wait for auto-negotiation to complete
Link is 100M
TFTP from server 192.168.178.26; our IP address is 192.168.178.19
Filename 'uImage.nopci'.
Load address: 0x61000000
Loading: #################################################################       #################################################################       #################################################################    #################################################################        #################################################################       #################################################################
################################
done
Bytes transferred = 2159948 (20f54c hex)
$ bootm 61000000
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2159884 Bytes =  2.1 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...........................................................................................................................
[    0.000000] Linux version 2.6.31.6_SMP_820 (root@ProDev) (gcc version 4.6.0 20110429 (prerelease) (GCC) ) #100 SMP Sun May 29 04:53:45 EDT1
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS
....

- Die Variablen für ipaddr und serverip habe ich mit dem Befehl 
'saveenv' im Nand gespeichert.
- Eigentlich sollte es auch kein Problem sein das tftp-Kommando in das 
boot-Kommando reinzupacken, dann bootet das System automatisch von TFTP, 
aber dann halt nicht mehr den Standardkernel vom NAND. Wobei man das ja 
durch die ENV wieder rückgängig machen kann.

Soweit mal meine knappe Zusammenfassung. Ich muss jetzt ins Bett.
Hier noch ein paar Punkte, die ich mir noch aufgeschrieben habe, um das 
etwas runder zu machen.
TODOs:
- U-Boot env modifizieren damit TFTP beim Booten automatisch ausgeführt 
wird
  Relativ unkritisch, die Daten weden alle in der U-Boot-Env 
gespeichert, die man später rekonstruieren kann. Mir wäre nicht bewusst 
was man dabei kaputt machen kann.
- U-Boot-Env-Image für jene, die nicht per UART auf U-Boot kommen, dann 
könnte man das Image per nandwrite schreiben.
  Eher kritisch, wenn man da das falsch Image nimmt kann man die Box 
bricken.
- Neuer Arch-Kernel mit XFS bauen
  Unkritisch, Fleisarbeit, reduziert für andere die Mühe sda2 zu 
formatieren
- MTD-Format Info übergeben
  Unkritisch, Damit hat der Arch-Kernel zugriff auf die Daten im Nand,
  man könnte so eventuell auch das original rootfs booten.
  Was bringt's?
- Kernel in MTD-Reinschreiben
  Kritisch, damit man den TFTP-Server nicht mehr benötigt muss der 
Kernel ins NAND
  Wir müssten checken ob das uImage.nopci kleiner ist als das verfügbare 
MTDx.
  Wenn man beim NAND-Schreiben einen Fehler macht kann man U-Boot 
zerstören und die Box bricken.

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> [ 2.250000] Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit":
> [ 2.250000] 0x000000000000-0x000000e00000 : "boot"
> [ 2.260000] 0x000000e00000-0x000008000000 : "rootfs"
>
> Hmm, wird der nand speicher nicht richtig erkannt?
>
Ja, die Formatierung des NAND-Speichers wird wohl im Kernel gesetzt. Man 
kann sie (bei meinem Arm-Angstrom-Bord in der Firma) auch als 
Boot-Paramter mitgeben.
Z.b. beim Angstrom, bei unserer Kiste muss das natürlich anders lauten:
setenv mtdparts atmel_nand:128k(b)ro,256k(u)ro,128k(e1)ro,128k(e2)ro,3M(l),-(root)
setenv bootargs mem=64M console=ttyS0,115200 mtdparts=$(mtdparts) root=/dev/nfs rw nfsroot=$(serverip):/srv/rootfs.2.6.38 ip=$(ipaddr)::$(gatewayip):$(netmask):::off ubi.mtd=root,2048
setenv bootargs $(ba.nfs)

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Wäre es denn möglich, wenn man eine gescheite uBoot bootcmd setzt, daß
> immer versucht wird, kernel + rootfs (optional auch ein initrd) von der
> internen Platte geladen wird, und falls diese nicht da sind, kernel und
> original-FW aus dem NAND?

Hm, weiß nicht wir vom U-Boot aus den Kernel von der Platte ziehen 
könne, wäre natürlich genial. Ansonsten wäre im NAND auch noch etwas 
Platz, eventuell kann man das ja noch den Kernel irgendwo unter 
bekommen.

Wobei ich mir nicht sicher bin was dagegen spricht dem Medion-Kernel 
durch den Pogoplug-Kernel zu ersetzten, falls dieser das Medion-Rootfs 
richtig mounten kann.
Demnach sollten wir jetzt mal rausfinden wie der mtdparts-Parameter für 
unser NAND lauten muss. Eventuell kann man das ja auch fest in die 
Kernelkonfiguration beim Compilieren rein schreiben.

Was ich dabei noch unsicher finde wie der Medion-Kernel sein Ramfs oder 
was auch immer lädt? Ich habe das immer noch nicht verstanden, liegt 
dieses initiale Rootfs/Ramfs/initrd im MTD? Ist das ein Boot-Parameter 
der auch beim Kernel eingebrannt ist?

Ob man den U-Boot dazu bekommt eine Fallback-Option zu implementieren 
weiß ich auch nicht, mir ist bisher nicht bewusst, dass ich da 
irgendwelche Bedingungen abfragen kann und daraufhin verschiedene Wege 
einschlagen kann. Da weiß vielleicht jemand anderes mehr.

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Was ich dabei noch unsicher finde wie der Medion-Kernel sein Ramfs oder
> was auch immer lädt? Ich habe das immer noch nicht verstanden, liegt
> dieses initiale Rootfs/Ramfs/initrd im MTD? Ist das ein Boot-Parameter
> der auch beim Kernel eingebrannt ist?

Teilweise habe ich das schon im Post
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"
herausbekommen.

Einfach mal
http://www.landley.net/writing/rootfs-howto.html
lesen, für den Zusammenhang es lesenswert.

In der Kernel Config steht
...
CONFIG_INITRAMFS_SOURCE="../build/fs.initrd/"
...

d.h., dass der Kernel sich dieses Verzeichnis beim bauen nimmt und 
daraus ein initramfs baut. Wenn man sich 
build_NSA212/trunk/build/fs.initrd anschaut, dann sieht es schon wie das 
root-Verzeichnis der Medion-Kiste aus.


Wir sollten aber auch beachten, dass noch folgende Teile aus dem NAND 
gemountet sind:

mtd5: 00a00000 00020000 "etc"
mtd6: 00a00000 00020000 "info"
mtd7: 05dc0000 00020000 "sysdisk"

Siehe Ausgabe von mount
http://www.mikrocontroller.net/articles/P89626#mount_Punkte

Ich vermute, dass das die Zyxel spezifischen Sachen sind, wie das Zyxel 
Paketsystem und einige Konfigurationen. Das ist nur Spekulation. Dadurch 
wäre der Support einfacher, die müssten einfach nur den Teil des NANDs 
neu schreiben, bei einem Update/Bugfix.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Wäre es denn möglich, wenn man eine gescheite uBoot bootcmd setzt, daß
> immer versucht wird, kernel + rootfs (optional auch ein initrd) von der
> internen Platte geladen wird, und falls diese nicht da sind, kernel und
> original-FW aus dem NAND?

Dimpflmoser schrieb:
> Ob man den U-Boot dazu bekommt eine Fallback-Option zu implementieren
> weiß ich auch nicht, mir ist bisher nicht bewusst, dass ich da
> irgendwelche Bedingungen abfragen kann und daraufhin verschiedene Wege
> einschlagen kann. Da weiß vielleicht jemand anderes mehr.

Für beide: Ja man kann einfache "if" Abfragen machen. Man könnte z.B. 
testen ob eine bestimmte IP Adresse per ping erreichbar ist und nur dann 
irgendwas machen. Hier mal ein ungetesteter Vorschlag:
setenv do_tftp-boot 'setenv bootargs console=ttyS0,115200 root=/dev/sda2 mem=128M; tftp 61000000 uImage.nopci; bootm 61000000'
setenv tftp-boot 'if ping ${serverip}; then run do_tftp-boot; fi;'
setenv bootcmd 'run tftp-boot; run boot_nand'
serverip muss auf dem TFTP Server gesetzt sein und "boot_nand" ist der 
Fallback und startet die Box so wie immer, siehe: P89626: uboot env



Ich hatte Aldi direkt angeschrieben, wegen dem Dual-Core, nun kam eine 
Rückmeldung:
wir beziehen uns auf Ihre unten stehende E-Mail, welche uns über unseren Handelspartner, die ALDI Einkauf GmbH & Co. oHG, erreichte und bedanken uns für Ihr Interesse an den Produkten aus unserem Hause.

Nachfolgend ein Auszug aus der Produktbeschreibung des Prozessors:
- Doppelkern ARM11MP Prozessor Architektur, wobei jeder Kern mit 750 MHz getaktet ist.
- Die Doppelkern Architektur ermöglicht die Entwickung von maßgeschneiderten abgegrenzten Anwendungen, ohne dabei die NAS Grundfunktion zu beeinträchtigen

Die Anzeige aus dem Bootprozess des Linux Kernels stellt dar, dass ein Prozessor gefunden und aktiviert wurde, diese zeigt jedoch nicht an, wieviele Kerne (Cores) vorhanden sind.

Die NAS wurde dementsprechend korrekt beworben, ein Softwareupdate ist aus jetziger Sicht nicht erforderlich.
Das ist ja ein Witz!

Habt ihr mal ein paar Argumente die den zweitletzten Satz entkräftet? 
Dann schreibe ich zurück.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk S. schrieb:
> Ok, der Kernel liegt unter http://dl.dropbox.com/u/9870397/P89626/uImage
>
> Was das rootfs angeht, bin ich auch noch nicht weitergekommen. Ich hätte
> erwartet, dass es irgendwo in den bootargs definiert wäre ...

Sieht ganz gut aus, glaube ich:
Filename 'uImage'.
Load address: 0x61000000
Loading: *
ARP Resend request
T invalid RARP header
#################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ########################################
done
Bytes transferred = 5196296 (4f4a08 hex)
$ bootm 61000000
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.14_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    5196232 Bytes =  5 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux......................................................................................................................................................................................................................................................... done, booting the kernel.
Linux version 2.6.31.14_SMP_820 (ds@hera) (gcc version 4.3.2 (crosstool-NG-1.8.0) ) #10 SMP Tue Dec 13 22:43:51 CET 2011
CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
Machine: Oxsemi NAS
1 memory region
Ignoring unrecognised tag 0x00000000
Memory policy: ECC disabled, Data cache writealloc
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
Kernel command line: console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 mem=128M poweroutage=yes
PID hash table entries: 512 (order: 9, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 128MB = 128MB total
Memory: 121684KB available (5340K code, 338K data, 2220K init, 0K highmem)
Hierarchical RCU implementation.
NR_IRQS:96
OX820_RPS_init_irq: interrupts 64 to 96
ox820_clocksource_init() Timer 2 running at 390625 Hz
Console: colour dummy device 80x30
console [ttyS0] enabled
Calibrating delay loop... 299.00 BogoMIPS (lpj=1495040)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
Calibrating local timer... 374.48MHz.
Brought up 1 CPUs
SMP: Total of 1 processors activated (299.00 BogoMIPS).
NET: Registered protocol family 16
Number of DMA channels = 4, version = 4
Allocating 303 SRAM generic DMA descriptors
bio: create slab <bio-0> at 0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
Switched to NOHz mode on CPU #0
TCP established hash table entries: 4096 (order: 3, 32768 bytes)
TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 4096 bind 4096)
TCP reno registered
NET: Registered protocol family 1
Create fragment cache
MitraStar NAS GPIO driver/controller 1.00
Initialize LEDs
 o SYS LED
 o COPY LED
 o Quota 4 LED
Initialize buzzer
Initialize buttons
 o Copy Button
 o Reset Button
nas_gpio: Register a char device 254:0
audit: initializing netlink socket (disabled)
type=2000 audit(0.810:1): initialized
VFS: Disk quotas dquot_6.5.2
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
fuse init (API version 7.12)
SGI XFS with security attributes, large block/inode numbers, no debug enabled
SGI XFS Quota Management subsystem
msgmni has been set to 237
alg: No test for stdrng (krng)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
serial8250: ttyS0 at MMIO 0x44200000 (irq = 55) is a 16550A
brd: module loaded
loop: module loaded
ox820sata: OX820 sata core.
scsi0 : oxnassata
scsi1 : oxnassata
ata1: SATA max UDMA/133 irq 50
ata2: SATA max UDMA/133 irq 50
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: ST1500DL003-9VT16L, CC4A, max UDMA/133
ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0x9 t4
ata1.00: configured for UDMA/133
ata1: EH complete
ata2: SATA link down (SStatus 0 SControl 300)
scsi 0:0:0:0: Direct-Access     ATA      ST1500DL003-9VT1 CC4A PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
sd 0:0:0:0: [sda] 4096-byte physical blocks
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda:
sd 0:0:0:0: Attached scsi generic sg0 type 0
 sda1 sda2
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
PPP BSD Compression module registered
sd 0:0:0:0: [sda] Attached SCSI disk
PPP MPPE Compression module registered
NET: Registered protocol family 24
PPPoL2TP kernel driver, V1.0
NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit)
Scanning device for bad blocks
Creating 7 MTD partitions on "NAND 128MiB 3,3V 8-bit":
0x000000000000-0x000000040000 : "stage1"
0x000000040000-0x0000003c0000 : "uboot"
0x0000003c0000-0x000000440000 : "uboot_env"
0x000000440000-0x000000e40000 : "kernel"
0x000000e40000-0x000001840000 : "etc"
0x000001840000-0x000002240000 : "info"
0x000002240000-0x000008000000 : "sysdisk"
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
Start USB clocks
oxnas-ehci oxnas-ehci.0: OXNAS EHCI Host Controller
oxnas-ehci oxnas-ehci.0: new USB bus registered, assigned bus number 1
oxnas-ehci oxnas-ehci.0: irq 39, io mem 0x00000000
oxnas-ehci oxnas-ehci.0: USB 0.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
usbcore: registered new interface driver usblp
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver ums-datafab
usbcore: registered new interface driver ums-freecom
usbcore: registered new interface driver ums-isd200
usbcore: registered new interface driver ums-jumpshot
usbcore: registered new interface driver ums-sddr09
usbcore: registered new interface driver ums-sddr55
usbcore: registered new interface driver ums-usbat
mice: PS/2 mouse device common for all mice
md: linear personality registered for level -1
md: raid0 personality registered for level 0
md: raid1 personality registered for level 1
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
usbhid: v2.6:USB HID core driver
TCP cubic registered
NET: Registered protocol family 10
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
registered taskstats version 1
Freeing init memory: 2220K
Warning: unable to open an initial console.
Probing for Synopsis GMAC, unit 0
eth0: Tuning GMAC 0 RGMII timings
eth0: PHY is Realtek RTL8211E, type 0x001cc915
eth0: Disable EEE (Energy Efficient Ethernet 802.3az)
eth0: Set SSC
eth0: GMAC ver = 53, vendor ver = 18 at 0xed400000, IRQ 40
eth0: Found PHY at address 7, type 0x001cc915 -> 10/100/1000
eth0: Ethernet addr: 00:30:e0:00:00:00
probe() eth0: Leon x2 clock
CoPro offload is active on egiga0
Alloc'ing ARM descs 8192 bytes
Alloc'ing CoPro parameters 40 bytes
gmac gmac.0: firmware: requesting gmac_copro_firmware

Dann dauert es eine ganze weile und geht dann nochmal ein Stück weiter:
CoPro: Programming start address as 0xd000e000
egiga0: Resetting GMAC
egiga0: GMAC reset complete
workaround step1
workaround step2
workaround finish
hw_set_mac_address() Storing port0 mac_adr in global array
egiga0: Setting Rx flow control thresholds for LAN port
CoPro available SRAM end 0x00000001
Copro offload started
Waiting for auto-negotiation to complete
Waiting for auto-negotiation to complete
egiga0: PHY is Realtek RTL8211E, type 0x001cc915
egiga0: Disable EEE (Energy Efficient Ethernet 802.3az)
egiga0: Set SSC
egiga0: link down
ADDRCONF(NETDEV_UP): egiga0: link is not ready
egiga0: link up, 1000Mbps, full-duplex, using pause, lpa 0xC5E1
ADDRCONF(NETDEV_CHANGE): egiga0: link becomes ready

Danach ist dann Schluss...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow, nun bin ich aber echt Überrascht!

Die Box war seid ca. 5Min ausgeschaltet, am hinteren Schalter. Netzteil 
allerdings drin und UART Verbindung mit PC. Keine LED an.

Nun hab ich einen SD-Kartenleser eingesteckt und plötzlich Piept die Box 
zweimal. ca. eine halbe Minute später noch einmal!

Wie kann das denn sein?

Der Schalter SW1, siehe: 
https://secure.flickr.com/photos/jensdiemer/6465730855/ sitzt zwar auf 
der Platine, aber sollte ehr nicht wirklich die Stromzufuhr trennen?

Kann mal jemand die Stromaufnahme messen?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, hab mal meine "usb_key_func" Vorlage ( 
https://github.com/jedie/NAS7820-Tools/tree/master/usb_key_func ) 
getestet. Es Funktioniert und sieht via UART so aus:
sda
sdb
checking sda
Trying to mount /dev/sda1
REISERFS warning (device sda1): super-6502 reiserfs_getopt: unknown mount option "iocharset=utf8"
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
checking sdb
Trying to mount /dev/sdb1
REISERFS warning (device sdb1): super-6502 reiserfs_getopt: unknown mount option "iocharset=utf8"
FAT: utf8 is not a recommended IO charset for FAT filesystems, filesystem will be case sensitive!
cp: '/mnt/parnerkey/usb_key_func.sh' and '/mnt/parnerkey/usb_key_func.sh' are the same file
cmd = cat /etc/Zy_Private /mnt/parnerkey/usb_key_func.sh | md5sum -c /mnt/parnerkey/usb_key_func.md5 
md5 check ok
******************************
Hello from usb_key_func.sh !!!
******************************
udhcpc (v1.17.2) started
Sending discover...
Sending select for 192.168.xxx.xxx...
Lease of 192.168.xxx.xxx obtained, lease time 43200
deleting routers
route: SIOCDELRT: No such process
adding dns 192.168.xxx.yyy
OK, get IP via DHCP.
OK, start telnet.

Please press Enter to activate this console.

Ab dem Punkt kann man sich dann per telnet verbinden... Es sind dann 
nicht viele Dienste am start:
/ # ps
  PID USER       VSZ STAT COMMAND
    1 root      2716 S    /bin/sh /init
    2 root         0 SW<  [kthreadd]
    3 root         0 SW<  [migration/0]
    4 root         0 SW<  [ksoftirqd/0]
    5 root         0 SW<  [events/0]
    6 root         0 SW<  [khelper]
    9 root         0 SW<  [async/mgr]
  105 root         0 SW<  [kblockd/0]
  110 root         0 SW<  [ata/0]
  111 root         0 SW<  [ata_aux]
  112 root         0 SW<  [harddrive_led]
  117 root         0 SW<  [khubd]
  138 root         0 SW<  [button controll]
  150 root         0 SW   [pdflush]
  151 root         0 SW   [pdflush]
  152 root         0 SW<  [kswapd0]
  153 root         0 SW<  [aio/0]
  154 root         0 SW<  [nfsiod]
  155 root         0 SW<  [cifsoplockd]
  163 root         0 SW<  [xfs_mru_cache]
  164 root         0 SW<  [xfslogd/0]
  165 root         0 SW<  [xfsdatad/0]
  166 root         0 SW<  [xfsconvertd/0]
  167 root         0 SW<  [crypto/0]
  659 root         0 SW<  [sd_wq/0]
  674 root         0 SW<  [scsi_eh_0]
  682 root         0 SW<  [scsi_eh_1]
  728 root         0 SW<  [ox820direct_eh]
  758 root         0 SW<  [mtdblockd]
  928 root         0 SW<  [hwraid_eh]
  940 root         0 SW<  [scsi_eh_2]
  941 root         0 SW<  [usb-storage]
 1082 root         0 SW<  [usbhid_resumer]
 1089 root         0 SW<  [rpciod/0]
 1220 root      2716 S    init
 1330 root      2716 S    /sbin/udhcpc -i egiga0
 1334 root      2720 S    telnetd -l /bin/sh
 1335 root      2716 S    init
 1336 root      2796 S    /bin/sh
 1339 root      2796 R    ps

btw. ich hab dazu nun eine alte 16MB SD Karte in einem Kartenleser 
genutzt.


Das wäre doch eine gute Möglichkeit, wenn man z.B. die Platte 
umformatieren möchte!
Weiß aber jemand den Grund, warum die Platte als RAID eingerichtet ist 
und man XFS statt ext4 verwendet?
Vielleicht einfach, weil Zyxel das so macht, weil es auch von denen NAS 
Systeme mit RAID gibt und die es so einheitlicher haben?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu den ständigen Laufwerksgeräuschen:

Ich hab mit meinen usb_key_func die Kiste mal "Nackig" hochfahren 
lassen. Somit laufen keine Dienste wie Samba und Co. Dennoch höre ich 
dieses Komische Geräusch von der Platte. Bin mir auch nicht Sicher ob es 
Zugriffe sind oder Rotieren.

Ich hab die Geräusche mal mit dem Handy Aufgenommen:
berarbeitetes MP3: 
http://dl.dropbox.com/u/10577181/Medion%20P89626%20Festplatte%20Soundclip%20bearbeitet.mp3
Ogirinal MP4 (AAC): 
http://dl.dropbox.com/u/10577181/Medion%20P89626%20Festplatte%20Soundclip%20original.mp4

Hört ihr das selbe bei eurer Box?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
er

Jens D. schrieb:
> Weiß aber jemand den Grund, warum die Platte als RAID eingerichtet ist
> und man XFS statt ext4 verwendet?
> Vielleicht einfach, weil Zyxel das so macht, weil es auch von denen NAS
> Systeme mit RAID gibt und die es so einheitlicher haben?

Scheint sehr wahrscheinlich...

Jens D. schrieb:
> Lucian M. schrieb:
>> Wäre es denn möglich, wenn man eine gescheite uBoot bootcmd setzt, daß
>> immer versucht wird, kernel + rootfs (optional auch ein initrd) von der
>> internen Platte geladen wird, und falls diese nicht da sind, kernel und
>> original-FW aus dem NAND?
>
> Dimpflmoser schrieb:
>> Ob man den U-Boot dazu bekommt eine Fallback-Option zu implementieren
>> weiß ich auch nicht, mir ist bisher nicht bewusst, dass ich da
>> irgendwelche Bedingungen abfragen kann und daraufhin verschiedene Wege
>> einschlagen kann. Da weiß vielleicht jemand anderes mehr.
>
> Für beide: Ja man kann einfache "if" Abfragen machen. Man könnte z.B.
> testen ob eine bestimmte IP Adresse per ping erreichbar ist und nur dann
> irgendwas machen. Hier mal ein ungetesteter Vorschlag:setenv do_tftp-boot 
'setenv bootargs console=ttyS0,115200 root=/dev/sda2 mem=128M; tftp 61000000 
uImage.nopci; bootm 61000000'
> setenv tftp-boot 'if ping ${serverip}; then run do_tftp-boot; fi;'
> setenv bootcmd 'run tftp-boot; run boot_nand'
> serverip muss auf dem TFTP Server gesetzt sein und "boot_nand" ist der
> Fallback und startet die Box so wie immer, siehe: P89626: uboot env

Jens, Dimpflmoser, könntet Ihr bitte in diese Richtung was probieren, 
weil Ihr habt ja UART Zugang? Ich denke schon dass dann uBoot von einer 
ext2-Partition (soll laut Sourcen eh' cramfs, ext2, fat, fdos, jffs2 und 
reiserfs können) der internen Platte sich den Kernel, gegebenenfalls 
auch die initrd laden kann, alles andere erledigt der Kernel/die initrd 
mit entsprechender Kommandozeile, oder?

Meine alte Linkstation Pro von Buffalo, basiert auch auf einem von 
Marvell hergestellten SoC, und tut genau das, sogar auch mit der 
Originalfirmware...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Ich denke schon dass dann uBoot von einer
> ext2-Partition (soll laut Sourcen eh' cramfs, ext2, fat, fdos, jffs2 und
> reiserfs können) der internen Platte sich den Kernel

Hier, in meinem älteren Beitrag kann man sich von der Linkstation 
inspirieren: Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Hier mal ein ungetesteter Vorschlag:setenv do_tftp-boot 'setenv bootargs 
console=ttyS0,115200 root=/dev/sda2 mem=128M; tftp 61000000 uImage.nopci; bootm 
61000000'
> setenv tftp-boot 'if ping ${serverip}; then run do_tftp-boot; fi;'
> setenv bootcmd 'run tftp-boot; run boot_nand'
> serverip muss auf dem TFTP Server gesetzt sein und "boot_nand" ist der
> Fallback und startet die Box so wie immer, siehe: P89626: uboot env

Das sieht gut aus, ich hab es mal Probiert (Mit dem ArchLinux 
"uImage.nopci"):
$ setenv ipaddr 192.168.7.178; setenv serverip 192.168.7.2;
$ setenv do_tftp-boot 'setenv bootargs console=ttyS0,115200 root=/dev/sda1 mem=128M; tftp 61000000 uImage.nopci; bootm 61000000'
$ setenv tftp-boot 'if ping ${serverip}; then run do_tftp-boot; fi;'
$ setenv bootcmd 'run tftp-boot; run boot_nand'
$ run bootcmd
Wait GMAC to reset
Wait for PHY reset.
PHY is Realtek RTL8211E
Wait for link to come up.............Link up
Wait for auto-negotiation to complete
Link is 1000M

ARP Resend request
host 192.168.7.2 is alive
Wait GMAC to reset
Wait for PHY reset.
PHY is Realtek RTL8211E
Wait for link to come up..............Link up
Wait for auto-negotiation to complete
Link is 1000M
TFTP from server 192.168.7.2; our IP address is 192.168.7.178
Filename 'uImage.nopci'.
Load address: 0x61000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ################################
done
Bytes transferred = 2159948 (20f54c hex)
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2159884 Bytes =  2.1 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................... done, booting the kernel.
[    0.000000] Linux version 2.6.31.6_SMP_820 (root@ProDev) (gcc version 4.6.0 20110429 (prerelease) (GCC) ) #100 SMP Sun May 29 04:53:45 EDT 2011
...
[    2.290000] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.300000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[    2.300000] oxnas-ehci oxnas-ehci.0: OXNAS EHCI Host Controller
[    2.310000] oxnas-ehci oxnas-ehci.0: new USB bus registered, assigned bus number 1
[    2.350000] oxnas-ehci oxnas-ehci.0: irq 39, io mem 0x00000000
[    2.370000] oxnas-ehci oxnas-ehci.0: USB 0.0 started, EHCI 1.00
[    2.370000] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[    2.380000] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[    2.380000] usb usb1: Product: OXNAS EHCI Host Controller
[    2.390000] usb usb1: Manufacturer: Linux 2.6.31.6_SMP_820 ehci_hcd
[    2.400000] usb usb1: SerialNumber: usb
[    2.400000] usb usb1: configuration #1 chosen from 1 choice
[    2.410000] hub 1-0:1.0: USB hub found
[    2.410000] hub 1-0:1.0: 2 ports detected
[    2.420000] Initializing USB Mass Storage driver...
[    2.420000] usbcore: registered new interface driver usb-storage
[    2.430000] USB Mass Storage support registered.
[    2.430000] mice: PS/2 mouse device common for all mice
[    2.440000] TCP cubic registered
[    2.440000] NET: Registered protocol family 10
[    2.450000] NET: Registered protocol family 17
[    2.450000] RPC: Registered udp transport module.
[    2.460000] RPC: Registered tcp transport module.
[    2.460000] List of all partitions:
[    2.470000] 0800      1465138584 sda driver: sd
[    2.470000]   0801          514048 sda1
[    2.480000]   0802      1464621952 sda2
[    2.480000] 1f00          131072 mtdblock0 (driver?)
[    2.480000] 1f01           14336 mtdblock1 (driver?)
[    2.490000] 1f02          116736 mtdblock2 (driver?)
[    2.490000] No filesystem could mount root, tried:  ext3 ext2 fuseblk
[    2.500000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
Meine Platte ist noch Original Eingerichtet z.Z. würde ich es gern auch 
so lassen, weil schon Kram drauf ist (Zwar ersetztbar, aber die Original 
Firmware soll auch parallel laufen können, so als Fallback)...

Ich versuche halt ein rootfs vom USB-Stick zu nehmen. Der ist mit ext4 
Eingerichtet. Ich verstehe aber nicht, warum bei "List of all 
partitions:" anscheinend nur die interne Platte und der Flash Kram 
aufgelistet wird, wo doch vorher USB initialisiert wurde.

An ext4 statt ext3 kann es nicht liegen, oder?


Ich hab einmal root=/dev/sda1 und einmal root=/dev/sdb1 Probiert...


btw. Nach dem "Kernel panic" kann man weder mit dem vorderen Taster, 
noch mit dem Hinteren Reset-Knopf einen Neustart veranlassen. Ist das 
bei euch auch so?

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Hört ihr das selbe bei eurer Box?

Ich habe die Kiste jetzt nicht vor mir stehen, aber ich meine sowas höre 
ich auch. Aber sie schaltet sich auch bei nichtgebrauch aus. Dann hört 
man meine ich nix mehr.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Meine Platte ist noch Original Eingerichtet z.Z. würde ich es gern auch
> so lassen, weil schon Kram drauf ist (Zwar ersetztbar, aber die Original
> Firmware soll auch parallel laufen können, so als Fallback)...

Nun, ich würde auf meiner Platte auch nicht so großartig viel ändern 
wollen, damit die Original-FW auch weiterhin starten kann. Ich würde 
sogar das NAND so lassen wie es ist, von der Original-FW ist ja auch 
nichts auf der Platte, sondern alles im NAND, bloß die FW erwartet sda1 
als swap und sda2 als XFS-formatierte Partition mit den Shares zu 
finden, da glaube ich kann man sda2 verkleinern, daran eine kitzekleine 
sda3 als Boot-Partition für Kernel und evtl. initrd erstellen, und 
danach eine erweiterte, größere Partition die man noch beliebig 
unterteilen kann, für verschiedene RootFS die man alternativ booten 
könnte (natürlich, jeweils nach anpassen des uBoot-Environment).

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> da glaube ich kann man sda2 verkleinern, daran eine kitzekleine
> sda3 als Boot-Partition für Kernel und evtl. initrd erstellen, und
> danach eine erweiterte, größere Partition die man noch beliebig
> unterteilen kann

Das wäre genial. Doch wie machen? Zumal das ganze ein RAID ist, oder?

Ich versuche nochmal mein Stick auf der Box neu zu partitionieren und 
als ext2 zu Formatieren...

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Meine Platte ist noch Original Eingerichtet z.Z. würde ich es gern auch
> so lassen, weil schon Kram drauf ist (Zwar ersetztbar, aber die Original
> Firmware soll auch parallel laufen können, so als Fallback)...
>
Für's Erste macht das bestimmt Sinn.
Mittelfristig sollten wir die chaotische Medion-Konfiguration hinter uns 
lassen und uns eher an ein bestehendes Projekt anhängen.

Deshalb ist zunächst mein Ziel den Arch-Kernel mit XFS-Support zu 
compilieren, dann muss man sda2 nicht mehr umformatieren und kann die 
bestehenden Sachen drauf lassen. Man müsste dann nur noch das Arch-Image 
nach /i-data/<platten-Id> auspacken.
Mal sehen wie weit ich da heute Abend komme.

> Ich versuche halt ein rootfs vom USB-Stick zu nehmen. Der ist mit ext4
> Eingerichtet. Ich verstehe aber nicht, warum bei "List of all
> partitions:" anscheinend nur die interne Platte und der Flash Kram
> aufgelistet wird, wo doch vorher USB initialisiert wurde.
>
> An ext4 statt ext3 kann es nicht liegen, oder?
Das ist immer noch das selbe Problem wie vor ein paar Tagen:
Der nakte Arch-Kernel integriert das USB-Device noch nict in sein System 
ein weshalb er auch nicht drauf zugreifen kann.
Beim Medion-Kernel wird bestimmt beim Boot vom ramfs mitgeliefert, dass 
der USB-Dongle eingebunden wird.

Mangels Erfahrung kann ich jetzt nicht sagen was man beim Kernel ändern 
muss, dass er den USB-Dongle als Rootfs akzeptiert.

Ob ext4 ein Problem ist weiß ich auch nicht genau. Ich glaube zwar, dass 
es eine Option gibt, die ext4 Rückwärtskompatibel macht, d.h. dass auch 
ein ext2/ext3-Treiber ext4 mounten kann, aber dann gibt man AFAIK die 
Vorteile von Ext4 auf. Der Arch-Kernel kann so wie er jetzt vorliegt 
kein Ext4. Mal sehen, wenn ich mich über XFS hermache, dann kann ich 
Ext4 ja noch aufnehmen.

Bye Dimpflmoser

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Lucian M. schrieb:
>> da glaube ich kann man sda2 verkleinern, daran eine kitzekleine
>> sda3 als Boot-Partition für Kernel und evtl. initrd erstellen, und
>> danach eine erweiterte, größere Partition die man noch beliebig
>> unterteilen kann
>
> Das wäre genial. Doch wie machen? Zumal das ganze ein RAID ist, oder?

Vielleicht mit den Tipps von Dimpfelmoser hier 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS" mit lazy unmount... 
ansonsten zur Not die Platte an einen PC hängen...

Geht denn grundsätzlich diese if-Abfrage in uBoot-Environment? Mangels 
UART-Zugang müsste ich so ein Environment fest verändern, aber auch 
ziemlich sicher sein dass zumindest der Fallback auf die Original-FW 
funktioniert um es bei mir selber zu probieren...

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D.:
Ich habe übrigens die gleiche Antwort von Medion erhalten wegen der Dual 
Core CPU. Andererseits wäre ich überrascht gewesen, wenn tiefer aus 
diesen Sachverhalt eingegangen worden wäre. Ich habe nochmal 
zurückgeschrieben, dass es nicht korrekt ist was sie sagen und mein 
Anliegen bitte jemanden weiterleiten sollen, der es versteht.

Wir werden uns sowieso selbst helfen müssen :)

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> btw. Nach dem "Kernel panic" kann man weder mit dem vorderen Taster,
> noch mit dem Hinteren Reset-Knopf einen Neustart veranlassen. Ist das
> bei euch auch so?

Des g'hört so!

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Lucian M. schrieb:
>> da glaube ich kann man sda2 verkleinern, daran eine kitzekleine
>> sda3 als Boot-Partition für Kernel und evtl. initrd erstellen, und
>> danach eine erweiterte, größere Partition die man noch beliebig
>> unterteilen kann
>
> Das wäre genial. Doch wie machen? Zumal das ganze ein RAID ist, oder?

Dazu muss man sda2 unmounten. Das kann man über den Weg machen, wie ich 
ihn oben für das Neuformatieren von sda2 geschrieben habe.

Letztendlich könnte man versuchen über ein
umount -l /i-data/<device-Id>

Die Platte auszuähngen. Um beim Resizen keine Daten zu verlieren wäre es 
aber bestimmt eine gute Idee vorher alle Prozesse zu beenden/killen die 
auf /i-data/<dev-Id>/... zugreifen.

Danach muss man xfs shrinken, per fdisk die Partion löschen und eine 
neue partition mit den richtigen Parametern anlegen und dann die 3. 
Kleine Boot-Partion anzulegen.
Auf dem Desktop gibt es da tools die machen ein FS-Resize & 
Repartitionierung in einem, ich schätze, dass wir das auf dem NAS nicht 
zur Verfügung haben.
Wie gut man XFS shrinken kann bin ich mir auch nicht sicher.
Ich schätze, da ist es einfacher per Tar den gesamten Inhalt von sda2 
wegsichern, die Partion und XFS neu Anlegen und im Anschluss die Daten 
rückzusichern.
Bei der Resize-Akrobatik ist die Gefahr eines Datenverlustes eh so hoch, 
dass man um ein Backup nicht drum rum kommt.

Tschüss Dimpflmoser

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Um beim Resizen keine Daten zu verlieren wäre es
> aber bestimmt eine gute Idee vorher alle Prozesse zu beenden/killen die
> auf /i-data/<dev-Id>/... zugreifen.

Die müsste man mit
# lsof | grep /i-data
rausbekommen oder nicht?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
>>> da glaube ich kann man sda2 verkleinern, daran eine kitzekleine
>>> sda3 als Boot-Partition für Kernel und evtl. initrd erstellen, und
>>> danach eine erweiterte, größere Partition die man noch beliebig
>>> unterteilen kann
>>
>> Das wäre genial. Doch wie machen? Zumal das ganze ein RAID ist, oder?
>
> Vielleicht mit den Tipps von Dimpfelmoser hier
> Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS" mit lazy unmount...
> ansonsten zur Not die Platte an einen PC hängen...

Das aushängen ist nicht das Problem. Da könnte man halt auch 
https://github.com/jedie/NAS7820-Tools/tree/master/usb_key_func nutzten.
Doch wie die XFS Parition im RAID Kram ohne Datenverluste klein machen? 
(Wobei ich jetzt nicht wirklich wichtigen Kram drauf hab)

Lucian M. schrieb:
> Geht denn grundsätzlich diese if-Abfrage in uBoot-Environment? Mangels
> UART-Zugang müsste ich so ein Environment fest verändern, aber auch
> ziemlich sicher sein dass zumindest der Fallback auf die Original-FW
> funktioniert um es bei mir selber zu probieren...

Auch wenn es bei mir funktioniert: Solange wir kein Kernel haben der 
Durchstartet und telnet/SSH starten kann oder wir ein Funktionierendes 
uBoot mit netconsole haben, macht das noch keinen Sinn.

Dimpflmoser schrieb:
> Ob ext4 ein Problem ist weiß ich auch nicht genau.

Sieht nicht so aus. Auf mit ext2 das selbe:
[    2.420000] VFS: Cannot open root device "sdb1" or unknown-block(0,0)
[    2.430000] Please append a correct "root=" boot option; here are the available partitions:
[    2.440000] 0800      1465138584 sda driver: sd
[    2.440000]   0801          514048 sda1
[    2.450000]   0802      1464621952 sda2
[    2.450000] 1f00          131072 mtdblock0 (driver?)
[    2.450000] 1f01           14336 mtdblock1 (driver?)
[    2.460000] 1f02          116736 mtdblock2 (driver?)
[    2.460000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Spricht dafür, das Partitionen von USB Geräten überhaupt nicht 
berücksichtigt werden.

Dimpflmoser schrieb:
> Mittelfristig sollten wir die chaotische Medion-Konfiguration hinter uns
> lassen und uns eher an ein bestehendes Projekt anhängen.
>
> Deshalb ist zunächst mein Ziel den Arch-Kernel mit XFS-Support zu
> compilieren

Dem Stimme ich zu. Wenn wir jedoch einen eigenen angepassten Kernel 
benötigen, haben wir doch wieder nur eine Insel-Lösung. Es sei denn 
jemand kann die Sache an das Arch-Projekt einfließen lassen.
Hilfreich wäre es vielleicht mehr Informationen bei 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2106&p=11324#p11324 
zu hinterlassen...

Die PLX-NAS7820 bzw. Pogoplug Pro/Video/v3 Unterstützung scheint eh z.Z. 
eine One-Man-Show zu sein, siehe: 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1410

Von daher ist die Frage, ob man mittelfristig überhaupt mit einer 
halbwegs Supporteten Lösung rechnen kann? Oder ob es dabei bleibt, das 
irgendwer einen Funktionierenden Kernel baut und der Allgemeinheit zur 
Verfügung stellt.
Weiß jemand wie das beim Thema Dockstar und Co. aussieht?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Letztendlich könnte man versuchen über einumount -l /i-data/<device-Id>
>
> Die Platte auszuähngen. Um beim Resizen keine Daten zu verlieren wäre es
> aber bestimmt eine gute Idee vorher alle Prozesse zu beenden/killen die
> auf /i-data/<dev-Id>/... zugreifen.

Ist doch alles nicht Nötig, wenn man 
https://github.com/jedie/NAS7820-Tools/tree/master/usb_key_func nutzt:
/ # mount
rootfs on / type rootfs (rw)
/proc on /proc type proc (rw,relatime)
/sys on /sys type sysfs (rw,relatime)
none on /proc/bus/usb type usbfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,uid=0,gid=5,mode=620)
/dev/mtdblock6 on /zyxel/mnt/info type yaffs2 (ro,relatime)
/dev/mtdblock7 on /zyxel/mnt/sysdisk type yaffs2 (ro,relatime)
/dev/sdb1 on /mnt/parnerkey type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro)
Siehe auch: 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Tools zum resizen könnte man dann über ein chroot bekommen. Aber stimmt 
schon, letztlich muß man so wie so ein Backup machen.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Das ist immer noch das selbe Problem wie vor ein paar Tagen:
> Der nakte Arch-Kernel integriert das USB-Device noch nict in sein System
> ein weshalb er auch nicht drauf zugreifen kann.
> Beim Medion-Kernel wird bestimmt beim Boot vom ramfs mitgeliefert, dass
> der USB-Dongle eingebunden wird.

Möglicherweise funktioniert das nur über dieses usbmuxd im Userspace 
nachdem das System gebootet hat (in den GPL-Sourcen sind nur binaries 
davon)? Das ist ein "USB multiplexor daemon for iPhone and iPod Touch 
devices" http://marcansoft.com/blog/iphonelinux/usbmuxd/ und bindet auch 
noch libusb, sowie zwei Libs von deren Sourcen im GPL-Paket anscheinend 
jede Spur fehlt: libplist und libmobiledevice 
(http://www.libimobiledevice.org/) ein.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine ähnliche Hardware gefunden: Level One GNS-1001
Kostet ca. 80€ ohne Platte und hat anscheinen nur einen USB Port -> 
http://www.heise.de/preisvergleich/692728

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Kostet ca. 80€ ohne Platte und hat anscheinen nur einen USB Port ->
> http://www.heise.de/preisvergleich/692728

Also noch schlechtere Austattung, denn leider auch nur 128MB RAM, und 
wohl auch mit der Firmware im NAND...

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Die müsste man mit# lsof | grep /i-data
> rausbekommen oder nicht?

Das habe ich gestern gesucht, hättest Du des ned schon gestern Abend 
sagen können.;-)
Habe es erfolglos mit fuser versucht, war aber ned so der Hit.

Bye Dimpflmoser

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum thema xtf resize: es gibt zwar ein xfs_growfs, ist auch auf der Box:
~ # xfs_growfs --help
xfs_growfs: invalid option -- '-'
Usage: xfs_growfs [options] mountpoint

Options:
  -d          grow data/metadata section
  -l          grow log section
  -r          grow realtime section
  -n          don't change anything, just show geometry
  -I          allow inode numbers to exceed 32 significant bits
  -i          convert log from external to internal format
  -t          alternate location for mount table (/etc/mtab)
  -x          convert log from internal to external format
  -D size     grow data/metadata section to size blks
  -L size     grow/shrink log section to size blks
  -R size     grow realtime section to size blks
  -e size     set realtime extent size to size blks
  -m imaxpct  set inode max percent to imaxpct
  -V          print version information
Aber das ist halt nur zum größer machen. Verkleinern geht nicht, siehe:
http://xfs.org/index.php/XFS_FAQ#Q:_Is_there_a_way_to_make_a_XFS_filesystem_larger_or_smaller.3F
http://xfs.org/index.php/Shrinking_Support

Also: tar erstellen, sichern, alles neu machen und zurück spielen...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Also: tar erstellen, sichern, alles neu machen und zurück spielen...

Ist ja auch das vernünftigste, und wer sich schon 1TB Videos 
draufgemüllt hat, selber schuld ;-)

Autor: matz3e (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens D.
Die Zeile die du gefunden hast, ider der Code vom Ethernet-TOE Teil. 
Dort werden die CRC32 berechnet.

Hier befinden sich der Code für das Hardware RAID
grep -n configure_ucode_engine drivers/ata/ox820sata.c 
1905:static void configure_ucode_engine(
2121:      configure_ucode_engine(OXNASSATA_UCODE_NONE, 1, 0, 1);
2124:      configure_ucode_engine(OXNASSATA_UCODE_JBOD, 1, 1, 1);
2129:          configure_ucode_engine(OXNASSATA_UCODE_RAID0, 0, 0, 1);
2132:          configure_ucode_engine(OXNASSATA_UCODE_RAID0, 1, 1, 1);
2139:          configure_ucode_engine(OXNASSATA_UCODE_RAID1, 0, 0, 1);
2142:          configure_ucode_engine(OXNASSATA_UCODE_RAID1, 1, 1, 1);

Zu dem InitRAMFS :
das ist ein mit gzip gepackte cpio Archive. Mann muss einfach nur nach 
dem gzip Header suchen und dann porbieren.

Das InitRAMFS ist an dem Kernel "angehängt", aus diesem Grunden ist es 
auch in Kconfig. Sonst würde ich es ja mit ATAGs als Addresse übergeben.

Zum Thema USB.
Da habe ich den Code noch nicht durchgelsen. Testet doch mal einen 
Kernel mit PCI.

Und das mit der "One Man Show" sah man auch schon an seinem git-Repo.
Ich weiss jetzt nicht ob es der 2.6.* oder 3.* Kernel war.

@Dimpflmoser
USB Dongle ??
Meinst wohl USB Host

@Lucian M.
usbmuxd.
Das ist ein daemon im Userspace und kein Treiber.
Da wird höchstens eine Art virtuelles Device angelegt.
Kein USB-Host.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ElektromAn schrieb:
> Testet doch mal einen Kernel mit PCI.

Hatte ich schon gemacht, hier: 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Autor: Mijzelf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
/dev/sdb1 on /mnt/parnerkey type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=utf8,shortname=mixed,errors=remount-ro)

Is the stick really mounted read-only? What happens if you try to 
redirect the stdout to stick?
#!/bin/sh

echo "Before redirect"
exec >/mnt/parnerkey/logfile 2>&1
echo "After redirect"

# Extra stuff

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mijzelf schrieb:
> Is the stick really mounted read-only? What happens if you try to
> redirect the stdout to stick?

Yes the stick will be mountet read-only. Look into the sources of 
/etc/init.d/rcS:
mount -o iocharset=utf8,shortname=mixed,ro ${mnt_point} /mnt/parnerkey
Don't known if we can remount the stick writeable.

I don't need to redirect stderr. I see the output via UART, see: 
P89626/UART ;)

If everything works fine, you can connect via telnet. If the stick not 
mounted of if check_key failed, you have IMHO no change to get any 
feedback without UART, because the own usb_key_func.sh scriptfile 
wouldn't be called.

Autor: Mijzelf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> I don't need to redirect stderr. I see the output via UART, see:
> P89626/UART ;)

I know. But I was wondering what I should have to do to get my FFP-stick 
working on the Medion.
http://zyxel.nas-central.org/wiki/FFP-stick
(And I don't have a Medion myself.)

Jens D. schrieb:
> Don't known if we can remount the stick writeable.

Yeah, that would be an option:
if touch /mnt/parnerkey/probe ; then
    rm /mnt/parnerkey/probe
else
    mount -o remount,rw /mnt/parnerkey
fi

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir gerade mal auffällt, weil ich gerade mit rsync (durch Debian 
chroot) auf NFS Daten synchronisiere:

Zum einen brauchen Manche Prozesse doch recht viel RAM. Hilfreich dabei, 
wenn man drauf verzichten kann:
killall zyshd python httpd
killall pure-ftpd smbd nmbd zyshclient zylogger
(rc.shutdown macht auch nicht viel anderes)

Außerdem verschwendet /usr/sbin/syslog-ng manchmal sehr viel CPU 
Leistung. Warum? Wohin wird überhaupt geloggt? Zumindest gibt es in 
/var/log kein syslog...
Ein "killall syslog-ng" schafft erstmal mehr Tempo mit rsync. Wobei es 
bei mir um die 5-7MB/s umherdümpelt (bei Dateigrößen um die 20MB)

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da unsere Firmware ja ursprünglich von Zyxel stammt, hier ein 
Interessanter Link:

ftp://ftp.zyxel.de/TH/Forum/NSA320GPL/

Gibt noch ein paar FTP Verzeichnisse, die Interessant sind. Zugangsdaten 
sind hier zu finden:

http://www.zyxelforum.de/-hot-news-nsa-serie-statement-bzgl-media-server-p16101.html#p16101

Vielleicht macht es Sinn, nachzusehen ob die Original Zyxel Firmware 
sich nicht besser auf der Box macht. Allerdings hat Zyxel selber 
anscheinend keinen NAS mit der selben Hardware wie die der P89626 
Box herraus gebracht hat, oder hab ich was übersehen? IMHO ist das nur 
eine Frage der Zeit...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Allerdings hat Zyxel selber
> anscheinend keinen NAS mit der selben Hardware wie die der P89626
> Box herraus gebracht hat, oder hab ich was übersehen? IMHO ist das nur
> eine Frage der Zeit...

Oder Medion hat diese Serie (also auch die von Aldi-Nord) von Zyxel 
herstellen lassen...

Autor: SP()()KY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Zu den ständigen Laufwerksgeräuschen:
>
> Ich hab mit meinen usb_key_func die Kiste mal "Nackig" hochfahren
> lassen. Somit laufen keine Dienste wie Samba und Co. Dennoch höre ich
> dieses Komische Geräusch von der Platte. Bin mir auch nicht Sicher ob es
> Zugriffe sind oder Rotieren.
>
> Ich hab die Geräusche mal mit dem Handy Aufgenommen:
> berarbeitetes MP3:
> http://dl.dropbox.com/u/10577181/Medion%20P89626%2...
> Ogirinal MP4 (AAC):
> http://dl.dropbox.com/u/10577181/Medion%20P89626%2...
>
> Hört ihr das selbe bei eurer Box?

ja, höre ich auch, aber ich habe timeout auf 15 minuten, dann herrscht 
schweigen.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@UART-Besitzer:

Würdet Ihr mal bitte posten, welche Kommandos unser uBoot-1.1.2 welches 
ab Werk geflasht wurde, unterstützt ("help" sollte die ausspucken)? 
Wahrscheinlich kann man das auch aus den konfigurierten Sourcen sich 
zusammenreimen, aber "help" ist doch wesentlicheinfacher, oder?

Mein ketzerischer Hintergedanke ist, eine Art Mini-Skripting in den 
Umgebungsvariablen, um der Reihe nach beim Auswerten von "bootcmd" z.B. 
erstmal von einer lokalen Partition versuchen zu booten, falls das nicht 
geht, von TFTP meinetwegen (oder das kann man auch auslassen), und wenn 
gar nichts mehr geht, schliesslich doch das originale "boot_nand" 
aufzurufen, so etwa wie hier beschrieben: 
http://www.denx.de/wiki/DULG/CommandLineParsing

Ich weiß bloß nicht ob unsere alte U-Boot Variante das alles 
unterstützt, sowas wie:
bootcmd=run boot_sda3 || run boot_tftp || run boot_nand
 wobei "boot_sda3" und "boot_tftp" noch eigens zu definieren wären. 
Somit kann man eine Art Multi-Boot emulieren, ohne UART, ohne die Box 
aufmachen zu müssen (wenn alles gut geht und man auch das Partitionieren 
von "innen" schafft), allenfalls die Platte muss man heraus nehmen um 
das, was auf sda3 booten könnte weg zu nehmen, damit die Box wieder zur 
Original-FW gezwungen wird. Was man natürlichj auh nicht mahen muß, wenn 
alle Varianten schön booten und man mit fw_setenv and den 
uBoot-Variablen herumkitzeln kann...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Wahrscheinlich kann man das auch aus den konfigurierten Sourcen sich
> zusammenreimen, aber "help" ist doch wesentlicheinfacher, oder?

Hatte ich schon mal gepostet und es geht IMHO nur TFTP kein USB oder 
NFS. Deswegen wäre ein "offener" uBoot Ersatz sehr Wünschenswert.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Hatte ich schon mal gepostet und es geht IMHO nur TFTP kein USB oder
> NFS.

Ja, wo denn? Mich interessiert ja nicht USB und NFS in uBoot, sowas kann 
Linux & Co, mich interessiert z.B. ob es das Kommando ext2load 
beherrscht ;-). Dann kann ich auch ohne die anderen, also nochmal, 
würdest Du uns bitte den output von help mal zeigen?

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider fährt meine Box aktuell gar nicht mehr hoch :(

Gestern abend abgeschaltet, heute abend wieder an, doch leider bootet 
sie nicht korrekt. Die blaue Lampe leuchtet, die grüne blinkt ab und an, 
aber sonst nichts. Weder Web-Interface, noch telnet tun, sogar auf ein 
Reset keine Reaktion, d.h. kein Piepsen.

Vom Festplattengeräusch her würde ich sogar bald sagen, dass sie 
irgendwo hängt und immer wieder versucht, den gleichen Sektor zu lesen.
Keine Ahnung, was ich jetzt noch machen kann,

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Würdet Ihr mal bitte posten, welche Kommandos unser uBoot-1.1.2 welches
> ab Werk geflasht wurde, unterstützt ("help" sollte die ausspucken)?
> Wahrscheinlich kann man das auch aus den konfigurierten Sourcen sich
> zusammenreimen, aber "help" ist doch wesentlicheinfacher, oder?

Das Kabel ist angekommen:

http://www.amazon.de/Datenkabel-Nokia-CA-42-DKU-5-5140i/dp/B0040JF7QE/ref=sr_1_4?s=ce-de&ie=UTF8&qid=1323977831&sr=1-4

Ich kann jetzt auch an den UART. Hier die Ausgabe von "help" vom U-Boot:
$ help
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
echo    - echo args to console
exit    - exit script
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
ledfail - Extinguish (0) or light (1) failure LED
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nand    - NAND sub-system
nboot   - boot from NAND device
nm      - memory modify (constant address)
nwboot          - NAND Write boot information
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk S. schrieb:
> Leider fährt meine Box aktuell gar nicht mehr hoch :(

Wenn echt nix mehr kommt, dann entweder ab zu Medion oder selbst Hand an 
den UART legen und gucken was los ist.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> z.B. ob es das Kommando ext2load
> beherrscht ;-). Dann kann ich auch ohne die anderen, also nochmal,
> würdest Du uns bitte den output von help mal zeigen?

Ich glaube das habe ich nicht in der Liste gesehen. Kann ich aber morgen 
mal nachsehen...

Ansonsten:
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Wenn echt nix mehr kommt, dann entweder ab zu Medion oder selbst Hand an
> den UART legen und gucken was los ist.

Leider ist mein Kabel noch nicht da, habe allerdings das gleiche Kabel 
bestellt. Vielleicht warte ich noch bis Montag oder Dienstag, bevor ich 
die Box zurückbringe.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk S. schrieb:
> Vom Festplattengeräusch her würde ich sogar bald sagen, dass sie
> irgendwo hängt und immer wieder versucht, den gleichen Sektor zu lesen.

Sind die Geräusche wie hier: 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"
Dann ist die Platte ok. Die haben wir anscheinend alle ;)

Ich meine meine Box ist auch mal nicht beim ersten mal "angesprungen", 
hab ich aber nicht weiter Untersucht...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Ich kann jetzt auch an den UART. Hier die Ausgabe von "help" vom U-Boot:$ help

Danke!

Jens D. schrieb:
> Ich glaube das habe ich nicht in der Liste gesehen. Kann ich aber morgen
> mal nachsehen...
>
> Ansonsten:

Du hast Recht, sorry, ich fand es nicht mehr auf die Schnelle. So, nun 
wissen wir's, kein ext2load dabei, also muß ein neuer uBoot her, 
wahrscheinlich auch ein neuerer...

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir haben ja die Medion-Sourcen von U-Boot 1.1.2 mit den Änderungen, 
dass es für das Board von Medion läuft. Wenn wir diese Änderungen nehmen 
und in eine aktuelle U-Boot Version mergen würden, wäre es ein optimaler 
Start für eine sichere Basis, auch für nicht "UARTer".

Ich kann aber den Aufwand nicht abschätzen. Die Hardwaredetails zum 
Board müssten in den Medion-Sourcen drin stehen.

In der README von U-Boot steht wie man vorgehen soll. Ok, ist ziemlich 
oberflächlich, aber da wir, wie gesagt, die Medion-Sourcen haben sollte 
es möglich sein.

http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=README;h=ff72e4705f5d7142322e51d808f07c491edef7c0;hb=HEAD#l3428

http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=README;h=ff72e4705f5d7142322e51d808f07c491edef7c0;hb=HEAD#l4687

Clone auf Github vom aktuellen U-Boot (http://git.denx.de/u-boot.git/) 
machen und einfach mal probieren. Ich hoffe ich finde mal die Zeit dazu.

Was meint ihr?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Clone auf Github vom aktuellen U-Boot (http://git.denx.de/u-boot.git/)
> machen und einfach mal probieren.

Das ist eine gute Idee! Vielleicht kann man die Sache dann auch im 
Original einfließen lassen. Ist vielleicht auch für andere NAS Geräte 
interessant, die auf dem selben SoC basieren (Siehe liste im Wiki)...
Wie sieht es denn mit den Lizenzen aus? Hat "Medion" seine Änderungen 
auch unter GPL gestellt?

Alle die UART haben, könnten es testen. Wenn brauchbar können es die 
anderen über TFTP mit Fallback probieren und wenn alles ok ist, kann man 
es am Ende auch fest in's NAND gießen...


Wobei einen Kernel würde uns ehr weiter bringen ;)

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Wie sieht es denn mit den Lizenzen aus?

Das habe ich mich auch schon gefragt. U-Boot selbst hat GPL. Deswegen 
musste doch Medion ihre Änderungen an U-Boot auch zugänglich machen. 
Insofern sollte es gehen. Ich bin aber weder Jurist noch Fachmann für 
Open-Source Lizenzen.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> U-Boot selbst hat GPL. Deswegen
> musste doch Medion ihre Änderungen an U-Boot auch zugänglich machen.

Das denke ich eigentlich auch. Das ist auch das Copyleft-Prinzip:

Alle abgeleiteten Programme eines unter der GPL stehenden Werkes dürfen 
von Lizenznehmern nur dann verbreitet werden, wenn sie von diesen 
ebenfalls zu den Bedingungen der GPL lizenziert werden.

(Erster Satz von: http://de.wikipedia.org/wiki/Gpl#Copyleft-Prinzip )

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Das habe ich mich auch schon gefragt. U-Boot selbst hat GPL. Deswegen
> musste doch Medion ihre Änderungen an U-Boot auch zugänglich machen.
> Insofern sollte es gehen. Ich bin aber weder Jurist noch Fachmann für
> Open-Source Lizenzen.

Also in den Sourcen vom Medion sind unter sysapps auch die Sourcen von 
u-boot 1.1.2

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aus der Datei trunk/sysapps/u-boot-1.1.2/board/oxnas/oxnas.c, die auf 
jeden Fall dazu gehört.
/*
 * (C) Copyright 2005
 * Oxford Semiconductor Ltd
 *
 * See file CREDITS for list of people who contributed to this
 * project.
 *
 * This program is free software; you can redistribute it and/or
 * modify it under the terms of the GNU General Public License as
 * published by the Free Software Foundation; either version 2 of
 * the License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA 02111-1307 USA
 */

Sieht gut aus, oder?

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich melde mich nochmal ;-)

@Jens D.
Ohh das mit dem PCI Kernel Image habe ich jetzt nicht gesehen,

Die Sourcen von der Zyxel Seite zum NSA320 sind von einem Marvell 
Kirkwood System.
NICHT *KOMPATIBEL*
Anderer SoC

Nochmals zu den Medion Kernel Sourcen.

Gegenüber den SATA / GMAC sind die Files für USB erfrischend  kurz 
geraten.
Sind nur ein paar hundert Zeilen. Auch ist mir da was aufgefallen was 
ich vielleicht andereswo gebrauchen könnte.

Im Zusammenhang mit dem Boardinit habe ich die GPIOs noch nicht 
verstanden.
Es gibt eine primäre, sekundäre und tertiäre Funktion WTF *??*

Achja
Es war doch mal eine Frage gestellt worden wozu der nicht belegte IC 
Lötplatz ist.
Mein Tipp
M41T00, PCF8563, RS5C372
Das sind RTC (Uhren) ICs, wenn die BOX ohne Netzwerk gebootet wird, 
könnt ihr das Austesten. Einmal länger laufen lassen und neu booten dann 
sollte die Zeit von neuen Anfangen.
Die sind auch in den Sourcen nicht aktiviert.

Jetzt mus ich noch herauskriegen was:
RPS, PRD, ORDB-DMA heisst ....
SRAM könnte statisches (schnelles) RAM sein, eine Art Cache für die 
Descriptoren ggf auch für den Coprozessor Leon.
Mal sehen

E-mAn

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ElektromAn schrieb:
> Es war doch mal eine Frage gestellt worden wozu der nicht belegte IC
> Lötplatz ist.
> Mein Tipp
> M41T00, PCF8563, RS5C372
> Das sind RTC (Uhren) ICs, wenn die BOX ohne Netzwerk gebootet wird,
> könnt ihr das Austesten. Einmal länger laufen lassen und neu booten dann
> sollte die Zeit von neuen Anfangen.

Du meinst U2 hier: http://www.flickr.com/photos/jensdiemer/6435947865/ ?

Ich meine gesehen zu haben das die Box beim runterfahren die aktuelle 
Zeit speichert und darauf beim hochfahren zugreift...

Dann wäre noch zu klären, was S3 hier wäre: 
http://www.flickr.com/photos/jensdiemer/6435948221/

Autor: nas-explorer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

glaubt Ihr, dass man auch rsync auf die Box bekommt? Würde gerne ein 
Backup mit Hardlinks haben, da bin ich doch sicher nicht der einzige. 
Oder kann man das ohne rsync mit einem shell script erledigen?

Danke!

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nas-explorer schrieb:
> Hi
>
> glaubt Ihr, dass man auch rsync auf die Box bekommt? Würde gerne ein
> Backup mit Hardlinks haben, da bin ich doch sicher nicht der einzige.
> Oder kann man das ohne rsync mit einem shell script erledigen?
>
> Danke!

rsync ist kein Problem. Mit Hilfe der toolchain aus den Medion-Sourcen 
und den Sourcen von rsync 3.0.9 lässt sich ein Binary ohne Probleme 
bauen. Wenn Du willst, kann ich Dir das Binary auch als Download bereit 
stellen.

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmmm.

Was ist denn vorhanden ..
Reset, Action Button
ggf. ist das ein Taster für das RAID.

Mal sehen vielleicht finden ich was.
Ich muss mir sowieso nochmal die Core-USB Sourcen ansehen.
In
struct ehci_hcd 
gibt es kein
is_tdi_rh_tt
jedenfalls nicht in den Vanilla Sourcen 2.6.31.14
-> Vanilla diese kommen von Linus Torvalds

TT -> Translation Transactor.
Damit funktioiert USB1.* hinter einem USB2 Hub.

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach vergessen

Wenn die Zeit auf der Platte gespeichert wird, dürfte irgendwann ein 
Delay auftreten wenn das DING einen längere Zeit aus war.
Testbar ist dieses.
Die BOX direkt mit dem PC verbinden, booten und darauf achten das kein 
NTP-Server im Netz am laufen ist.

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und wenn einer mit suchen will
Ich empfehle git und meld ggf. googlen was das ist ;-)
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git remote add stable git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
git fetch stable
git checkout -b V2.6.31.14 v2.6.31.14
dann
meld vanilla.sourcen medion-sourcen
Mit der Angabe der "Verzeichnisse"

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

hatte mir für heute Abend/Nacht gewünscht, dass ich den Arch-Kernel neu 
baue.

Leider habe ich die Sourcen und insbesondere die Konfiguration des 
Arch-Kernels nicht gefunden. Als ersten Versuch habe ich den Kernel von 
Pogoplug genommen:
http://download.pogoplug.com/opensource/pro/pogopro-linux-2.6.31.6-r2.tar.bz2

Bei dem hatte ich den Eindruck, dass er dem Arch Kernel sehr ähnlich 
ist. Aber dort hängt der Kernel beim Boot, wahrscheinlich die selbe 
Situation, die Jens und Lucian vorher hatten.

Habt Ihr eine Idee wo ich die Kernel-Config des Arch-Kernels herbekomme?

Tschüss Dimpflmoser

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mal im IRC von archlinuxarm um Unterstützung gebeten. Leider wurde 
mir bisher nicht erfolgreich weiter geholfen, jedoch hat einer der Leute 
dort gesagt, dass XFS-Support ein Problem in dem OXNAS-Kernel wäre.

Das wundert mich zwar aber ich möchte es nicht ernsthaft in Frage 
stellen.

Irgendwie ist das doch verflixt, dass wir weder die Konfiguration des 
Original Medion-Kernels noch des Arch-Kernels bekommen. Ich glaube es 
handelt sich um eine Verschwörung. :-/

So, ich mach' heut' früher schluss. ;-)

Gute Nacht.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wurde leider nichts mit dem früher in's Bett gehen.

Habe eben den Medion-Kernel halbwegs erfolgreich gebaut.

- in das Verzeichnis trunk/linux-2.6.31.14/ gewechselt
- Datei STG212_Kernel.config kopieren nach .config
- make ARCH=arm
-> Fehler wegen initrd....
- make ARCH=arm menuconfig
  - disable initrd - speichern
- make ARCH=arm
- make ARCH=arm uImage

- uImge per tftp laden und der Kernel greift auf mein ext2-Arch-Rootfs 
zu.

Da das Verzeichnis für die richtigen Module fehlt fehlt zumindest eth0 
aber der Kernel bootet. Natürlich wird immer noch nur ein Core 
verwendet, aber wir hätten eine Grundlage, um von dort aus weiter zu 
machen, bzw. diesen Kernel und/oder dessen .config mit dem von Pogoplug 
zu vergleichen.

Im Arch-Pogoplug-IRC bekam ich inzwischen auch die Info, dass die dort 
enthaltene Datei .config~ die aktuelle Konfiguration ist, damit sollte 
der Kernel eigentlich bauen. Bin gerade dabei ihn zu bauen, dauert auf 
meiner alten Kiste aber leider recht lange. Mal sehen ob ich da heute 
noch mehr erfahre.

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal eine git clone gemacht und die sourcen bei github 
eingestellt. Bisher nix großartiges und keine Fortschritte.

http://github.com/michaelkebe/u-boot-medion-p89626

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich habe den Medion u-Boot einfach mal mit 
Festplatten-Unterstützung gebaut (ich musste bloß ein auskommentiertes 
#define wieder enablen, werde ihn gelich hochladen, vielleich probiert 
jemand den aus, zu chainloaden und sagt uns dann wie der output von 
help aussieht, und ob er seinen Dienst sonst noch tut...

Mein Problem ist derzeit, ich musste aus einer alten WD My Book World 
GPL Kit ein utility namens packager suchen, um das u-Boot Binary noch 
mit dem notwendigen Header zu wrappen, das steht am Ende des skriptes 
welches uBoot baut. In den Medion-Sourcen habe ich das nicht gefunden...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Mein Problem ist derzeit, ich musste aus einer alten WD My Book World
> GPL Kit ein utility namens packager suchen, um das u-Boot Binary noch
> mit dem notwendigen Header zu wrappen, das steht am Ende des skriptes
> welches uBoot baut. In den Medion-Sourcen habe ich das nicht gefunden...

Ok, ich war heute nacht einfach zu müde, packager ist natürlich unter 
build/stage1/tools zu finden, muß man nur bauen. So, ich habe 
*u-boot.bin* und *u-boot.wrapped* hochgeladen, bitte mal probieren:

http://www.muresan.de/medion-nas/u-boot.bin
http://www.muresan.de/medion-nas/u-boot.wrapped

Wahrscheinlich braucht man *u-boot.wrapped* beim Flashen, und wenn man 
es läd, muß man die addresse von der er ausgeführt wird wie 
http://jeff.doozan.com/debian/uboot/build_uboot.htm um 200 bytes weiter 
nehmen,  *u-boot.bin* kann man wohl von der gleichen in elcher man es 
geladen hat wohl ausführen, sehe ich das richtig?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> (ich musste bloß ein auskommentiertes
> #define wieder enablen

Es ging um
SDK_BUILD_HDD_BOOT
 in board/oxnas/config-820.mk in den mitgelieferten u-boot-1.1.2 
Sourcen.

Autor: Jens D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weiß jemand wie man das RAID wieder aufsetzt, wenn man die Platte Platt 
machen will, um Platz für ein (oder mehrere) ext3/4 rootfs zu machen?

Sind alle nötigen Programme auf der Box? Hat das jemand schon mal 
gemacht?

Was passiert eigentlich, wenn man kein neues RAID Aufsetzt? Also wie 
verhält dann sich das Original System?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Weiß jemand wie man das RAID wieder aufsetzt, wenn man die Platte Platt
> machen will, um Platz für ein (oder mehrere) ext3/4 rootfs zu machen?
Keine Ahnung, muß man es denn neu aufsetzen, wenn man /dev/sda2 dann 
wieder als XFS erstellt? Möglicherweise ja...

Jens D. schrieb:
> Sind alle nötigen Programme auf der Box? Hat das jemand schon mal
> gemacht?
Es soll auf der CD ein Programm zum Festplatten vorbereiten geben, ich 
denke ich las mal im Australien-Forum etwas darüber...

Jens D. schrieb:
> Was passiert eigentlich, wenn man kein neues RAID Aufsetzt? Also wie
> verhält dann sich das Original System?
Eigentlich könnte man sogar erwarten, die Box könnte auch selber aus der 
Weboberfläche eine neue Platte einrichten, da ja die Original-FW 
geflasht ist, manche werden sogar so ohne Platte verkauft. Kann man wohl 
beides mit einer aderen leeren Festplatte erstmal ausprobieren...

Autor: Jens D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab was gefunden:
http://www.zyxelforum.de/nsa220-festplatten-mit-live-linux-auslesen-p11848.html#p11848
Dort wird die HDD allerdings am Ubuntu PC gehängt und eingerichtet. Dazu 
wird u.a. mdadm genutzt. Ist das auf der Box vorhanden?

Wobei, wenn nicht, kann man es vermutlich ja mit einem chroot System 
nachinstallieren...

Noch eine Frage: Muß es überhaupt RAID sein und/oder muß sda1 und sda2 
XFS sein, oder funktioniert die Original Firmware auch mit ext3/4

Autor: Hans M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Sind alle nötigen Programme auf der Box? Hat das jemand schon mal
> gemacht?

Der erste Post zu dem Thema war wirklich in dem australischen Forum. 
(Dass hierzu die CD benötigt wird)

Allerdings hab ich inzwischen auch gelesen, dass es ohne die CD geht und 
nur die Box benötigt wird. (war glaub auch im australischen Forum)
"If the disk installed is blank/new/no operating system (it boots off 
the disk) it displays the initialise option."
von: alxr
posted 2011-Nov-30, 10pm AEST

hoffe ich konnte helfen

mfg
Hans

Autor: Jens D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, gut. Aber dann macht sie wahrscheinlich eh wieder das selbe Layout 
der Platte und man hat wieder kein Platz für andere rootfs ;)

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

habe jetzt den Arch/Pogoplug-Kernel mit XFS compiliert. Da ich meine 
Partition sda2 ja platt gemacht habe kann ich das nicht testen. Aber 
vielleicht wollt Ihr ja.

Der Kernel liegt hier:
https://s3-eu-west-1.amazonaws.com/medion-nas/uImage.arch

Die zugehörige Config liegt dort:
https://s3-eu-west-1.amazonaws.com/medion-nas/.config

Meine U-Boot-Kommandos:

setenv bootargs console=ttyS0,115200 root=/dev/sda2 mem=128M
tftp 61000000 uImage.arch
bootm 61000000

Natürlich startet damit ein benutzbares System, da dort wahrscheinlich 
noch kein Rootfs liegt. Aber Ihr solltet an den Konsolen-Messages sehen 
ob sda2 als Rootfs gemounted werden kann.

Falls das klappt kann man das Arch-Rootfs nach sda2 auspacken.

Berichtet doch mal bitte wie es bei Euch funktioniert.

Tschüss Dimpflmoser

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Naja, gut. Aber dann macht sie wahrscheinlich eh wieder das selbe Layout
> der Platte und man hat wieder kein Platz für andere rootfs ;)

Sehr wahrscheinlich. Aber hoffentlich wird andersrum eine 
umpartitionierte Platte dann auch so wie sie ist in Ruhe gelassen wenn 
man mal wieder die Original-FW bootet.

Hast Du denn vielleicht mein neu übersetztes u-boot über tftp probiert, 
ob es funzt und wegen den neuen Kommandos?

Ich überlege gerade, wenn diese rudimentären Skriptmöglichkeiten von 
u-boot es erlauben, zu Prüfen ob eine gewisse Datei auf einer Partition 
existiert, kann man dadurch ohne UART und unter Vorasussetztung, dass 
die Box immer bootet und man Zugang hat, festlegen was gebootet wird... 
Auch könnte man sich vorstellen, den OTC-Button in u-boot zu 
unterstützen um darauf reagieren zu können, für andere Plattformen gibt 
es sowas...


Mir ist in der Original-FW noch aufgefallen, im intitrd, im Startskript 
(init) wird mit /sbin/mrd_mac die MAC-addresse der NIC ausgelesen, und 
dann ifconfig übergeben, wahrscheinlich kriegt nur so ifconfig die mit? 
Dieses mrd_mac braucht auch noch /lib/libzyboot.so, für beide fand ich 
keine Sourcen, werden wir diese Binaris denn wohl brauchen? Hat jemand 
das mal im Archlinux-RootFS angeschaut?

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Dort wird die HDD allerdings am Ubuntu PC gehängt und eingerichtet. Dazu
> wird u.a. mdadm genutzt. Ist das auf der Box vorhanden?
>
So weit ich mich erinnern kann ist mdadm drauf, bin mir da ziemlich 
sicher.

> Noch eine Frage: Muß es überhaupt RAID sein und/oder muß sda1 und sda2
> XFS sein, oder funktioniert die Original Firmware auch mit ext3/4

Habe eben nochmal den Medion-Kernel gebooted. Die mounts auf /dev/md4 
schlagen fehl, da dort anscheinend xfs als Filesystem eingestellt ist.

Allerdings funktioniert ein manuelles Mount problemlos:
mount /dev/md4 /i-data/6764ac2f
ls /i-data/6764ac2f
bin
boot
dev
etc
home
kernel26-oxnas-nopci-2.6.31.6_SMP_820.3-1.1-arm.pkg.tar.xz
kernel26-oxnas-pci-2.6.31.6_SMP_820.3-1.1-arm.pkg.tar.xz
ledcontrol.tgz
lib
lost+found
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var


Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es tut sich was bei meinem Versuch ein aktuelles U-Boot für die 
Medion-Box zu bauen. Man kann zwar noch nicht kompilieren, aber es 
passiert schonmal was.

https://github.com/michaelkebe/u-boot-medion-p89626

Weiss jemand was das Define CONFIG_SYS_INIT_SP_ADDR für die Board 
Konfiguration macht und wie die gesetzt werden soll?

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Mir ist in der Original-FW noch aufgefallen, im intitrd, im Startskript
> (init) wird mit /sbin/mrd_mac die MAC-addresse der NIC ausgelesen, und
> dann ifconfig übergeben, wahrscheinlich kriegt nur so ifconfig die mit?
> Dieses mrd_mac braucht auch noch /lib/libzyboot.so, für beide fand ich
> keine Sourcen, werden wir diese Binaris denn wohl brauchen? Hat jemand
> das mal im Archlinux-RootFS angeschaut?

Habe beim Booten von Arch die MAC-Adresse im Boot-Kommando weg gelassen 
und bekomme problemlos Zugriff auf's Netzwerk.
Könnte mir vorstellen, dass die MAC-Adressen bei Auslieferungen alle 
identlisch sind und es dann knallt wenn man zwei dieser Boxen im selben 
Netz hat.
Ich schätze, dass die MAC-Adresse über den Bootmechanismus erst durch 
eine individuelle Adresse ersetzt wird.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
stelle gerade fest, dass der Medion-Kernel mir original-Rootfs, jedoch 
mit sda2 als ext2-Formatiert die Platte auch nicht mehr anhält.

Habe jetzt auch keine Idee was da da die Ursache dazu ist, da auf sda2 
ja keine signifikanten Daten für das System liegen.

Autor: BillX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wachtmeister Dimpflmoser
Du MUSST als hersteller von so geräten dafür sorgen das die 
unterschiedliche macs haben!!! Du bist auch verpflichtet die macs zu 
kaufen... deswegen würde mich das sehr wundern wenn die alle die gleiche 
haben... aber ihr könntet ja mal teile eurer macs posten und 
vergleichen...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
IMHO wäre es ganz gut, wenn diejenigen die Downloads zur Verfügung 
stellen, die MD5 dazu packen. Dann kann man leichter suchen und 
zuordnen, welche Sachen man getestet hat.

Ich mache das mal Nachträglich und benenne meine Dateien mal um und füge 
die Post-ID in den Dateinamen ein:

Lucian M. schrieb:
> http://www.muresan.de/medion-nas/u-boot.bin
> http://www.muresan.de/medion-nas/u-boot.wrapped

Create hashes for 'u-boot2461023.wrapped'...
md5: 8b95720d4505382128e86604bf9523a6

Create hashes for 'u-boot2461023.bin'...
md5: c588b2c15e2db9f81d43a4cbf64f5d25


Wachtmeister Dimpflmoser schrieb:
> Der Kernel liegt hier:
> https://s3-eu-west-1.amazonaws.com/medion-nas/uImage.arch
>
> Die zugehörige Config liegt dort:
> https://s3-eu-west-1.amazonaws.com/medion-nas/.config

Create hashes for 'uImage2461228.arch'...
md5: 4db01b74fdf6082fac068200e6c5c58d

Create hashes for 'uImage2461228.arch.config'...
md5: 2913a873b189461ca3803a0d2114e0de


Ich teste die Sachen nun...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Ich meine meine Box ist auch mal nicht beim ersten mal "angesprungen",
> hab ich aber nicht weiter Untersucht...

Nun ist es wieder so: Schaltbare Stecktose eingeschaltet, Box geht in 
uBoot bleibt aber da, das kann ich per UART sehen.
Dann mal Netzteil von Box gezogen und wieder eingesteckt. Nun Fährt die 
Box normal hoch...

Kennt noch jemand ähnliche Verhaltensweisen?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Lucian M. schrieb:
>> http://www.muresan.de/medion-nas/u-boot.bin
>> http://www.muresan.de/medion-nas/u-boot.wrapped
>
> Create hashes for 'u-boot2461023.wrapped'...
> md5: 8b95720d4505382128e86604bf9523a6
>
> Create hashes for 'u-boot2461023.bin'...
> md5: c588b2c15e2db9f81d43a4cbf64f5d25

Klappt schonmal:
Bytes transferred = 95500 (1750c hex)
## Starting application at 0x61000000 ...
Initialising disks
SATA PHY not ready for device 1
Detecting SATA busses:
Bus 0: Found first device OK
  Device 0: Model: ST1500DL003-9VT16L Firm: CC4A Ser#: 5YD5RGDA
            Type: Hard Disk
            Capacity: 131071.9 MB = 127.9 GB (268435455 x 512)
  Device 1: not available
Failed to read valid environment from disk, using built-in default


U-Boot 1.1.2 (Dec 16 2011 - 00:16:41)

U-Boot code: 60D00000 -> 60D1750C  BSS: -> 60D1B1A0
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0 
$ help
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
bootm   - boot application image from memory
bootp   - boot image via network using BootP/TFTP protocol
cmp     - memory compare
cp      - memory copy
crc32   - checksum calculation
diskboot- boot from IDE device
echo    - echo args to console
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls- list files in a directory (default /)
go      - start application at address 'addr'
help    - print online help
ide     - IDE sub-system
iminfo  - print header information for application image
ledfail - Extinguish (0) or light (1) failure LED
loop    - infinite loop on address range
md      - memory display
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
version - print monitor version

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Klappt schonmal:

Danke für's Testen! Das ist ja schön, daß es soweit geht, freut mich. 
Ich frage mich nur, warum die von Michael Kebe kompilierte Variante mit 
netconsole das Netzwerk komplett lahm gelegt hatte, weil netconsole dazu 
wäre schon noch was Feines...

> Bytes transferred = 95500 (1750c hex)
> ## Starting application at 0x61000000 ...
> Initialising disks
> SATA PHY not ready for device 1
> Detecting SATA busses:
> Bus 0: Found first device OK
>   Device 0: Model: ST1500DL003-9VT16L Firm: CC4A Ser#: 5YD5RGDA
>             Type: Hard Disk
>             Capacity: 131071.9 MB = 127.9 GB (268435455 x 512)
>   Device 1: not available
> Failed to read valid environment from disk, using built-in default

So, weil uBoot nun die Platte erkennt, probiert es wohl auch das 
Environment von dort zu lesen, sowas kann man sich möglicherweise auch 
zu Nutzen machen...

>
> U-Boot 1.1.2 (Dec 16 2011 - 00:16:41)
>
> U-Boot code: 60D00000 -> 60D1750C  BSS: -> 60D1B1A0
> RAM Configuration:
>         Bank #0: 60000000 128 MB
> SRAM Configuration:
>         64KB at 0x50000000

@MichaelKebe: Dein CONFIG_SYS_INIT_SP_ADDR könnte man möglicherweise in 
ox820.h gleich auf CFG_SRAM_BASE setzen, glaube ich, nachdem ich mir 
noch so die u-Boot Konfigs für andere Boards angeguckt habe, bin mir 
aber nicht ganz sicher...

> *** Warning - bad CRC, using default environment

Was ist denn nun damit eigentlich? Jens, hast Du dir mal im neu 
gestarteten uBoot das environment angeschaut, ist es eventuell anders al 
Du es vorher verändert hast (weil er meint "using default..."), kannst 
Du sowas nachvollziehen?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Wachtmeister Dimpflmoser schrieb:
>> Der Kernel liegt hier:
>> https://s3-eu-west-1.amazonaws.com/medion-nas/uImage.arch
>>
>> Die zugehörige Config liegt dort:
>> https://s3-eu-west-1.amazonaws.com/medion-nas/.config
>
> Create hashes for 'uImage2461228.arch'...
> md5: 4db01b74fdf6082fac068200e6c5c58d
>
> Create hashes for 'uImage2461228.arch.config'...
> md5: 2913a873b189461ca3803a0d2114e0de

Geht auch, weiß aber nicht ob die XFS Unterstützung auch Funktionieren 
würde:
Bytes transferred = 2418764 (24e84c hex)
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2418700 Bytes =  2.3 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................................. done, booting the kernel.
[    0.000000] Linux version 2.6.31.6_SMP_820 (jo@waldhof) (gcc version 4.3.2 (crosstool-NG-1.8.0) ) #100 SMP Fri Dec 16 11:32:46 CET 2011
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS
[    0.000000] 1 memory region
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda1 mem=128M
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 128MB = 128MB total
[    0.000000] Memory: 125040KB available (4176K code, 266K data, 132K init, 0K highmem)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:96
[    0.000000] OX820_RPS_init_irq: interrupts 64 to 96
[    0.010000] Console: colour dummy device 80x30
[    0.010000] console [ttyS0] enabled
[    0.020000] Calibrating delay loop... 299.00 BogoMIPS (lpj=1495040)
[    0.250000] Security Framework initialized
[    0.250000] Mount-cache hash table entries: 512
[    0.260000] CPU: Testing write buffer coherency: ok
[    0.260000] Calibrating local timer... 374.49MHz.
[    0.330000] CPU1: Booted secondary processor
[    0.430000] Calibrating delay loop... 299.82 BogoMIPS (lpj=1499136)
[    0.640000] Brought up 2 CPUs
[    0.650000] SMP: Total of 2 processors activated (598.83 BogoMIPS).
[    0.660000] NET: Registered protocol family 16
[    0.660000] Number of DMA channels = 4, version = 4
[    0.670000] Reserving a DMA channel for DirectRAID
[    0.670000] Allocating 389 SRAM generic DMA descriptors
[    0.690000] bio: create slab <bio-0> at 0
[    0.690000] SCSI subsystem initialized
[    0.720000] NET: Registered protocol family 2
[    0.720000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.730000] Switched to NOHz mode on CPU #0
[    0.730000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.730000] Switched to NOHz mode on CPU #1
[    0.740000] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.750000] TCP: Hash tables configured (established 4096 bind 4096)
[    0.750000] TCP reno registered
[    0.760000] NET: Registered protocol family 1
[    0.760000] Create fragment cache
[    0.770000] fuse init (API version 7.12)
[    0.770000] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
[    0.780000] SGI XFS Quota Management subsystem
[    0.790000] msgmni has been set to 244
[    0.800000] alg: No test for stdrng (krng)
[    0.800000] io scheduler noop registered
[    0.800000] io scheduler anticipatory registered (default)
[    0.810000] io scheduler deadline registered
[    0.810000] io scheduler cfq registered
[    0.840000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.840000] serial8250: ttyS0 at MMIO 0x44200000 (irq = 55) is a 16550A
[    0.860000] brd: module loaded
[    0.870000] loop: module loaded
[    0.870000] ox820sata: OX820 sata core.
[    0.880000] scsi0 : oxnassata
[    0.880000] scsi1 : oxnassata
[    0.880000] ata1: SATA max UDMA/133 irq 50
[    0.890000] ata2: SATA max UDMA/133 irq 50
[    0.890000] ox820sata: reseting SATA core
[    1.420000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.420000] ata1.00: ATA-8: ST1500DL003-9VT16L, CC4A, max UDMA/133
[    1.430000] ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[    1.440000] ata1.00: configured for UDMA/133
[    1.440000] ox820sata: reseting SATA core
[    2.150000] ata2: SATA link down (SStatus 0 SControl 300)
[    2.150000] scsi 0:0:0:0: Direct-Access     ATA      ST1500DL003-9VT1 CC4A PQ: 0 ANSI: 5
[    2.160000] sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
[    2.170000] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    2.170000] sd 0:0:0:0: [sda] Write Protect is off
[    2.180000] tun: Universal TUN/TAP device driver, 1.6
[    2.180000] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    2.180000] NAND: Page read time 40ms
[    2.180000] NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit)
[    2.180000] Scanning device for bad blocks
[    2.210000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.250000]  sda:
[    2.250000] Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit":
[    2.250000] 0x000000000000-0x000000e00000 : "boot"
[    2.260000] 0x000000e00000-0x000008000000 : "rootfs"
[    2.270000] mice: PS/2 mouse device common for all mice
[    2.270000] TCP cubic registered
[    2.280000] NET: Registered protocol family 10
[    2.280000] NET: Registered protocol family 17
[    2.290000]  sda1 sda2
[    2.290000] RPC: Registered udp transport module.
[    2.290000] RPC: Registered tcp transport module.
[    2.300000] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.310000] List of all partitions:
[    2.310000] 0800      1465138584 sda driver: sd
[    2.320000]   0801          514048 sda1
[    2.320000]   0802      1464621952 sda2
[    2.330000] 1f00          131072 mtdblock0 (driver?)
[    2.330000] 1f01           14336 mtdblock1 (driver?)
[    2.340000] 1f02          116736 mtdblock2 (driver?)
[    2.340000] No filesystem could mount root, tried:  ext3 ext2 ext4 fuseblk xfs
[    2.350000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)

Wobei, selbst wenn xfs funktioniert, klappt das auch mit dem RAID 
Aufbau???

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
>> Bus 0: Found first device OK
>>   Device 0: Model: ST1500DL003-9VT16L Firm: CC4A Ser#: 5YD5RGDA
>>             Type: Hard Disk
>>             Capacity: 131071.9 MB = 127.9 GB (268435455 x 512)
>>   Device 1: not available
>> Failed to read valid environment from disk, using built-in default
>
> So, weil uBoot nun die Platte erkennt, probiert es wohl auch das
> Environment von dort zu lesen, sowas kann man sich möglicherweise auch
> zu Nutzen machen...

Kann das vielleicht bedeuten, das uBoot halt auch nicht mit dem RAID 
zurecht kommt?

IMHO interessanter wäre ein uBoot mit USB Support. Dann könnte man ein 
eigenes System starten (von USB oder Platte), wenn ein USB-Stick dran 
hängt. Wenn nicht dann normales System als fallback starten.
Es gibt ja auch den uBoot Befehl "ext2ls", vielleicht kann man also auf 
dem ext2 Stick eine Datei hinterlegen und nur wenn die da ist, was 
machen.

>> *** Warning - bad CRC, using default environment
>
> Was ist denn nun damit eigentlich? Jens, hast Du dir mal im neu
> gestarteten uBoot das environment angeschaut, ist es eventuell anders al
> Du es vorher verändert hast (weil er meint "using default..."), kannst
> Du sowas nachvollziehen?

Ja, ich hab meine Angaben "ipaddr" und "serverip" geändert. IMHO ist die 
meldung dann normal. Man kann sie auch irgendwie fixen, weiß aber nicht 
mehr wie... Neuen CRC schreiben???

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Geht auch, weiß aber nicht ob die XFS Unterstützung auch Funktionieren
> ...
> [    0.000000] Memory policy: ECC disabled, Data cache writealloc
> [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 32512
> [    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda1 mem=128M

Dein Kernel kriegt irgendwie root=/dev/sda1 mitgeteilt, da ist doch 
swap, oder? Hast Du Dich bloß vertippt?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
>>> *** Warning - bad CRC, using default environment

siehe: http://www.denx.de/wiki/DULG/WarningBadCRCUsingDefaultEnvironment

"saveenv" sollte abhilfe schaffen. Wobei ich das IMHO gemacht habe...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Dein Kernel kriegt irgendwie root=/dev/sda1 mitgeteilt, da ist doch
> swap, oder? Hast Du Dich bloß vertippt?

Stimmt. Ich probiere nochmal sda2... Wobei ich mein rootfs dort gelöscht 
habe ;)

Ergebnis:
[    2.380000] XFS mounting filesystem sda2
[    2.630000] XFS: resetting qflags for filesystem sda2
[    2.630000] VFS: Mounted root (xfs filesystem) on device 8:2.
[    2.640000] Freeing init memory: 132K
[    2.690000] Warning: unable to open an initial console.
[    2.700000] Kernel panic - not syncing: No init found.  Try passing init= option to kernel.
[    2.710000] [<c002eca0>] (unwind_backtrace+0x0/0xe4) from [<c0372884>] (panic+0x3c/0x124)
...

Wow, sieht gut aus... Ich kopiere mal ArchLinuxARM wieder rein...

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
>> Create hashes for 'uImage2461228.arch.config'...
>> md5: 2913a873b189461ca3803a0d2114e0de
>
> Geht auch, weiß aber nicht ob die XFS Unterstützung auch Funktionieren
> würde

@Jens, welche bootargs hast Du dem Kernel mitgegeben?
Falls das die original Medion bootargs sind weiß der Kernel nicht, dass 
er auf sda2 zugreifen soll.

Würdest Du mal versuchen, root=/dev/sda2 hinzuzufügen.

Raid würde ich zunächst mal außen vor lassen, zum einen weil ich davon 
überhautp keine Ahnung habe :-) zum Anderen, weil wir ohne 
zweite/externe Platte gar nichts davon haben außer eine zusätzliche 
Komplexität und Fehlerquelle.

So wie ich es verstanden habe sollte die Partition auch ohne Raid 
eingebunden werden.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Kann das vielleicht bedeuten, das uBoot halt auch nicht mit dem RAID
> zurecht kommt?

Soweit ich das verstanden habe tut unser Raid nichts anderes als die 
Daten der internen Platte auf die externe Platte zu spiegel. Demnach 
sollte die interne Platte ein normales Dateisystem sein. Wobei ich mir 
nicht vorstellen kann, dass man U-Boot dazu bekommt ein XFS-Dateisystem 
zu lesen. Dafür ist es einfach zu komplex.

> IMHO interessanter wäre ein uBoot mit USB Support. Dann könnte man ein
> eigenes System starten (von USB oder Platte), wenn ein USB-Stick dran
> hängt. Wenn nicht dann normales System als fallback starten.
Das wäre natürlich genial. Man könnte auf den USB-Stick den Kernel und 
eventuell eine initrd legen, wenn der Kernel gefunden wir wird dieser 
geladen, ansonsten der interne Kernel.

Allerdings habe ich persönlich gar keinen so großen Bedarf, das alte 
System zu erhalten. Natürlich habe ich große Sorge, einen Fehler zu 
machen und das System zu Bricken, weshalb ich mich scheue etwas auf dem 
Flash zu machen.

Ansonsten möchte ich nur einen weniger vermurksten Kernel haben, damit 
ich den VDR zum Laufen bekomme.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum RAID hab ich ja auch nicht wirklich verstanden. Eine Antwort 
liefert WarheadsSE bei 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2106&start=10#p11339 
:
> md raid, done to prevent single block failure causing image corruption.
> The 7820 SDK formats it this way.

Verstanden habe ich es nicht.

Ich wusste allerdings nicht, das man auch einfach das RAID ignorieren 
kann?!?! Dachte, wenn es als RAID eingerichtet ist, müsste man es auch 
dementsprechend ansprechen... Ich kenne mich da auch nicht aus...


Hab Archlinux auf sda2 (/i-data/6764ac2f) kopiert. Mit """bootargs = 
console=ttyS0,115200 root=/dev/sda2 mem=128M""" läuft der Arch Kernel an 
und bootet durch!!!
Filename 'uImage2461228.arch'.
Load address: 0x61000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ##################
done
Bytes transferred = 2418764 (24e84c hex)
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2418700 Bytes =  2.3 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................................. done, booting the kernel.
[    0.000000] Linux version 2.6.31.6_SMP_820 (jo@waldhof) (gcc version 4.3.2 (crosstool-NG-1.8.0) ) #100 SMP Fri Dec 16 11:32:46 CET 2011
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS
[    0.000000] 1 memory region
[    0.000000] Ignoring unrecognised tag 0x00000000
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 mem=128M
[    0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[    0.000000] Memory: 128MB = 128MB total
[    0.000000] Memory: 125040KB available (4176K code, 266K data, 132K init, 0K highmem)
[    0.000000] Hierarchical RCU implementation.
[    0.000000] NR_IRQS:96
[    0.000000] OX820_RPS_init_irq: interrupts 64 to 96
[    0.010000] Console: colour dummy device 80x30
[    0.010000] console [ttyS0] enabled
[    0.020000] Calibrating delay loop... 299.00 BogoMIPS (lpj=1495040)
[    0.250000] Security Framework initialized
[    0.250000] Mount-cache hash table entries: 512
[    0.260000] CPU: Testing write buffer coherency: ok
[    0.260000] Calibrating local timer... 374.49MHz.
[    0.330000] CPU1: Booted secondary processor
[    0.430000] Calibrating delay loop... 299.82 BogoMIPS (lpj=1499136)
[    0.640000] Brought up 2 CPUs
[    0.650000] SMP: Total of 2 processors activated (598.83 BogoMIPS).
[    0.660000] NET: Registered protocol family 16
[    0.660000] Number of DMA channels = 4, version = 4
[    0.670000] Reserving a DMA channel for DirectRAID
[    0.670000] Allocating 389 SRAM generic DMA descriptors
[    0.690000] bio: create slab <bio-0> at 0
[    0.690000] SCSI subsystem initialized
[    0.720000] NET: Registered protocol family 2
[    0.720000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
[    0.730000] Switched to NOHz mode on CPU #0
[    0.730000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
[    0.730000] Switched to NOHz mode on CPU #1
[    0.740000] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
[    0.750000] TCP: Hash tables configured (established 4096 bind 4096)
[    0.750000] TCP reno registered
[    0.760000] NET: Registered protocol family 1
[    0.760000] Create fragment cache
[    0.770000] fuse init (API version 7.12)
[    0.770000] SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
[    0.780000] SGI XFS Quota Management subsystem
[    0.790000] msgmni has been set to 244
[    0.800000] alg: No test for stdrng (krng)
[    0.800000] io scheduler noop registered
[    0.800000] io scheduler anticipatory registered (default)
[    0.810000] io scheduler deadline registered
[    0.810000] io scheduler cfq registered
[    0.840000] Serial: 8250/16550 driver, 2 ports, IRQ sharing disabled
[    0.840000] serial8250: ttyS0 at MMIO 0x44200000 (irq = 55) is a 16550A
[    0.860000] brd: module loaded
[    0.870000] loop: module loaded
[    0.870000] ox820sata: OX820 sata core.
[    0.880000] scsi0 : oxnassata
[    0.880000] scsi1 : oxnassata
[    0.880000] ata1: SATA max UDMA/133 irq 50
[    0.890000] ata2: SATA max UDMA/133 irq 50
[    0.890000] ox820sata: reseting SATA core
[    1.420000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.420000] ata1.00: ATA-8: ST1500DL003-9VT16L, CC4A, max UDMA/133
[    1.430000] ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
[    1.440000] ata1.00: configured for UDMA/133
[    1.440000] ox820sata: reseting SATA core
[    2.150000] ata2: SATA link down (SStatus 0 SControl 300)
[    2.150000] scsi 0:0:0:0: Direct-Access     ATA      ST1500DL003-9VT1 CC4A PQ: 0 ANSI: 5
[    2.160000] sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
[    2.170000] sd 0:0:0:0: [sda] 4096-byte physical blocks
[    2.170000] sd 0:0:0:0: [sda] Write Protect is off
[    2.180000] tun: Universal TUN/TAP device driver, 1.6
[    2.180000] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[    2.180000] NAND: Page read time 40ms
[    2.180000] NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND 128MiB 3,3V 8-bit)
[    2.180000] Scanning device for bad blocks
[    2.210000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.250000]  sda:
[    2.250000] Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit":
[    2.250000] 0x000000000000-0x000000e00000 : "boot"
[    2.260000]  sda1 sda2
[    2.260000] 0x000000e00000-0x000008000000 : "rootfs"
[    2.270000] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.280000] mice: PS/2 mouse device common for all mice
[    2.280000] TCP cubic registered
[    2.280000] NET: Registered protocol family 10
[    2.290000] NET: Registered protocol family 17
[    2.290000] RPC: Registered udp transport module.
[    2.300000] RPC: Registered tcp transport module.
[    2.380000] XFS mounting filesystem sda2
[    2.600000] Starting XFS recovery on filesystem: sda2 (logdev: internal)
[    3.100000] XFS: resetting qflags for filesystem sda2
[    3.140000] Ending XFS recovery on filesystem: sda2 (logdev: internal)
[    3.150000] VFS: Mounted root (xfs filesystem) on device 8:2.
[    3.150000] Freeing init memory: 132K
INIT: version 2.88 booting
 
 > Arch Linux ARM
 
 > http://www.archlinuxarm.org 

   ------------------------------
:: Mounting Root Read-Only                                               [FAIL] 
:: Adjusting system time and setting kernel timezone                     [DONE] 
:: Starting UDev Daemon                                                  [DONE] 
:: Triggering UDev uevents                                               [DONE] 
:: Loading Modules                                                       [BUSY] [    4.910000] Probing for Synopsis GMAC, unit 0
[    4.930000] eth0: Tuning GMAC 0 RGMII timings
[    4.940000] eth0: Unknown PHY, type 0x001cc915
[    4.940000] eth0: GMAC ver = 53, vendor ver = 18 at 0xed400000, IRQ 40
[    4.950000] eth0: Found PHY at address 7, type 0x001cc915 -> 10/100/1000
[    4.960000] eth0: Ethernet addr: 00:30:e0:00:00:00
[    4.960000] probe() eth0: Leon x2 clock
                                                                         [DONE] 
:: Waiting for UDev uevents to be processed                              [DONE] 
:: Bringing up loopback interface                                        [DONE] 
:: Checking Filesystems                                                  [DONE] 
:: Remounting Root Read/Write                                            [FAIL] 
:: Creating mtab                                                         [DONE] 
:: Mounting Local Filesystems                                            [FAIL] 
:: Activating Swap                                                       [DONE] 
:: Configuring Time Zone                                                 [DONE] 
:: Removing Leftover Files                                               [DONE] 
:: Setting Hostname: alarm                                               [DONE] 
:: Setting Locale: en_US.UTF-8                                           [DONE] 
:: Setting Consoles to UTF-8 mode                                        [DONE] 
:: Loading Keyboard Map: us                                              [DONE] 
:: Saving dmesg Log                                                      [DONE] 
INIT: Entering runlevel: 3
:: Setting MAC address                                                   [BUSY] FATAL: Module oxnas_led not found.
cat: /usr/local/mac_addr: No such file or directory
Usage:
  ifconfig [-a] [-v] [-s] <interface> [[<AF>] <address>]
  [add <address>[/<prefixlen>]]
  [del <address>[/<prefixlen>]]
  [[-]broadcast [<address>]]  [[-]pointopoint [<address>]]
  [netmask <address>]  [dstaddr <address>]  [tunnel <address>]
  [outfill <NN>] [keepalive <NN>]
  [hw <HW> <address>]  [metric <NN>]  [mtu <NN>]
  [[-]trailers]  [[-]arp]  [[-]allmulti]
  [multicast]  [[-]promisc]
  [mem_start <NN>]  [io_addr <NN>]  [irq <NN>]  [media <type>]
  [txqueuelen <NN>]
  [[-]dynamic]
  [up|down] ...

  <HW>=Hardware Type.
  List of possible hardware types:
    loop (Local Loopback) slip (Serial Line IP) cslip (VJ Serial Line IP) 
    slip6 (6-bit Serial Line IP) cslip6 (VJ 6-bit Serial Line IP) adaptive (Adaptive Serial Line IP) 
    strip (Metricom Starmode IP) ash (Ash) ether (Ethernet) 
    tr (16/4 Mbps Token Ring) tr (16/4 Mbps Token Ring (New)) ax25 (AMPR AX.25) 
    [    8.450000] eth0: Unknown PHY, type 0x001cc915
netrom (AMPR NET[    8.450000] CoPro offload is active on eth0
/ROM) rose (AMPR[    8.460000] Alloc'ing ARM descs 8192 bytes
 ROSE) tunnel (I[    8.460000] Alloc'ing CoPro parameters 36 bytes
PIP Tunnel) 
  [    8.470000] gmac gmac.0: firmware: requesting gmac_copro_firmware
  ppp (Point-to-Point Protocol) hdlc ((Cisco)-HDLC) lapb (LAPB) 
    arcnet (ARCnet) dlci (Frame Relay DLCI) frad (Frame Relay Access Device) 
    sit (IPv6-in-IPv4) fddi (Fiber Distributed Data Interface) hippi (HIPPI) 
    irda (IrLAP) ec (Econet) x25 (generic X.25) 
    infiniband (InfiniBand) eui64 (Generic EUI-64) 
  <AF>=Address family. Default: inet
  List of possible address families:
    unix (UNIX Domain) inet (DARPA Internet) inet6 (IPv6) 
    ax25 (AMPR AX.25) netrom (AMPR NET/ROM) rose (AMPR ROSE) 
    ipx (Novell IPX) ddp (Appletalk DDP) ec (Econet) 
    ash (Ash) x25 (CCITT X.25) 
[    8.570000] CoPro: Programming start address as 0xd000e000
[    8.670000] eth0: Resetting GMAC
[    8.680000] eth0: GMAC reset complete
[    8.680000] eth0: Setting Rx flow control thresholds for LAN port
[    9.240000] eth0: Unknown PHY, type 0x001cc915
[    9.740000] eth0: link down
[   11.700000] ADDRCONF(NETDEV_UP): eth0: link is not ready
                                                                         [FAIL] 
:: Starting Syslog-NG                                                    [BUSY] [   12.740000] eth0: link up, 1000Mbps, full-duplex, using pause, lpa 0xC5E1
[   12.740000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
                                                                         [DONE] 
:: Starting Network                                                      [DONE] 
:: Mounting Network Filesystems                                          [DONE] 
:: Starting crond daemon                                                 [DONE] 
:: Starting Secure Shell Daemon                                          [BUSY] ssh-keygen: generating new host keys: RSA1 RSA DSA ECDSA 
                                                                         [DONE] 
:: Starting OpenNTPD                                                     [DONE] 

Arch Linux 2.6.31.6_SMP_820  (alarm) (ttyS0)

alarm login: 

Autor: Jürg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier eine Antwort von Medion wegen den defekten Dateien.

vielen Dank für Ihre Nachricht.
Die Verwendung der Norton Internet Security Suite hat reproduzierbar 
Fehler bei der Übertragung verursacht.
Als Workaround kann momentan nur die Verwendung eines alternativen 
Schutzprogrammes genannt werden.
Ihre Anfrage habe ich an die zuständige Fachabteilung weitergeleitet, 
damit diese dort umgehend bearbeitet wird.
Ich bitte Sie noch um etwas Geduld. Sobald mir eine Rückmeldung 
vorliegt, werde ich Sie sofort informieren.
Sie haben weitere Fragen? Wir helfen Ihnen gerne!
Wir wünschen Ihnen eine schöne Adventszeit.
Freundliche Grüße aus Essen
Medion Technologie Center

Mal abwarten was da noch kommt.
mfg Jürg

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ACHTUNG: Ich vermute das beim beschreiben von sda2 mit archlinix das 
RAID zerstört! Zumindest fährt meine Box nicht mehr mit der normalen 
Firmware hoch.

Letzte Zeilen per UART sind:
Starting LCD panel...
/etc/init.d/rcS: line 226: /sbin/LCDd: not found
yaffs: dev is 32505861 name is "mtdblock5" rw
yaffs: passed flags ""
/etc/zyxel/conf exist..
NTFS driver 2.1.29 [Flags: R/O MODULE].
Fri Dec 16 14:00:00 GMT 2011
Starting zylogd...
 zylog starts.
Starting uamd...
Starting ZySH daemon and client...
Start NAS system daemon....
 Start ZySH daemon
zyshd: version 2.0.0 (build: 21:37:18 Oct  5 2011)
% zylog init start 
cat: can't open '/var/run/syslog-ng.pid': No such file or directory
Try to KILL SIGHUP to syslog-ng: pid=0
syslog-ng not running, start /usr/sbin/syslog-ng
Dec 16 14:00:04 (none) syslog-ng[1324]: syslog-ng starting up; version='2.0.10'
zyio_open_config success. (/etc/__system_default.xml, 0)
zyio_open_config success. (/etc/zyxel/conf/__system_default_device_ha.xml, 0)
/usr/sbin/zic -d /etc /var/zyxel/myzone_rule
/bin/ln -s -f /etc/MyZone /etc/localtime
/bin/hostname nas-server
Init SMB DB access... 
rm: can't remove '/var/log/samba/smb.db': No such file or directory
Initialize fw_key module
fw_key_result: 2
Assemble volume....
[1347] [288] outfile=/tmp/zysh.client.1347.d
[1347] server write-only FIFO is opened (fd=6)
[1347] server read-only FIFO is opened (fd=7)
[1347] server error read-only FIFO is opened (fd=8)
argc = 1,  func = 277
md: md4 stopped.
md: bind<sda2>
raid1: raid set md4 active with 1 out of 2 mirrors
md4 using HW RAID-1
HW-RAID1 sda2, is read/write.
HW-RAID1 using disk sda2 on port 0 mirror 0
md4: detected capacity change from 0 to 1499772813312
 md4: unknown partition table
cat: can't open '/tmp/mduuid.map': No such file or directory
Filesystem "md4": Disabling barriers, trial barrier write failed
XFS mounting filesystem md4
XFS quotacheck md4: Please wait.
mount invoked oom-killer: gfp_mask=0x802d0, order=0, oomkilladj=0
[<c0243d08>] (unwind_backtrace+0x0/0xe4) from [<c029cd90>] (oom_kill_process+0xa0/0x210)
[<c029cd90>] (oom_kill_process+0xa0/0x210) from [<c029d390>] (__out_of_memory+0x130/0x1bc)
[<c029d390>] (__out_of_memory+0x130/0x1bc) from [<c029d488>] (out_of_memory+0x6c/0xdc)
[<c029d488>] (out_of_memory+0x6c/0xdc) from [<c02a0544>] (__alloc_pages_nodemask+0x54c/0x584)
[<c02a0544>] (__alloc_pages_nodemask+0x54c/0x584) from [<c02c0408>] (cache_alloc_refill+0x310/0x5c0)
[<c02c0408>] (cache_alloc_refill+0x310/0x5c0) from [<c02c0834>] (kmem_cache_alloc+0x94/0xac)
[<c02c0834>] (kmem_cache_alloc+0x94/0xac) from [<c048e85c>] (kmem_zone_alloc+0x74/0xe4)
[<c048e85c>] (kmem_zone_alloc+0x74/0xe4) from [<c046ca14>] (xfs_inode_alloc+0x24/0xc4)
[<c046ca14>] (xfs_inode_alloc+0x24/0xc4) from [<c046ce10>] (xfs_iget+0x35c/0x570)
[<c046ce10>] (xfs_iget+0x35c/0x570) from [<c04391a4>] (xfs_qm_dqusage_adjust+0x58/0x174)
[<c04391a4>] (xfs_qm_dqusage_adjust+0x58/0x174) from [<c0475980>] (xfs_bulkstat+0x6ec/0xbe8)
[<c0475980>] (xfs_bulkstat+0x6ec/0xbe8) from [<c0439ac0>] (xfs_qm_quotacheck+0x100/0x194)
[<c0439ac0>] (xfs_qm_quotacheck+0x100/0x194) from [<c043a5c8>] (xfs_qm_mount_quotas+0xd8/0x170)
[<c043a5c8>] (xfs_qm_mount_quotas+0xd8/0x170) from [<c048339c>] (xfs_mountfs+0x5e0/0x6d0)
[<c048339c>] (xfs_mountfs+0x5e0/0x6d0) from [<c049b534>] (xfs_fs_fill_super+0x1d4/0x318)
[<c049b534>] (xfs_fs_fill_super+0x1d4/0x318) from [<c02c6f80>] (get_sb_bdev+0x124/0x154)
[<c02c6f80>] (get_sb_bdev+0x124/0x154) from [<c049931c>] (xfs_fs_get_sb+0x18/0x24)
[<c049931c>] (xfs_fs_get_sb+0x18/0x24) from [<c02c5d0c>] (vfs_kern_mount+0x50/0xa8)
[<c02c5d0c>] (vfs_kern_mount+0x50/0xa8) from [<c02c5da8>] (do_kern_mount+0x34/0xdc)
[<c02c5da8>] (do_kern_mount+0x34/0xdc) from [<c02dde54>] (do_mount+0x160/0x848)
[<c02dde54>] (do_mount+0x160/0x848) from [<c02de5d8>] (sys_mount+0x9c/0xd0)
[<c02de5d8>] (sys_mount+0x9c/0xd0) from [<c023f040>] (ret_fast_syscall+0x0/0x2c)
Mem-info:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:  37
Active_anon:605 active_file:10 inactive_anon:608
 inactive_file:0 unevictable:3000 dirty:0 writeback:0 unstable:0
 free:2558 slab:17469 mapped:455 pagetables:63 bounce:0
Normal free:10232kB min:10240kB low:12800kB high:15360kB active_anon:2420kB inactive_anon:2432kB active_file:40kB inactive_file:0kB unevictable:12000kB present:130048kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 314*4kB 170*8kB 52*16kB 10*32kB 5*64kB 2*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 1*4096kB = 10232kB
3499 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages of RAM
2692 free pages
1759 reserved pages
17472 slab pages
2195 pages shared
0 pages swap cached
Out of memory: kill process 1315 (zyshd) score 521 or a child
Killed process 1447 (sh)
mount invoked oom-killer: gfp_mask=0x802d0, order=0, oomkilladj=0
[<c0243d08>] (unwind_backtrace+0x0/0xe4) from [<c029cd90>] (oom_kill_process+0xa0/0x210)
[<c029cd90>] (oom_kill_process+0xa0/0x210) from [<c029d390>] (__out_of_memory+0x130/0x1bc)
[<c029d390>] (__out_of_memory+0x130/0x1bc) from [<c029d488>] (out_of_memory+0x6c/0xdc)
[<c029d488>] (out_of_memory+0x6c/0xdc) from [<c02a0544>] (__alloc_pages_nodemask+0x54c/0x584)
[<c02a0544>] (__alloc_pages_nodemask+0x54c/0x584) from [<c02c0408>] (cache_alloc_refill+0x310/0x5c0)
[<c02c0408>] (cache_alloc_refill+0x310/0x5c0) from [<c02c0834>] (kmem_cache_alloc+0x94/0xac)
[<c02c0834>] (kmem_cache_alloc+0x94/0xac) from [<c048e85c>] (kmem_zone_alloc+0x74/0xe4)
[<c048e85c>] (kmem_zone_alloc+0x74/0xe4) from [<c046ca14>] (xfs_inode_alloc+0x24/0xc4)
[<c046ca14>] (xfs_inode_alloc+0x24/0xc4) from [<c046ce10>] (xfs_iget+0x35c/0x570)
[<c046ce10>] (xfs_iget+0x35c/0x570) from [<c04391a4>] (xfs_qm_dqusage_adjust+0x58/0x174)
[<c04391a4>] (xfs_qm_dqusage_adjust+0x58/0x174) from [<c0475980>] (xfs_bulkstat+0x6ec/0xbe8)
[<c0475980>] (xfs_bulkstat+0x6ec/0xbe8) from [<c0439ac0>] (xfs_qm_quotacheck+0x100/0x194)
[<c0439ac0>] (xfs_qm_quotacheck+0x100/0x194) from [<c043a5c8>] (xfs_qm_mount_quotas+0xd8/0x170)
[<c043a5c8>] (xfs_qm_mount_quotas+0xd8/0x170) from [<c048339c>] (xfs_mountfs+0x5e0/0x6d0)
[<c048339c>] (xfs_mountfs+0x5e0/0x6d0) from [<c049b534>] (xfs_fs_fill_super+0x1d4/0x318)
[<c049b534>] (xfs_fs_fill_super+0x1d4/0x318) from [<c02c6f80>] (get_sb_bdev+0x124/0x154)
[<c02c6f80>] (get_sb_bdev+0x124/0x154) from [<c049931c>] (xfs_fs_get_sb+0x18/0x24)
[<c049931c>] (xfs_fs_get_sb+0x18/0x24) from [<c02c5d0c>] (vfs_kern_mount+0x50/0xa8)
[<c02c5d0c>] (vfs_kern_mount+0x50/0xa8) from [<c02c5da8>] (do_kern_mount+0x34/0xdc)
[<c02c5da8>] (do_kern_mount+0x34/0xdc) from [<c02dde54>] (do_mount+0x160/0x848)
[<c02dde54>] (do_mount+0x160/0x848) from [<c02de5d8>] (sys_mount+0x9c/0xd0)
[<c02de5d8>] (sys_mount+0x9c/0xd0) from [<c023f040>] (ret_fast_syscall+0x0/0x2c)
Mem-info:
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:  40
Active_anon:597 active_file:0 inactive_anon:608
 inactive_file:4 unevictable:3000 dirty:0 writeback:0 unstable:0
 free:2556 slab:17469 mapped:451 pagetables:71 bounce:0
Normal free:10224kB min:10240kB low:12800kB high:15360kB active_anon:2388kB inactive_anon:2432kB active_file:0kB inactive_file:16kB unevictable:12000kB present:130048kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0
Normal: 304*4kB 173*8kB 53*16kB 10*32kB 5*64kB 2*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 1*4096kB = 10232kB
3487 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages of RAM
2695 free pages
1759 reserved pages
17472 slab pages
2259 pages shared
0 pages swap cached
Out of memory: kill process 1315 (zyshd) score 750 or a child
Killed process 1452 (zyshd)

Danach kommt nix mehr.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mittels https://github.com/jedie/NAS7820-Tools/tree/master/usb_key_func 
komme ich noch ran an die Kiste.

Kenne mich mit RAID und mdadm aber nicht aus. Ich schau mir mal die 
Beiträge bei http://serverfault.com/questions/tagged/mdadm an...

Hier info's:
/ # mdadm --examine /dev/sda2
/dev/sda2:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 6764ac2f:13c1222d:89c3c472:784d3b93
  Creation Time : Wed Aug 17 21:49:13 2011
     Raid Level : raid1
  Used Dev Size : 1464621888 (1396.77 GiB 1499.77 GB)
     Array Size : 1464621888 (1396.77 GiB 1499.77 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 4

    Update Time : Fri Dec 16 14:00:52 2011
          State : clean
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0
       Checksum : 1aeba5c0 - correct
         Events : 185105


      Number   Major   Minor   RaidDevice State
this     0       8        2        0      active sync   /dev/sda2

   0     0       8        2        0      active sync   /dev/sda2
   1     1       0        0        1      faulty removed
"faulty removed" hört sich nicht gut an, was?
/ # mdadm --version
mdadm - v3.1.5 - 23rd March 2011
/ # mdadm --detail /dev/md4
mdadm: md device /dev/md4 does not appear to be active.
/ # cat /proc/mdstat 
Personalities : [linear] [raid0] [raid1] 
unused devices: <none>

Was könnte ich tun?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tolle Fortschritte jedenfalls, auch wenn noch nicht alles reibungslos 
läuft!

Jens D. schrieb:
> [    2.250000] Creating 2 MTD partitions on "NAND 128MiB 3,3V 8-bit":
> [    2.250000] 0x000000000000-0x000000e00000 : "boot"
> [    2.260000]  sda1 sda2
> [    2.260000] 0x000000e00000-0x000008000000 : "rootfs"

Was bedeutet denn dieses "Creating" von Partitionen im NAND, kann es 
sein, daß der Arch-Kernel tatsächlich da im NAND was verändert und daß 
deswegen der Original-Kernle und die Original-FW zerschossen sind?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Letzte Zeilen per UART sind:
> ...
> Danach kommt nix mehr.

Vielleicht wären auch die Zeilen von Anfang an interessant gewesen, um 
eventuell was zu finden, was schief gegangen sein könnte, mit 
irgendwelchem mounten von NAND-Bereichen...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im nacken System kommt man so an die Daten ran:
/ # mdadm --assemble /dev/md0 /dev/sda2 --run
mdadm: /dev/md0 has been started with 1 drive (out of 2).
/ # mount -t xfs /dev/md0 /mnt
/ # mdadm --detail /dev/md0
/dev/md0:
        Version : 0.90
  Creation Time : Wed Aug 17 21:49:13 2011
     Raid Level : raid1
     Array Size : 1464621888 (1396.77 GiB 1499.77 GB)
  Used Dev Size : 1464621888 (1396.77 GiB 1499.77 GB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 0
    Persistence : Superblock is persistent

    Update Time : Thu Jan  1 00:18:47 1970
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : 6764ac2f:13c1222d:89c3c472:784d3b93
         Events : 0.185107

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       0        0        1      removed



Die Daten sind dann unter mnt

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Was bedeutet denn dieses "Creating" von Partitionen im NAND, kann es
> sein, daß der Arch-Kernel tatsächlich da im NAND was verändert und daß
> deswegen der Original-Kernle und die Original-FW zerschossen sind?

Hallo,

ich habe mehrmals zwischen Arch/Pogoplug- und Medion-Kernel hin und her 
gewechselt und hatte kein Problem mit dem Flash.

Mir kommt aber gerade ein anderer Gedanke:

In der Tat habe ich noch nicht raus gefunden wie man dem Arch-Kernel die 
Geometrie des Nands mitteilt. Deshalb wird anscheinend das Defaultlayout 
verwendet.
Jens hat ja beim ersten Boot anscheinend keinen Rootfs-Parameter 
angenommen. Da könnte es sein, dass Arch dann MTD2 als Root verwendet 
hat und schreibend darauf zugegriffen hat.

Alles nur Spekulation, wäre aber eine Erklärung.

Tschüss Dimpflmoser

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Dieses Verzeichnis ist allerdings leer:/sys/devices/system/cpu/cpu1

Jep, das ist beim ArchLinuxARM Kernel auch "voll":
[jens@alarm ~]$ ls /sys/devices/system/cpu/cpu0/topology/
core_id        core_siblings_list   thread_siblings
core_siblings  physical_package_id  thread_siblings_list
[jens@alarm ~]$ ls /sys/devices/system/cpu/cpu1/topology/
core_id        core_siblings_list   thread_siblings
core_siblings  physical_package_id  thread_siblings_list

mit htop sieht man auch schön die die Last auf zwei Kernen verteilt 
wird. So wie es sich gehört ;)

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegen RAID defekt: 
http://archlinuxarm.org/forum/viewtopic.php?p=11374#p11374

Wobei ich vermute, das es einfach nur als "defekt" markiert ist, aber 
nicht wirklich kaputt ist. Die Frage ist jedoch, wie man diesen "Flag" 
zurück setzten kann...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wachtmeister Dimpflmoser schrieb:
>> IMHO interessanter wäre ein uBoot mit USB Support. Dann könnte man ein
>> eigenes System starten (von USB oder Platte), wenn ein USB-Stick dran
>> hängt. Wenn nicht dann normales System als fallback starten.
> Das wäre natürlich genial. Man könnte auf den USB-Stick den Kernel und
> eventuell eine initrd legen, wenn der Kernel gefunden wir wird dieser
> geladen, ansonsten der interne Kernel.

Ich glaube, selbst im aktuellem uBoot - 
https://github.com/michaelkebe/u-boot-medion-p89626/blob/master/README - 
wird bloß UHCI unterstützt, unser SoC scheint EHCI zu haben, und auch 
das, nicht wirklich standard...

> Ansonsten möchte ich nur einen weniger vermurksten Kernel haben, damit
> ich den VDR zum Laufen bekomme.

Tja, das wäre natürlich ein guter VDR Server. Wie sieht es mit dem 
Pogoplug / Archlinux Kernel USB-mässig aus? In meinem Gentoo chroot 
innerhalb der laufenden Original-FW (denn mein UART-Kabel ist noch in 
einem desolaten Zustand, wegen meinem Sohn der mal daran zerren musste, 
ich werde aber wahrscheinlich demnächst wieder zum Lötkolben greifen) 
schlägt lsusb fehl:
medion-nas / # lsusb
unable to initialize libusb: -99

BTW, ein cooler VDR Server wäre ein NAS mit einem mini-PCIe Slot, da 
könnte man vielleicht so eine Octopus-Bridge von DigitalDevices 
verwenden, nur weiß ich auch da nicht ob die ganzen Treiber GPL und 
somit für armv6 übersetzbar sind....

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wollte eigentlich aus der Dockstar ein VDR-Server machen. Das Problem 
war aber das ich keine DVB USB-Stick gefunden habe, der unter Linux auch 
läuft :(

lsusb in chroot hat bei mir IMHO ebenfalls nicht funktioniert.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Wollte eigentlich aus der Dockstar ein VDR-Server machen. Das Problem
> war aber das ich keine DVB USB-Stick gefunden habe, der unter Linux auch
> läuft :(

Habe mir einen DVB-USB-Dongle von Sundtek gekauft, der ist zwar relativ 
teuer, closed source aber er tut in der Dockstar und auch im Medion 
Image wurde die Karte/der Dongle erkannt.
Deren Support scheint wirklich gut zu sein, d.h. deren höherer Preis 
geht anscheinend direkt in den Community support.

>
> lsusb in chroot hat bei mir IMHO ebenfalls nicht funktioniert.
'Mein' Arch-Kernel hatte nur wenige USB-Features eincompiliert. Habe das 
zwar inzwischen gemacht aber habe noch nicht nachgesehen ob sich der 
USB-Support verbessert hat.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wachtmeister Dimpflmoser schrieb:
> Jens D. schrieb:
>> lsusb in chroot hat bei mir IMHO ebenfalls nicht funktioniert.
> 'Mein' Arch-Kernel hatte nur wenige USB-Features eincompiliert. Habe das
> zwar inzwischen gemacht aber habe noch nicht nachgesehen ob sich der
> USB-Support verbessert hat.

Ok, habe mal nachgesehen und bin recht angetan:
Arch Linux 2.6.31.6_SMP_820  (alarm) (ttyS0)

alarm login: root
Password: 
Last login: Fri Dec 16 13:45:30 CST 2011 on ttyS0
[root@alarm ~]# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[root@alarm ~]# [ 1442.610000] usb 1-2: new high speed USB device using oxnas-ehci and address 2
[ 1442.760000] usb 1-2: configuration #1 chosen from 1 choice
[ 1442.780000] scsi2 : SCSI emulation for USB Mass Storage devices
[ 1447.810000] scsi 2:0:0:0: Direct-Access     Imation  Atom USB Device  PMAP PQ: 0 ANSI: 0 CCS
[ 1448.190000] sd 2:0:0:0: [sdb] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB)
[ 1448.200000] sd 2:0:0:0: [sdb] Write Protect is off
[ 1448.200000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1448.210000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1448.220000]  sdb: sdb1
[ 1448.250000] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1448.250000] sd 2:0:0:0: [sdb] Attached SCSI removable disk

[root@alarm ~]# mount /dev/sdb1 /mnt
[root@alarm ~]# mount
/dev/root on / type ext2 (rw,relatime,errors=continue)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
/sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
/run on /run type tmpfs (rw,nosuid,nodev,relatime,size=10240k,mode=755)
udev on /dev type tmpfs (rw,nosuid,relatime,size=10240k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev)
/dev/sdb1 on /media/ATOM type vfat (rw,noatime,utf8,gid=100,umask=002)
/dev/sdb1 on /mnt type vfat (rw)

[root@alarm ~]# ls /mnt/nas/
32bit                             dreambox
32bit23                           EmbestRecipe.html
4161.0.gpl_source_md86407.exe     installer.tar.gz
64bit                             medion
arch                              mips
ArchLinuxARM-oxnas-latest.tar.gz  mipsel
armoabi                           mipsel2
armsysv                           mipselbcm
chk32bit                          nanddump
chk32bit23                        nandtest
chk64bit                          nandwrite
chkarmoabi                        openwrtmipsr2
chkarmsysv                        oxnas-install.sh
chkmips                           ppc32
chkmipsel                         ppc64
chkmipsel2                        sh4
chkmipselbcm                      sundtek_installer_110909.1537.sh
chkopenwrtmipsr2                  sundtek_installer_development.sh
chkppc32                          uImage.nopci
chkppc64                          uImage.pci
chksh4                            xfsloop

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wachtmeister Dimpflmoser schrieb:
> Ok, habe mal nachgesehen und bin recht angetan:
> Arch Linux 2.6.31.6_SMP_820  (alarm) (ttyS0)
> ...
> [root@alarm ~]# lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Sieht in der Tat nicht schlecht aus. Würdest Du bitte Deine 
Kernel-Konfig irgendwo hochladen?

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Derzeit bemühe ich mich gerade am MTD/NAND-Flash aber komme irgendwie 
nicht weiter:

Ich habe nirgendwo rausgefunden wie man zur Runtime / mit einem Userland 
Tool die MTD-Partitonen konfigurieren kann.
Habe weder im Medion- noch im Pogoplug-Kernel eine 
Konfigurations-Möglichkeit für das MTD-Layout gefunden. Allerdings 
gibt's eine Config-Option die so was ähliches sagt wie: Parse MTD 
CMDLINE ARGs.

Bei meinem Atmel-Board gibt man dann die Config über die bootargs-Zeile 
an. Und zwar in der Form:
setenv bootargs <op 1> .. <op-N> mtdparts=\
 <nand_name>:<size1>(<name1>)[ro|rw],<size2>(name2)[ro,rw]...

Anscheindend wird aber dieser Parameter ignoriert.
Im Bootlog sieht man dann dass das Nand mit dem Namen "NAND 128MiB 3,3V 
8-bit" angelegt wird. Nach etwas Suchen habe ich den Hinweis gefunden, 
dass dieser Name mit Spaces nicht per U-Boot übergeben werden kann. Also 
habe ich ein wenig nach diesem Namen gesucht und habe die Spaces und 
Sonderzeichen rausgenommen. Der Namen lautet jetzt NAND128NiB3_3V8bit. 
Leider scheint das auch nicht zu helfen.

Irgend eine Idee???

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ich antworte mir mal wieder selbst. :-/

Habe im Medion-Kernel das Layout für das NAND-Flash gefunden und zum 
Pogoplug rüber kopiert.

Der Bootvorgang sieht jetzt so aus:
## Booting image at 61000000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2409196 Bytes =  2.3 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux...........................................................................................................................
[    0.000000] Linux version 2.6.31.6_SMP_820 (jo@waldhof) (gcc version 4.3.2 (crosstool-NG-1.8.0) ) #105 SMP Fri Dec 16 21:31:13 CET 2011
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS
<snip>
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/sda2 mem=128M
<snip>
[    0.700000] SCSI subsystem initialized
[    0.700000] usbcore: registered new interface driver usbfs
[    0.710000] usbcore: registered new interface driver hub
[    0.710000] usbcore: registered new device driver usb
[    0.750000] NET: Registered protocol family 2
<snip>
[    2.210000] NAND device: Manufacturer ID: 0xad, Chip ID: 0xf1 (Hynix NAND128MiB3_3V8bit)
[    2.210000] Scanning device for bad blocks
<snip>
[    2.280000] Creating 7 MTD partitions on "NAND128MiB3_3V8bit":
[    2.280000] 0x000000000000-0x000000040000 : "stage1"
[    2.290000] 0x000000040000-0x0000003c0000 : "uboot"
[    2.300000] 0x0000003c0000-0x000000440000 : "uboot_env"
[    2.300000] 0x000000440000-0x000000e40000 : "kernel"
[    2.310000] 0x000000e40000-0x000001840000 : "etc"
[    2.320000] 0x000001840000-0x000002240000 : "info"
[    2.330000] 0x000002240000-0x000008000000 : "sysdisk"
[    2.330000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
<snip>

Habe noch nicht versucht das Nand zu mounten, aber Ihr könnt Euch denken 
was ich gleich mache. ;-)

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier jetzt mal meine aktuellen Dateien zum Download:

aktuelles uImage:
Pogoplug - noPci - XFS-Support - USB-Support - MTD/NAND-Layout
https://s3-eu-west-1.amazonaws.com/medion-nas/uImage_pogo_xfs_usb_mtd
https://s3-eu-west-1.amazonaws.com/medion-nas/uImage_pogo_xfs_usb_mtd.md5

die aktuelle .config dazu:
https://s3-eu-west-1.amazonaws.com/medion-nas/.config_pogoplug_xfs_usb
https://s3-eu-west-1.amazonaws.com/medion-nas/.config_pogoplug_xfs_usb.md5

Um das Image zu bauen sollte man sich aus dem Medion-Kernel-Tree 
folgende Datei in den Pogoplug-Tree kopieren:
./drivers/mtd/nand/ox820_nand.c

Bye Dimpflmoser

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab gerade gesehen, das ArchLinuxARM auf Dockstar und GoFlexNet/-Home 
sehr einfach installierbar sind:

http://archlinuxarm.org/platforms/armv5/seagate-dockstar
http://archlinuxarm.org/platforms/armv5/seagate-goflex-net
http://archlinuxarm.org/platforms/armv5/seagate-goflex-home

Interessant dabei:
Can I use ext3/4?
U-Boot only supports booting from ext2 drives. Booting from ext3/4 drives is unstable and is not recommended. But, if you know what you're doing, you can make an ext2 /boot partition as sda1 and partition the rest as ext3/4. Make sure to edit /etc/fstab too! 

Doch, wie sieht es eigentlich mit Updates aus? Wenn der Kernel im NAND 
ist, muß er ja nach jedem Update auch neu geflasht werden. Ich meine ich 
hätte vor einigen Monaten gelesen, das man das automatisieren will. Weiß 
da jemand was drüber?

Wäre es somit nicht das beste den Kernel auf einer ext2 Partition zu 
belassen und ein uBoot zu installieren, welches den dann von dort lädt? 
Im NAND könnte man vielleicht noch einen "alternden" Fallback Kernel 
belassen...
Dann müßte man sicht beim "dist-upgrade" um nicht viel kümmern.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Wäre es somit nicht das beste den Kernel auf einer ext2 Partition zu
> belassen und ein uBoot zu installieren, welches den dann von dort lädt?
> Im NAND könnte man vielleicht noch einen "alternden" Fallback Kernel
> belassen...

Ja was versuche ich Buffalo Linkstation Verwöhnter Euch denn alle paar 
Postings von mir nahe zu bringen, mit u-Boot welcher loadext2 kann, 
Umpartitionieren der internen Platte ;-) ???

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, mein aktueller Pogoplug/Arch-Kernel erkennt jetzt zwar die 
richtigen Partitionen, allerdings hat dieser Kernel keine 
YAFFS2-Unterstützung. Die scheint überhaupt nicht im Source-Tree 
enthalten zu sein, weshalb wir die wahrscheinlich aus dem Medion-Kernel 
rüber ziehen müssen.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wachtmeister Dimpflmoser schrieb:
> Schade, mein aktueller Pogoplug/Arch-Kernel erkennt jetzt zwar die
> richtigen Partitionen, allerdings hat dieser Kernel keine
> YAFFS2-Unterstützung. Die scheint überhaupt nicht im Source-Tree
> enthalten zu sein, weshalb wir die wahrscheinlich aus dem Medion-Kernel
> rüber ziehen müssen.

Hat denn auch die Benennung des NAND mit oder ohne Spaces (siehe Jens 
Post Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS") irgend eine 
Bedeutung?

Und noch was: Es gibt doch, ichglaube seitens der Archlinux guys 
Bemühungen, einen 3.1er Kernel Oxnas-fit zu machen. Könnte es denn nicht 
sein, dass da schon weitaus mehr unterstützt wird (z.B. auch dieses 
YAFFS2)?

Aber ich will natürlich Deine Arbeit auf gar keinen Fall schmälern, 
dieser Pogoplug/Arch-Kernel wie er bei Dir schon bootet ist erstmal 
natürlich der Hammer, wenn alles Nötige auch vernünftig läuft, 
hauptsache dual-core! Ob das vielleicht mal Hitzeprobleme machen wird 
(z.B. wenn man doch mal was nativ auf dem Kistchen kompilieren muss oder 
so), lassen wir auf uns zukommen, und suchen dann auch dafür Lösungen...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Ja was versuche ich Buffalo Linkstation Verwöhnter Euch denn alle paar
> Postings von mir nahe zu bringen, mit u-Boot welcher loadext2 kann,
> Umpartitionieren der internen Platte ;-) ???

Ja, ich denke Platte platt machen, ist IMHO keine schlechte Idee 
(besonders jetzt, wo bei mir das Original System es eh nicht mehr tut ;) 
)

Aber auch generell: RAID und XFS ist mit ein wenig suspekt ;)

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Ja was versuche ich Buffalo Linkstation Verwöhnter Euch denn alle paar
> Postings von mir nahe zu bringen, mit u-Boot welcher loadext2 kann,
> Umpartitionieren der internen Platte ;-) ???

Das könnte schon eine guter Ansatz sein.

Ich denke, die interne Platte kann man problemlos platt machen und so 
formatieren wie man das für sich benötigt.
Man könnte eine eine boot-Partition mit ext2 anlegen auf der der Kernel 
liegt. Da sie im Normalbetrieb ja nicht bzw. nur Read-Only gemountet 
wird ist ext2 ja auch keine echte Einschränkung. Das Rootfs kann dann ja 
wieder ein beliebiges Dateisystem haben.

Grundsätzlich wäre ich halt seeeehr vorsichtig das u-boot image zu 
überschreiben. Statt dessen würde ich eher das bisherige ziemlich 
überdimensionierte Kernel-Image teilen, in den ersten Teil kommt dann 
der 'neue' U-Boot drauf, dahinter der Fallback/Medion-Kernel.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Hat denn auch die Benennung des NAND mit oder ohne Spaces (siehe Jens
> Post Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS") irgend eine
> Bedeutung?

Bin mir nicht sicher ob ich verstehe was Du meinst. Dieser Namen 'NAND 
128MiB 3,3V 8-bit' ist nur dafür da, um den richtigen Baustein zu 
identifizieren. Also für den Fall, dass Du mehrere Bausteine hättest.

So lange der Name beim Kernelbauen uns später beim Parsen identisch ist 
ist  es anscheinend egal wie man ihn schreibt. Hatte nur von einem Typen 
ein Posting gelesen, der sagte, dass er einen Namen mit Leerzeichen noch 
nicht per Bootargs ansprechen konnte.
Sobald /dev/mtd mal erkannt ist ist der Name AFAIK irrelevant. Auch die 
Namen der Partitionen ist nicht wirklich relevant, vielleicht 
vergleichbar mit dem Label bei Disk-Partitionen. Die MTD-Partitionen 
spricht man später ja per /dev/mtd<X> bzw /dev/mtdblock<X> an und nicht 
mit dem Namen.

Ist halt Human Readable und schützt so etwas vor kleinen Katastrophen 
beim Flashen.

> Und noch was: Es gibt doch, ichglaube seitens der Archlinux guys
> Bemühungen, einen 3.1er Kernel Oxnas-fit zu machen. Könnte es denn nicht
> sein, dass da schon weitaus mehr unterstützt wird (z.B. auch dieses
> YAFFS2)?
Grundsätzlich sehe ich bei unserem Kernel kein Problem wegen yaffs2. Da 
dieser Support ja im Medion-Kernel drin ist bekommen wir den auch in den 
Pogoplug-Kernel rein. Ist alles eine Frage der Mühe, die wir uns machen.

> Aber ich will natürlich Deine Arbeit auf gar keinen Fall schmälern,
Ach wass, mach' Dir deshalb keinen Kopf, bei Open Source Hacken ist doch 
der Wettbewerb wer was schneller hinbekommt und so mehr Aufsehen erregt.
Ich habe den Eindruck die aktiven hier ergänzen sich ganz gut, jeder hat 
so seine eigene Schwerpunkte und wenn wir es schaffen, das irgendwie zu 
koordinieren und bündeln wird das bestimmt ein schönes Ergebnis.

Ich hoffe ja, dass unsere Community etwas anwächst wenn nächste Woche 
(22.12.) das Teil bei Aldi-Nord verkauft wird.
Vielleicht haben die ja schon einen besseren Kernel drauf von dem wir 
schnorren können.
Zumindest haben die frischen Käufer einen besseren Einstieg da sie auf 
die Vorarbeit von Aussies, ArmArch und uns zurückgreifen können.
Ich denke wir haben da schon einen guten Schritt gemacht.

> dieser Pogoplug/Arch-Kernel wie er bei Dir schon bootet ist erstmal
> natürlich der Hammer, wenn alles Nötige auch vernünftig läuft,
> hauptsache dual-core!
Ja eigentlich glaube ich, dass das nakte System halbwegs gut die HW 
unterstützt. Die ganzen Media-Streaming/Backup/Web-Interface sachen sind 
zwar weg, aber wer weiß vielleicht können wir die später alle aus dem 
NAND-Flash starten.

Ansonsten ist die Kiste eigentlich schon fast in dem Zustand, dass ich 
mich um den VDR kümmern könnte. Allerdings muss ich mich dann doch mal 
aufraffen und das Teil so flashen, dass es selbständig bootet, aber ich 
trau' mich noch ned.


> Ob das vielleicht mal Hitzeprobleme machen wird
> (z.B. wenn man doch mal was nativ auf dem Kistchen kompilieren muss oder
> so), lassen wir auf uns zukommen, und suchen dann auch dafür Lösungen...
Also ohne Gehäuse und das Blech von der Plattenrückseite entfernt wird 
die Box bisher nicht sehr heiß.

Da die Box bei mir sowieso in den Keller soll mache ich mir auch keine 
Sorgen drum, da eventuell noch einen Lüfter drauf blasen zu lassen.
Irgendwo haben wir doch auch noch eine Lüftersteuerung in den Sourcen 
gefunden, wer weiß vielleicht können wir die ja abgreifen. Aber das 
wirklich später

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wachtmeister Dimpflmoser schrieb:
> Grundsätzlich wäre ich halt seeeehr vorsichtig das u-boot image zu
> überschreiben.

Wieso? Wenn ein uBoot über TFTP funktioniert, sollte es dann auch aus 
dem NAND funktionieren, oder nicht?

Noch eine Idee: Kann man nicht einen zusätzliches uBoot parallel zum 
original ins NAND packen? Ich kenne die Größenordnungen nicht wirklich, 
aber 128MB hört sich nach recht viel an ;)

btw. die Original Software schaut des öfteren bei Medion auf dem Server 
vorbei. Die könnten natürlich auf die Idee kommen, eine neue Firmware 
raus zu bringen und den bisher genutzten Zugang zu zu machen. z.B. damit 
keiner nachsehen kann, ob wirklich dualcore oder nicht ;) Wobei UART 
können die ja schlecht schließen, oder?

Öberflächlich gesehen, wird es Otto-Normalos wohl egal sein, ob 2 Kerne 
oder nicht. Doch wenn jemand Streming + Konvertierung nutzt und es 
ruckelt, dann vielleicht schon ;)

Ich für meinen Teil, brauche den ganzen Streaming Quatsch nicht. Am ende 
soll NFS und Samba laufen...
VDR wollte ich eigentlich auf die Dockstar packen ;) Dazu aber im 
anderen Thread mehr...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Die Demontage und das Wechseln der S-ATA Festplatte ist sehr einfach für
> Schrauber möglich: Unter den Gummifussflächen sind zwei Schrauben zu
> lösen, dann kann man das Gehäuse aus zwei Schalen recht einfach
> auseinander nehmen.

Verdammt, wie kriege ich denn die Gehäusehälften auseinander, nachdem 
die 2 Schräubchen aus den Füssen 'raus sind, die sind so fest 
aneinander? Ich will gerade sehen ob 2x4-adrige Flachkabelbuchsen auf 
die UART-Pins passen, dann löte ich mir das Konverterkabel welches ich 
früher bei der Linkstation hin und wieder genutzt habe, wieder 
zusammen...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Verdammt, wie kriege ich denn die Gehäusehälften auseinander, nachdem
> die 2 Schräubchen aus den Füssen 'raus sind, die sind so fest
> aneinander?

Ok, so langsam lassen die sich auseinanderspreizen, ich war halt mit 
diesen winzigen Laschen und Haken übervorsichtig...

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So habe jetzt yaffs2 im Kernel drin, aber da kommen viele 
Fehlermeldungen und ich wäre derzeit zu ängstlich, um da auch einen 
Schreibzugriff zu testen.

Hier mal der Output:
[root@alarm ~]# mkdir /mnt/mtdblock5 /mnt/mtdblock6 /mnt/mtdblock7

[root@alarm ~]# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 08000000 00020000 "NAND128MiB3_3V8bit"
mtd1: 00040000 00020000 "stage1"
mtd2: 00380000 00020000 "uboot"
mtd3: 00080000 00020000 "uboot_env"
mtd4: 00a00000 00020000 "kernel"
mtd5: 00a00000 00020000 "etc"
mtd6: 00a00000 00020000 "info"
mtd7: 05dc0000 00020000 "sysdisk"

[root@alarm ~]# mount -o ro -t yaffs2 /dev/mtdblock5 /mnt/mtdblock5
[  119.450000] yaffs: dev is 32505861 name is "mtdblock5" ro
[  119.450000] yaffs: passed flags ""

[root@alarm ~]# mount -o ro -t yaffs2 /dev/mtdblock6 /mnt/mtdblock6
[  127.290000] yaffs: dev is 32505862 name is "mtdblock6" ro
[  127.290000] yaffs: passed flags ""
[  127.320000] uncorrectable error : 
<snip>
[  127.380000] uncorrectable error : 

[root@alarm ~]# mount -o ro -t yaffs2 /dev/mtdblock7 /mnt/mtdblock7
[  134.790000] yaffs: dev is 32505863 name is "mtdblock7" ro
[  134.790000] yaffs: passed flags ""
[  138.000000] uncorrectable error : 
<snip>
[  138.010000] uncorrectable error : 

[root@alarm ~]# ls -l /mnt/mtdblock5
total 32
-rw-r--r-- 1 root root 3072 Oct  5 08:21 backupjob.db
drwxr-xr-x 1 root root 2048 Dec 31  1969 cert
drwxr-xr-x 1 root root 2048 Dec 16 11:21 conf
drwxr-xr-x 1 root root 2048 Oct  5 08:54 dmsf
-rw-r--r-- 1 root root 3072 Dec 14 16:26 dservice.db
-rw-r--r-- 1 root root  170 Dec 14 16:17 flickr-ul.conf
-rw-r--r-- 1 root root  170 Dec 14 16:05 flickr-ul.conf~
-rw-r--r-- 1 root root    5 Dec 14 16:17 flickr-ul.dat~
<snip
-rw-r--r-- 1 root root  135 Oct  5 08:21 zy-pkg.conf
drwxr-xr-x 1 root root 2048 Oct  5 08:54 zy-pkgs

[root@alarm ~]# ls -l /mnt/mtdblock6
[  157.160000] uncorrectable error : 
[  157.170000] uncorrectable error : 
[  157.170000] uncorrectable error : 
[  157.170000] uncorrectable error : ls: /mnt/mtdblock6/revision: No such
[  157.180000] uncorrectable error :  file or directo
[  157.180000] uncorrectable error : ry
ls: /mnt/mtdbloc
[  157.190000] uncorrectable error : k6/zld_checksum:
[  157.190000] uncorrectable error :  No such file or
[  157.200000] uncorrectable error :  directory

[  157.200000] uncorrectable error : ls: /mnt/mtdblock6/r
[  157.210000] uncorrectable error : omfile_checksum:
[  157.210000] uncorrectable error :  No such file or
[  157.220000] uncorrectable error :  directory
ls: 
[  157.220000] uncorrectable error : /mnt/mtdblock6/i
[  157.230000] uncorrectable error : mage_checksum: N
[  157.230000] uncorrectable error : o such file or d
[  157.240000] uncorrectable error : irectory
ls: /m
[  157.240000] uncorrectable error : nt/mtdblock6/los
[  157.250000] uncorrectable error : t+found: No such
[  157.250000] uncorrectable error :  file or directory
ls: /mnt/mtd
[  157.260000] uncorrectable error : block6/modelid: 
[  157.260000] uncorrectable error : No such file or directory
ls: /mnt/mtdblock6/fwversion: No such file or directory
ls: /mnt/mtdblock6/core_checksum: No such file or directory
ls: /mnt/mtdblock6/lost+found: No such file or directory
total 8
-rw-r--r-- 1 root root   33 Oct  6 06:16 core_checksum
-rwxr-xr-x 1 root root   64 Dec 31  1969 fw_key
-rw-r--r-- 1 root root   12 Oct  6 06:16 fwversion
-rw-r--r-- 1 root root   33 Oct  6 06:16 image_checksum
drw-r--r-- 1 root root 2048 Oct  6 06:51 lost+found
drw-r--r-- 1 root root 2048 Oct  6 06:51 lost+found
-rw-r--r-- 1 root root    5 Oct  6 06:16 modelid
-rw-r--r-- 1 root root    6 Oct  6 06:16 revision
-rw-r--r-- 1 root root    5 Oct  6 06:16 romfile_checksum
-rw-r--r-- 1 root root   33 Oct  6 06:16 zld_checksum

[root@alarm ~]# ls -l /mnt/mtdblock7
[  164.350000] uncorrectable error : 
[  164.350000] uncorrectable error : ls: /mnt/mtdblock7: No such file or directory
[  164.360000] uncorrectable error : 
[  164.360000] uncorrectable error : ls: /mnt/mtdblock7/sysdisk.img: No such file or directory
total 88066
drwx------ 1 root root     2048 Dec 16 16:31 lost+found
-rw-r--r-- 1 root root 90177536 Oct  6 06:53 sysdisk.img

[root@alarm ~]# losetup /dev/loop0 /mnt/mtdblock7/sysdisk.img 
[root@alarm ~]# mount -o ro /dev/loop0 /mnt/sysdisk

[  478.080000] uncorrectable error : 
<gaaaanz viel snip>
[  483.620000] uncorrectable error : 
[  483.630000] uncorrectable error : mount: mount point /mnt/sysdisk does not exist
[root@alarm ~]# mkdir /mnt/sysdisk
[root@alarm ~]# mount -o ro /dev/loop0 /mnt/sysdisk                                                                                           
[root@alarm ~]# ls /mnt/sysdisk/
bin  lib  lost+found  sbin  tmp.tar.gz  usr


Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> http://archlinuxarm.org/platforms/armv5/seagate-dockstar
> http://archlinuxarm.org/platforms/armv5/seagate-goflex-net
> http://archlinuxarm.org/platforms/armv5/seagate-goflex-home
>
> Interessant dabei:Can I use ext3/4?
> U-Boot only supports booting from ext2 drives....

Hm. Dieses "only ext2" stammt von der dockstar Anleitung. Doch bei der 
zu GoFlexNet / GoFlexHome wird ext3 eingerichtet.

Ob die Deskstar-Anleitung veralter ist, oder hat es was mit ext3 über 
SATA und ext2 über USB zu tun?

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Hm. Dieses "only ext2" stammt von der dockstar Anleitung. Doch bei der
> zu GoFlexNet / GoFlexHome wird ext3 eingerichtet.
>
> Ob die Deskstar-Anleitung veralter ist, oder hat es was mit ext3 über
> SATA und ext2 über USB zu tun?

ext3 ist ext2+Journal, d.h. wenn Du ein ext3-Laufwerk als ext2 mountest 
ist das kein Unterschied zu einem 'normalen' ext2. Demnach wird u-boot 
auch auf ext3 zugreifen können, mit journaling ist halt nix, wobei das 
bei RO-Access auch keinen Sinn macht.

Bye Dimpflmoser

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yessss, nun habe ich auch UART Zugang, zwar ist mein Kabel relativ kurz, 
aber dafür steckt es in der Linkstation wo ich mit ssh 'rankomme und 
dann mit minicom los geht's...

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Yessss, nun habe ich auch UART Zugang, zwar ist mein Kabel relativ kurz,
> aber dafür steckt es in der Linkstation wo ich mit ssh 'rankomme und
> dann mit minicom los geht's...

Versteh' ich das richtig, Du benutzt Deine Linkstation als Adapter? D.h. 
SSH vom PC zur Linkstation, UART-TTL von Linkstation zu UART-TTL zur 
Medion? Auch 'ne gute Idee.

Ich bin ja froh, dass ich das Kabel von einem Kollegen geliehen bekam, 
da mein Kabel per Warensendung verschickt wird, was kurz vor Weihnachten 
nicht wirklich flink ist.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wachtmeister Dimpflmoser schrieb:
> Versteh' ich das richtig, Du benutzt Deine Linkstation als Adapter? D.h.
> SSH vom PC zur Linkstation, UART-TTL von Linkstation zu UART-TTL zur
> Medion? Auch 'ne gute Idee.

Fast haargenau so, aber es ist ein normales USB <-> PL-2303 <-> TTL-UART 
Kabel (genau einer von diesen hier hat mir mindbender damals geschickt: 
http://buffalo.nas-central.org/wiki/Use_a_cheap_phone_sync_cable_with_the_serial_port) 
welches ich auch direkt vom PC nutzen könnte, also die Linkstation ist 
nun der "PC", weil er an einem ihrer USB-Ports steckt, nicht in ihrem 
UART, sonst wäre es mir sowas von umständlich...
Im Übrigen ist leider der UART-Anschluss der Linkstation anders belegt 
:-( 
http://buffalo.nas-central.org/wiki/Add_a_Serial_port_to_the_ARM9_Linkstation
Aber im Prinzip müsste es eigentlich bloß mit einem 3-Adrigen Kabel 
zwischen 2 UARTS von 2 NASen möglich sein, keine schlechte Idee....

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich werde mir im Laufe des heutigen Tages (naja, zwischen Einkaufen mit 
Frau u. Kind und anderen "real life" Sachen) NFS-Boot in den u-Boot 
Sourcen von Medion vorknüpfen, ich denke das ist auch machbar. Dafür 
aber müsste auch der Kernel das unterstützen? Und noch eine Sache muss 
geklärt werden, und zwar wie man ein "neues" u-Boot dazu bringt, die 
Environment-Konfig aus dem NAND zu nutzen (die will z.B. ein über TFTP 
gestarteter nicht nehmen, da checksum failure, darüber hinaus will es 
wenn es HDD Unterstützung hat, diese auch erstmal von Platte laden). 
Wahrscheinlich muß man da schon beim Übersetzen einige Sachen 
festlegen...

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

so weit ich mich erinnere hat der Medion-Kernel keine Unterstützung für 
NFS-Dateisysteme.
Wäre bestimmt aber keine Hexerei, das in den Kernel rein zu hacken.

U-Boot benötigt doch keinen besonderen NFS-Support, oder willst Du auch 
den Kernel von einem NFS-Share holen?
Habe selbst noch nie U-Boot kompiliert und deshalb keine Erfahrung wie 
man ihn eine neue/bestehende Env runter schieben kann.

Bei mir kommt jetzt auch mein Real-Life mit der Bahn an und bin bis 
Dienstag durch einen langanhaltenden höherprioren Interrupt belegt. ;-)

Tschüss Dimpflmoser

Autor: FileDescriptor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

tolles Forum, da mein MyBook Live 2TB-NAS gerade den Geist aufgibt, muss 
ich die Daten woanders hinsichern, daher habe ich vorgestern bei Aldi 
zugeschlagen. Sehr viel nützliche Info hier in der kurzen Zeit, besten 
Dank an alle!

Ich habe gesehen, dass verschiedene Binaries in den Medion-Sourcen im 
x-tools.armv5v6.tar.gz liegen, die offenbar direkt nutzbar sind (aber 
natürliich noch nicht direkt in den "richtigen" Verzeichnissen liegen):

/i-data/6764ac2f/public/SSH/usr/sbin # ./sshd -v
sshd: illegal option -- v
OpenSSH_5.1p1, OpenSSL 0.9.8o 01 Jun 2010
usage: sshd [-46DdeiqTt] [-b bits] [-C connection_spec] [-f config_file]
            [-g login_grace_time] [-h host_key_file] [-k key_gen_time]
            [-o option] [-p port] [-u len]

rsync und perl liegen auch drin:

ubuntu@d610:~/MEDION_SRC/x-tools/armv6_le/arm-none-linux-gnueabi/sys-roo 
t$  find .|egrep 'perl|rsync'
./usr/lib/perl5
./usr/lib/perl5/5.8.8
./usr/lib/perl5/5.8.8/IO
./usr/lib/perl5/5.8.8/IO/Handle.pm
./usr/lib/perl5/5.8.8/IO/Seekable.pm
./usr/lib/perl5/5.8.8/IO/File.pm
./usr/lib/perl5/5.8.8/File
./usr/lib/perl5/5.8.8/File/Basename.pm
...
./usr/bin/rsync
./usr/bin/perl
./usr/bin/microperl

Damit sollte man das eine oder andere schon auch nativ direkt machen 
können.

Gruß FileDescriptor

Autor: nas-explorer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

versuche gerade den cross-compiler zu installieren, wie auf der 
"articles"-Seite beschrieben:

- Runterladen gpl_source_md86407.exe von Medion
- Entpacken auf Windows-Rechner ergibt eine Liste von tar.gz-Dateien
- Schieben der tar-Archive auf das NAS
- Einloggen als root über telnet
- Entpacken von x-tools über tar -xvf x-tools.armv5v6.tar.gz
- Verschieben von x-tools nach /opt?
Hier tauchte das erste Problem auf: das Root-Filesystem liegt ja im RAM 
des NAS. Da der Ordner x-tools nicht gerade klein ist, scheint er mir 
die ganze Kiste zu blockieren. Außerdem ist das Verzeichnis /opt nach 
jedem Reboot weg. Also habe ich x-tools nach /i-data/md0/.system/opt auf 
die Harddisk geschoben und unter root einen Link /opt -> 
/i-data/md0/.system/opt angelegt.
- Die Systempfade aktualisieren mit
 export 
CC=/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnuea 
bi-gcc
- und, damit man den compiler auch findet zusätzlich zur Anleitung:
 export PATH=$PATH:/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin

Jetzt kann ich den compiler auch wie beschrieben aufrufen, z.B. mit 
arm-none-linux-gnueabi-gcc -Wall -g -o hello hello.c (Schätze mal in der 
Anleitung muss es auch hello.c und nicht hello-c heißen)

Und was passiert? Eine Fehlermeldung:
line 1: syntax error: unexpected "("

Diese Fehlermeldung kommt auch, wenn ich gcc ohne Optionen starte, hat 
also nichts mit meiner garantiert richtigen "hello.c" zu tun.

Hat jemand eine Idee, warum der compiler nicht läuft? Ist die Anleitung 
unvollständig?

Danke!

Autor: Hans M. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@nas-explorer:
ich denke du machst hier einiges falsch.

ich kenne mich zwar mit (cross-)compilern garnicht aus, aber ich weiß 
soviel, dass wenn du auf der box etwas für die Box kompilieren willst, 
brauchst du keinen crosscompiler!!

sowas brauchst du nur wenn du für eine andere architektur etas 
kompilieren willst. Also z.B. auf deinem (x86) PC was für die Box.

ausserdem wenn du auf der Box was compilieren willst brauchst du da wohl 
extrem extrem lange dazu.

also versuch das ganze nochmal auf einem PC.

mfg
Hans

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Medion liefert die Sourcen zwar als exe-Datei, allerdings sind die 
Programme für Linux gedacht. Also Linux-Rechner starten, die x-tools 
nach /opt kopieren, Environment-Variablen setzen und los gehts ... (im 
README steht zwar Debian, aber es sollte eigentlich mit jeder 
Distribution funktionieren).

Autor: nas-explorer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für Eure schnellen Antworten!
Ich will rsync compilieren für ein backup script. Und dafür brauch ich 
einen Compiler (siehe 
ttp://www.mikrocontroller.net/topic/240238#2445374). Und noch diverse 
andere Tools.

Oder habe ich das falsch verstanden und ich erzeuge die binaries für die 
Box auf einem anderen Linux Rechner? Ich dachte ich muss dort 
compilieren, wo ich auch die Anwendung laufen lassen will. Da habe ich 
noch das Problem, dass meine Linux-Kiste gerade den Geist aufgegeben hat 
...

???

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die x-tools sind eine Cross-Compiler Toolschain, d.h. sie erzeugen 
ARM-binaries auf einem x86-System.
Wenn es dir nur um rsync geht, so kannst Du es auch von 
http://dl.dropbox.com/u/9870397/P89626/rsync laden.Ich habe es vor ein 
paar Tagen mit den x-tools erstellt.

Autor: hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
ich möchte abfragen, ob sich die HDD im spindown Zustand befindet und 
zur Kontrolle eine LED zur Anzeige setzten. Den Zustand der HDD frage 
ich wie folgt ab:

/usr/local/zy-pkgs/bin/smartctl -i -n standby /dev/sda

Die LED kann man mit setLED setzen.
Die Befehle funktioniert in der Kommandozeile von Telnet auch. Leider 
aber nicht in einem shell script das ich - um es zu testen - von der 
telnet Kommando Zeile ausführe.

Zum Test der Kommandos habe ich folgendes Script "test.sh" geschrieben 
das im Verzeichnis "public" liegt:

#! /bin/sh
/usr/local/zy-pkgs/bin/smartctl -i -n standby /dev/sda
setLED HDVOL4 RED BLINK

Ausführen tue ich das script dann mit
sh /i-data/6764ac2f/public/test.sh

Natürlich ist das Script noch nich vollständig. Aber leider bin ich ja 
schon in den Grundzügen gescheitert. Nur: Was mache ich falsch???

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FileDescriptor schrieb:
> Ich habe gesehen, dass verschiedene Binaries in den Medion-Sourcen im
> x-tools.armv5v6.tar.gz liegen, die offenbar direkt nutzbar sind (aber
> natürliich noch nicht direkt in den "richtigen" Verzeichnissen liegen):

Das stimmt, da könnte man sich bedienen. Da braucht man aus erstmal 
nichts kompilieren.

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ist der Stand beim mergen des Medion U-Boots in die aktuelle Version 
von U-Boot. Mittlerweile kompiliert alles durch. Doch leider beim Linken 
gibt es ein Problem:
...
/opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld: BFD (GNU Binutils) 2.20.1.20100303 assertion fail /root/crosstool-ng-1.8.0-4.3.2-2.9-armv6_le/targets/src/binutils-2.20.1/bfd/elf32-arm.c:12425
/bin/bash: line 1:  8570 Segmentation fault      /opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-ld -pie -T u-boot.lds -Bstatic $UNDEF_SYM arch/arm/cpu/arm11/start.o --start-group api/libapi.o arch/arm/cpu/arm11/libarm11.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ox820/libox820.o --end-group /home/michael/medion/u-boot-medion-p89626/arch/arm/lib/eabi_compat.o -L /opt/x-tools/armv6_le/arm-none-linux-gnueabi/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2 -lgcc -Map u-boot.map -o u-boot
make: *** [u-boot] Error 139


Es schlägt eine Assertion im Linker fehl. Hat jemand eine Idee? 
Möglicherweise muss ich eine andere CPU für das Medion Nas auswählen. 
Folgende gibt es bei der aktuellen U-Boot Version:
arm1136  arm1176  arm720t  arm920t  arm925t  arm926ejs  arm946es  arm_intcm  armv7  asm-offsets.s  ixp  lh7a40x  pxa  s3c44b0  sa1100

Ich habe mal cpu/arm11/* in die aktuelle Version von U-Boot gemergt, 
aber da kommt auch der Fehler. arm11 wird bei den Medion-Sourcen für das 
Nas (ox820) verwendet... Ist was genau ist arm11 und ist der einer der 
o.g. CPUs von der aktuellen U-Boot Version vielleicht der gleiche?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Es schlägt eine Assertion im Linker fehl. Hat jemand eine Idee?
> Möglicherweise muss ich eine andere CPU für das Medion Nas auswählen.
> Folgende gibt es bei der aktuellen U-Boot Version:
> arm1136  arm1176  arm720t  arm920t  arm925t  arm926ejs  arm946es  arm_intcm
> armv7  asm-offsets.s  ixp  lh7a40x  pxa  s3c44b0  sa1100
>
> Ich habe mal cpu/arm11/* in die aktuelle Version von U-Boot gemergt,
> aber da kommt auch der Fehler. arm11 wird bei den Medion-Sourcen für das
> Nas (ox820) verwendet... Ist was genau ist arm11 und ist der einer der
> o.g. CPUs von der aktuellen U-Boot Version vielleicht der gleiche?

Ich nutze nicht die mitgelieferten cross-toolchains, sondern habe mir 
unter Gentoo mit crossdev einen eigenen gebaut, mit dem ich erfolgreich 
den Kernel, u-boot aus den Medion-Sourcen, ein Gentoo FS bauen kann, 
alles schon auf der NAS ausführen können (u-boot und Kernel über TFTP, 
das rootfs bisher nur unter chroot aus der Original-FW, aber es geht). 
Was ich damit nun sagen will, ich habe für das Toolchain folgendes tuple 
und Optimierungseinstellungen, das und ein Blick hier 
http://dev.gentoo.org/~armin76/arm/chost.xml könnte Dir vielleicht 
weiter helfen:
armv6j-unknown-linux-gnueabi
"-march=armv6j -mtune=arm1136jf-s"
Demnach würde ich sagen, die CPU ist ein arm1136 aus der armv6 Familie, 
also sollten die uBoot-Sourcen alles haben, probier doch mal arm1136...

Autor: Florian F. (ultrazauberer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am Donnerstag gibt es bei Aldi Nord die Medion P89630 mit 2TB.

Es ist diese hier: http://aldi.medion.com/md86587/nord/?refPage=aldi

Das dürfte doch das gleiche System wie die 1,5TB Version sein, oder? Ich 
überlege mir diese als Ersatz für meine Dockstar zu holen.

Meint ihr, dass 2x750Mhz trotzdem mindestens so gut performen, wie die 
1,2GHz von der Dockstar? Wenn ich aktuell über das 1GBit/s Netzwerk 
kopiere, limitiert USB2 bei 30MB/s und die Auslastung ist bei ~80-90%.

Wenn bei diesem NAS allerdings die CPU limitiert, dann brauche ich mir 
diese nicht unbedingt zulegen.

Autor: Dirk S. (disa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian F. schrieb:
> Meint ihr, dass 2x750Mhz trotzdem mindestens so gut performen, wie die
> 1,2GHz von der Dockstar? Wenn ich aktuell über das 1GBit/s Netzwerk
> kopiere, limitiert USB2 bei 30MB/s und die Auslastung ist bei ~80-90%.

Mit der aktuellen Firmware wird nur ein Prozessorkern unterstützt, 
deshalb wird es wohl etwas langsamer sein ...

Autor: Florian F. (ultrazauberer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ui, was ist denn das für eine Fehlkonstruktion? Naja, ich denke mit 
einem guten Linux-Kernel wird das korrigierbar sein, vorausgesetzt, dass 
man das NAS freischalten kann.

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Florian F. schrieb:
> Am Donnerstag gibt es bei Aldi Nord die Medion P89630 mit 2TB.
> Das dürfte doch das gleiche System wie die 1,5TB Version sein, oder?
Würde wetten das das das gleiche Gerät ist. Vielleicht tun sie ja ein 
wenig an der SW aber es ist zu befürchten, dass die nix besser machen 
als beim 1.5TB-System.

> Meint ihr, dass 2x750Mhz trotzdem mindestens so gut performen, wie die
> 1,2GHz von der Dockstar? Wenn ich aktuell über das 1GBit/s Netzwerk
> kopiere, limitiert USB2 bei 30MB/s und die Auslastung ist bei ~80-90%.
Naja, hängt natürlich von der jeweiligen Aufgabe ab. Falls die Aufgabe / 
das Programm gut paralellisierbar ist dann müsste es ja halbwegs 
hinkommen. Falls das alles sequentiell abläuft ist es natürlich auf 
einem Core 'gefangen'.
Wenn die verschiedenen Programme/Programmteile weitgehend unabhängig 
voneinander laufen dann kann das sogar einen Geschwindigkeitsvorteil 
darstellen, da Wartezeiten entfallen, aber pauschal kann man das 
bestimmt nicht beantworten.

> Wenn bei diesem NAS allerdings die CPU limitiert, dann brauche ich mir
> diese nicht unbedingt zulegen.
Dirk hat ja schon beschrieben, dass die Medion-SW nur einen Kernel 
unterstützt. Hier im Forum gibt es Aussagen, dass Medion eine 
Nachbesserungsverpflichtung abstreite, da die Werbeaussage eingehalten 
wird: Es wurden 2 Kerne versprochen, es werden 2 Kerne geliefert. 
Niemand sprach von der Unterstützung durch das OS.

Allerdings läuft ja der Kernel des Pogoplugs auf einem Arch-Rootfs und 
dieser Kernel unterstützt beide Cores, aber das erfordert Bereitschaft 
zum Basteln.

Vielleicht bekommt es ja jemand hin anhand des Pogoplug-Kernels, den 2 
Core im Medion-Kernel zu unterstützen, dann muss man nur den Kernel 
austauschen.

Außerdem sollte man noch erwähnen, dass einige Leute hier im Forum oder 
war es im Aussi-Forum von Hitzeproblemen gesprochen haben.

Also wenn ich eine Dockstar hätte und mit der zufrieden wäre würde ich 
nicht umsteigen, aber die Dockstar bekommt man heute ja nicht mehr (zu 
bezahlbaren Preisen)

Bye Dimpflmoser

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Es wurden 2 Kerne versprochen, es werden 2 Kerne geliefert.
> Niemand sprach von der Unterstützung durch das OS.

Das ist typische "Nepper, Schlepper, Bauernfänger" Philosofie, was haben 
sie sich dabei gedacht, die typischen Aldi-Kunden sind keine Hacker und 
Bastler. Kein Witz, als ich dort war, hat in der Schlange 2 oder 3 
Kunden vor mir eine Oma 2 solche NAS gekauft, die wurden nur auf Anfrage 
unter der Kassentheke oder aus dem Lagerraum hervor gebracht...

Dimpflmoser schrieb:
> Allerdings läuft ja der Kernel des Pogoplugs auf einem Arch-Rootfs und
> dieser Kernel unterstützt beide Cores, aber das erfordert Bereitschaft
> zum Basteln.

Apropos, mein Gentoo-FS bootet auch (fast), ich habe es hinbekommen ihn 
über NFS-Root erstmal zu probieren, mit dem umkonfigurierten 
Medion-Kernel (mii und gmac, sowie die entsprechende firmware für LEON 
im Kernel einkompiliert), momentan hängt gerade udhcpc beim beziehen der 
Netzwerkeinstellung. Möglicherweise weil das netzwerk eh' schon 
konfiguriert ist, da NFS-Root?

Dimpflmoser, wie sieht es denn aus mit einen Patches für XFS an den 
Arch-Kernel, ist der Kernel Deiner Meinung nach schon brauchbar?

Als nächstes nachdem dieses Gentoo durchbootet würde ich mal schauen wie 
ich das mit dem uBoot Environment hinbekomme, ich bräuchte auf jeden 
Fall ein neues uBoot mit der Unterstützuung für die Festplatte, NFS habe 
ich auch hereinbekommen, aber zu dem Zeitpunkt war mein Kernel noch 
nicht ohne Module und Firmware-Blob netzwerkfähig und ich war noch am 
Suchen...

Autor: FileDescriptor (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hans schrieb:

> Zum Test der Kommandos habe ich folgendes Script "test.sh" geschrieben
> das im Verzeichnis "public" liegt:
>
> #! /bin/sh
> /usr/local/zy-pkgs/bin/smartctl -i -n standby /dev/sda
> setLED HDVOL4 RED BLINK
>
> Ausführen tue ich das script dann mit
> sh /i-data/6764ac2f/public/test.sh

Hi Hans,

die magic 1st line #! sollte keine Leerstelle zu dem Programmaufruf 
haben. Ausserdem: Liegt die aufzurufende sh wirklich unter /bin?

Gruß FileDescriptor

Autor: Florian F. (ultrazauberer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Florian F. schrieb:
>> Am Donnerstag gibt es bei Aldi Nord die Medion P89630 mit 2TB.
>> Das dürfte doch das gleiche System wie die 1,5TB Version sein, oder?
> Würde wetten das das das gleiche Gerät ist. Vielleicht tun sie ja ein
> wenig an der SW aber es ist zu befürchten, dass die nix besser machen
> als beim 1.5TB-System.
>
>> Meint ihr, dass 2x750Mhz trotzdem mindestens so gut performen, wie die
>> 1,2GHz von der Dockstar? Wenn ich aktuell über das 1GBit/s Netzwerk
>> kopiere, limitiert USB2 bei 30MB/s und die Auslastung ist bei ~80-90%.
> Naja, hängt natürlich von der jeweiligen Aufgabe ab. Falls die Aufgabe /
> das Programm gut paralellisierbar ist dann müsste es ja halbwegs
> hinkommen. Falls das alles sequentiell abläuft ist es natürlich auf
> einem Core 'gefangen'.
> Wenn die verschiedenen Programme/Programmteile weitgehend unabhängig
> voneinander laufen dann kann das sogar einen Geschwindigkeitsvorteil
> darstellen, da Wartezeiten entfallen, aber pauschal kann man das
> bestimmt nicht beantworten.

Was meinst du denn, wenn es jemals eine Firmware mit Dualcore 
Unterstützung geben würde, ob man damit über Samba mehr als 30MB/s 
schaffen könnte?

>> Wenn bei diesem NAS allerdings die CPU limitiert, dann brauche ich mir
>> diese nicht unbedingt zulegen.
> Dirk hat ja schon beschrieben, dass die Medion-SW nur einen Kernel
> unterstützt. Hier im Forum gibt es Aussagen, dass Medion eine
> Nachbesserungsverpflichtung abstreite, da die Werbeaussage eingehalten
> wird: Es wurden 2 Kerne versprochen, es werden 2 Kerne geliefert.
> Niemand sprach von der Unterstützung durch das OS.
>
> Allerdings läuft ja der Kernel des Pogoplugs auf einem Arch-Rootfs und
> dieser Kernel unterstützt beide Cores, aber das erfordert Bereitschaft
> zum Basteln.
>
> Vielleicht bekommt es ja jemand hin anhand des Pogoplug-Kernels, den 2
> Core im Medion-Kernel zu unterstützen, dann muss man nur den Kernel
> austauschen.
>
> Außerdem sollte man noch erwähnen, dass einige Leute hier im Forum oder
> war es im Aussi-Forum von Hitzeproblemen gesprochen haben.
>
> Also wenn ich eine Dockstar hätte und mit der zufrieden wäre würde ich
> nicht umsteigen, aber die Dockstar bekommt man heute ja nicht mehr (zu
> bezahlbaren Preisen)

Ich habe damals 4 Dockstars gekauft und eine noch in Reserve. Die 
anderen 3 sind im Einsatz und es sind wirklich klasse Geräte. Man sollte 
nur die Installation auf einer richtigen HDD anstatt auf einem USB-Stick 
zu installieren. Ich habe trotz Optimierungen mir schon innerhalb von 8 
Monaten einen USB-Stick gekillt, weil einfach zu viel geschrieben wurde.

Der Grund für das Aldi NAS wäre: 2TB Festplatte und dank Anbindung über 
die interne SATA Schnittstelle, hoffe ich im 1GBit/s LAN mehr als 30MB/s 
zu schaffen.
Das geht natürlich nur, wenn die 2 Kerne unterstützt werden und die CPU 
und die Schnittstelle nicht limitiert.

> Bye Dimpflmoser

Danke für die Informationen!

Grüße
Florian

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für alle, die evtl. das Teil bei Aldi kaufen wollen, schaut euch mal 
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS" an ;) Ist 
nicht so, das es ein super Angebot bei Aldi ist.

Zu DualCore: Allen den das nicht gefällt, sollten IMHO Aldi eine Mail 
schreiben und nicht Medion. Aldi ist der Verkäufer. Den wird es 
sicherlich mehr interessieren, wenn Medion Käse liefert.

Zu Dockstar-Ersatz: Die Dockstar schafft echt 30MB/s ? Per Samba? Dachte 
es wäre deutlich weniger! Mehr schafft das P89626 im 
Auslieferungszustand auch nicht.

Zu alle die sich mit den Sourcen Auseinander setzten und auf die Gefahr 
das ich mich wiederhole: Sind wir uns einig darüber, das Ziel ist es die 
nötigen Änderungen für die Box zu sammeln und in ArchLinuxARM zu 
integrieren? Wobei ich mich nicht damit auskenne, wie das praktisch 
Funktioniert.

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke nicht, dass wir hier einig sind. irgendwie postet jeder seinen 
Fortschritt, aber es gibt kein gemeinsames Ziel. Ich würde das 
vielleicht allgemein halten und einfach nur sagen, dass wir versuchen 
sollten von den Medion-Sourcen wegzukommen und eine komplette Firmware 
inklusive U-Boot mit freier Software zu bauen. Jeder hat halt woanders 
seinenFokus.

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke nicht, dass wir hier einig sind. irgendwie postet jeder seinen 
Fortschritt, aber es gibt kein gemeinsames Ziel. Ich würde das 
vielleicht allgemein halten und einfach nur sagen, dass wir versuchen 
sollten von den Medion-Sourcen wegzukommen und eine komplette Firmware 
inklusive U-Boot mit freier Software zu bauen. Jeder hat halt woanders 
seinen Fokus.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, dann hätten wir nur einige Insellösungen. Das wäre schade, denn 
wenn jemand das Interesse verliert, stehen die Anderen dumm da ;)

Bei uBoot sehe ich das nicht so kritisch. Da brauchen wir einmal eine 
Funktionierende Version, mit allen Features und gut, oder?
Aber beim Kernel kommen regelmäßig Updates, gerade die 
Sicherheitskritischen sind interessant. Wäre schon schön, wenn das quasi 
Automatisch funktioniert. Macht es also vielleicht sogar Sinn, die 
nötigen Modifikationen bis hinauf zum Kernel zu reichen?

Welche Patches sind da überhaupt wirklich nötig? Wird dazu eigentlich 
nichts vom SoC Hersteller PLX Tech [1] bereitgestellt bzw. ist der nicht 
auch Bestrebt, das sein SoC direkt vom Linux Kernel unterstützt wird?

Wie sieht das wohl von Seiten der anderen NSA "Hersteller" aus, die den 
selben SoC nutzten?

Mir geht es halt nur darum, das man mit der Box auch auf langer Sicht 
was anfangen kann und nicht nur Spielerei für den Moment...

Ich kenne mich da zu wenig aus, kann also sein, das ich Blödsinn rede ;)

[1] http://www.plxtech.com/products/consumer/nas7820

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Aber beim Kernel kommen regelmäßig Updates, gerade die
> Sicherheitskritischen sind interessant. Wäre schon schön, wenn das quasi
> Automatisch funktioniert. Macht es also vielleicht sogar Sinn, die
> nötigen Modifikationen bis hinauf zum Kernel zu reichen?
>
> Welche Patches sind da überhaupt wirklich nötig? Wird dazu eigentlich
> nichts vom SoC Hersteller PLX Tech [1] bereitgestellt bzw. ist der nicht
> auch Bestrebt, das sein SoC direkt vom Linux Kernel unterstützt wird?

Meinst du MAINLINE

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Naja, dann hätten wir nur einige Insellösungen. Das wäre schade, denn
> wenn jemand das Interesse verliert, stehen die Anderen dumm da ;)

Was denn nennst Du Insellösung? Ich hoffe doch, unser gemeinsames Ziel 
ist es das Kistchen zu "öffnen", und das heißt dann daß man einen 
brauchbaren bootloader und einen brauchbaren Kernel (dual-core-fähig, 
bekannte .config, verfügbare Patches wenn sie notwendig sind, bekannte 
erforderliche command-line Argumente) hat fürs Erste, dann noch die 
entscheidenden Userspace-Besonderheiten dokumentiert (wenn man z.B. im 
Userspace unbedingt irgendeinen Daemon am Laufen braucht, oder 
irgendwelche Sachen in das /proc FS schreiben muß, damit die Kiste auch 
auf Dauer happy läuft, die LEDs nicht blöde herumblinken auch wenn die 
alternative Firmware gebootet ist, eventuell der OTC-Button auch nutzbar 
ist, das Handling der MAC-Adresse, usw...). Wenn man das kennt, kann man 
beliebige Distributionen (je nachdem wie sich Freiwillige für welche von 
denen finden, ich z.B. hab' nichts am Hut mit Debian-Derivaten, 
Archlinux, usw, bin halt ein Gentoo-er, habe keine Zeit mich in anderen 
zu vertiefen, wenn mein Gentoo rund läuft, stelle ich es gerne auch 
anderen zur Verfügung, sowie das erworbene Wissen um die genannten 
"Besonderheiten", das kann man nämlich gemeinsam sammeln und in jeder 
Distribution nutzen.

> Bei uBoot sehe ich das nicht so kritisch. Da brauchen wir einmal eine
> Funktionierende Version, mit allen Features und gut, oder?

Muß man auch mal definieren, was sind alle sinvollen Features? Ich 
konnte z.B. sehr einfach uboot-1.1.2 aus den Medion-Sourcen die 
Festplattenunterstützung, NFS (dann kann man sich z.B. TFTP Server 
schenken) und DHCP entlocken. Eine aktuelle Version an die Michael Kebe 
arbeitet, ist natürlich wünschenswert.

> Aber beim Kernel kommen regelmäßig Updates, gerade die
> Sicherheitskritischen sind interessant. Wäre schon schön, wenn das quasi
> Automatisch funktioniert. Macht es also vielleicht sogar Sinn, die
> nötigen Modifikationen bis hinauf zum Kernel zu reichen?

So macht man das auch, wie acuh ElektromAn meint, es sollen die Patches 
in Mainline fliessen, nur so kannst Du erfolgreich auf lange Sicht auch 
aktuellere Firmwares nutzen, so passierte es auch mit anderen SoCs 
(seinerzeit mit der orion5 Platform die auch von Marvell stammt). Nur 
als Beispiel, ichhatte in meinemm Gentoo RootFS eine udev-170 oder so, 
die viel zu neu war für die Version des Medion-Kernels, und auch des 
Pogoplug-Kernels, das System bootete erst gar nicht, wegen udev (das ja 
von Medion gar nicht genutzt wird). Ich brauchte etwas Zeit, 
herauszufinden dass ein Downgrade auf udev-164 die Lösung war. Wäre der 
MAINLINE-Kernel in der Lage, mit diesem SoC umzugehen, könnten wir 
aktuelle 3.1er Versionen nutzen...

Just my 0.02€...
Lucian

Autor: Dimpflmoser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Apropos, mein Gentoo-FS bootet auch (fast), ich habe es hinbekommen ihn
> über NFS-Root erstmal zu probieren, mit dem umkonfigurierten
> Medion-Kernel (mii und gmac, sowie die entsprechende firmware für LEON
> im Kernel einkompiliert),
Na das wäre ja auch nicht schlecht. Es gibt eine super 
Gentoo-Unterstützung für den VDR, wäre eine Alternative zu Arch. Wobei 
mir bei Arch gefällt, dass das eine rolling Release ist, d.h. man muss 
keine lästigen Distributionswechsel fahren.

> momentan hängt gerade udhcpc beim beziehen der
> Netzwerkeinstellung. Möglicherweise weil das netzwerk eh' schon
> konfiguriert ist, da NFS-Root?
Hm, kann ich mir nicht so recht vorstellen. Bei meinem 'Büro-Board' 
mache ich das so, dass ich per U-Boot eine IP-Adresse an den Kernel 
übergebe mit dem er das Rootfs mountet, danach noch die IP-Adresse per 
dhcp zu ändern macht natürlich auch keinen Sinn, da dann ja das Rootfs 
nicht mehr gefunden wird.

> Dimpflmoser, wie sieht es denn aus mit einen Patches für XFS an den
> Arch-Kernel, ist der Kernel Deiner Meinung nach schon brauchbar?
>
Hm ob's brauchbar ist kann ich nicht sagen, da ich XFS ja nicht nutze. 
XFS habe ich auch nicht patchen müssen, das war im Source-Tree drin und 
musste nur aktiviert werden. Wie zuverlässig es funktioniert muss man 
dann im laufenden Betrieb testen und ich habe ja noch keinen laufenden 
Betrieb, außerdem habe ich XFS nur ein einem Loopfs als Test angelegt, 
das konnte ich mounten, und per 'touch' eine Datei anlegen. Mehr habe 
ich nicht getestet, wüsste aber nicht warum es da grundsätzliche 
Probleme geben sollte.

Wie es um das Problem mit dem Raid in der Medion-SW steht kann ich auch 
nicht sagen, da fehlt es mir an Kanntnis über Raid, an einer lauffähigen 
Installation und persönliches Bedürfnis.

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dimpflmoser schrieb:
> Na das wäre ja auch nicht schlecht. Es gibt eine super
> Gentoo-Unterstützung für den VDR, wäre eine Alternative zu Arch.

In der Tat, nutze ich seit Jahren...

Dimpflmoser schrieb:
> Wobei mir bei Arch gefällt, dass das eine rolling Release ist, d.h.
> man muss keine lästigen Distributionswechsel fahren.

Ist doch bei Gentoo auch so, wenn man hin und wieder die Pakete 
aktualisiert, wobei das alles durch selber Kompilieren 
geschieht(natürlich, in der Paketverwaltung automatisiert, d.h. 
Installationen dauern halt etwas länger), zudem stellt man dadurchimmer 
sicher, dass man bei Versionssprüngen von diversen Libs gezwungen wird, 
die davon abhängigen Pakete dagegen neu zu übersetzten, damit das System 
konsistent bleibt. Ich sehe das als Vorteil mit der Source-basierten 
Installation, denn ich bau mir mittlerweile für jede erdenkliche neue 
Version eines Programmes, wenn ich die denn ungbedingt haben muss, 
selber ein Ebuild und kann es schön geordnet installieren und nutzen. 
Und gibt es noch überhaupt kein Ebuild (Installationsskript) für ein 
Programm, kann ich es mittlerweile sehr leicht selber schreiben. Von 
Cross-builden eines völlig neuen RootFS (oder für welches es andere nur 
uralte gibt) ganz zu schweigen...

Dimpflmoser schrieb:
> Hm ob's brauchbar ist kann ich nicht sagen, da ich XFS ja nicht nutze.
> XFS habe ich auch nicht patchen müssen

Achso, ich hatte ursprünglich verstanden, Du hattest XFS patchen 
müssen... Na dann sehe ich eigentlichdeswegen keine Probleme, "Deinen" 
Kernel nachzubauen. Hast Du denn noch andere Sachen machen müssen 
(Yaffs2 oder so)?

Dimpflmoser schrieb:
> Wie es um das Problem mit dem Raid in der Medion-SW steht kann ich auch

Jedenfalls, für "alternative" FW kann man mit raid=noautodetect in der 
Kernel-Kommandozeile, sofern Support dafür drinn ist, das Scannen 
deaktivieren.

Dimpflmoser schrieb:
> Hm, kann ich mir nicht so recht vorstellen. Bei meinem 'Büro-Board'
> mache ich das so, dass ich per U-Boot eine IP-Adresse an den Kernel
> übergebe mit dem er das Rootfs mountet, danach noch die IP-Adresse per
> dhcp zu ändern macht natürlich auch keinen Sinn, da dann ja das Rootfs
> nicht mehr gefunden wird.

Du hast recht, das klingt logisch. Ich hatte das übersehen, das eine 
dhcp-Anfrage ihm das NFS-Rootfs unterm Hintern wegnimmt. Naja, ich nutze 
es ja NFS-Root auch nur jetzt während der Tests...

Autor: Danjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

zuerst ein dickes Lob an die tüchtigen Kernel-Bastler.
Bin schon seit Beginn ein stiller Mitleser. Leider kann ich euch bei der 
Arbeit nicht unterstützen, hätte aber an der möglichen Endlösung großes 
Interesse.
Mein Ziel war es eigentlich den Logitech Media Server 
(Squeezebox-Server) auf der Kiste zu installieren. Das kann ich aber so 
wie sie jetzt funktioniert sicherlich vergessen. Oder hat es zufällig 
schon jemand am Laufen?
Aktuell läuft somit noch zusätzlich mein Squeezeplug als Server im 
Netzwerk mit. Bis ich den ablösen kann würde ich gerne den Twonky und 
den httpd Dienst stoppen, da diese Schuld an der RAM Auslastung und den 
permanenten Plattenzugriffen sind. Leider bekomme ich das nicht hin... 
kann mir jemand dabei helfen? Nach einem "killall twonkymedia" startet 
der sich immer wieder neu.

Vielen Dank und Gruß

Daniel

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Evtl. hilft ein "chmod -x twonkymedia" weiter?
Müßte evtl. nach jedem Start passieren. Also ein kleines Skript in 
/usr/local/zy-pkgs/etc/init.d/ packen?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu dem "Baugleichen" Iomega Home Media Network Hard Drive, Cloud Edition 
hab ich gerade gefunden, das es angeblich kein Flash Speicher haben 
soll:

"""
There is no flash, the OS sits on the hard drive on its own EXT3 
formatted partition. The data partition is formatted XFS.
"""
von: 
http://www.smallnetbuilder.com/nas/nas-reviews/31444-new-to-the-charts-iomega-home-media-network-hard-drive-cloud-edition

Finde ich ja irgendwie seltsam. Dann gibt es da kein uBoot, oder fest in 
einem kleinen ROM?


Für die Kernel-Hacker sind evtl. die Dateien unter 
http://downloads.iomega.nas-central.org/Home_Media/Kernel/2.6.24.7/ auf 
für uns interessant ?!?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> """
> There is no flash, the OS sits on the hard drive on its own EXT3
> formatted partition. The data partition is formatted XFS.
> """
> von:
> http://www.smallnetbuilder.com/nas/nas-reviews/314...
>
> Finde ich ja irgendwie seltsam. Dann gibt es da kein uBoot, oder fest in
> einem kleinen ROM?

Wieso seltsam, wie soll denn das SoC (welches von einem 
Halbleiterhersteller für mehrere OEM NAS-Hersteller gefertigt wird) denn 
wissen, dass es von der Partition booten soll, sowas ist doch nicht fest 
im Silizium gegossen sondern wird vom Bootloader und dessen 
Konfiguration gesteuert. Ist wenn Du so magst, "Geschmacksache", Systeme 
mit Flash kann man sogar ohne Festplatte verkaufen, und der Endkunde 
bestückt sie mit einer die er will, andersrum wie in diesem Fall haben 
sie kein Flash verbaut, dafür aber sehr viel vorteilhafter 256MB RAM und 
das Verkaufsmodell ist "immer mit interner Festplatte dabei", also kann 
die Firmware auf eine Partition, ist auch viel einfacher zu handhaben, 
weist auch nicht dieses NAND-Partitions-Chaos vor wie bei Medion/Zyxel, 
kann man auch schwerer endgültig "bricken", weil man ja vor jeder 
Veränderung des Originalzustands sich ein Backup machen kann, oder noch 
besser, alle Spielereien kann man auf einer andere Festplatte 
probieren...

Jens D. schrieb:
> Für die Kernel-Hacker sind evtl. die Dateien unter
> http://downloads.iomega.nas-central.org/Home_Media... auf
> für uns interessant ?!?

Vermutlich vergleichsweise viel zu alter Kernel...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Konfiguration gesteuert. Ist wenn Du so magst, "Geschmacksache", Systeme
> mit Flash kann man sogar ohne Festplatte verkaufen, und der Endkunde
> bestückt sie mit einer die er will, andersrum wie in diesem Fall haben
> sie kein Flash verbaut

Hmm, vielleicht ist eher gemeint, "kein relativ großer Flash für die 
Firmware", und nicht allgemein (also der Bootloader muß doch irgendwo 
hin, und muß auch konfigurierbar sein).

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das meinte ich mit Merkwürdig ;)

Auf dem Iomega HMNHDCD läuft der ArchLinuxArm Kernel nicht direkt. Man 
bekommt ArchLinux aber schon hin, mit ein paar Klimmzügen: 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1909&p=10728&hilit=iomega+Cloud+Edition+kernel#p10727

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine Beobachtung, seit ich am Freitag spät am abend die NAS nun 
halb-nackend (linke Plastikhälfte weg, damit ich nicht so viel wieder 
aufmachen muß wenn ich entweder das UART-Kabel ganz heraus nehme, oder 
eine vernünftige Ausführung improvisiere) betreibe und hin und wieder 
neu starte, oder mal wieder laufen lasse: Die Festplatte wird da oben, 
wenn sie denn länger nicht schlafen geht so ziemlich heiß (bei mir der 
Fall wenn ich unter Gentoo nativ auf der NAS mal kompilieren muß, weil 
sich nun mal nicht 100% alle Pakete überhaupt, oder fehlerfrei 
cross-kompilieren lassen).

Ich denke fast, wir sollten mal auf der Platine nach einem Anschluss für 
diese Lüftersteuerung von der die Rede war, suchen, auch der Kernel hat 
so ein Modul, muß man nur konfigurieren, und dann könnte man den Boden 
des Gehäuses modifizieren und einen nach oben blasenden Lüfter verbauen, 
und die Füße mit noch dickeren Gummisohlen abkleben, damit die 
Luftzirkulation gefördert wird...

Was meint ihr?

Autor: 0815user (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danjel schrieb:
> Nach einem "killall twonkymedia" startet
> der sich immer wieder neu.

Du musst zuerst den app_wd killen, der mit 'nice -n 22 app_wd' gestartet 
wird.
Wenn man die Strings im app_wd untersucht ist twonky -media und -server 
dort
hart codiert.

Zur stoppen den Mediaservers ist es einfacher und vollständig das Script
'mediaserver.sh stop' aufzurufen, da es auch das Pythonprogramm 
cdsdeamon.pyc
beendet, das die Datenbank startet.

Da ich bisher nicht mit dem Programm "renice" versucht habe die 
Ausführung des Programms app_wd zu beschleunigen (Werde es zum Test mal 
von der Dockstar auf das NAS kopieren), weiss ich nicht wann ein kill 
des app_wd Erfolg hat.

Anregungen ??

Autor: Mijzelf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Finde ich ja irgendwie seltsam. Dann gibt es da kein uBoot, oder fest in
> einem kleinen ROM?

There is a u-boot, but it's on harddisk. AFAIK the SoC has a tiny 
(flash?)rom, just smart enough to load a bootloader from a fixed sector 
address of the harddisk.
http://iomega.nas-central.org/wiki/Stock_Configuration_(Home_Media_CE)#.27Unused_space.27_.28first_32_MiB.29

I don't know of a serial bootlog of the HomeMediaCE, but the 
HomeMedia'Classic' uses the same trick, and gives:
Initialising disks
No FIS received from device 1
No FIS received from device 1
Detecting SATA busses:
Bus 0: Found first device OK
  Device 0: Model: ST3500418AS  Firm: CC44 Ser#: 6VM1QZR8
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
  Device 1: not available
Environment successfully read from disk 0 primary image


U-Boot 1.1.2 (Dec 10 2008 - 07:58:49)
http://iomega.nas-central.org/wiki/Serial_port_(Home_Media)

I suppose the 'internal bootloader' is responsible for the lines up to 
'Environment successfully ...'.

Autor: nikolay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Servus Leute wollte hier mal meine Anfrage und die Antwort die ich von 
Medion erhalten habe posten.

Anfrage vom 12.12.11:
______________________________________________
Hallo, das Medion NAS P89626, welches letzte Woche bei Aldi Süd
erhältlich war wurde mit "Dual Core" beworben.
Nach Foreninformationen wird jedoch nur ein Core dieses Systems genutzt.
Wird es in absehbarer Zeit eine neue Firmware geben, mit der die
beworbene "Dual Core"-Funktionalität hergestellt, d.h. auch der zweite
Core genutzt wird?
Da dies ja groß beworben wurde ist, sollte dieses auch dem Kunden zur 
Verfügung gestellt werden. Sonst würde so eine Werbung einen ja in die 
Irre führen
Mit freundlichen Grüßen

Antwort Medion vom 17.12.11
______________________________________________
Sehr geehrter Herr ,

wir bedanken uns für die Kontaktaufnahme mit dem Medion E-Mail Support.

Selbstverständlich wird der Dual Core des NAS P89626 im vollen Umfang 
genutzt.

Wir wünschen Ihnen einen schönen Tag.

Mit freundlichen Grüßen
Medion Technologie Center
Ralf Ingo Schulz

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mijzelf schrieb:
> I suppose the 'internal bootloader' is responsible for the lines up to
> 'Environment successfully ...'.

That output looks like that internal bootloader could be also uBoot 
itself, hard-coded to chainload the other one from disk (and capable of 
doing so, which the one from the Aldi-NAS is not, only if recompiled 
with modified options).
Having the "internal" bootloader capable of loading from hard-drive 
opens new possibilities, so I'm really thinking of replacing it with the 
one recompiled, to which I enbled HDD access, NFS (as alternative to 
tftp) and DHCP (comes very handy), so that one really gives lots of 
possibilities...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nikolay schrieb:
> Selbstverständlich wird der Dual Core des NAS P89626 im vollen Umfang
> genutzt.

Ja, hat die Oma auch so verstanden. Unglaublich wie Medion versucht, 
alle Kunden für dumm zu verkaufen.

Autor: acer2k (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich verfolge den Thread hier schon ein bisschen und frage mich gerade ob 
jemand es schon geschafft hat ein Usenetdownloader zu integrieren wie z. 
B. nzbget oder http://sabnzbd.org/ ?
Wäre es net super möglichkeit Stromsparend downzuloaden.

Autor: Joerg W. (joerg_w76)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NZBGet hat Andreas Ehrle hier schon am 2.12. gepostet.

Die Eignung als Downloadserver steht außer Frage, desgleichen die 
Nutzbarkeit als Backupsystem. Aber dafür habe ich schon ein Kistchen - 
wie einige andere hier interessiert mich die Verwendung als Audio- 
und/oder Videoserver. Es wird sicherlich in jedem Fall noch ein Weilchen 
dauern, bis entsprechende Lösungen stabil laufen - wenn es überhaupt 
soweit kommt. Und da schliesst sich eigentlich meine Frage an: bin ich 
aufgrund des doch recht beschränkten RAMs des Medion-NAS nicht doch 
besser beraten, gleich mit dem Selbstbau eines - sicher dann teureren - 
Medien-PCs zu beginnen?
Vielleicht kann ja jemand von seinen Erfahrungen mit anderen 
NAS-Systemen in dieser Hinsicht berichten? Auch die vielgelobte Synology 
211j kommt ja mit 128 MB aus. Was taugt deren 
"Audiostation"-Funktionalität im Vergleich zum Squeezebox-Server bspw.?

Autor: Markus V. (acer2k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Danke,

dass nzbget habe ich gefunden.
nur in sachen Linux bin ich leider auch ein Noob muss ich sagen.
Telnet zugang hab ich, aber wie bekomme ich das nzbget da drauf?
Kann mir da jemand helfen?

Autor: Danjel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für den Hinweis "app_wd" killen. Habe somit erfolgreich den 
Twonky deaktivieren können.

Kurzer Erfahrungsbericht zum Thema Squeezeplug (nur Audio):
- Bei mir läuft das Squeezeplug Image (SD-Karte) auf der SheevaPlug (1,2 
Ghz, 512 RAM) tadellos. Absolut ausreichend für den SqueezeboxServer 
(bzw. Logitech Media Server). Generell sollten aber auch 128 RAM 
ausreichen, da auch viele die Dockstar Lösung im Einsatz haben. Hab die 
Medion NAS nur wegen den Plattenpreisen und dem "DualCore" geholt...
- Mein mittelfristiges Ziel ist die QNAP TS-119p II ;-)

Gruß

Daniel

Autor: erwano (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kannst du Danjel kannst du das mit dem app_wd killen bitte für "Doofe" 
nochmals genau erläutern.

Ich bin auf der telnet console. Was muss ich eintippen?
Wie kann ich überprüfen, ob es erfolgreich war?
Eigentlich dürfte ioh doch dann die 192.168.xxx.yyy:9001 nicht mehr 
aufrufen können?

Bg,

erwano

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich hab nun mal die Platte komplett platt gemacht und folgende 
Partitionen eingerichtet:
/ # fdisk -l

Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
255 heads, 63 sectors/track, 182401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1        2433    19543041   83  Linux
/dev/sda2            2434        4866    19543072+  83  Linux
/dev/sda3            4867        4929      506047+  82  Linux swap / Solaris
/dev/sda4            4930      182401  1425543840   83  Linux

Also zweimal 20GB für ArchLinuxARM und Debian (oder was anderes), eine 
kleine 512MB Swap und halt den Rest.

Dann hab ich mal neu gebootet. Die Firmware bootet durch und Platte 
bleibt unangetastet.
In der Web-Oberfläche taucht dann bei InternesLaufwerk: "Gegenwärtig 
sind keine Volumen vorhanden." auf. Leider kann man dort nicht über 
"Hinzufügen" seine ext3 Partition angeben. Er will dann irgendwas mit 
"JBOD-Volumen" machen. Denke er würde dann die Platte wieder Platt 
machen und sein RAID Einrichten.

sda1 formatieren: Dabei ist mir aufgefallen, das es einmal "mke2fs" (aus 
BusyBox) gibt und einmal "mke2fs.new" mit der man mit -j auch ext3 
erstellen kann.

Also hab ich mit mke2fs.new sda1 als ext3 Formatiert und ArchLinuxARM 
rootfs drauf gepackt:
/ # mke2fs.new -j -L rootfs /dev/sda1
/ # mount /dev/sda1 /mnt
/ # cd /mnt/
/mnt # wget http://archlinuxarm.org/os/ArchLinuxARM-oxnas-latest.tar.gz
/mnt # tar xzf ArchLinuxARM-oxnas-latest.tar.gz
/mnt # reboot

Dann TFTP Eingerichtet, siehe z.B. GoFlexHome: TFTP server einrichten 
und Arch noPCI Kernel zur Verfügung gestellt.
Die "uImage.nopci" Datei bekommt man aus der 
ArchLinuxARM-oxnas-latest.tar.gz und liegt im Verzeichnis "/boot" hat 
die MD5 von: 3bcad3e97624e94ab84358f1a2746428

In uBoot dann:
setenv serverip 192.168.xxx.yyy; setenv ipaddr 192.168.xxx.zzz;
setenv bootargs console=ttyS0,115200 root=/dev/sda1 mem=128M
tftp 61000000 uImage.nopci
bootm 61000000

Dann bootet ArchLinuxARM von sda1 hoch. Was man dann weiter machen kann, 
wegen Einrichtung hatte ich schon bei GoFlexHome: ArchLinuxARM 
beschrieben.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nach dem hochfahren, hab ich das gemacht:
[root@alarm ~]# pacman -Scc 
[root@alarm ~]# pacman -Syyuf

Jetzt wird es interessant: Er Updated den Kernel: linux-3.1.4-2
Unter /boot ist nun IMHO eine neues uImage:
[root@alarm ~]# ls -la /boot/
total 7784
drwxr-xr-x  2 root root    4096 Dec 19 15:55 .
drwxr-xr-x 23 root root    4096 Dec 19 15:33 ..
-rw-r--r--  1 root root  824016 May 29  2011 System.map26-oxnas-pci
-rw-r--r--  1 root root 2821148 Dec  4 00:37 uImage
-rw-r--r--  1 root root 2159948 May 29  2011 uImage.nopci
-rw-r--r--  1 root root 2132324 May 29  2011 uImage.pci
[root@alarm ~]# md5sum /boot/uImage.nopci 
3bcad3e97624e94ab84358f1a2746428  /boot/uImage.nopci
[root@alarm ~]# md5sum /boot/uImage
992c857e5f987fc3867a181fa558befa  /boot/uImage
Ich meine die Dateien vom "May 29  2011" waren noch aus dem 
ArchLinuxARM-oxnas-latest.tar.gz Archiv und die uImage Datei ist neu.

Ich teste mal diese zu Booten ;)

...geht leider nicht:
Filename 'uImage3.1.4-2'.
Load address: 0x61000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ################################
done
Bytes transferred = 2821148 (2b0c1c hex)
## Booting image at 61000000 ...
   Image Name:   Linux-3.1.4-2-ARCH
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2821084 Bytes =  2.7 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Stage-1 Bootloader Tue Aug  9 16:44:00 CST 2011
Attempting to set PLLA to 750MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000F0000
  plla_ctrl2 : 0x001D01A0
  plla_ctrl3 : 0x00000017
PLLA Set

Setup memory, testing
Reading NAND, Image 0
  Hdr len: 0x0001A94C
  Hdr CRC: 0xF0019DAC
 OK


U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)

U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0 
$ 

Vielleicht sind einfach nur die Adressen falsch?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> So, ich hab nun mal die Platte komplett platt gemacht und folgende
> Partitionen eingerichtet:/ # fdisk -l
>
> Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
> 255 heads, 63 sectors/track, 182401 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
>
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1               1        2433    19543041   83  Linux
> /dev/sda2            2434        4866    19543072+  83  Linux
> /dev/sda3            4867        4929      506047+  82  Linux swap / Solaris
> /dev/sda4            4930      182401  1425543840   83  Linux
>
> Also zweimal 20GB für ArchLinuxARM und Debian (oder was anderes), eine
> kleine 512MB Swap und halt den Rest.

Schön, würdest Du mal bitte wenn Du mal das Kistchen wieder neu bootest 
testen, ob das qasi entsprechende Kommando in dem u-boot was ich 
hochgeladen hatte(Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS") 
überhaupt einen brauchbaren Output zumindest mit Deinen vorderen 
Partitionen bringt? Die riseige Anzahl der Blocks der hinteren packt das 
uBoot-1.1.2 aus den Medion-Sourcen leider nicht, die Zahl wird negativ, 
passt im verwendeten Datentyp nicht 'rein (das auch mit der 
Partitionierung im Auslieferungszustand). Wenn zumindest die vorderen 
erkannt werden, kann man das neu übersetzte uBoot dennoch nutzen. Um 
weiterhin der Original-FW ein Volume zur Verfügung zu stellen, müssen 
wir uns wohl noch weiter mit den Konzepten von RAID und der Nutzung von 
"mdadm" unter der Haube vertraut machen. Ich konnte deswegen nämlich 
auch im über NFS gebooteten Gentoo die Originale sda2 nicht mounten...

Achja, die relevanten Kommandos, die ich Dich bitten würde, 
auszuprobieren und deren output zu posten:
ide part 0 (inetwa fdisk -l)
ext2ls (auf eine der korrekt erkannten ext2(3) partitionen, "ext2ls 0:1/ für die erste z.B.
Ich hoffe mal, Michael Kebe schafft die Portierung der ox820 Plattform 
in den neuen uBoot-Sourcen, denn umgekehrt, die neue Disk-Unterstützung 
in den alten u-boot hatte ich eben probiert, kann man vergessen...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anscheinend ist der Kernel generell nicht für Oxsemi brauchbar, siehe: 
http://archlinuxarm.org/forum/viewtopic.php?t=2027&p=11056

btw. 3.1 läuft auf meine GoFlex Home Kiste ;)

Man kann aber ohne Probleme wieder mit dem "alten" Kernel starten.

btw. lsmod Vergleich:
/ # lsmod
gmac 47336 0 - Live 0xbf004000
mii 6764 1 gmac, Live 0xbf000000
Arch Linux 2.6.31.6_SMP_820  (PLX7820) (ttyS0)

[root@PLX7820 ~]# lsmod
Module                  Size  Used by
vfat                   11048  1 
fat                    51584  1 vfat
bootled_module          1472  0 
gmac                   40372  0 
mii                     6328  1 gmac

Ob da http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1234 Sinn 
macht?

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> ide part 0 (inetwa fdisk -l)
> ext2ls (auf eine der korrekt erkannten ext2(3) partitionen, "ext2ls 0:1/ für die 
erste z.B.
Filename 'u-boot2461023.bin'.
Load address: 0x61000000
Loading: ###################
done
Bytes transferred = 95500 (1750c hex)
## Starting application at 0x61000000 ...
Initialising disks
SATA PHY not ready for device 1
Detecting SATA busses:
Bus 0: Found first device OK
  Device 0: Model: ST1500DL003-9VT16L Firm: CC4A Ser#: 5YD5xxxx
            Type: Hard Disk
            Capacity: 131071.9 MB = 127.9 GB (268435455 x 512)
  Device 1: not available
Failed to read valid environment from disk, using built-in default


U-Boot 1.1.2 (Dec 16 2011 - 00:16:41)

U-Boot code: 60D00000 -> 60D1750C  BSS: -> 60D1B1A0
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0 

$ ide part 0

Partition Map for IDE device 0  --   Partition Type: DOS

Partition     Start Sector     Num Sectors     Type
    1                   63        39086082      83
    2             39086145        39086145      83
    3             78172290         1012095      82
    4             79184385      -1443879616     83

$ help ext2ls
ext2ls <interface> <dev[:part]> [directory]
    - list files from 'dev' on 'interface' in a 'directory'

$ ext2ls ide 0:1
$ ext2ls ide 0:1 /
$ ext2ls ide 1:0
** Bad partition - ide 1:0 **
$ ext2ls ide 0:0
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - ide 0:0 **
$ ext2ls ide 0:0 /
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - ide 0:0 **
$ ext2ls ide 0:2 /
Failed to mount ext2 filesystem...
** Bad ext2 partition or disk - ide 0:2 **
$ ext2ls ide 0:1 /boot
** Can not find directory. **
** Error ext2fs_ls() **
$ ext2ls ide 1:1 /
** Bad partition - ide 1:1 **

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab mal eine Frage zu MAC Adresse. Offensichtlich ist sie in der uBoot 
Variable "ethaddr" gespeichert. Das scheint ja generell bei allen/vielen 
Dingern mit uBoot so zu sein.

Im Wiki steht bei P89626: uboot env:
/ # fw_printenv 
bootargs= console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01
...
ethaddr=00:11:41:xx:xx:xx

Wie kommt es, das bei den bootargs was anderes übergeben wird als die 
eigentliche Adresse?

btw. Lustig ist, wenn man nach "00:30:e0:00:00:01" sucht, findet man 
einige Einträge: http://www.google.de/#q="00:30%3Ae0%3A00%3A00%3A01";
Wohl wieder ein Hinweis darauf, wo überall die selbe Firmware läuft?

00:30:e0 steht wohl für "OXFORD SEMICONDUCTOR LTD.", aber 00:11:41 für 
"GoodMan Corporation" ?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Partition Map for IDE device 0  --   Partition Type: DOS
>
> Partition     Start Sector     Num Sectors     Type
>     1                   63        39086082      83
>     2             39086145        39086145      83
>     3             78172290         1012095      82
>     4             79184385      -1443879616     83
>

Danke Jens, eigentlich sieht es nicht soooo schlecht aus, mal abgesehen 
vom Schluß. Die zahlen kann man alle bis auf die erste und letzte durch 
63 und dann nochmal durch 255 teilen, und man kommt schon auf jene von 
dem gscheiten fdisk.

> $ help ext2ls
> ext2ls <interface> <dev[:part]> [directory]
>     - list files from 'dev' on 'interface' in a 'directory'
>
> $ ext2ls ide 0:1
> $ ext2ls ide 0:1 /

Bisher alles gut, kann es hier denn sein, die erste Partition ist noch 
leer?

> $ ext2ls ide 1:0
> ** Bad partition - ide 1:0 **

Vermutlich wollte er auf die 2te, nicht vorhandene Platte zugreifen...

> $ ext2ls ide 0:0
> Failed to mount ext2 filesystem...
> ** Bad ext2 partition or disk - ide 0:0 **
> $ ext2ls ide 0:0 /
> Failed to mount ext2 filesystem...
> ** Bad ext2 partition or disk - ide 0:0 **

Eigentlich glaube ich nicht dass es da eine Partition "0" gibt, u-Boot 
beginnt anscheinend bei "1" zu zählen...

> $ ext2ls ide 0:2 /
> Failed to mount ext2 filesystem...
> ** Bad ext2 partition or disk - ide 0:2 **
> $ ext2ls ide 0:1 /boot
> ** Can not find directory. **
> ** Error ext2fs_ls() **
> $ ext2ls ide 1:1 /
> ** Bad partition - ide 1:1 **


Also ich weiß nicht so richtig was ich von ext2ls sagen soll...

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> btw. Lustig ist, wenn man nach "00:30:e0:00:00:01" sucht, findet man
> einige Einträge: http://www.google.de/#q="00:30%3Ae0%3A00%3A00%3A01...
> Wohl wieder ein Hinweis darauf, wo überall die selbe Firmware läuft?

Die ist hard-codiert in den u-Boot-Sourcen, müsste eigentlich geändert 
werden. Auch bin ich mir nicht sicher ob die tatsächlich genutzt wird, 
weil ich denke uBoot schreibt sie aus der anderen Variable in ein 
HW-Register der NIC, von wo dann der Kernel (oder das Modul je nachdem) 
sie wieder liest und den Userspace-Tools ifconfig & Co zur Verfügung 
stellt, angeblich nach einem Zyklus "LinkUp-Down-Up" oder so...

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens D.
Teste mal deine Netzwerkperformace.
Ist den Sourcen von dem neuen Kernel ist kein TPE drin.

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ElektromAn schrieb:
> @Jens D.
> Teste mal deine Netzwerkperformace.
> Ist den Sourcen von dem neuen Kernel ist kein TPE drin.

Argg.

TOE -> TCP Offload Engine
Netzwerkbeschleunigun um CRC bei den Paketen zu berechnen

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> Bisher alles gut, kann es hier denn sein, die erste Partition ist noch
> leer?

Ne, auf /dev/sda1 ist mein ArchLinuxARM rootfs. alle anderen sind aber 
noch unformatiert und somit leer.

Lucian M. schrieb:
>> btw. Lustig ist, wenn man nach "00:30:e0:00:00:01" sucht, findet man
>> einige Einträge: http://www.google.de/#q="00:30%3Ae0%3A00%3A00%3A01...
>> Wohl wieder ein Hinweis darauf, wo überall die selbe Firmware läuft?
>
> Die ist hard-codiert in den u-Boot-Sourcen, müsste eigentlich geändert
> werden. Auch bin ich mir nicht sicher ob die tatsächlich genutzt wird,
> weil ich denke uBoot schreibt sie aus der anderen Variable in ein
> HW-Register der NIC, von wo dann der Kernel (oder das Modul je nachdem)
> sie wieder liest und den Userspace-Tools ifconfig & Co zur Verfügung
> stellt, angeblich nach einem Zyklus "LinkUp-Down-Up" oder so...

Zumindest wird diese MAC zu den bootargs hinzugefügt. Beim ArchLinux 
gibt man dann die "echte" MAC per /usr/local/mac_addr an... Woher das 
Originalsystem die MAC Adresse nimmt, weiß ich nicht.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Ich hab den hier:pl2303: Prolific PL2303 USB to serial adaptor driverhab nochmal 
nachgesehen, ist ein Datenkabel für Siemens C25/35 Also laut
> der Liste bei http://www.mikrocontroller.net/articles/UART_auf_USB ein
> DCA-540

Achtung: Das DCA-540 ist kein Kabel mit PL2303, es hat auch keinen 
USB2Serial-Wandler drin sondern ist ein reines USB-Adapterkabel. 
Entgegen der Beschreibung von obigem Link ist das DCA-540 auch kein 
Kabel für C25/35 sondern für das SX1 und jünger.

Wer sich ein Siemens-Kabel kaufen möchte sollte da eher auf ein DCA-510 
kaufen.

Autor: Wachtmeister D. (dimpflmoser)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus V. schrieb:
> dass nzbget habe ich gefunden.
> nur in sachen Linux bin ich leider auch ein Noob muss ich sagen.
> Telnet zugang hab ich, aber wie bekomme ich das nzbget da drauf?
> Kann mir da jemand helfen?

Hallo,

ich schätze, dass Du für die individuellen Anpassungen schon gewisses 
Grundwissen in Sachen Linux benötigst.
Wie Du in diesem Thread siehst gibt es auf dieser Box viele Baustellen 
mit viel Potential, aber das ist alles derzeit im Bastelstadium, das 
entpsrechenden Aufwand und Kompromissbereitschaft in Komfort und 
Stabilität erwartet.

Falls Du dieses Linux-Wissen erarbeiten möchtest wäre ein stabileres 
System bzw ein Desktop eher die richtige Spielwiese. Eventuell wäre 
sowas wie die Dockstar/GoFlex da besser geeignet, da gibt es fertige 
Linux Distributionen für.

Ich möchte Dich nicht von dieser Box abhalten, aber ohne ausreichend 
Linux-Erfahrung und eine hohe Toleranzschwelle wirst Du bei dieser Kiste 
nur Frust ernten.
Entweder Du verwendest sie so wie vorgesehen über Webinterface etc oder 
ich empfehle den Verkauf über E-Bay, da machst Du wahrscheinlich noch 
gutes Geld mit.
Alternativ würde ich sie zu Aldi zurück bringen, da die SW nicht wie 
versprochen die beiden Kernel unterstützt.

Tschüss Dimpflmoser

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke ich bin am Ende meiner Möglichkeiten angelangt. Ich hatte eine 
Konversation in der Mailing-Liste von U-Boot.

http://www.mail-archive.com/u-boot@lists.denx.de/msg73361.html

Es hat sich für mich herauskristalisiert, dass ich nicht tief genug in 
der Sache, zum einen in U-Boot zum anderen im Hardwarebereich (SoCs, 
Memory layout, ...), drin bin. Und so leider die Sache liegen lassen 
muss.

Möglicherweise wird mir später auch ein JTAG Anschluss fehlen um ein 
kaputtgeflashtes Board wiederzubeleben, oder zum debuggen von U-Boot. Im 
übrigen habe ich mit JTAG keine Erfahrung und keine entsprechende 
Hardware.

Falls ich aber weiter mit Input versorgt werde, der bei der Problematik 
hilft, so läuft es natürlich weiter.

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte mir mal bei eBay ein JTAG-USB Ding bestellt. Kam aus China und 
war eine weile lang unterwegs. Genutzt habe ich es noch nie. Die Frage 
wäre auch, wo der JTAG Anschluss wäre.

Aber: Es dürfte doch Gefahrlos möglich sein, ein uBoot per TFTP und mit 
UART zu testen. Das schlimmste ist IMHO das es halt nicht funktioniert, 
aber nicht das man deine Box damit verschießt, oder nicht?

Vielleicht gibt es noch andere "ox820" NAS Systeme die schon eine neuere 
uBoot Version benutzten?
Übrigends soll OX820 == NAS7820 sein, siehe: 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1909#p10446 Somit 
kommen dann wieder die Bekannten [[P89626#.C3.84hnliche_Ger.C3.A4te]] in 
Frage.

Iomega HMNHD Cloud Edition nutzt wohl auch nur U-Boot v1.1.2, siehe:
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1909#p10504 btw. 
http://pastebin.com/P5WM9Dsx

Was nutzt dieses "Level One GNS-1001" Ding und was der "Pogoplug 
Pro/Video/v3" ?

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Aber: Es dürfte doch Gefahrlos möglich sein, ein uBoot per TFTP und mit
> UART zu testen. Das schlimmste ist IMHO das es halt nicht funktioniert,
> aber nicht das man deine Box damit verschießt, oder nicht?

Richtig, doch ich glaube das hilft nicht richtig bis zum Schluß weiter.

Allein die Tatsache, daß uBoot gezogen über TFTP und gestartet aus dem 
Speicher wenn das SoC schon am Laufen ist (also CPU läuft schon, "sieht 
den Speicher" usw, ist also initialisiert) garantiert nicht daß dieses 
neue uBoot dann im NAND geflasht, an der Stelle von wo es später nach 
Aus-/Einshalten der SoC selber starten und alles ALLEINE machen soll 
(also diese Initialisierungen) dann nicht doch crasht, dann hat man 
nämlich die Box gebrickt und kommt an JTAG oder gar wegwerfen nicht mehr 
vorbei...

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie kann man das Nas denn reseten ? De nimmt den standardlogin nicht an.

Schönen Dank schonmal..

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, ich kenne mich auch nicht mit dem NAND Kram so ganz aus. Aber ist es 
nicht so, das eh noch genügend NAND Speicher da ist, so das man ein 
neues uBoot parallel flashen kann. So das das alte uBoot automatisch das 
neue läd und gut?
Zwar dauert das Booten dann ein Tick länger, aber was solls? Wäre für 
mich erstmal eine nette Lösung.

Dann kann jemand, der der es wagen will, auch probieren, den alten 
komplett zu ersetzten. Die Vorsichtigen bleiben dann erstmal dabei...

Btw. Selbst wenn man Elektronikschrott produziert. Ist die Platte immer 
noch den Kaufpreis wert!

Autor: noxx (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
denke ich werde auch versuchen, trotz geringer linux kenntnisse so ein 
NAS zu ergattern. hoffe das dann irgendwann tutorials gibt, sofern da an 
software was gemacht wurde von euch oder jemanden, die auch ein laie 
versteht. solange wird das teil als netzwerkspeicher herhalten müssen. 
bisher verstehe ich hier ehrlich nur bahnhof, was solls.

gruss

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> OK, ich kenne mich auch nicht mit dem NAND Kram so ganz aus. Aber ist es
> nicht so, das eh noch genügend NAND Speicher da ist, so das man ein
> neues uBoot parallel flashen kann. So das das alte uBoot automatisch das
> neue läd und gut?
> Zwar dauert das Booten dann ein Tick länger, aber was solls? Wäre für
> mich erstmal eine nette Lösung

Ich denke schon daß es gehen sollte, bloß muß man entweder diesen Platz 
finden, oder einfach auf das Original-Layout der NAND Partitionen und 
Original-FW ganz und gar pfeifen (was ja auch nicht jedem sehr weh tun 
sollte)...

Autor: Jens D. (jedie) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lucian M. schrieb:
> das Original-Layout der NAND Partitionen und
> Original-FW ganz und gar pfeifen (was ja auch nicht jedem sehr weh tun
> sollte)...

Genau. Zumal man es ja auch vorher Sichern kann. Doch kenne ich mich mit 
dem Partitionen im NAND nicht aus. Weiß nicht, wie man neue erstellt 
oder alte Löscht. Kennt sich da jemand aus, oder weiß wo man sich Schlau 
machen kann?

Btw. Hab mal bei http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2150 
Nachgefragt, ob jemand ein neuere uBoot für NAS7820 mit ext2 Support 
kennt. Mal sehen, vielleicht haben wir ja Glück...

Autor: Michael K. (michaelkebe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier eine Hochglanzbroschüre, die uns wahrscheinlich nicht weiterhilft.

http://pdf1.alldatasheet.com/datasheet-pdf/view/319543/PLX/NAS7820.html

Autor: Lucian M. (lucian_m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jens D. schrieb:
> Genau. Zumal man es ja auch vorher Sichern kann. Doch kenne ich mich mit
> dem Partitionen im NAND nicht aus. Weiß nicht, wie man neue erstellt
> oder alte Löscht. Kennt sich da jemand aus, oder weiß wo man sich Schlau
> machen kann?

Neuere mtd-utils-1.4.8 als die aus den Medion-Sourcen könnten dabei 
vielleicht helfen. Unter Gentoo habe ich die heute gerade für die NAS 
gebaut, werde dann mal schauen was aus diesen vielen binaries für uns 
relevant und brauchbar wäre, denn es sind viel mehr als Zyxel in ihrer 
Firmware drauf packen:
htpc2 mtd-utils-1.4.8 # ROOT="/usr/armv6j-unknown-linux-gnueabi" equery f mtd-utils | grep bin/
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/doc_loadbios
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/docfdisk
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flash_erase
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flash_eraseall
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flash_lock
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flash_otp_dump
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flash_otp_info
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flash_unlock
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/flashcp
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ftl_check
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ftl_format
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/jffs2dump
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/jffs2reader
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/mkfs.jffs2
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/mkfs.ubifs
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/mtd_debug
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/mtdinfo
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/nanddump
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/nandtest
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/nandwrite
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/nftl_format
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/nftldump
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/recv_image
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/rfddump
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/rfdformat
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/serve_image
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/sumtool
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubiattach
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubicrc32
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubidetach
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubiformat
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubimkvol
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubinfo
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubinize
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubirename
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubirmvol
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubirsvol
/usr/armv6j-unknown-linux-gnueabi/usr/sbin/ubiupdatevol

> Btw. Hab mal bei http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2150
> Nachgefragt, ob jemand ein neuere uBoot für NAS7820 mit ext2 Support
> kennt. Mal sehen, vielleicht haben wir ja Glück...

Naja, das problem wäre eher "neueres uBoot", als mit ext2 Support, wegen 
der Unterstützung von Riesen-Festplatten. Jedenfalls, es ist ein derart 
vermurkster Code, was die Typen bei u-boot-1.1.2 geändert haben, sie 
haben keine Gelegenheit ausgelassen, auch an nicht SoC-spezifieschen 
Stellen Funktionssignaturen zu ändern, da wo die Code-Richtlinien von 
uBoot #defines vorgesehen haben, dann doch eine Variable einzuführen, 
usw, so daß man gar nichts mehr versteht...
Deswegen glaube ich daß es schon ganz happig ist, ein neueres uBoot zu 
bekommen, wahrscheinlich gibt's deswegen kein neueres...

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Kebe schrieb:
> Ich denke ich bin am Ende meiner Möglichkeiten angelangt. Ich hatte eine
> Konversation in der Mailing-Liste von U-Boot.
>
> http://www.mail-archive.com/u-boot@lists.denx.de/msg73361.html
>
> Es hat sich für mich herauskristalisiert, dass ich nicht tief genug in
> der Sache, zum einen in U-Boot zum anderen im Hardwarebereich (SoCs,
> Memory layout, ...), drin bin. Und so leider die Sache liegen lassen
> muss.
>
> Möglicherweise wird mir später auch ein JTAG Anschluss fehlen um ein
> kaputtgeflashtes Board wiederzubeleben, oder zum debuggen von U-Boot. Im
> übrigen habe ich mit JTAG keine Erfahrung und keine entsprechende
> Hardware.
>
> Falls ich aber weiter mit Input versorgt werde, der bei der Problematik
> hilft, so läuft es natürlich weiter.

Hallo, ein paar Anmerkungen, da ich den Thread durchgelesen habe ... ;-)

Dein Git Repo ist : 
git://github.com/michaelkebe/u-boot-medion-p89626.git nicht das mit 
https !
Deine Toolchain ist wahrscheinlich defekt.
Die Toolchain in dem FILE  arch/arm/config.mk brauchst du nicht direkt 
anzugeben es geht auch per Shell.
z.B. bei mir
make ox820 CROSS_COMPILE="armv6j-unknown-linux-gnueabi-"
Dann komme ich so weit
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/arch/arm/cpu/arm1136/start.S:327: undefined reference to `lowlevel_init'
arch/arm/lib/libarm.o: In function `board_init_r':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/arch/arm/lib/board.c:487: undefined reference to `flash_init'
arch/arm/lib/libarm.o:(.data+0x0): undefined reference to `timer_init'
arch/arm/lib/libarm.o:(.data+0xc): undefined reference to `serial_init'
common/libcommon.o: In function `_do_env_set':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/cmd_nvedit.c:296: undefined reference to `serial_setbrg'
common/libcommon.o: In function `serial_printf':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:218: undefined reference to `serial_puts'
common/libcommon.o: In function `getc':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:310: undefined reference to `serial_getc'
common/libcommon.o: In function `tstc':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:329: undefined reference to `serial_tstc'
common/libcommon.o: In function `putc':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:393: undefined reference to `serial_putc'
common/libcommon.o: In function `puts':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:417: undefined reference to `serial_puts'
common/libcommon.o: In function `jumptable_init':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/exports.c:43: undefined reference to `get_timer'
common/libcommon.o: In function `addr2info':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/flash.c:126: undefined reference to `flash_info'
common/libcommon.o: In function `flash_write':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/flash.c:181: undefined reference to `write_buff'
common/libcommon.o: In function `stdio_init':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_putc'
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_puts'
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_getc'
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_tstc'
lib/libgeneric.o: In function `udelay':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/lib/time.c:40: undefined reference to `__udelay'
board/ox820/libox820.o: In function `eth_rx':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/eth.c:1885: undefined reference to `NetReceive'
board/ox820/libox820.o: In function `ide_preinit':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/ide-820.c:849: undefined reference to `EnableSATAPhy'
board/ox820/libox820.o: In function `phy_reset':
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/ide-820.c:765: undefined reference to `workaround5458'
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/ide-820.c:777: undefined reference to `delay'
armv6j-unknown-linux-gnueabi-ld: BFD (GNU Binutils) 2.22 assertion fail /tmp/portage/cross-armv6j-unknown-linux-gnueabi/binutils-2.22/work/binutils-2.22/bfd/elf32-arm.c:13830
/bin/sh: Zeile 1:  4394 Speicherzugriffsfehler  armv6j-unknown-linux-gnueabi-ld -pie -T u-boot.lds -Bstatic -Ttext "-1" $UNDEF_SYM arch/arm/cpu/arm1136/start.o --start-group api/libapi.o arch/arm/cpu/arm1136/libarm1136.o arch/arm/lib/libarm.o common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o drivers/block/libblock.o drivers/dma/libdma.o drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o drivers/power/libpower.o drivers/rtc/librtc.o drivers/serial/libserial.o drivers/spi/libspi.o drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o fs/ext2/libext2fs.o fs/fat/libfat.o fs/fdos/libfdos.o fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o fs/yaffs2/libyaffs2.o lib/libfdt/libfdt.o lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o net/libnet.o post/libpost.o board/ox820/libox820.o --end-group /home/elektroman/GIT/MASTER/u-boot-medion-p89626/arch/arm/lib/eabi_compat.o -L /usr/lib/gcc/armv6j-unknown-linux-gnueabi/4.5.3 -lgcc -L /usr/lib/gcc/armv6j-unknown-linux-gnueabi/4.5.3 -lgcc -Map u-boot.map -o u-boot
make[1]: *** [u-boot] Fehler 139
make[1]: Leaving directory `/home/elektroman/GIT/MASTER/u-boot-medion-p89626'
make: *** [ox820] Fehler 2
el

Mach eine eingeben Branch auf, damit du nachher doe Code einfach auf die 
liste "werfen" kannst. z.B.
bit checkout -b oxnas820
Das erzeugt die einen Branch oxnas820,
Dann kannst du getrost darauft entwickeln. Versuche nicht auf diesen 
Branch oxnas820 zu pullen oder zu mergen.
Am besten würde ich dann das pullen auf master auch lassen, ggf 
einen neunen Branch als Startpunkt nehmen, damit du nacher ein diff 
machen kannst, um diese Änderung mailine zu schicken.

Autor: ElektromAn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Argg

einen neuen Branch erzeugen mit
git checkout -b oxnas820