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?
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???
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?
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:
1
[ 2.380000] XFS mounting filesystem sda2
2
[ 2.630000] XFS: resetting qflags for filesystem sda2
3
[ 2.630000] VFS: Mounted root (xfs filesystem) on device 8:2.
4
[ 2.640000] Freeing init memory: 132K
5
[ 2.690000] Warning: unable to open an initial console.
6
[ 2.700000] Kernel panic - not syncing: No init found. Try passing init= option to kernel.
7
[ 2.710000] [<c002eca0>] (unwind_backtrace+0x0/0xe4) from [<c0372884>] (panic+0x3c/0x124)
8
...
Wow, sieht gut aus... Ich kopiere mal ArchLinuxARM wieder rein...
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.
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.
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!!!
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
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:
1
Starting LCD panel...
2
/etc/init.d/rcS: line 226: /sbin/LCDd: not found
3
yaffs: dev is 32505861 name is "mtdblock5" rw
4
yaffs: passed flags ""
5
/etc/zyxel/conf exist..
6
NTFS driver 2.1.29 [Flags: R/O MODULE].
7
Fri Dec 16 14:00:00 GMT 2011
8
Starting zylogd...
9
zylog starts.
10
Starting uamd...
11
Starting ZySH daemon and client...
12
Start NAS system daemon....
13
Start ZySH daemon
14
zyshd: version 2.0.0 (build: 21:37:18 Oct 5 2011)
15
% zylog init start
16
cat: can't open '/var/run/syslog-ng.pid': No such file or directory
17
Try to KILL SIGHUP to syslog-ng: pid=0
18
syslog-ng not running, start /usr/sbin/syslog-ng
19
Dec 16 14:00:04 (none) syslog-ng[1324]: syslog-ng starting up; version='2.0.10'
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?
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...
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
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...
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:
1
medion-nas / # lsusb
2
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....
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.
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.
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:
1
Arch Linux 2.6.31.6_SMP_820 (alarm) (ttyS0)
2
3
alarm login: root
4
Password:
5
Last login: Fri Dec 16 13:45:30 CST 2011 on ttyS0
6
[root@alarm ~]# lsusb
7
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
8
[root@alarm ~]# [ 1442.610000] usb 1-2: new high speed USB device using oxnas-ehci and address 2
9
[ 1442.760000] usb 1-2: configuration #1 chosen from 1 choice
10
[ 1442.780000] scsi2 : SCSI emulation for USB Mass Storage devices
11
[ 1447.810000] scsi 2:0:0:0: Direct-Access Imation Atom USB Device PMAP PQ: 0 ANSI: 0 CCS
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?
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:
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???
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:
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.
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 ;-) ???
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.
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...
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 ;)
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.
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
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...
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...
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...
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:
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
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...
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.
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....
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...
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
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
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!
@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
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).
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
...
???
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.
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???
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.
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:
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:
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?
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:
1
armv6j-unknown-linux-gnueabi
2
"-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...
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.
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 ...
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.
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
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...
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
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
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.
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.
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.
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
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
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
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.
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...
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
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?
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...
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).
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?
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 ??
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
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...
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.
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.
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.?
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?
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
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
So, ich hab nun mal die Platte komplett platt gemacht und folgende
Partitionen eingerichtet:
1
/ # fdisk -l
2
3
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
4
255 heads, 63 sectors/track, 182401 cylinders
5
Units = cylinders of 16065 * 512 = 8225280 bytes
6
7
Device Boot Start End Blocks Id System
8
/dev/sda1 1 2433 19543041 83 Linux
9
/dev/sda2 2434 4866 19543072+ 83 Linux
10
/dev/sda3 4867 4929 506047+ 82 Linux swap / Solaris
11
/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:
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:
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:
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:
1
ide part 0 (inetwa fdisk -l)
2
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...
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:
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:
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" ?
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...
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...
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
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.
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.
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
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.
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" ?
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...
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!
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
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)...
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...
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:
1
htpc2 mtd-utils-1.4.8 # ROOT="/usr/armv6j-unknown-linux-gnueabi" equery f mtd-utils | grep bin/
> 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...
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
1
make ox820 CROSS_COMPILE="armv6j-unknown-linux-gnueabi-"
Dann komme ich so weit
1
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/arch/arm/cpu/arm1136/start.S:327: undefined reference to `lowlevel_init'
2
arch/arm/lib/libarm.o: In function `board_init_r':
3
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/arch/arm/lib/board.c:487: undefined reference to `flash_init'
4
arch/arm/lib/libarm.o:(.data+0x0): undefined reference to `timer_init'
5
arch/arm/lib/libarm.o:(.data+0xc): undefined reference to `serial_init'
6
common/libcommon.o: In function `_do_env_set':
7
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/cmd_nvedit.c:296: undefined reference to `serial_setbrg'
8
common/libcommon.o: In function `serial_printf':
9
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:218: undefined reference to `serial_puts'
10
common/libcommon.o: In function `getc':
11
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:310: undefined reference to `serial_getc'
12
common/libcommon.o: In function `tstc':
13
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:329: undefined reference to `serial_tstc'
14
common/libcommon.o: In function `putc':
15
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:393: undefined reference to `serial_putc'
16
common/libcommon.o: In function `puts':
17
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/console.c:417: undefined reference to `serial_puts'
18
common/libcommon.o: In function `jumptable_init':
19
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/exports.c:43: undefined reference to `get_timer'
20
common/libcommon.o: In function `addr2info':
21
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/flash.c:126: undefined reference to `flash_info'
22
common/libcommon.o: In function `flash_write':
23
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/flash.c:181: undefined reference to `write_buff'
24
common/libcommon.o: In function `stdio_init':
25
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_putc'
26
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_puts'
27
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_getc'
28
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/common/stdio.c:244: undefined reference to `serial_tstc'
29
lib/libgeneric.o: In function `udelay':
30
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/lib/time.c:40: undefined reference to `__udelay'
31
board/ox820/libox820.o: In function `eth_rx':
32
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/eth.c:1885: undefined reference to `NetReceive'
33
board/ox820/libox820.o: In function `ide_preinit':
34
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/ide-820.c:849: undefined reference to `EnableSATAPhy'
35
board/ox820/libox820.o: In function `phy_reset':
36
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/ide-820.c:765: undefined reference to `workaround5458'
37
/home/elektroman/GIT/MASTER/u-boot-medion-p89626/board/ox820/ide-820.c:777: undefined reference to `delay'
Mach eine eingeben Branch auf, damit du nachher doe Code einfach auf die
liste "werfen" kannst. z.B.
1
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.
Jens D. schrieb:> Bei http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2146 gibt es ein> uBoot. Keine Ahnung welche Version und weiß auch nicht, ob er bei uns> laufen würde. Wäre aber vielleicht ein Test Wert.
Ich habe mir mal Sourcen von denen ich glaube das es die sind, bei
WarheadsSE hier http://ppl.ug/Ze91Jqp1MEg/ (oxnas-uboot-plx-source.tgz)
angesehen, es ist auch uboot-1.1.2, ein diff zwischen denen und
"unseren" weist schon ein paar Unterschiede auf, aber ich denke nichts
bahnbrechendes.
Jedenfalls, aus dem verlinkten Thread glaube ich zu entnehmen, dass
dieses u-boot-1.1.2 nur von Platten mit 512B-Sektoren booten kann, und
auch nur wenn sie nicht zu weit "hinten" sind, also das bei so großen
Platten. Somit beisst sich das mit unserer 4K-Platte...
Markus V. schrieb:> 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?
ich hab schon mal kurz was im whirlpool forum gepostet:
>To use NZBGet on the nas is pretty easy.>Copy the binary nzbget from my post above somewhere on the nas.>The libs >included go into /lib (you can use symlinks). Then create a config_file>and start the grabber:>./nzbget -D -c config_file>>make sure you to that you configured everything in config_file
Das sollte eigentlich ausreichen. Wo hängt es denn?
Die vergangenen Wochen haben gezeigt, dass Downloads pausiert werden
sollten während des Postprocessings. Zudem empfehle ich nzbget mit nice
-n 19 zu starten.
Gruß
PS: echt schnelle und vielversprechende Fortschritte hier
Hallo,
jo superdank an euch.
Wollte schon fast doch verkaufen hehe :-) Aber ich hatte die
Installanleitung von nzbget übersehen. So hab jetzt alles kopiert.
Soweit funktioniert es auch. Ich brauch nur noch ne config Datei
erstellen :-)
Hallo,
ich brauch nochmal eure Hilfe.
So die Dateioperationen mit kopieren etc. ist ja net schwer gewesen.
Ähnelt ja dem guten alten MS-Dos lol. Das hab ich auch gut hinbekommen.
Ich habe mir jetzt einen Config File für das nzbget gemacht.
Wenn ich das nzbget im Daemon Mode (./nzbget -D -c
/i-data/6764ac2f/usenet/nzbget.conf) starte mit den Config File, dann
passiert einfach gar nix obwohl ich in mein nzb Verzeichnis eine nzb
reingeworfen habe.
Auch ein Log File wird leider nicht angelegt.
Wenn ich jetzt das nzbget nicht im Daemon Mode starte dann sagt er mir
als Fehlermeldung dass das NZB File not specified angegeben ist. Ich
denke der scannt mein nzb Verzeichnis.
Hat jemand eine Beispiel Config Datei?
Meine sieht so aus.
Andreas Ehrle schrieb:>>Copy the binary nzbget from my post above somewhere on the nas.>>The libs >included go into /lib (you can use symlinks). Then create a
config_file
>>and start the grabber:>>./nzbget -D -c config_file
Wie sieht es dann nach einem neustart aus? Ist dann nicht alles weg?
So Leute ich hab es geschafft.
irgendwie schien was mit den Verzeichnis angaben falsch zu sein hehe :-)
Aber schon alleine für den Download hat sich die NAS für mich gelohnt
grins. Stromsparender kann man es ja nicht machen.
Kann mir noch jemand verraten wie ich den nzbet standardmäßig starte?
Auch bei einem neustart. Sowas wie ne autoexec.bat hab ich jetzt nicht
gefunden :-)
Hallo zusammen hab hier was gefunden:
https://github.com/WarheadsSE/OX820-3.1-Linux
scheint ein Portierungsversuch des 3.1 Kernels auf ox820 zu sein... bin
in einem ArchLinux Forumeintrag darauf gestoßen. Ist ursprünglich für
den Pogoplug gedacht sollte aber theoretisch (wenn fertig) wegen
identischem SOC auch auf dem Medion NAS laufen,oder?
vielleicht hilft es jemandem weiter...
MFG
maexlich
maexlich schrieb:> Hallo zusammen hab hier was gefunden:> https://github.com/WarheadsSE/OX820-3.1-Linux> scheint ein Portierungsversuch des 3.1 Kernels auf ox820 zu sein... bin> in einem ArchLinux Forumeintrag darauf gestoßen. Ist ursprünglich für> den Pogoplug gedacht sollte aber theoretisch (wenn fertig) wegen> identischem SOC auch auf dem Medion NAS laufen,oder?> vielleicht hilft es jemandem weiter...>> MFG> maexlich
Ist mir schon bekannt ...
Jens D. schrieb:> Noch eine interessantere Alternative:> SilverStone SST-DC01: http://www.heise.de/preisvergleich/634508>
1
> Dual-core ARM 11 mit 750MHz
2
> 256MB DDR2 SDRAM
3
> 256MB NAND flash
4
> Gigabit Ethernet
5
> 2.5” SATA-II intern (9.5mm & 12.5mm)
6
> eSATA extern
7
> 2x USB 2.0
8
> Power + Reset Button
9
>
>> Kostet allerdings ca. 100€ leer. Ob es wohl der selbe Prozessor ist?
Alu-Gehäuse ...
In den update Archiven sind rpm's drin (Redhat/Fedora)
riecht irgendwie nach Marvell/Kirkwood
das IB6220 von Raidsonic hat auch eine Kirkwood CPU und rpm Archive
...
@Andreas Ehrle
Hast du dein nzbget mit unrar am laufen?
Würde gerne, dass er mir den ganzen mist auch noch entpackt den ich
runtergeladen habe.
Ich denke mal du musst das irgendwie in der config im postprocess
einbauen.
Für einen Tipp wäre ich dankbar.
Man(n) mag nicht meinen, was um 8.00 Uhr morgens schon vor so
einem Aldi los ist. Eigentlich sollte sollte die Betriebsanleitung
mit "haben sie nix besseres zu tun um diese Zeit?" beginnen.
Nunja, habe das Ding mit 2TB (Medion P89630) ergattern können und gucke
mir das Ding heute abend in aller Ruhe an.
Frage mal am Rande: Ist eine Alternative Software wie FreeNAS oder
OpenMediaVault (OMV würde mir besser gefallen) denkbar oder ist das
komplett ausgeschlossen?
Gruss
Hoi
hatte um 8 Glück und hab eine bei Aldi Nord bekommen
(gab nur 3 und hinter mir der(evtl. eBay-Hamster?) hat die anderen 2
gekauft)
Welch ein wunder ... es ist das gleiche Board mit den gleichen
Firmwaremacken -> (Firmware 1.00 UZD.2)
Also spare ich Geld und bleibe vorerst bei meinen Dockstars. Ein Schacht
für eine interne 3,5" HDD wäre zwar schön gewesen, aber nicht für diesen
Preis und dann noch mit eingeschränkter Leistung...
Weiß jemand, ob das Medion NAS bzw. die verbaute CPU eine
Hardware-Fließkommaeinheit besitzt? Das wäre sehr interessant zwecks
Livestream-Transcodierung. ;-)
Medion hat mir wieder geschrieben. Mal sehen, ob das wirklich bei
jemanden mit ausreichendem technischen Verständnis ankommt.
2011/12/22 <mailfeedback@medion.com>:
Sehr geehrter Herr ...,
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.
Wir haben eine Stellungnahme unserer Fachabteilung angefordert. Sobald
uns diese vorliegt werden wir uns wieder mit Ihnen in Verbindung setzen
und bitten um noch etwas Geduld.
---------------------------
2011/12/15 von mir
> Mit dieser Antwort bin ich keinster Weise zufrieden!>> Bitte leiten sie mein Anliegen an den Nächsten mit tieferen> technischen Verständnis weiter, denn dass was sie sagen ist falsch.>> Mit freundlichen Gruß> ...>>
---------------------------
> 2011/12/15 <mailfeedback@medion.com>:> > Sehr geehrter Herr ...,> >> > 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.> >> > Wir hoffen, Ihnen hiermit alle notwendigen Informationen mitgeteilt zu haben> > und verbleiben> >> > mit freundlichem Gruß
---------------------------
2011/12/12 von mir:
> >> Meldung=Die bei ihnen gekaufte Netzwerkfestplatte wurde mit einer> >> Dual-Core-CPU beworben. So wie sich rausgestellt hat wird aber nur ein Core> >> genutzt.> >>> >> Ist ein Firmwareupdate geplant, das dieses Problem löst?> >>> >> Weitere Details hier:> >> Beitrag "Alles Rund um den MEDION LIFE P89626 NAS"> >>> >> Mit freundlichen Gruß
Michael Kebe schrieb:>> > 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.>> >>> > Wir hoffen, Ihnen hiermit alle notwendigen Informationen mitgeteilt zu haben>> > und verbleiben
Exakt das gleiche habe ich auch als Rückmeldung erhalten. Somit haben
schon IMHO mehrere Leute angefragt. Ich hoffe, das auch die neuen P89630
User nochmal nachfragen, damit das Interesse auch wahrgenommen wird.
Ich halte die Aussage von Medion schlicht für falsch. Ich hab im Wiki
mal gesammelt: P89626: Single Core Problem Bitte um weitere Fakten
ergänzen.
Hoi
mal 2 andere Fragen:
1:
Ich hab gerade auf dem NAS gesehen, das da syslog_ng läuft und versucht,
die Logmeldungen an meinen Homeserver zu schicken.
/etc/syslog_ng/syslog_ng.conf geändert und syslog_ng neu gestartet ->
geht
Box neu gestartet -> änderungen an /etc/syslog_ng/syslog_ng.conf weg
wieso behält der die änderungen an der /etc/exports und die der
syslog_ng.conf nicht???
Hat da schon jemand ne lösung?
2:
Hat es jemand geschafft, eine NFS-Freigabe für USB-Platten per
Webinterface anzulegen? Bei mit hat er sich geweigert, die USB-Platte
überhaupt als Auswahlmöglichkeit anzubieten!
hoshi schrieb:> geht> Box neu gestartet -> änderungen an /etc/syslog_ng/syslog_ng.conf weg>> wieso behält der die änderungen an der /etc/exports und die der> syslog_ng.conf nicht???
Hallo,
zunächst mal ein "Herzlich Willkommen" an alle Aldi-Nord-2TB-User. Euer
Input wird das System verbessern.
Dann möchte ich zu dieser Frage auf die Suche verweisen.
Ich weiß, dass dieser Thread zu einem unübersichtlichen Monstrum
geworden ist. Aber es steht schon sehr viel drin und die meisten der
FAQs sind hier schon bearbeitet und zum größten Teil beantwortet worden.
Bevor dieser Thread noch unübersichtlicher wird:
Bitte verschafft Euch einen Überblick über das was hier schon gelaufen
ist.
Ich weiß, dass das Durcharbeiten dieses Threads aufwändig ist, aber wir
haben das bisher schon viel Arbeit in die Ergründung des Medion NAS
gesetzt, was hier zwar unübersichtlich aber dennoch in gutem Umfang
dokumentiert ist.
Wenn hier jeder seine individuelle Frage stellt, die oben schon
beantwortet ist, nur weil er zu faul für's Suchen ist, hält er die
anderen an der Weiterentwicklung ab.
Neue Fragen, Ideen, Vorschläge und vor allem Tipps sind natürlich super,
aber ein wenig die Vergangenheit erarbeiten kann man erwarten.
Tschüss Dimpflmoser
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.
Hm. Wolle mein ArchLinuxARM mal einrichten und /dev/sda4 per Samba frei
geben, um mal zu sehen wie schnell es ist, nun das:
1
[root@PLX7820 ~]# fdisk -v
2
fdisk (util-linux 2.20.1)
3
[root@PLX7820 ~]# fdisk -l
4
5
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
6
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
Partition 1 does not start on physical sector boundary.
15
/dev/sda2 39086145 78172289 19543072+ 83 Linux
16
Partition 2 does not start on physical sector boundary.
17
/dev/sda3 78172290 79184384 506047+ 82 Linux swap / Solaris
18
Partition 3 does not start on physical sector boundary.
19
/dev/sda4 79184385 2930272064 1425543840 83 Linux
20
Partition 4 does not start on physical sector boundary.
Scheint so, als wenn die Platte als 512Bytes/Sektor eingerichtet wurde,
aber es ist ja eine 4KB/Sektor platte... Kann das sein? Was mache ich
nun am besten?
Ich starte mal neu und schau, was fdisk aus dem Original System so sagt:
1
/ # fdisk -v
2
fdisk (util-linux 2.13-pre7)
3
/ # fdisk -l
4
5
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
6
255 heads, 63 sectors/track, 182401 cylinders
7
Units = cylinders of 16065 * 512 = 8225280 bytes
8
9
Device Boot Start End Blocks Id System
10
/dev/sda1 1 2433 19543041 83 Linux
11
/dev/sda2 2434 4866 19543072+ 83 Linux
12
/dev/sda3 4867 4929 506047+ 82 Linux swap / Solaris
Lese bei https://wiki.archlinux.org/index.php/Advanced_Format das fdisk
ab v2.17.2 Änderungen für 4K Sektor platten hat.
Somit ist es wohl keine gute Idee, das fdisk v2.13-pre7 von der Original
Firmware zu nutzten, was ich aber getan hab :(
Damit kann man es überprüfen:
1
/ # fdisk -lu /dev/sda
2
3
Disk /dev/sda: 1500.3 GB, 1500301910016 bytes
4
255 heads, 63 sectors/track, 182401 cylinders, total 2930277168 sectors
5
Units = sectors of 1 * 512 = 512 bytes
6
7
Device Boot Start End Blocks Id System
8
/dev/sda1 63 39086144 19543041 83 Linux
9
/dev/sda2 39086145 78172289 19543072+ 83 Linux
10
/dev/sda3 78172290 79184384 506047+ 82 Linux swap / Solaris
11
/dev/sda4 79184385 2930272064 1425543840 83 Linux
Startet mit 63, also falsch, weil nicht durch 8 Teilbar.
Kann mal jemand, der noch die Original Partitionen hat, mit '''fdisk -lu
/dev/sda''' prüfen, wie die Ausrichtung ist? Wäre ja geil, wenn alle NAS
mit ungünstiger Ausrichtung ausgeliefert wurden... (Ich glaube bei
P89626: fdisk kann man es so nicht sehen.)
@Dimpflmoser
Von syslog_ng hab ich im Thread bisher nichts gelesen!
aber Punkt 1 is auch gelöst (hätte ich mir ja denken können, nachdem ich
dropbear eingebaut hab)
Falls es wer in der Übersichtsseite verewigen will:
syslog_ng.sys nach /i-data/6764ac2f/admin/cfg/syslog-ng.conf kopieren
und folgende Zeilen einfügen
----
destination loghost { tcp("192.168.x.y" port(z)); };
log { source(s_sys); destination(loghost); };
----
(x,y und z sind nach den eigenen bedürfnissen anzupassen)
dazu dann ein passendes Script (/i-data/6764ac2f/admin/bin/syslog-ng.sh)
----
#!/bin/sh
killall syslog-ng
cp /i-data/6764ac2f/admin/cfg/syslog-ng.conf
/etc/syslog-ng/syslog-ng.conf
syslog-ng
----
welches mit in /usr/local/zy-pkgs/etc/init.d/ZYPKG_DEPS unter START-UP
eingetragen wird
Auf der Gegenseite ist dann syslog_ng (oder ein andere Logger)
ensprechend anzupassen: Bei mir (auch syslog-ng) sieht das so aus:
----
# --- NAS ---
destination nas_syslog {
file("/var/log/$YEAR/$MONTH/$DAY/messages_nas_syslog-$YEAR-$MONTH-$DAY"
template(t_local)); };
source nas_syslog{ tcp(ip(0.0.0.0) port(z)); };
log { source(nas_syslog); destination(nas_syslog); };
----
z ist natürlich mit dem Port des NAS identisch.
@Jens D.
~ # fdisk -lu /dev/sda
Disk /dev/sda: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 63 1028159 514048+ 83 Linux
/dev/sda2 1028160 3907024064 1952997952+ 9 AIX bootable
Jens D. schrieb:> Außerdem sollte jeder die Wiki Seiten lesen und ggf. ergänzen ;)
Aber bitte daran denken, das auch "normalsterbliche" das WIKI lesen. :)
Da ich die letzten Tage recht wenig über Fortschritte geschrieben habe,
wollte mal kurz über meine Aktivitäten im Bezug auf das Medion NAS
berichten:
Wie schon ein paar mal erwähnt, liegt mein Haupt-Augenmerk, das NAS als
VDR-Server im Keller zu betreiben. Die Original-SW würde dafür zwar
wahrscheinlich auch tun, allerdings ist mir das ganze Setup zu
verworren.
Deshalb habe ich ja den Pogoplug/Arch Linux -Kernel meiner Meinung nach
recht erfolgreich für unser NAS angepasst, der direkt die interne Platte
als Rootfs verwendet.
Der Kernel kann zwar grundsätzlich auf den yaffs2-formatierten
NAND-Speicher zugreifen, allerdings wirft er da viele Fehlermeldungen
aus weshalb ich dem aktuell nicht vertrauen würde.
Wenn ich in einem späteren Stadium mal das NAND-Flash als Root-FS nutzen
möchte würde ich da vermutlich auf UBI umsteigen, da das eine bessere
Verwaltung von Bad Blocks und ein besseres 'Wear-Leveling' mitbringt.
Insofern sehe ich yaffs2 ein wenig als totes Pferd an, um das ich mich
derzeit nicht mehr kümmern möchte.
Auf der Platte habe ich bisher als 2 Partition ein Ext3-Dateisystem mit
dem ArmArchLinux-Rootfs. Da ich Arch Linux nicht kenne und es für das
Dockstar NAS schon einige Debian-VDR-Installationen gibt hatte ich mich
mal um ein Debian Rootfs gekümmert.
Leider hat das Debian Rootfs einige Devices, wie z.B. das
Ethernet-Interface nicht unterstützt. Ich habe dann angefangen, die
Komponenten aus dem Arch Rootfs zusammen zu suchen, damit ich die ins
Debian-System überführen kann. Dabei bin ich zwar langsam aber
kontinuierlich voran gekommen, aber habe mich irgendwann gefragt ob das
der richtige Weg ist.
Mein Schluss war, dass das Arch Rootfs ja schön stabil läuft und das ein
guter Ausgangspunkt für die nächsten Schritte ist. Dabei muss ich halt
in Kauf nehmen, dass ich manches neu bzw selbst machen muss und vor
allem, dass ich einiges neu lernen muss.
Also habe ich die letzten Nächte damit verbracht, mich in Arch
einzulesen.
Gestern Abend habe ich mir dann einfach mal ein VDR-User Paket für X68
gezogen und als Architektur/Prozessor unseren ARM eingetragek und ein
'makepkg' drauf los gelassen.
Ich muss sagen, bin beeindruckt wie weit ich damit gekommen bin, es hat
einen kleinen Fehler wegen einer fehlenden Datei gegeben aber ansonsten
habe ich den Eindruck, dass es problemlos durchläuft. Diesen Fehler habe
ich dann nicht mehr adressiert, da es schon viel zu spät/früh war, aber
ich weiß wie ich ihn beheben muss.
Leider sehe ich für die kommenden Tage bis Neujahr nur noch wenig Zeit,
um mich um das Baby zu kümmern. Mal sehen ob ich von meinem
Haushaltsvorstand etwas Zeit rausschinden kann.
Soweit mal mein aktueller Status.
Bye Dimpflmoser
Hallo Jens D
Hast du schon was über die Geräusche rausgefunden?
Meiner Meinung nach sind die nicht normal. Bei mir verhindern Sie den
Standby. Nach Stunden irgendwann hören vielleicht mal die Geräusche auf
und dann kann die Festplatte in den Standby Modus gehen. Timeout ist
auch bei mir auf 15 Minuten eingestellt. Schalte ich die jedoch aus und
wieder ein, dann hab ich meist erstmal ruhe, bis Ihr einfällt wieder
etwas du fabrizieren. Da auch die Status LED leuchtet, gehe ich stark
davon aus, dass doch irgendwie ein Zugriff auf die Platte erfolgt und es
sich hierbei nicht um die Platte selbst handelt.
Wäre auch für eine Seagate Festplatte nicht normal, wenn Sie solche
Geräusche produzieren würde die ganze Zeit. Es nervt einfach wenn die
Festplatte nicht gerade irgendwo weg gesperrt steht.
@Dimpflmoser: Ja, ich würde ein Debian ebenfalls vor ziehen, weil ich
mich besser damit auskenne. Aber ArchLinux ist auch nicht schlecht
dokumentiert.
Komponenten von ArchLinux nach Debian zu übernehmen macht IMHO keinen
Sinn. Wäre schon besser, wenn man über die Paketverwaltung alles
erledigen kann.
Zu den Platten Geräuschen kann ich nicht viel sagen. Sie sind
kontinuierlich da. Da auch andere die selben Geräusche hören, denke ich
das es normal ist. ich kann es nur hoffen. In jedem Fall sollte man die
SMART Werte beobachten.
Ob es Sinn macht, mit der Sound Datei an Seagate zu schreiben?
noxx schrieb:> Jens D. schrieb:>> Außerdem sollte jeder die Wiki Seiten lesen und ggf. ergänzen ;)>> Aber bitte daran denken, das auch "normalsterbliche" das WIKI lesen. :)
Nun, bei Dokus ist immer die Frage wer die Audienz ist. Mein Eindruck
ist, dass die meisten, die hier aktiv beitragen, nicht daran
interessiert sind, wie die aktuelle Firmware am besten einzusetzen ist;
sondern sie wollen das System modifiziern und ihren Bedürfnissen
anpassen.
Zu diesen Anpassungen gehören einfach einige Schritte, die eine gewisse
Kenntniss von Linux, Kernelkram und (Cross-)kompilieren vorraus setzten.
Ein Linux-Neuling ist dabei bestimmt überfordert. Ich denke für einen
Neuling ist dieses NAS nicht die richtige Spielwiese, da wir keine
Kochrezepte und Anleitungen liefern können, wir sind hier alle am
Experimentieren, wobei vieles schief geht und auch die Gefahr besteht,
dass man was kapput macht.
Ich denke es gibt bessere Systeme für den Einstieg in (Embedded-)Linux
als das Medion-NAS, wie z.B. OpenWRT, NSLU2, Fritz!Box/Freetz, Beagle
Board.
Wer Linux-Erfahrung auf dem Desktop hat und keine Scheu vor bash und vi
hat ist hier natürlich super aufgehoben. Die ein oder andere dumme Frage
haben wir alle, und wir lernen am besten in der Gemeinschaft.
Eine Einführung in GCC/Bash/vi ist hier aber nicht sinnvoll.
Jens D. schrieb:> Zu den Platten Geräuschen kann ich nicht viel sagen. Sie sind> kontinuierlich da. Da auch andere die selben Geräusche hören, denke ich> das es normal ist. ich kann es nur hoffen. In jedem Fall sollte man die> SMART Werte beobachten.
Also ich habe nicht den Eindruck, dass meine Platte komische Geräuche
von sich gibt.
Unter Arch fährt die Platte nach dem Kommondo 'hdparm -S 10' auch
zuverlässig runter. Sie wacht zwar immer mal wieder auf aber schläft
dann auhc wieder ein.
Ich vermute, dass das Aufwachen durch Logfiles, Cronjobs und anderes
Housekeeping statt findet.
Mittelfristig müssen die Logfiles bestimmt in ein Ram-FS ausgelagert
werden.
Ist es nicht so, dass der smartd regelmäßig die Platte nach ihrem
aktuellen Zustand abfragt und so bisher unerklärliche Plattenzugriffe
erzeugt?
Jens D. schrieb:> @Dimpflmoser: Ja, ich würde ein Debian ebenfalls vor ziehen, weil ich> mich besser damit auskenne. Aber ArchLinux ist auch nicht schlecht> dokumentiert.
Jepp, fühle mich unter Arch wie ein Depp und finde einfachste Dinge
nicht. Schon allein das BSD-Init-System verunsichert micht. Das letzte
mal dass ich mit BSD-Init zu tun hatte war 1994 unter Arcorn-Unix und
SunOS5, aber da war ich nur User der die Kisten nicht verwaltet hat,
außerdem sind die sowieso immer durch gelaufen.
In der Tat scheint mir Arch gut dokumentiert zu sein und mir gefallen
zwei Aspekte:
- Rolling release, bei einem Produktivsystem schiebe ich die
Dist-Upgrades immer so lange vor mir her, weil ich Sorgen vor den
Auswirkungen habe. Mein V-Server der öffentlich erreichbar ist läuft
noch unter Debian 4, für das es seit 2 Jahren keine Sicherheitspatches
mehr gibt. Sehr leichtsinnig.
- Das Konzept 'Keep it simple' und der Ansatzt, dass der Versuch durch
Abstraktion, die Komplexität vor dem User zu verstecken, das System in
der Regel komplizierter macht. D.h. mache manches lieber von Hand, dann
scheint es zwar weniger sexy zu sein, aber Du versehst wenigstens was
das System tut.
> Komponenten von ArchLinux nach Debian zu übernehmen macht IMHO keinen> Sinn. Wäre schon besser, wenn man über die Paketverwaltung alles> erledigen kann.
Dafür müssten wir halt die richtigen Binaries in Debian finden bzw
daraus ein Paket bauen. Ist natürlich alles machbar und in dem
PogoplugPro-Forum ja auch erwähnt, aber wieso soll man sich diese Mühe
machen wenn diese Arbeit in Arch schon erledigt ist und Arch eben seine
eigenen Reize hat.
Dimpflmoser schrieb:> Ich vermute, dass das Aufwachen durch Logfiles, Cronjobs und anderes> Housekeeping statt findet.> Mittelfristig müssen die Logfiles bestimmt in ein Ram-FS ausgelagert> werden.
busybox-syslogd wäre eine Alternative: DockstarDebianSqueeze: syslog
Will das Archiv dann auf ein NFS verschieben, mit fdisk alles neu machen
und das Archiv anschließend wieder entpacken.
Spricht was dagegen bzw. hat jemand eine bessere Idee?
Sooooooooooooooo
Wie modde ich eine NAS.
Ich habe das dingen jetzt so leise, da kann das teil von mir aus machen
was es will :-)
Wie bin ich vorgegangen (Achtung Garantieverlust).
Ich habe die NAS aufgeschraubt und die Festplatte rausgeholt.
Ab in den PC mit der Festplatte.
Da habe ich mir die Demo Version von HDD tune Pro heruntergeladen und
habe das AAM auf ganz niedrig gestellt. Interessant die Festplatte ist
schon auf einen Wert von 208 von 254 eingestellt. :-)
Also ab auf eine Wert von 128 (der niedrigste).
Die Festplatte wieder rausgenommen und in die NAS gebaut.
Allerdings habe ich diese noch vom Gehäuse entkoppelt mit
Gummidichtungsringen an den Schrauben und alles zusammengebaut und siehe
da. Ich höre so gut wie kein Geräusch mehr :-) Jetzt ist das mir auch
völlig egal was die NAS so treibt :-)
Ach so ja, die nebenwirkung :-)
Was drauf war ist weg. Irgendwie scheint der PC diese etwas
umzuformatieren. Aber es ist auf jedenfall leiser geworden.
Also Bilder hab ich jetzt nicht gemacht.
Aber es reicht auch wenn du nen Stück Styropur drunter zimmerst,
hauptsache es ist etwas entkoppelt vom Gehäuse.
Theoretisch würde es mit einem linux tool genauso gehen mit den AAM :-)
Aber ich habe leider keins. Daher musste die Windows Kiste dafür
herhalten.
@Jens D.
> Naja, ok. sda1 liste mit Sektor 63 ungünstig, aber zumindest ist dei> wichtigere sda1 ok, denn 1028160/8=128520 (also gerade Teilbar)...
sda1 ist eh nur eine Swap-Partiton
Das er erst bei 63 anfängt, sollte normal sein. Das ist bei allen meinen
Platten auch so, sobald sie Partitioniert sind. Bei Platten die keine
Partiton haben (unter Linux nicht nötig, wenn die Platte komplett
benutzt wird). Das wird damit zusammen hängen, es sonst Probleme mit der
Partitiontable geben könnte, die ja in Sektor1 ist.
Es gibt auch Bootmanager (bin mir nicht sicher, aber bei Lilo ist das
glaube so), das die sich mit auf der 1. Spur verewigen. Da ich Grub mit
einer eigener Patition nutze und der Startcode von grub angeblich mit in
Sektor 1 passt, hab ich keinen Rechner, bei dem ich das auf die schnelle
mal prüfen kann.
> Theoretisch würde es mit einem linux tool genauso gehen mit den AAM :-)> Aber ich habe leider keins. Daher musste die Windows Kiste dafür> herhalten.
das passende Programm dazu wäre "hdparm", welches leider nicht mit auf
der Box ist.
---
-M Get/set acoustic management (0-254, 128: quiet, 254: fast)
---
hab mal bissel wegen der CPU geschaut, falls sich Aldi/Medion bei
jemanden eher meldet als bei mir:
wie bereit am 7.12.2011 von gepostet, spricht sysfs hier eindeutige
Worte, die auch Aldi/Medion so akzeptieren müssen!
/sys/devices/system/cpu/kernel_max -> 1
/sys/devices/system/cpu/offline -> 1
/sys/devices/system/cpu/online -> 0
/sys/devices/system/cpu/possible -> 0-1
/sys/devices/system/cpu/present -> 0-1
wichtig ist hier:
offline: cpus that are not online because they have been
HOTPLUGGED off or exceed the limit of cpus allowed by the
kernel configuration (kernel_max above).
Quelle:
http://www.kernel.org/doc/Documentation/ABI/testing/sysfs-devices-system-cpu
Bei denen die schon lauffähige Alternativkernel haben, sollte das so
aussehen
/sys/devices/system/cpu/offline ->
/sys/devices/system/cpu/online -> 0-1
/sys/devices/system/cpu/possible -> 0-1
/sys/devices/system/cpu/present -> 0-1
bei
/sys/devices/system/cpu/kernel_max -> 1
bin ich mir nicht zu 100% sicher, ober das so auch richtig wäre. Bei
anderen Linux-Kisten kommen ich da 3(Kernel für max 4 CPUs übersetzt)
bzw. 7(Kernel für max 8 CPUs übersetzt).
hoshi schrieb:> wie bereit am 7.12.2011 von gepostet, spricht sysfs hier eindeutige> Worte, die auch Aldi/Medion so akzeptieren müssen!
Danke für die Info. Ich habs ins Wiki gepackt.
Werde gleich mal Rückmeldung mit ArchLinux geben...
Hiermal ein Konverter von u-boot.wrapped auf das Format im mtd2.
Dort sind insgesamt 448kB tatsächliche Grösse im MTD2 verfügbar. Pro
Byte werden sowohl im MTD1 und MTD2 jeweils ein 8 Byte Block verwendet.
1
#include<stdint.h>
2
#include<stdio.h>
3
4
voidprintnandimgbyte(uint8_tval)
5
{
6
uint8_tbytes[8];
7
bytes[0]=(val&0x01)?0x55:0xAA;
8
bytes[1]=(val&0x02)?0x55:0xAA;
9
bytes[2]=(val&0x04)?0x55:0xAA;
10
bytes[3]=(val&0x08)?0x55:0xAA;
11
bytes[4]=(val&0x10)?0x55:0xAA;
12
bytes[5]=(val&0x20)?0x55:0xAA;
13
bytes[6]=(val&0x40)?0x55:0xAA;
14
bytes[7]=(val&0x80)?0x55:0xAA;
15
fwrite(bytes,8,1,stdout);
16
}
17
18
intmain(intargc,char*argv[])
19
{
20
uint8_tc;
21
while(fread(&c,1,1,stdin)==1)
22
{
23
printnandimgbyte(c);
24
}
25
26
return0;
27
}
Code ist nach dem Inhalt vom build/stage1/src/nand.c nachgebaut.
Aufruf:
1
gcc -o makenandimage makenandimage.c
2
makenandimage <u-boot.wrapped >u-boot.mtd2
Das Tool packager packt vor das U-Boot Image lediglich ein 8 Byte Header
bestehend aus Daten-Länge (uint32_t) und CRC32 (uint32_t) vor das
eigentliche u-boot Binary.
ft schrieb:> Hiermal ein Konverter von u-boot.wrapped auf das Format im mtd2.
Kannst du eine compilierte Version zur Verfügung stellen? Vielleicht
direkt für ARM, damit alle es auf der Box benutzten können?
Hier nochwas zum u-boot build,
in sysapps/u-boot-1.1.2/board/oxnas/config-820.mk:
nicht einfach die Variable #SDK_BUILD_HDD_BOOT ?= 1 reinnehmen, sondern
lieber direkt darunter die Zeile USE_SATA ?= 1 einfügen.
vorher:
1
# Memory size in megabytes if probing is not enabled
2
MEM_SIZE ?= 128
3
4
#SDK_BUILD_HDD_BOOT ?= 1
5
SDK_BUILD_NAND_BOOT ?= 1
6
7
# Overwrite the mem= Linux bootarg stored in the environment with the amount
nachher:
1
# Memory size in megabytes if probing is not enabled
2
MEM_SIZE ?= 128
3
4
#SDK_BUILD_HDD_BOOT ?= 1
5
SDK_BUILD_NAND_BOOT ?= 1
6
7
USE_SATA ?= 1
8
# Overwrite the mem= Linux bootarg stored in the environment with the amount
Dann wird der u-boot auch weiterhin das Nand-Flash als Environment
verwenden. Nur der SATA-Code sollte dadurch mit reinkommen.
Habs aber selber noch nicht auf die Box gebracht.
Bin ja auch gerade erst dabei den Bootprozess auseinanderzunehmen.
Markus V. schrieb:> Sooooooooooooooo> Wie modde ich eine NAS.>> Ich habe das dingen jetzt so leise, da kann das teil von mir aus machen> was es will :-)
Das sehe ich nun aber nicht so.
Mein NAS soll 24/7 laufen und während der Ruhezeiten gefälligst schlafen
und keine kostbare Energie verbraten und das HDD Leben sinnlos
verkürzen.
Jetzt habe ich mal alle Medienfreigaben ausgehakt aber Ruhe herrscht
immer noch nicht. Kann man den Medienserver generell abschalten?
ft schrieb:> Dann wird der u-boot auch weiterhin das Nand-Flash als Environment> verwenden. Nur der SATA-Code sollte dadurch mit reinkommen.
Das ist ein guter Fang, danke!
ft schrieb:> Hiermal ein Konverter von u-boot.wrapped auf das Format im mtd2.>> ...>> Code ist nach dem Inhalt vom build/stage1/src/nand.c nachgebaut.
Woher eigentlich die Info, ich dachte packager der die .wrapped Variante
macht reicht. Hast Du dann so ein u-boot erfolgreich ins NAND geflasht?
derzeit nicht. Allerdings hatte ich das Gegenstück aus dem stage1 mir
geschnappt und ein kleines Verifikationstool zusammengebaut mit dem ich
ein Backup des MTD2 (ohne OOB) hab durchlaufen lassen (Code zu grossen
Teilen aus stage1 entnommen). Hier konnte ich die korrekte CRC
verifizieren. Und dagegen habe ich dann den Output von meinem Code
gecheckt. Und hatte ein ebenso korrektes Ergebnis.
Daher braucht man ein u-boot.wrapped welches dann ins MTD2 Format
konvertiert wird.
stage1 ist der erste Loader der am Anfang des Flash liegt. Der ist
ebenfalls in diesem Format abgelegt.
Stage1 verwendet ein U-Boot-ähnliches Image-Format zum Laden welches
nochmal in diesem Parity-Code abgelegt wird.
Ladereihenfolge:
MTD1(stage1) -> MTD2(u-boot) -> MTD4(kernel)
MTD1 enthält stage1 (enthält auch SATA Lader-Code im Archiv, wird aber
nur als NAND-Lader kompiliert)
MTD2 enthält U-Boot in besagten Format
nur MTD1 und MTD2 verwenden diesen Parity-Code. In den anderen
MTD-Bereichen wird Binärformat ohne Parity-Code verwendet.
Mein persönlicher Grund:
Ein SATA-fähiger U-Boot ist halt eine gute Basis fürs Kernel-Hacken. Ist
halt deutlich schneller was auf die Platte zu legen und man kann wen man
die USB-Platte (ebenfalls Aldi-Abgebot) gleich mitgekauft hat auch
gleich die Platte am PC behandeln wenn mal was schief geht. Aber daher
eben der SATA-fähige U-Boot erstmal nötig. Nach dem 4kByte Sektor
Support will ich auch nochmal schauen, aber erstmal sehen was im Kernel
bezüglich der gesperrten CPU zu finden ist.
Anmerkung: bin im Moment nicht in der Nähe des NAS (daher ein
Flash-Backup und das Source-Archiv zum Analysieren)
Hallo zum Dual Core nicht aktiv Problem,
zwischen dem PogoPlug Pro Kernel und dem Medion-Kernel gibt es einen
Unterschied in init/main.c.
PogoPlug Pro Kernel (2.6.31.6):
1
/* Called by boot processor to activate the rest. */
2
staticvoid__initsmp_init(void)
3
{
4
unsignedintcpu;
5
6
/*
7
* Set up the current CPU as possible to migrate to.
8
* The other ones will be done by cpu_up/cpu_down()
9
*/
10
set_cpu_active(smp_processor_id(),true);
11
12
/* FIXME: This should be done in userspace --RR */
13
for_each_present_cpu(cpu){
14
if(num_online_cpus()>=setup_max_cpus)
15
break;
16
if(!cpu_online(cpu))
17
cpu_up(cpu);
18
}
19
20
/* Any cleanup work */
21
printk(KERN_INFO"Brought up %ld CPUs\n",(long)num_online_cpus());
22
smp_cpus_done(setup_max_cpus);
23
}
Medion-Kernel (2.6.31.14):
1
/* Called by boot processor to activate the rest. */
2
staticvoid__initsmp_init(void)
3
{
4
unsignedintcpu;
5
6
/*
7
* Set up the current CPU as possible to migrate to.
8
* The other ones will be done by cpu_up/cpu_down()
9
*/
10
set_cpu_active(smp_processor_id(),true);
11
12
/* FIXME: This should be done in userspace --RR */
13
for_each_present_cpu(cpu){
14
if(num_online_cpus()>=setup_max_cpus)
15
break;
16
if(!cpu_online(cpu))
17
cpu_up(cpu);
18
break;/* Do not bring up the second core because stable issue has not been fix (Chorus) */
19
}
20
21
/* Any cleanup work */
22
printk(KERN_INFO"Brought up %ld CPUs\n",(long)num_online_cpus());
23
smp_cpus_done(setup_max_cpus);
24
}
im neueren Kernel findet sich dieses tolle break mit passendem
Kommentar.
Aber erstmal schauen ob es noch weitere solcher Stellen gibt.
scheint das einzige zu sein,
wahrscheinlich ist es sinnvoll jedem NAS mit vollständig aktivem
Doppelkern einen Lüfter zu spendieren. Stabilitätsprobleme sind
eigentlich immer ein Ausdruck von zu schwacher Wärmeabführ.
Die ARM Architektur kann meines Wissens keine CPUs hotpluggen, daher
dürfte der Kernel dafür keinen Support haben, somit wird die CPU ohne
ein Entfernen des breaks nicht im Zwei-Kern-Betrieb arbeiten.
Daher auch wohl der leere cpu1-Ordner im sysfs.
Eine Stelle bin ich mir nicht sicher könnte aber für eine erfolgreiche
Aktivierung des zweiten Kerns notwendig sein.
In Source-Datei arch/arm/mm/proc-v6.s:
PogoPlug-Pro Kernel:
Rückmeldung zu Samba Performance unter ArchLinuxArm:
Schreiben ca. 16MB/s bei 75-80% Auslastung eines Kerns.
Lesen ca. 23MB/s bei um die 50% Auslastung eines Kerns.
Der andere Kern macht fast nix.
Zum Vergleich: Mit der [GoFlexHome] mit ArchLinux und im Grunde selben
Einrichtung komme ich auf:
23MB/s schreiben, bei ca. 80% CPU Auslastung (hat nur einen Kern
@1.2GHz)
lesen: 30MB/s bei 70% Auslastung
Beide NAS hängen mit einem Ubuntu PC am selben GBit-Switch. Kopiert hab
ich von Nautilus SMB auf lokale Platte...
Ob der Kernel einfach besser auf Kirkwood Optimiert ist, oder weil
Single-Thread Aktion, machen sich die 750Mhz zu 1.2GHz bemerkbar?
Jens D. schrieb:> Ob der Kernel einfach besser auf Kirkwood Optimiert ist, oder weil> Single-Thread Aktion, machen sich die 750Mhz zu 1.2GHz bemerkbar?
Wohl eher letzteres, und Du sagtest auch dass nur ein Kern belastet
wird, und der auch nicht voll, wahrscheinlich würde eine Verbesserung an
"unserem" NAS nur dann sichtbar, wenn Samba beide Kerne nutzen würde.
Welche Version hast Du denn im ArchLinux? Keine ahnung ob eine neuere da
effizienter damit umgeht, ich könnte später wenn ich auch den dual-core
fähigen Kernel boote mal mit samba-3.6.1 unter Gentoo testen nachdem ich
es baue, ich sehe gerade da gibt es bereits ebuilds für
samba-4.0.0_alpha11 und samba-4.0.0_alpha17. Aber wie esagt, ich weiß
nicht ob sie solche Optimierungen mit bringen.
Um den Support für grosse Platten im u-boot zu aktivieren, sollte es
genügen
folgendes in sysapps/u-boot-1.1.2/include/configs/ox820.h zu ergänzen.
#define CFG_64BIT_LBA
dann wird der SATA-Code mit 64 Bit Support kompiliert.
Habe auch Samba v3.6.1
Ich hatte nur mit einer 700MB ISO Datei probiert. Denke da dürfte
Multi-Threading nicht gehen. Sicher hat der Dual-Core aber mehr
Potenzial, wenn mehrere Gleichzeitig Zugriffe erfolgen. Oder wenn die
Box noch andere Sachen anstellen soll.
Noch eine Allgemine Frage: Ich hab nun in der Anleitung
P89626/ArchLinuxARM: ArchLinuxARM installieren es so gemacht:
/dev/sda4 ist die große Datenpartition
In '''/etc/fstab''' mounte ich /dev/sda4 nach /media/daten und im Samba
Beispiel dann:
1
[Daten]
2
path = /media/daten
3
read only = no
4
public = yes
5
writable = yes
6
guest ok = no
USB-Sticks/-Platten sollten wohl auch nach media gemountet werden. Von
daher wäre das nicht schlecht:
ft schrieb:> Um den Support für grosse Platten im u-boot zu aktivieren, sollte es> genügen> folgendes in sysapps/u-boot-1.1.2/include/configs/ox820.h zu ergänzen.>> #define CFG_64BIT_LBA>> dann wird der SATA-Code mit 64 Bit Support kompiliert.
Na cool, dann hätten wir ja alles beisammen eigentlich :-). Von der
Platte den kernel holen war auch mein Wunsch, jetzt sollten wir noch die
Sache mit dem Flashen 'rauskriegen. In der Original-FW fand ich glaube
ich 2 skripte wo es um Flashen ging, aber Zyxel scehint da jeweils nur
Kernel (der default auch ein initrd beinhaltet) und sysroot zu flashen,
keinen bootloader. Ich könnte auch falsch liegen, aber ich fand bisher
nichts in die Richtung.
WarheadsSE von ArchLinuxArm hat auch folgendes auf github
veröffentlicht:
"Gentlemen,
I apologize for contacting some of you out of the blue, but I wanted to
pass along my 1.1.2 sources that have the merged support for
NAND/network/SATA between PLX & CE's sources:"
https://github.com/WarheadsSE/uboot-ox820
ft schrieb:> ... Allerdings muss man den 4kB Sektorgrösse Support noch ermitteln.
Ist es denn nicht so, dass diese Platte trotz Verwendung von
physikalisch 4K großen Cluster, dem "Betriebsystem" 512 Bytes
vorgaukelt, und somit auch uBoot? Also so eine Build von uBoot mit
aktiviertem CFG_64BIT_LBA könnte Jens mal auf seiner partitionierten
Platte los lassen, um zu sehen ob nun
1
ide part 0
2
und
3
ext2ls ide 0:1
korrekt funktionieren. Was meint Du, Jens, willst denn so ein Build?
Zumindest ohne das ATA_FEATURES Kommando sollte das so geschehen. Daher
sagte ich ja, dass man das mal anschauen muss. Daher könnte es durchaus
auf Anhieb funktionieren, wenn die Umsetzung von 64 Bit Offset auf 48bit
LBA ohne weiteres im u-boot klappt.
Da ich halt mein NAS nicht zur Hand hab, hab ich mir halt gedacht meine
Erkenntnisse unmittelbar anderen zur Verfügung zu stellen. Aber im neuen
Jahr werde ich an meinem definitiv einen u-boot mit SATA-Support
installieren. Dann kann man auch an viele schöne Dinge (mpd, pulseaudio
mit USB-Soundkarte usw.) denken.
Zum Flashen wurde ja oben schonmal was beschrieben.
Das Binary flashcp befindet sich auf der Box und eignet sich zum Flashen
des Bootloaders.
Hier die Zeile für den U-Boot (noch nicht probiert, ist aber wohl
sicherlich auch nicht anders als im Firmware-Update-Fall)
Aufgrund des Platzes kann man ja auch überlegen hintendran einfach im
MTD2 noch einen U-Boot zu flashen (allerdings dann Binärformat). Das
braucht dann einen Kernel mit angepassten MTD-Layout.
@ft
Vielen dank für Deine wertvollen Tipps, ich habe paar von denen mal
umgesetzt, größter Erfolg bisher ist die dualcore Unterstützung im
Medion-Kernel (habe beide Änderungen vorgenommen, mal sehen wie sich das
auf Stabilität und Wärmeentwicklung auswirkt).
Nun zu uBoot:
Habe wie Du sagtest, anstelle von SDK_BUILD_NAND_BOOT eher USE_SATA
verwendet, tatsächlich nutzt er das Environment aus dem Flash, was mich
auch wirklich freut, denn ich habe mittlerweile eine Art multi-boot menu
da gebastelt um schnell mal den NFS-Root fähigen Kernel über tftp zu
holen und ein Gentoo via NFS zu starten...
Auffällig war nun das die Festplatte nicht mehr automatisch
initialisiert wird wie bei SDK_BUILD_NAND_BOOT (welches wophl dort sogar
sein Environment sucht), aber ein expliziter Aufruf der Initialisierung
tut's und eigentlich passt das so eher.
Leider zeigt auch ein mit CFG_64BIT_LBA gebautes uBoot die
Original-Partitionen der internen Platte immer noch falsch an. Werde
wenn Du willst nochmal den output posten, nachedem ich wieder mal neu
boote, momentan "spiele" ich ein bisschen mit dem dual-core Prozessor
beim nativen Kompilieren unter Gentoo, weil sich leider nicht alles
cross-emergen lässt.
Das riecht nach dieser auf 4kB Sektoren ausgerichteten Partitionstabelle
nach DOS-Schema. Das muss ich mir auch erst noch anschauen. Aber da kann
ich im Moment nix zeitnahes versprechen, aber vielleicht kann man in
neueren u-boots dazu was finden.
Aber es sind schon mal schön dass der aktuellere Kernel mit Dual-Core
soweit funktionieren kann.
Die u-boot Kombination USE_SATA plus NAND default hat den Vorteil dass
man noch eine vollwertige Fallback-Firmware im Flash halten kann. Alles
was man dann halt noch braucht ist eine Seriell-Verbindung.
Da gibt es im u-boot noch so ein paar Nettigkeiten mit 32bit Integern,
die müssen halt noch alle aufgebohrt werden, dass geht allerdings besser
mit dem NAS zur Hand. Der Partitionstabellencode rechnet mit zu kurzen
Integern.
Das hat auch U-Boot 1.3.4 in gleicher Form, der Code muss also erst noch
aufgebohrt werden.
Hallo,
ich hab ein kleines Problem.
Wenn ich Dateien in Lib speicher (z. B. Librarys von nzbget) und dann
irgendwann die NAS neu starte, dann sind die kompletten Daten nicht mehr
vorhanden. Ich muss alles neu kopieren.
Weiß einer woran das liegen könnte?
ft schrieb:> Das riecht nach dieser auf 4kB Sektoren ausgerichteten Partitionstabelle> nach DOS-Schema. Das muss ich mir auch erst noch anschauen. Aber da kann> ich im Moment nix zeitnahes versprechen, aber vielleicht kann man in> neueren u-boots dazu was finden.
Ich hatte aml vergangen Tage sogar versucht die Partitionsunterstützung
veon neueren uBoots in 1.1.2 zu back-porten, die unterstützen natürlich
um einiges mehr, bin aber dann doch an einigen größeren Änderungen an
der Code-Architektur gescheitert, hatte mir eher erhofft daß man den
natürlicheren Weg gehen kann, und dieses SoC im aktuellen u-Boot zu
unterstützen. Was Michael Kebe ja auch versucht hat, ist aber gar nicht
so einfach.
> Aber es sind schon mal schön dass der aktuellere Kernel mit Dual-Core> soweit funktionieren kann.
In der tat, irgendwann habe ich ihn in htop auch ackern gesehen,
erstmals ist immer nur der erste beschäftigt, liegt wahrscheinlich auch
am ausgeführten Code...
> Die u-boot Kombination USE_SATA plus NAND default hat den Vorteil dass> man noch eine vollwertige Fallback-Firmware im Flash halten kann. Alles> was man dann halt noch braucht ist eine Seriell-Verbindung.
Sehe ich auch so, war auch von Anfang an mein Vorhaben es irgendwann so
hin zu bekommen (so kenne ich es von der Buffalo Linkstation Pro).
Deswegen bin ich auch noch nicht ganz bereit, die Original-FW ganz zu
schrotten, weil sie ja im Flash ist, ich denke es sollte doch
hinzubekommen sein, ein modifiziertes uBoot, vielleicht auch für die
Original-FW ein modifizierter Kernel mit dualcore Unterstützung in den
Flash zu brennen, und dabei auf einer umpartitionierten Festplatte so
mit degradiertem raid1 wie sie die Original-FW anspricht, beide
betreiben kann.
Dann braucht man am Schluß noch nicht mal UART Zugang, wenn man
vernünftige uBoot-Variablen mit fw_setenv vorher setzt. Na gut, das ist
Glücksache...
So, gehe nun ins Bett, Gute Nacht.
es gibt noch einen auskommentierten Parameter in include/configs/ox820.h
#define CONFIG_LBA48
den sollte man auch mit reinnehmen, da die 1,5-2TB Versionen alle mit
mehr als 24Bit LBA adressieren.
Eine Option, die ich gerade in den u-boot sourcen sehe, wäre es eine
kleine Partition an den Anfang zu legen und den Kernel da einfach blank
draufzulegen.
Allerdings muss man dann halt anders formatieren, damit der Kernel
sequentiell mit aufsteigener Blocknummer abliegt.
1
dd if=uImage of=/dev/sdaX
und als U-Boot Kommando (aktuelles ide device mit Kernel selektiert):
1
ide read <target mem address> <start block> <block count>
Wie das funktionieren kann, müsste man halt erstmal noch genauer
anschauen, wäre aber eine Alternative zur grösseren Änderung am
Partitionstabellen-Code.
Ist erstmal nur eine grobe Idee. Aber
Jetzt am besten noch folgendes in ox820.h im u-boot ergänzen, dann ist
zumindest das zuletzt genannte Kommando in der Lage irgendwo auf der
Platte zu lesen:
@ft:
Habe die zusätzlichen #defines aktiviert, noch zeigt uboot negative
Zahlen, kann ich auch gut verstehen daß da der integer-typ geändert
werden müsste, oder noch mehr. Das schliesst aber nicht aus, dass jetzt
vielleicht auf den "vorderen" Partitionen doch zugegriffen werden
kann...
@Jens:
Würdest Du das mal bitte wieder probieren?
http://www.muresan.de/medion-nas/u-boot.bin.hdd
@Lucian M.
lediglich im Partitionstabellen-Code müssen ein paar ints gegen lbaint_t
ausgetauscht werden, dann kann man zumindest eine kleine Boot-Partition
hinzufügen.
anbei die Änderungen um zumindest die Boot-Partitions-Idee umzusetzen.
Es gibt noch ein paar weitere ints die zu lbaint_t umgebaut werden
müssen, da es noch block_read als Funktionspointer gibt, der ebenfalls
ein lbaint_t benötigt.
hab noch die fürs NAS fehlenden lbaint_t nachgezogen. Den blkcnt hab ich
zurückgeändert, da ja eh für soviel Daten nicht genügend RAM zur
Verfügung steht.
ft schrieb:> hab noch die fürs NAS fehlenden lbaint_t nachgezogen. Den blkcnt hab ich> zurückgeändert, da ja eh für soviel Daten nicht genügend RAM zur> Verfügung steht.
Hmm, mit diesem patch crasht u-boot sobald man die partitionstabelle
anzeigen lassen will mit "ide part 0".
Folgendes hab ich aber im u-boot-1.3.4 gefunden als README.sata
Dokument:
Das wäre zumindest etwas das ohne integer aufbohren funktioniert.
Lediglich sata muss man wohl gegen ide austauschen.
1. SATA usage in U-boot
There are two ways to operate the hard disk
* Read/write raw blocks from/to SATA hard disk
* ext2load to read a file from ext2 file system
1.0 How to read the SATA hard disk's information?
=> sata info
SATA device 0: Model: ST3320620AS Firm: 3.AAD Ser#: 4QF01ZTN
Type: Hard Disk
Supports 48-bit addressing
Capacity: 305245.3 MB = 298.0 GB (625142448 x 512)
1.1 How to raw write the kernel, file system, dtb to a SATA hard disk?
Notes: Hard disk sectors are normally 512 bytes, so
0x1000 sectors = 2 MBytes
write kernel
=> tftp 40000 /tftpboot/uImage.837x
=> sata write 40000 0 2000
write ramdisk
=> tftp 40000 /tftpboot/ramdisk.837x
=> sata write 40000 2000 8000
write dtb
=> tftp 40000 /tftpboot/mpc837xemds.dtb
=> sata write 40000 a000 1000
1.2 How to raw read the kernel, file system, dtb from a SATA hard disk?
load kernel
=> sata read 200000 0 2000
load ramdisk
=> sata read 1000000 2000 8000
load dtb
=> sata read 2000000 a000 1000
boot
=> bootm 200000 1000000 2000000
Ein Nicht-Standard-printf wird im u-boot verwendet daher nicht %lld
sondern %qd
das war falsch im Ausgabecode. Im neuen Jahr werd ich auf meinem eigenen
erst direkt testen können. Aber so kann man es wenigstens mal auf
irgendeinem der Medion-NAS-Geräte überprüfen.
Zum USB-Support:
USB-Support müsste erst explizit eingebaut werden.
Es handelt sich beim OX820 um EHCI mit einem zusätzlichen Startup-Code.
Im neuen u-boot scheint auch erstmal kein passender EHCI Code enthalten
zu sein.
Hallo
Habe mir gestern die 2tb version von aldi geholt, soweit ist alles gut
aber wenn ich vom lappy (wlan) dateien drauf kopiere (ca 6gb) geht
er nicht über 8 mb/s, also dauert so eine dauert ca 15min zu kopieren.
Woran liegt das ?
nas an 1gbit switch, frtitzbox 7570 300mbit, wlan stick 300mbit
Und kann man irgendwie das hinbommen das man auf dem NAS mehrteilige
rars entpacken kann? Denn dann könnt man ja dirket aufs NAS laden und
dort entpacken. Das wäre so Hammergeil wenn das machbar wäre.
Das ist möglich: https://wiki.archlinux.org/index.php/RAR
Und bei solchen Aktionen spielt imho der Doppelkern-Prozessor auch seine
Qualitäten aus, weil parallele Aktionen, Streaming etc. schön
geschmeidig bleiben. Die Marvell-Boxen sind sicherlich schneller, neigen
aber vermutlich eher zum blockieren.
Nebenbei, ich bin der Typ aus dem Arch-Forum, der sich durch das Setup
auf der Iomega HMNHDCD gequält hat. Ist dieselbe Hardware wie die
Medion-Box, nur mit 256 MB RAM, auf 600 Mhz getakteter CPU und komplett
ohne Flash. Die Firmware ist genauso wirr wie bei Medion. Aber immerhin
waren beide Kerne freigeschalten - und der Chip hat auch nicht mehr Luft
und keinen Kühlkörper.
Ich wollte eigentlich auf 750 Mhz gehen, habe aber mittlerweile kein
Interesse mehr dran. Die HDD Performance ist durch DMA hinreichend
abgekoppelt von der CPU. Das ganze System fühlt sich völlig anders an
als 486 oder altes Embedded Zeug, wo die CPU noch jedes Bit von HDD zur
NIC getragen hat. Wenn Medion Zweifel an der Thermik hatte, hätten sie
es wie iomega machen sollen. Gerade bei diesem SoC einfach einen Kern
abzuschalten ist grober Unfug.
Wenn ich euch irgendwie helfen kann, sagt Bescheid. Ansonsten kann ich
nur viel Erfolg wünschen - es lohnt sich! Ich bin immer noch begeistert
von der kleinen Kiste, seit die konfuse Firmware runter ist.
Ciao,
solo
@solo:
zu der Abschaltidee des zweiten Kerns seitens Medion gleiche Auffassung
Ich nehme mal an, dass da entweder etwas vergleichbares wie stage1 des
Medion NAS läuft. Hatte mir das Iomega HMNHDCD Source-Archiv nicht so
genau angeschaut. Mir hatte allerdings die Versionnummer des Kernels
nicht so zugesagt, da eben noch eine Ecke betagter. Aber, da gibt es ja
eine gute Grundlage und um solche Unfeinheiten zu entdecken kann man ja
sowas immer mit dem Original-Kernel der gleichen Version vergleichen.
Ich nehme an, dass mit Kühlung das NAS wohl durchaus mit 2x750MHz laufen
kann. Jedenfalls hat bei mir der Betrieb mit einem 8cm 12V Lüfter an 5V
gezeigt, dass die Festplatte ohne weiteres bei 32°C bleibt und eher noch
sinken kann, da ist eine weitere Wärmequelle mit solch einer Kühlung
sinnvoll, damit der Wärmehaushalt stimmt. Anderenfalls wirds womöglich
der Festplatte sogar noch zu kalt.
@Lucian M.:
heute werd ich da wohl nicht mehr viel zum 64bit Integer finden aber
zumindest zeigt es, dass man da die Anpassung hinbekommen kann.
@Bernd Bick:
schon mal Nutzer: admin / Passwort: 1234 versucht?
Thread beobachten
Seitenaufteilung abschalten