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


von ElektromAn (Gast)


Lesenswert?

Zu dem Thema Overclock :

WarheadSE hat das DING bis 925 MHz geschaft und das für die PogoplugPro. 
Leider ist dieser Stage1 Code unter NDA
Siehe 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1846&hilit=asterisk#p10163

ggf. hilft es auch mal hier zu lesen

aus include/configs/oxnas.h im uBoot
1
/**
2
 * Architecture
3
 */
4
#define CONFIG_ARM926EJS    1
5
#define CONFIG_OXNAS        1
6
//#define CONFIG_OXNAS_RESET_DELAY
7
//#define CONFIG_OXNAS_USE_PCI            /* Enables PCI clock and takes out of reset - needed if require access to static bus */
8
//#define CONFIG_OXNAS_FEEDBACK_PCI_CLKS  /* Feedback PCI clock out 3 to drive PCI core clock - needed if require access to static bus */
9
#define CONFIG_OXNAS_MANUAL_STATIC_ARBITRATION
10
#define CONFIG_OXNAS_USE_SATA   /* Define to include support for SATA disks */
11
12
#define CONFIG_SYS_NO_FLASH     /* Define to NOT include flash support on static bus */
13
14
/* Shall we overclock the CPU? */
15
#define PLL_400MHZ   0x00003014
16
#define PLL_425MHZ   0x00002b10
17
#define PLL_437_5MHZ 0x00003e18
18
#define PLL_466MHZ   0x00003010
19
#define PLL_500MHZ   0x00003410
20
#define PLL_533MHZ   0x00003810
21
//#define OXNAS_OVERCLOCK (PLL_533MHZ)
man beachte ARM926 ...
sowie aus board/oxnas/oxe800/platform.S
1
#ifdef OXNAS_OVERCLOCK
2
        /* Delay so the broken JTAG can get control */
3
        ldr r0, =DELAY_1S
4
        bl delay
5
6
        /* Configure the PLL to run faster */
7
        ldr r1, =SYS_CTRL_PLLSYS_CTRL
8
        ldr r2, =SYS_CTRL_PLLSYS_KEY_CTRL
9
10
        /* 0xBEADFACE -> PLL_KEY */
11
        /* Bypass PLL */
12
        ldr r3, [r1]
13
        ldr r5, =0x20000
14
        orr r3, r3, r5
15
        ldr r4, =0xbeadface
16
        str r4, [r2]
17
        str r3, [r1]
18
19
        /* 0xBEADFACE -> PLL_KEY */
20
        /* Set m,p and s for PLL at 400MHz */
21
        ldr r5, =0xffff0000
22
        and r3, r3, r5
23
        ldr r5, =OXNAS_OVERCLOCK
24
        orr r3, r3, r5
25
        str r4, [r2]
26
        str r3, [r1]
27
28
        /* Wait at least 300uS */
29
        ldr r0, =DELAY_200US
30
        bl delay
31
        ldr r0, =DELAY_200US
32
        bl delay
33
34
        /* 0xBEADFACE -> PLL_KEY */
35
        /* Disable PLL bypass */
36
        ldr r5, =0xfffdffff
37
        and r3, r3, r5
38
        str r4, [r2]
39
        str r3, [r1]
40
#endif // OXNAS_OVERCLOCK

Dann noch die wichtige Stage1 Ausgabe von der Pogoplug
1
Stage-1 Bootloader XCE_STAGE1: 1.1: Tue Feb  8 01:40:26 PST 2011
2
Attempting to set PLLA to 700MHz ...
3
  plla_ctrl0 : 0x0000000A
4
  plla_ctrl1 : 0x000E0000
5
  plla_ctrl2 : 0x001C01A0
6
  plla_ctrl3 : 0x00000016
7
PLLA Set
8
9
Setup memory, testing
10
Reading NAND, Image 0
11
  Hdr len: 0x0001C030
12
  Hdr CRC: 0x39F6D832
13
 OK

von Sven B. (ft-)


Lesenswert?

Nachtrag:

Ich gehe schon davon aus, dass wenn ich ein erstes Image nach dem Aufbau 
produziere, wohl durchaus ein U-Boot 1.1.2 dort einbaue. Halt weil der 
Code nunmal schon auf anderen Geräten läuft.

Das wäre dann genau das was den meisten bereits hilft.

von Sven B. (ft-)


Lesenswert?

@ElektromAn:

Die CPU des PogoPlugPro sowie des Medion NAS ist ein arm11 MPCore.

Einen 926EJS gibt es NICHT als Zweikern-CPU.

Die Datei include/configs/oxnas.h ist vom Vorgänger PogoPlug. Es ist 
nicht die des PogoPlugPro.

so sieht sie beim PogoPlug Pro im U-Boot Source aus:
1
#if (NAS_VERSION == 820)
2
    #include "configs/ox820.h" 
3
#elif (NAS_VERSION == 810)
4
    #include "configs/ox810.h" 
5
#elif (NAS_VERSION == 800)
6
    #include "configs/ox810.h" 
7
#else
8
    #warning 
9
#endif
10
11
#endif

Zur OXNAS Familie gehören mehrere SoC:

OX800 ARM926EJ-S
OX810 ARM926EJ-S
OX820 ARM11 MPCore


Das Medion NAS wie auch PogoPlugPro ist ein OX820.


Folgende Zeile findet sich in configs/ox820.h:
1
#define CONFIG_ARM11        1

Lest den richtigen Source code ansonsten kann ich nur fröhliches Bricken 
wünschen.

von Sven B. (ft-)


Lesenswert?

Hier mal was zur Info zur GPL (was eben gerade den Kernel und U-Boot 
betrifft):

Jeder der einen unter der GPL-stehenden Source Code zum Bauen eines 
Binaries verwendet und diese Binaries an andere gibt, muss auch diesen 
den Zugang zum Source Code ermöglichen.

Hier mal als Zusammenhang wie:

Medion NAS => Medion muss den Source Code bereitstellen
HMNDCE => Iomega muss den Source Code bereitstellen
PogoPlugPro => Cloud Engines muss den Source Code bereitstellen

Ihr könnt euch mal auf www.gpl-violations.org umschauen.

PLXtech muss den Kernel nicht den Medion-Kunden als Source geben. Aber 
Medion muss dieses tun, weil Medion Binaries an besagte Kunden 
weitergibt.

Nur mal so zum Thema NDA und Linux-Kernel. Die GPL erlaubt keine 
Einschränkungen von aussen. Und der Kernel wird ausschliesslich unter 
der GPL verbreitet.

von ElektromAn (Gast)


Lesenswert?

@Sven B.
ICH werde die BOX (Pogoplug) nicht bricken, da ich keine Lust habe 
an uBoot herumzuschrauben.

Das einzige was ich machen werde/würde ich am Kernel zu arbeiten.

Es geht auch anderes das ein System auf der HDD genutzt wird und dafür 
braucht es nur die Unterstüzung des Kernels. Wenn darin ein InitRamFS 
ist kann es ggf. auch ein System auf der Platte starten.

Und was nützt ein #define wenn es nicht verwendet wird.
1
find -type f | xargs grep CONFIG_ARM11
2
./include/configs/ox820.h:#define CONFIG_ARM11        1
aus den PopoplugPro uBoot sourcen.

von Sven B. (ft-)


Lesenswert?

@ElektromAn:

Es ging mir lediglich darum nachzuweisen, dass du da den falschen Source 
Code herangezogen hast. Deswegen der letzte Satz von mir in dem Post als 
allgemeiner Satz, weil wenn dann Leute voreilig auf deinem Post 
aufbauen, dann wird es zu einem Bricken kommen.

Deine Variante ist genau die die ich als Kernel-Tausch-Variante 
beschrieben habe, d.h. Kerńel und Initrd im Flash tauschen. U-Boot und 
stage1 bleiben unangetastet. Nur am U-Boot Environment eventuelle 
Änderungen.

Nur habe ich auch in meinem vorherigen Post den Unterschied zwischen 
PogoPlug und PogoPlugPro darstellen wollen. Ich hoffe es ist mir 
gelungen und dir somit auch der Hardware-Unterschied klar geworden.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> Deine Variante ist genau die die ich als Kernel-Tausch-Variante
> beschrieben habe, d.h. Kerńel und Initrd im Flash tauschen. U-Boot und
> stage1 bleiben unangetastet. Nur am U-Boot Environment eventuelle
> Änderungen.

Hätte aber den Nachteil, das man bei jedem Kernel Update neu Flashen muß 
:(

Sven B. schrieb:
> Nur mal so zum Thema NDA und Linux-Kernel. Die GPL erlaubt keine
> Einschränkungen von aussen. Und der Kernel wird ausschliesslich unter
> der GPL verbreitet.

Wie sieht es mit stage1 aus?

von Max H. (maexlich)


Lesenswert?

Jens D. schrieb:
> Hätte aber den Nachteil, das man bei jedem Kernel Update neu Flashen muß
> :(

das stimmt glaub ich nicht ganz. Theoretisch wäre auch eine art 
Kexec-loader methode möglich. --> kernel + initrd sind nur dazu da einen 
weiteren Kernel per kexec  von der Festplatte zu starten. Den weg schlug 
ich beim Bifferboard ( 
http://www.mikrocontroller.net/articles/Bifferboard ) auch ein, so war 
es auch möglich Kernels zu laden die größer waren als 1Mb :D Man braucht 
nur die init in der initrd so umzuschreiben, dass sie:
1. eine festplatte nach /mnt mountet
2. den kernel von der festplatte lädt
3. die festplatte unmountet
4. den geladenen kernel per kexec ausführt

von BigMerlin (Gast)


Lesenswert?

Hallo zusammen ,

weiß einer von euch warum das aufnehmen von der D-Box via nfs geht das 
abspielen jedoch nicht?

von Jens D. (jedie) Flattr this


Lesenswert?

Max H. schrieb:
> Theoretisch wäre auch eine art
> Kexec-loader methode möglich. --> kernel + initrd sind nur dazu da einen
> weiteren Kernel per kexec  von der Festplatte zu starten.

Naja gut, aber wenn das uBoot direkt machen kann, wäre das doch 
einfacher, oder nicht?

von Max H. (maexlich)


Lesenswert?

mit dem Nachteil, dass wenn mals uboot zerflasht ist kann mer des ganze 
auch gleich als Briefbeschwerer benutzen ^^ außerdem hätten wir dann 
nicht die Probleme wie Dateisystem support in uboot, usb support in 
uboot etc...

Ein mit xfs und usb funktionierender Kernel existiert bereits und es 
wäre theoretisch auch möglich das raid in der init richtig einzurichten, 
sodass man auch von dem normalen Festplattenlayout aus Kernel booten 
kann.

von Jens D. (jedie) Flattr this


Lesenswert?

solo schrieb:
> Wie versprochen hänge ich die ersten 32MB meiner iomega HMNHDCE an.
> Frisch gezogen mit:
>
> dd if=/dev/sda of=iomega_HMNHDCE_first_32mb.img bs=512 count=65536
>
> Jemand mit serieller Konsole sollte das auf eine leere HDD schreiben und
> ins Medion NAS stecken. Das Image enthält GPT-Partitonstabelle, stage1,
> mehrere uboot-kopien mit env's und das Kernel-image.
>
> Falls in der Konsole die SoC-Initialisierung mit 600Mhz auftaucht, habt
> ihr einen guten Startpunkt, was gescheites zu basteln.

Es geht!!!
1
dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536
2
65536+0 records in
3
65536+0 records out
4
33554432 bytes (34 MB) copied, 5.88124 s, 5.7 MB/s

Ausgaben:
1
Stage-1 Bootloader Tue Jan 18 15:00:30 MST 2011
2
Attempting to set PLLA to 600MHz ...
3
  plla_ctrl0 : 0x0000021A
4
  plla_ctrl1 : 0x00480000
5
  plla_ctrl2 : 0x008F008B
6
  plla_ctrl3 : 0x00000154
7
PLLA Set
8
9
Setup memory, testing
10
Reading disk 0, Image 0
11
  Sector : 0x0000009A
12
  Hdr len: 0x0001948C
13
  Hdr CRC: 0xA6FB1209
14
 OK
15
Initialising disks
16
SATA PHY not ready for device 1
17
Detecting SATA busses:
18
Bus 0: Found first device OK
19
  Device 0: Model: ST1500DL003-9VT16L Firm: CC4A Ser#: 5YD5RGDA
20
            Type: Hard Disk
21
            Capacity: 131071.9 MB = 127.9 GB (268435455 x 512)
22
  Device 1: not available
23
Environment successfully read from disk 0 primary image
24
25
26
U-Boot 1.1.2 (Aug 26 2010 - 14:02:09)
27
28
U-Boot code: 60D00000 -> 60D1948C  BSS: -> 60D1D11C
29
RAM Configuration:
30
        Bank #0: 60000000 256 MB
31
SRAM Configuration:
32
        64KB at 0x50000000
33
In:    serial
34
Out:   serial
35
Err:   serial
36
Setting Linux mem= boot arg value
37
38
IDE read: device 0 block # 288, count 1 ... 1 blocks read: OK
39
Hit any key to stop autoboot:  0 
40
PLX>>help
41
?       - alias for 'help'
42
base    - print or set address offset
43
bdinfo  - print Board Info structure
44
bootm   - boot application image from memory
45
bootp   - boot image via network using BootP/TFTP protocol
46
cmp     - memory compare
47
cp      - memory copy
48
crc32   - checksum calculation
49
diskboot- boot from IDE device
50
echo    - echo args to console
51
exit    - exit script
52
ext2load- load binary file from a Ext2 filesystem
53
ext2ls- list files in a directory (default /)
54
go      - start application at address 'addr'
55
help    - print online help
56
ide     - IDE sub-system
57
iminfo  - print header information for application image
58
ledfail - Extinguish (0) or light (1) failure LED
59
loop    - infinite loop on address range
60
md      - memory display
61
mm      - memory modify (auto-incrementing)
62
mtest   - simple RAM test
63
mw      - memory write (fill)
64
nm      - memory modify (constant address)
65
otp    - OTP sub-system
66
ping    - send ICMP ECHO_REQUEST to network host
67
printenv- print environment variables
68
rarpboot- boot image via network using RARP/TFTP protocol
69
reset   - Perform RESET of the CPU
70
run     - run commands in an environment variable
71
saveenv - save environment variables to persistent storage
72
setenv  - set environment variables
73
test    - minimal test like /bin/sh
74
tftpboot- boot image via network using TFTP protocol
75
version - print monitor version
76
PLX>>ide part 0
77
78
Partition Map for IDE device 0  --   Partition Type: DOS
79
80
Partition     Start Sector     Num Sectors     Type
81
    1                    1      -387938129      ee

von Jens D. (jedie) Flattr this


Lesenswert?

Hm. War ein wenig voreilig beim testen. Nun hab ich ja keine system mehr 
auf Platte und kann nun nicht wirklich irgendwas booten.

Nun muß ich mal sehen, wie die das original system aus dem NAND booten 
kann ;)

von Max H. (maexlich)


Lesenswert?

Ein wort --> GEIL :D
dann hat sich die obere Diskusion wohl erledigt^^
Das Tor ist offen =) jetzt kann das nächste Jahr ja kommen :P

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Wie sieht es mit stage1 aus?

Der stage1 ist kein Kernel Bestandteil. Daher sieht es hier eben auch 
anders aus.

Max H. schrieb:
> das stimmt glaub ich nicht ganz. Theoretisch wäre auch eine art
> Kexec-loader methode möglich.

Einmal müssten wir dann definitiv flashen und insbesondere, dass was im 
Flash ist komplett verändern, da ja ein komplett anderes initrd für 
diese Methode benötigt wird.

Das Hauptproblem bei allen diesen Änderungen ist, dass wir aktuell noch 
keine Recovery-Methode haben. Sollte hier beim Flashen der falsche MTD 
beschrieben werden, dann haben wir ebenfalls einen Brick.

Max H. schrieb:
> Theoretisch wäre auch eine art
> Kexec-loader methode möglich. --> kernel + initrd sind nur dazu da einen
> weiteren Kernel per kexec  von der Festplatte zu starten.
Jens D. schrieb:
> Naja gut, aber wenn das uBoot direkt machen kann, wäre das doch
> einfacher, oder nicht?

Wir könnten auch einfach einen SATA-tauglichen U-Boot in den MTD-Block 
schreiben, wo der Kernel liegt. Warum also einen Kernel nehmen, wenn der 
U-Boot genauso gut wäre.

Oder noch simpler einen SATA-stage1 ins MTD, für dessen 8kB ist 
garantiert noch irgendwo Platz ohne was anderes kaputt zu machen.

Und diesen dann von geflashten U-Boot laden und starten.

Der Rest ist dann auf Platte + neuem U-Boot Environment.

Max H. schrieb:
> Ein mit xfs und usb funktionierender Kernel existiert bereits und es
> wäre theoretisch auch möglich das raid in der init richtig einzurichten,
> sodass man auch von dem normalen Festplattenlayout aus Kernel booten
> kann.

Beim XFS habe ich doch schon mal einiges zitiert, dass gerade für die 
heimische Betriebsumgebung ohne USV dieses nicht für alle Umstände 
geeignet ist.

Das verzögerte Schreiben des XFS verträgt eben keine Stromausfälle im 
falschen Moment. Der häufigste Stromausfall wird eben mal das Ziehen vom 
Stecker oder solche Geschichten sein.

Zu dem ist eine kexec-Umgebung ebenfalls nicht so simpel aufzusetzen, da 
wäre ein SATA-stage1 irgendwo anders noch zusätzlich im Flash 
untergebracht noch eine Runde einfacher und das Recovery von einer 
defekten Firmware auf Festplatte gespeichert mit RAW-Sektorzugriff nun 
mal auch leicht zu reparieren.

Die Geschichten mit dem zerschossenen RAID bzw. XFS kann man ja hier 
hinlänglich lesen.
Der Name RAID ist "Redundant Array of Inexpensive Disks". Das Wort 
"redundant" ist bei dem Setup des Medion NAS nicht gegeben. Also kein 
RAID. Den Begriff JBOD ("just a bunch of disks") würde ich da schon 
akzeptieren.

von Jens D. (jedie) Flattr this


Lesenswert?

Kann mir jemand ein printenv vom original system geben? (Hätte ich mal 
vorher sichern sollen ;)

Brauche die uBoot Befehle, um das Original System aus den NAND laden zu 
können...

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Es geht!!!

Perfekt, dann bleibt das Flash unangefasst.
Das ist die Optimum-Lösung.

Dann werde ich auch mit genau dem Setup bei meinem NAS testen.

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Brauche die uBoot Befehle, um das Original System aus den NAND laden zu
> können...

bootcmd=run boot_nand
load_nand=nboot 61000000 0 440000
boot=bootm 61000000
boot_nand=run load_nand boot

Habs gerade aus meinem MTD3 Backup extrahiert.

von Max H. (maexlich)


Lesenswert?

schon gut ich gebe mich geschlagen ;) mit der sata-stage1 
Bootmöglichkeit die Jens getestet hat existiert jetzt ja auch eine 
Recovery Möglichkeit =)

von Jens D. (jedie) Flattr this


Lesenswert?

Danke, habe ich gerade auch im Wiki bei P89626: uboot env gefunden.

Leider hab ich nun kein nboot :( Siehe help Ausgaben bei
Beitrag "Re: Alles Rund um den MEDION LIFE P89626 NAS"

Jemand eine Idee, wie man vielleicht ein ganzes System per FTP booten 
könnte? Wäre generell mal gut zu wissen.

Oder wie könnte ich das original uBoot wieder her bekommen?

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> der wie könnte ich das original uBoot wieder her bekommen?

Die ersten 32MB plätten

dd if=/dev/zero of=/dev/<platte> bs=512 count=65536

So einfach kommt das NAND wieder hoch.

von Lucian M. (lucian_m)


Lesenswert?

Max H. schrieb:
> schon gut ich gebe mich geschlagen ;) mit der sata-stage1
> Bootmöglichkeit die Jens getestet hat existiert jetzt ja auch eine
> Recovery Möglichkeit =)

Ja, und das ist alles wirklich sehr erfreulich. Für ein recovery muß man 
wohl dann wenn man keinen UART-Zugang hat die Platte wieder heraus holen 
und dise ersten Sektoren wieder löschen? Willeicht nur den stage1-Teil? 
Könnten wir diesen dump den solo freundlicherweise zur Verfügung 
gestellt hat auf das nötigste reduzieren?

von SP()()KY (Gast)


Lesenswert?

auch mein schreiben an Medion bzgl. Single Core Nutzung ist angekommen 
^^

=========================================

Sehr geehrter Herr ...,

vielen Dank für Ihre Mitteilung.

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.

Ich wünsche Ihnen einen guten Rutsch ins neue Jahr.

Freundliche Grüße aus Essen
Medion Technologie Center
Daniel Dildrop

=========================================

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> Die ersten 32MB plätten
>
> dd if=/dev/zero of=/dev/<platte> bs=512 count=65536
>
> So einfach kommt das NAND wieder hoch.

Ja gut, dann muß ich aber mal eben die Platte wieder ausbauen und am PC 
an stöpseln :(

Ideen was man ohne ausbau tun kann? (Geht nämlich jetzt nicht auf die 
schnelle :)

von Sven B. (ft-)


Lesenswert?

Lucian M. schrieb:
> Ja, und das ist alles wirklich sehr erfreulich. Für ein recovery muß man
> wohl dann wenn man keinen UART-Zugang hat die Platte wieder heraus holen
> und dise ersten Sektoren wieder löschen? Willeicht nur den stage1-Teil?
> Könnten wir diesen dump den solo freundlicherweise zur Verfügung
> gestellt hat auf das nötigste reduzieren?

Das ist auch meine Idee, wir nehmen das Image als Information und bauen 
darauf dann das was wir brauchen auf.

Ja man kann es sicherlich mit einem Build-Kit kleiner gestalten.

Der stage1 und u-boot ist wichtig. Daher reicht es bis zum Sektorstart 
des Kernels.

Sektoren 0-1289 und eine neue Partitionstabelle dürften reichen.

Für die Leute die 600MHz statt Lüfter wollen tut der stage1 von der 
HMNDCE.

Der U-Boot hat ext2load drin. Also denkt an Partition ab Sektor 1290 mit 
Ext2/Ext3 und 3,8GB für Arch RootFS.

Die gängige Lösung wäre somit praktisch fertig. Muss nur noch einer mal 
umsetzen und die Schritte zusammenschreiben.

von Michael K. (michaelkebe)


Lesenswert?

Endlich konnte ich mal wieder lesen was hier passiert ist. Und das sind 
ja wunderbare Neuigkeiten.


Damit ich das richtig Verstehe, ist jetzt folgendes Möglich?

1) Jemand könnte jetzt ein Basis-System installieren (Debian oder ARM 
Linux), anschliessend die ersten paar MB von der Platte dd'n und für 
andere zur Verfügung stellen.

2) Diese können sich einfach per Telnet mit einer unangetasteten Box 
verbinden und das Image der ersten paar MB über einen angeschlossenen 
USB-Stick dann wiederum auf die interne Platte schreiben und haben nach 
einem Reboot das gleiche Basis-System.

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Ideen was man ohne ausbau tun kann? (Geht nämlich jetzt nicht auf die
> schnelle :)

mw
ide write

und dann U-Boot zum Überschreiben des Sektors 34 verwenden und den 
Sektor 57088.

von Sven B. (ft-)


Lesenswert?

mw l 0x60000000 0 128
ide write 0x60000000 22 1
ide write 0x60000000 df00 1

Damit werden dann einfach mal Nullen auf die jeweils ersten Sektoren des 
stage1 auf der Platte geschrieben.

von Sven B. (ft-)


Lesenswert?

Michael Kebe schrieb:
> 1) Jemand könnte jetzt ein Basis-System installieren (Debian oder ARM
> Linux), anschliessend die ersten paar MB von der Platte dd'n und für
> andere zur Verfügung stellen.

Da wir nicht alle die gleichen Platten haben, könnte man das besser als 
kleines Bash-Skript mit Daten-Image bauen, was dann die Partitionen 
passend neu erstellt.

Michael Kebe schrieb:
> 2) Diese können sich einfach per Telnet mit einer unangetasteten Box
> verbinden und das Image der ersten paar MB über einen angeschlossenen
> USB-Stick dann wiederum auf die interne Platte schreiben und haben nach
> einem Reboot das gleiche Basis-System.

Genauso nur eben besser mit Bash-Skript.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> mw
> ide write
>
> und dann U-Boot zum Überschreiben des Sektors 34 verwenden und den
> Sektor 57088.

Verstehe, aber so auf die schnelle weiß ich nicht wie ich das machen 
sollte.

Hab aber eine Lösung gefunden, ein uBoot mit nboot per TFTP laden und 
booten:
1
tftp 0x61000000 u-boot2470376.bin.hdd;go 61000000
2
nboot 61000000 0 440000; bootm 61000000

uBoot von Beitrag #2470376 hat ja nboot ;)

Läuft wieder, mit usb_key_func ;) So kann ich die Platte neu machen ;)

von Sven B. (ft-)


Lesenswert?

Die Medion-Firmware ist allerdings inkompatibel mit dem SATA-Boot, weil 
sie grosse Teile der Boot-Umgebung zerstören würde.

Aber wir haben zumindest einen Weg für ArchLinux, Debian usw.

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> uBoot von Beitrag #2470376 hat ja nboot ;)

Genau der mit aktiven SATA bei NAND-Boot. ;)

Ich habe ein blankes HDD-Image erstellt. Wenns läuft, dann braucht es 
nur noch einen Kernel.

Allerdings kann ich noch nicht sagen, ob ich den stage1 richtig auf 
750MHz geschafft hab einzustellen.

Ein U-Boot mit SATA-Boot ist drin und default environment. Also bei 
Einsatz erstmal das NAND-U-Boot-Environment wegen der MAC-Adresse 
auslesen.

von Sven B. (ft-)


Angehängte Dateien:

Lesenswert?

Jetzt auch das Archiv dazu

install.sh /dev/sda

aber nur auf dem NAS

Partitionen werden vom Skript gelöscht.

kernel-install.sh /dev/sda kernel-image

ebenfalls so nur auf dem NAS.

von Sven B. (ft-)


Lesenswert?

Zum fehlenden Kernel
den installiert man so auf dem NAS

./kernel-install.sh /dev/sda uImage

Den Kernel habe ich noch nicht in passender Form aber vielleicht kann 
jemand mit laufendem Arch Linux Kernel mal die Datei /proc/config.gz 
auslesen und posten wenn die Datei vorhanden ist.

von Sven B. (ft-)


Angehängte Dateien:

Lesenswert?

Hier nochmal in der 600MHz Variante.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> Jetzt auch das Archiv dazu

Ich werde es mal testen.

Btw. mach doch ein github Projekt draus, dann können mehrere Dran 
arbeiten. Kannst gern auch https://github.com/jedie/NAS7820-Tools forken 
und einfügen...

von Jens D. (jedie) Flattr this


Lesenswert?

Jens D. schrieb:
> Sven B. schrieb:
>> Jetzt auch das Archiv dazu
>
> Ich werde es mal testen.
>
> Btw. mach doch ein github Projekt draus, dann können mehrere Dran
> arbeiten. Kannst gern auch https://github.com/jedie/NAS7820-Tools forken
> und einfügen...

Schon passiert: 
https://github.com/jedie/NAS7820-Tools/tree/master/sataboot
Dennoch forken und weiter arbeiten ;)

von Max H. (maexlich)


Lesenswert?

Oder einfach die skripts von  WarheadsSE verwenden ;)

von Sven B. (ft-)


Lesenswert?

@Jens D.

passt schon unter gleichen Namen ft- hab ich mal einen github.com 
Account angelegt.

Der U-Boot mit Sicherheit noch nicht die finale aber man kriegt damit 
schon was hin.

von Sven B. (ft-)


Lesenswert?

Max H. schrieb:
> Oder einfach die skripts von  WarheadsSE verwenden ;)

Der Kernel muss für die Festplatten-LEDs ein paar Patches haben, die 
noch sein müssen. Aber das ist auch eine Variante da hast Recht.

Allerdings dürfen wir das Medion NAS hardwaretechnisch unverändert nicht 
so hoch getaktet laufen lassen.

von Sven B. (ft-)


Lesenswert?

Im Archiv von WarheadsSE findet sich alles von 700-850MHz in 50MHz 
Schritten. Dann braucht es ja nur noch das eine Exemplar mit 600MHz fürs 
Untertakten.

Der Kernel ist für die Ungeduldigen auch erstmal was, wenn die nopci 
Variante verwendet wird.

Die Partitionstabelle die geschrieben wird, könnte passen allerdings 
kann ich es nicht ohne weiteres sagen.

Somit haben wir also eine erste Basis mit ArchLinux die man ohne TFTP 
Boot installieren kann.

@Jens D.

Du hast doch gerade eh eine geplättete Platte gehabt, dann hättest 
gleich das erste voll lauffähige ArchLinux-System.

von Lucian M. (lucian_m)


Lesenswert?

Sven B. schrieb:
> Der Kernel muss für die Festplatten-LEDs ein paar Patches haben, die
> noch sein müssen. Aber das ist auch eine Variante da hast Recht.

Was spricht denn momentan gegen den Medion-Kernel mit aktivierter 
dualcore Unterstützung?

von Sven B. (ft-)


Lesenswert?

Nichts ausser der Konfig bezüglich der bootargs. Die kann man aber 
anpassen.


Ich habe ja auch nicht gesagt, dass es abgeschlossen ist. Nur das eine 
erste Methode für die Ungeduldigen gefunden ist.


Ich möchte vom Prinzip her auch den Kernel mit den 
Festplatten-LED-Anpassungen nutzen können. Ist nun mal doch schöner wenn 
man die Festplatten-Aktivität auch sieht.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> @Jens D.
>
> Du hast doch gerade eh eine geplättete Platte gehabt, dann hättest
> gleich das erste voll lauffähige ArchLinux-System.

Das hab ich mir auch gedacht ;)
1
./install.sh /dev/sda
2
3
+ dd if=/dev/zero of=/dev/sda bs=512 count=65536
4
65536+0 records in
5
65536+0 records out
6
33554432 bytes (34 MB) copied, 6.73036 s, 5.0 MB/s
7
+ dd if=signature.bin of=/dev/sda bs=512 seek=57080
8
0+1 records in
9
0+1 records out
10
20 bytes (20 B) copied, 0.00239615 s, 8.3 kB/s
11
+ dd if=stage1.bin of=/dev/sda bs=512 seek=34
12
16+1 records in
13
16+1 records out
14
8472 bytes (8.5 kB) copied, 0.00894974 s, 947 kB/s
15
+ dd if=stage1.bin of=/dev/sda bs=512 seek=57088
16
16+1 records in
17
16+1 records out
18
8472 bytes (8.5 kB) copied, 0.00297727 s, 2.8 MB/s
19
+ dd if=u-boot-1.1.2-sata.wrapped of=/dev/sda seek=154 bs=512
20
197+1 records in
21
197+1 records out
22
101224 bytes (101 kB) copied, 0.0232166 s, 4.4 MB/s
23
+ dd if=u-boot-1.1.2-sata.wrapped of=/dev/sda seek=57208 bs=512
24
197+1 records in
25
197+1 records out
26
101224 bytes (101 kB) copied, 0.0224716 s, 4.5 MB/s
27
28
29
30
./kernel-install.sh /dev/sda /boot/uImage.nopci  
31
32
+ dd if=/boot/uImage.nopci of=/dev/sda seek=1290 bs=512
33
4218+1 records in
34
4218+1 records out
35
2159948 bytes (2.2 MB) copied, 0.546008 s, 4.0 MB/s
36
+ dd if=/boot/uImage.nopci of=/dev/sda seek=58344 bs=512
37
4218+1 records in
38
4218+1 records out
39
2159948 bytes (2.2 MB) copied, 0.509667 s, 4.2 MB/s
40
41
42
Restarting system.
43
44
45
Stage-1 Bootloader Tue Aug  9 16:44:00 CST 2011
46
Attempting to set PLLA to 750MHz ...
47
  plla_ctrl0 : 0x0000000A
48
  plla_ctrl1 : 0x000F0000
49
  plla_ctrl2 : 0x001D01A0
50
  plla_ctrl3 : 0x00000017
51
PLLA Set
52
53
Setup memory, testing
54
Reading NAND, Image 0
55
  Hdr len: 0x0001A94C
56
  Hdr CRC: 0xF0019DAC
57
 OK
58
59
60
U-Boot 1.1.2 (Jun 24 2011 - 09:41:57)
61
62
U-Boot code: 60D00000 -> 60D1A94C  BSS: -> 60D1F004
63
RAM Configuration:
64
        Bank #0: 60000000 128 MB
65
SRAM Configuration:
66
        64KB at 0x50000000
67
NAND:128 MiB
68
In:    serial
69
Out:   serial
70
Err:   serial
71
Setting Linux mem= boot arg value
72
Hit any key to stop autoboot:  0

Sieht nicht so aus, als wenn das richtig wäre...



btw. wie ist das mit der Sektor größe 512 bs. 4096 und dd? Die Angaben 
bei 
http://iomega.nas-central.org/wiki/Stock_Configuration_%28Home_Media_CE%29#.27Unused_space.27_.28first_32_MiB.29 
sind ja in Sektoren...

von Sven B. (ft-)


Lesenswert?

@Jens D.

Die Sektorengrösse ist bei dd unbedeutend. BS = Block Size

Probiere doch mal das Skript von WarheadsSE aus. Lediglich die symlinks 
müsstest du ändern

ln -sf stage1/stage1.wrapped750 stage1.wrapped
ln -sf uImages/uImage.nopci uImage

im Skript dann noch disk=/dev/sdc anpassen.

und dann "./disk_create" aufrufen.

Der ROM-Code und stage1 denken in 512 Byte Sektoren also dem Legacy Mode 
den Festplatten nach dem Reset einschalten.

Eventuell muss ich noch erst ein bisschen stage1 bauen üben. Daher mal 
mit dem Skript.

von Sven B. (ft-)


Angehängte Dateien:

Lesenswert?

Mir ist an dem Skript von WarheadsSE aufgefallen, dass er ein paar Bytes 
des MBR schreibt. Ich habe den ersten Sektor mal mit eingepflegt.

Ich nehme mal an das Perl nicht so ohne weiteres auf dem NAS erreichbar 
sein wird.

von Sven B. (ft-)


Lesenswert?


von Sven B. (ft-)


Lesenswert?

Das Skript nutzt die Binaries erstmal von WarheadsSE. Allerdings ohne 
Perl damit nur coreutils verwendet werden. Ich habe das Perl-Segment von 
WarheadsSE in ein mbr.bin-Binary umgewandelt.

von Jens D. (jedie) Flattr this


Lesenswert?

Ich hab nochmal das gemacht:

> dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536

Nun möchte ich mal normale MBR Partitionen mit fdisk erstellen und dann 
mal sehen, ob man ArchLinux booten kann. Danach kann man ja mal 
probieren erstmal nur die Kopie von uBoot zu überschreiben, siehe:

http://iomega.nas-central.org/wiki/Stock_Configuration_%28Home_Media_CE%29#.27Unused_space.27_.28first_32_MiB.29

Demnach gibt es jeweils von stage1, uBoot und uImage eine zweite Kopie, 
bei Sektor 57088, 57208 und 58344...
Die kann man ja als erstes versuchen zu überschreiben...


Nun zu fdisk. Ich habe nun also das gemacht:
o   create a new empty DOS partition table
n   add a new partition
Partition number (1-4, default 1): 1
First sector (2048-2930277167, default 2048): +32M
Last sector, +sectors or +size{K,M,G} (65536-2930277167, default 
2930277167): +20G

Dann sieht das so aus:
1
   Device Boot      Start         End      Blocks   Id  System
2
/dev/sda1           65536    42008575    20971520   83  Linux

Dürfte doch ok sein, oder?

von Sven B. (ft-)


Lesenswert?

Der Start ist erstmal in Ordnung.

Der stage1 kann vom Prinzip her ja zum Testen auch erstmal drin bleiben 
und nur U-Boot tauschen. Der muss nämlich wegen der RAM-Grössen-Angabe 
geändert werden oder es klappt per Bootargs.


Ich nehme an den Abschnitt aus dem MBR ist das was ich nicht hatte.

von Jens D. (jedie) Flattr this


Lesenswert?

Jens D. schrieb:
> Dann sieht das so aus:   Device Boot      Start         End      Blocks   Id 
System
> /dev/sda1           65536    42008575    20971520   83  Linux
>
> Dürfte doch ok sein, oder?

Hm. Doch wie macht man weiter?

Erstellt man eine neue Parition schlägt fdisk als startsektor 2048 vor, 
was natürlich nicht geht.

Ob es vielleicht Sinn macht eine erste ungenutzte fake Parition zu 
erstellen?

/dev/sda1            2048       65535       31744   ??  ?????
/dev/sda2           65536    42008575    20971520   83  Linux

Doch welchen Typ nehmen? "0" == Empty oder "da" == Non-FS data ?

von Sven B. (ft-)


Lesenswert?

Nein 2048 darfst nicht nehmen. Einfach 42008576 eingeben als First 
Sector.

Also ab der zweiten Partition einfach den Vorschlag übergehen und den 
Ende-Sektor der letzten Partition + 1 eingeben.

von Jens D. (jedie) Flattr this


Lesenswert?

Also "0" == Empty wäre eh keine gute Idee ;)

Sieht nun so aus:
1
   Device Boot      Start         End      Blocks   Id  System
2
/dev/sda1           65536    42008575    20971520   83  Linux
3
/dev/sda2        42008576    83951615    20971520   83  Linux
4
/dev/sda3        83951616    85000191      524288   82  Linux swap / Solaris
5
/dev/sda4        85000192  2930277167  1422638488   83  Linux
Doch wenn man immer bei "Start" +1 vom letzten "End" nimmt, hat man dann 
sicher immer "gerade" Sektoren (von wegen 4096K pro Sektor) ???

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Doch wenn man immer bei "Start" +1 vom letzten "End" nimmt, hat man dann
> sicher immer "gerade" Sektoren (von wegen 4096K pro Sektor) ???

Teile einfach durch 8 dann weist du es.

Die Sektoren sind zwar nur 4kB = 4096 Byte aber das ist auf der 
Festplatte. Das Thema des Alignments kommt daher, dass Dateisysteme auch 
in Blöcken denken, die grösser als ein Sektor sind. Und wenn man diese 
auf die 4kB Sektoren der Platte abstimmt, dann gibt es maximale 
Leistungsfähigkeit.

Anmerkung: Ich habe mal versucht, ein Partitionierskript zu bauen mit 
Hilfe von parted. Die erste Partition definitiv in Reichweite des 
U-Boot.

von Sven B. (ft-)


Lesenswert?

Deine Partitionstabelle ist aber soweit in Ordnung. Alle 
Partitionsstarts sind ganzzahlige Vielfache von 8.

von Jens D. (jedie) Flattr this


Lesenswert?

parted ist aber beim Original system und auch nicht beim ArchLinux out 
of the box dabei... Kann man bei archlinux natürlich nach installieren 
;)


Tja, schade... Nach dem ich fdisk gemacht habe, startet uBoot nicht mehr 
von Platte :(

Wie kann man prüfen, ob die richtigen Daten an der richtigen Stelle noch 
liegen? Bzw. Wie kann man das dd von iomega_HMNHDCE_first_32mb.img so 
abändern, das die Partitionstabelle nicht wieder überschreiben werden? 
Würde ein seek=1 reichen?

Gut, ich kann eine Sicherung anlegen, mit:

> dd if=/dev/sda of=mbr_sicherung bs=512 count=1

Dann:

> dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536

und zurück spielen, mit:

> dd if=mbr_sicherung of=/dev/sda bs=512 count=1

von solo (Gast)


Lesenswert?

Jens D. schrieb:
> Es geht!!!
Jippie! Und gleich bis zum U-Boot-Prompt, wie ich vermutet hatte. Ihr 
könnt das ..._first_32MB-Image verkleinern, indem ihr die kernel images 
am ende abschneidet.

Ein Tipp noch: Ich hab ewig Zeit damit verplempert, nach dem 
Partitionieren immer wieder eine unbootbare Platte zu haben. Der 
Perl-Abschnitt in WHSE'S Skript ist wichtig. Irgendwas um den MBR herum 
ist auch wichtig - ich hab das aber nicht genau eingrenzen können, bevor 
mir die Energie ausging. Nehmt zum Partitionieren parted oder sgdisk und 
macht eine GPT drauf - dann interessiert der MBR nicht.

Ich hab mich hier wegen akutem schlechten Gewissen eingeklinkt, weil ich 
nicht mehr genug Antrieb hatte, den Iomega-HMNHDCE-Prozess zu 
dokumentieren. Das ist aber notwendig, um die User-Basis für ArchLinux 
auf diesem SoC groß genug zu bekommen, damit genug Motivation für die 
Anpassung neuer Kernels entsteht. PLX wird uns da im Stich lassen.

Ciao,

solo

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> Mir ist an dem Skript von WarheadsSE aufgefallen, dass er ein paar Bytes
> des MBR schreibt. Ich habe den ersten Sektor mal mit eingepflegt.

Das könnte der Grund sein, warum das bei mir nun nicht mehr klappt!

von Jens D. (jedie) Flattr this


Lesenswert?

Ihr meint den Teil:
1
perl <<EOF | dd of="$disk" bs=512
2
    print "\x00" x 0x1a4;
3
    print "\x00\x5f\x01\x00";
4
    print "\x00\xdf\x00\x00";
5
    print "\x00\x80\x00\x00";
6
    print "\x00" x (0x1b0 -0x1a4 -12 );
7
    print "\x22\x80\x00\x00";
8
    print "\x22\x00\x00\x00";
9
    print "\x00\x80\x00\x00";
10
EOF

Kenne mich leider nicht mit perl aus. Weiß also nicht was da genau 
passiert. Auf der anderen Seite, könnte man das irgendwo machen, wo perl 
installiert ist und dann per dd in einer Datei schreiben und gut...

Eigentlich haben wir die Daten ja in iomega_HMNHDCE_first_32mb.img

Wenn die Beispiele bei 
http://wiki.ubuntuusers.de/shell/dd#MBR-Boot-Loader-und-Partitionstabelle-sichern 
stimmen, ist der MBR 446 Bytes groß, danach kommt die 
Partitionstabelle...

Ich teste das mal so:

eigene MBR + Partitionstabelle sichern:

> dd if=/dev/sda of=ersten_512_bytes bs=512 count=1

Dann:

> dd if=iomega_HMNHDCE_first_32mb.img of=/dev/sda bs=512 count=65536

Original sichern:

> dd if=/dev/sda of=nur_mbr bs=446 count=1

eigene MBR + Partitionstabelle zurück:

> dd if=mbr_sicherung of=/dev/sda bs=512 count=1

nur MBR aus iomega_HMNHDCE zurück:

> dd if=nur_mbr of=/dev/sda bs=446 count=1

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Das ist aber notwendig, um die User-Basis für ArchLinux
> auf diesem SoC groß genug zu bekommen, damit genug Motivation für die
> Anpassung neuer Kernels entsteht. PLX wird uns da im Stich lassen.

Darum bin ich ja froh, dass wir zumindest von dem Geräteherstellern die 
an die Kunden verkaufen den Source vom Kernel geben müssen.

Wir haben ja mittlerweile von Cloud Engines, Iomega und Medion 
Kernel-Sourcen bekommen, da haben wir auf jeden Fall genügend Quellen.

Allerdings beim Kernel-Config durchschauen beim Medion-Kernel. Da hab 
ich gerade gedacht mich tritt ein Pferd als ich die einkompilierten 
Joystick-Treiber gesehen habe. Joystick am NAS mal ehrlich.

Jens D. schrieb:
> Kenne mich leider nicht mit perl aus. Weiß also nicht was da genau
> passiert. Auf der anderen Seite, könnte man das irgendwo machen, wo perl
> installiert ist und dann per dd in einer Datei schreiben und gut...

Nimm das mbr.bin aus dem Repo von mir. 
https://github.com/ft-/NAS7820-Tools/sataboot.

Das sind 512 Byte aber kannst ja auch "dd if=mbr.bin of=/dev/sda 
count=446 bs=1" schreiben. Hatte ja gesagt, dass ich das Perl-Skript in 
ein Binary umgewandelt habe.

von Sven B. (ft-)


Lesenswert?

Das Parted hatte ich auf dem System gesehen, aber wohl wieder an einer 
Stelle erst verfügbar, wenn das regulare System bootet.

von Jens D. (jedie) Flattr this


Lesenswert?

Jens D. schrieb:
> Ich teste das mal so:

Das ist es! Nun kommt wieder der iomega uBoot zum Vorscheinen. 
Allerdings bringt ext2ls hier auch nichts :(

Außerdem kann ich den Kernel per TFTP nicht ganz booten: 
http://pastie.org/3092786 (Der normalerweise aber klappt)

Mit dem Kernel aus iomega_HMNHDCE_first_32mb.img will es auch nicht:
1
...
2
[    2.300000] mice: PS/2 mouse device common for all mice
3
[    2.300000] md: linear personality registered for level -1
4
[    2.300000] md: raid0 personality registered for level 0
5
[    2.300000] md: raid1 personality registered for level 1
6
[    2.400000] device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com
7
[   �Stage-1 Bootloader Tue Jan 18 15:00:30 MST 2011
8
Attempting to set PLLA to 600MHz ...
9
...

Aber die Partitionen sind noch da ;)

von Sven B. (ft-)


Lesenswert?

Problem ist der Iomega U-Boot setzt eine zu hohe RAM-Grösse. Somit 
schlägt ein Booten zwangsläufig fehl, weil der Kernel die RAM-Grösse 
nicht selbst bestimmt.

ext2ls funktioniert bei deiner 20GB Partition nicht, weil der U-Boot im 
ext2 Lese-Code nur bis 4GB adressieren kann.

Ich habe zum makepartitions.sh jetzt mal auch ein parted gelegt. Benutzt 
nur libs die auch im USB-Spezialboot verfügbar sind.

Schreib mal in die bootargs "mem=128M" dazu.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> Problem ist der Iomega U-Boot setzt eine zu hohe RAM-Grösse. Somit
> schlägt ein Booten zwangsläufig fehl, weil der Kernel die RAM-Grösse
> nicht selbst bestimmt.
Stimmt. Dann sind wir wieder an der gleichen Stelle, das wir ein 
funktionierenden uBoot brauchen :(

Sven B. schrieb:
> ext2ls funktioniert bei deiner 20GB Partition nicht, weil der U-Boot im
> ext2 Lese-Code nur bis 4GB adressieren kann.
Ah, ok. Das wäre bei mir auch der Fall.

Wenn wir also bei einem Kernel Update nicht per dd nach /dev/sda 
schreiben wollen, dann sollten wir eine erste Partition erstellen, die 
nur für den Kernel ist. Vielleicht eine kleine ext3 Partition, die wir 
nach /boot mounten?



Ich für meinen Teil, verschiebe weitere Tests auf nächstes Jahr ;)

von Sven B. (ft-)


Lesenswert?

@Jens D.

habe gerade mit den u-boot und stage1 Binaries von WarheadsSE ein 
update.sh gebaut, was den u-boot und stage1 austauschen kann.

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Wenn wir also bei einem Kernel Update nicht per dd nach /dev/sda
> schreiben wollen, dann sollten wir eine erste Partition erstellen, die
> nur für den Kernel ist. Vielleicht eine kleine ext3 Partition, die wir
> nach /boot mounten?

Davon rede ich doch die ganze Zeit, irgendwas kleineres. Entweder eine 
4GB Partition oder nur eine für den Kernel und ein paar bedeutsame 
Dateien wie initrd.

@all

Ich versuche gerade mal, ob der Medion-Kernel nicht zu verhackt ist. 
Ansonsten werde ich mir mal den Iomega-Source (gleiche Kernel-Version) 
vornehmen und schauen was fehlt.

von Jens D. (jedie) Flattr this


Lesenswert?

Einen Kernel brauchen wir doch erstmal nicht, sondern ein uBoot... Der 
ArchLinux nopci Kernel läuft ja normalerweise...

von Sven B. (ft-)


Lesenswert?

@Jens D.

Für die meisten wird das, was jetzt zur Verfügung steht, ausreichen. Ich 
bin nur neugierig, was da noch so umtriebiges geschehen ist. Man weiss 
ja nie wann man die Firmware wieder mal zu Gesicht bekommt.

Danach werd ich auch schauen, was ich wirklich auf Dauer haben will.

Ein U-Boot könnte man auch erstmal von WarheadsSE auf die Platte 
schreiben, dann haben wir einen passenden U-Boot auf der Platte.

Schau ins Repo bei mir da liegt ein u-boot von WarheadsSE, dass zum 
Medion NAS passen wird, ist von WarheadsSE's PogoPlugPro 
ArchLinux-Anpassungen.
(PogoPlugPro 128MB, Medion NAS 128MB)

Alles weitere ist nur Gimmick und muss nun mal nicht von allen gemacht 
werden. (neuerer U-Boot usw.)

Ich hab gleich nochmal ein update-uboot.sh Skript gebaut.

von Sven B. (ft-)


Lesenswert?

Medion Kernel lässt sich noch gut entschlacken. Medion-Image ca. 5MB mit 
initrd drin. Angepasstes Image ca. 1,8MB. Für ein initrd Boot ideal.

Vielleicht baue ich ja ein pivot_root System mit ext2 o. ext3 Partition 
als Start-Partition, dass wär mal einfacher zu warten als jedes initrd.

von Tim Friedrich (Gast)


Lesenswert?

Ich habe mir glaube heute das NAS zerschossen. Gibt es eine Möglichkeit 
die alte (neue) Firmware per USB draufzuspielen? Also ich habe es mit 
der NSA210 Firmware probiert (und natürlich das check file geändert) und 
da bleibt er zumindest bei einem blinken der blauen LED stehen. Wenn ich 
gar nicht den stick reinmache, also normal boote, kommt er bis nach der 
Initialisierung vom USB und dann wird die blaue LED rot. In diesen 
Zustand bleibt er dann...

von solo (Gast)


Angehängte Dateien:

Lesenswert?

Den iomega-Kernel hab ich jetzt seit Wochen mit Arch laufen. Ich hänge 
noch die lib/modules zum reinkopieren ins rootfs an. Das nur, falls er 
mit dem auf 128MB korrigierten Startparametern bei euch bootet und ihr 
Verwendung dafür habt. Die LED funktionieren nicht.

Das ist vorerst alles, was ich für euch tun kann. Das wichtigste ist 
imho jetzt, einen aktuellen 3.1er Kernel zum Laufen zu bringen. Dann 
dürfen wir uns noch lange über aktuelle Software auf unseren Kisten 
freuen. Wenn da jemand WHSE und redsquare unterstützen kann... imho 
wichtiger als die u-boot- und stage1-Spielereien.

@Sven B., den Unermüdlichen
Vielen Dank für deine Skripterei. Das ist das, was ich nicht gut kann. 
Ich werde das auf dem iomega testen und vielleicht kriegen wir eine 
Anleitung vom Stecken eines präparierten USB-Sticks am Neugerät bis zum 
laufenden ArchLinux hin.

Ciao,

solo

von Sven B. (ft-)


Lesenswert?

Tim Friedrich schrieb:
> Ich habe mir glaube heute das NAS zerschossen. Gibt es eine Möglichkeit
> die alte (neue) Firmware per USB draufzuspielen? Also ich habe es mit
> der NSA210 Firmware probiert (und natürlich das check file geändert) und
> da bleibt er zumindest bei einem blinken der blauen LED stehen. Wenn ich
> gar nicht den stick reinmache, also normal boote, kommt er bis nach der
> Initialisierung vom USB und dann wird die blaue LED rot. In diesen
> Zustand bleibt er dann...

Wenn es wirklich die Firmware aufgespielt hat

NSA210 Firmware ist die falsche Firmare. Da hat man Glück wenns 
überhaupt noch irgendwie bootet.

Die einzige Recovery die wir jetzt noch im Petto haben, ist die 
Festplatte ausbauen und an Rechner hängen und dann mit Kernel usw. 
initialisieren.

Ein Recovery-Boot für die Medion Firmware hat noch keiner geschrieben. 
Wäre aber möglich.

ACHTUNG an alle (Fehlinformierten)! Medion NAS != NSA210, da 
unterschiedliche Hardware.

Das Medion NAS besitzt keine Firmware Update Möglichkeit per USB, die 
wurde glücklicherweise auskommentiert.

Wenn es das nicht getan hat
Vielleicht kommst ja noch per telnet dran, denn wenn es nur die 
Festplatte ist, dann heisst es einfach Partitionen löschen. Das wurde 
schon mehrfach geübt.

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Vielen Dank für deine Skripterei. Das ist das, was ich nicht gut kann.
> Ich werde das auf dem iomega testen und vielleicht kriegen wir eine
> Anleitung vom Stecken eines präparierten USB-Sticks am Neugerät bis zum
> laufenden ArchLinux hin.

Genauso denke ich auch, weil das schon absolut sicher ist, dass zwar die 
Daten weg sein werden aber wenigstens kein Brick entsteht.

solo schrieb:
> Den iomega-Kernel hab ich jetzt seit Wochen mit Arch laufen. Ich hänge
> noch die lib/modules zum reinkopieren ins rootfs an. Das nur, falls er
> mit dem auf 128MB korrigierten Startparametern bei euch bootet und ihr
> Verwendung dafür habt. Die LED funktionieren nicht.

Da ich gerade mit dem Medion-Kernel rumgespielt habe und jedes Mal in 
irgendwelche wilden Hacks geraten bin, werde ich mir wohl entweder den 
2.6.31.14 vom HMNDCE oder den 3.1 heranziehen und da den LED-Kram für 
rausziehen und in ordentlicher Form integrieren.

@solo: Ist zumindest der 3.1 Kernel für PLX7820 gemäss GPL-Bedingungen 
im Source Code verfügbar. Der Kernel für PLX7820 im ArchLinux ARM sollte 
es nämlich nach GPL eigentlich auch sein. NDAs werden von der GPL nicht 
zugelassen.

von Sven B. (ft-)


Lesenswert?

Tim Friedrich:

Du kannst zum Festplatten Löschen folgendes auf den Stick packen. Dann 
kannst das NAS nach Anleitung neu einrichten, wenn nur die Daten auf der 
Platte vom Problem betroffen sind.

https://github.com/ft-/NAS7820-Tools  und dort killpartusbstick

Wichtiger Hinweis

ACHTUNG Nicht bei einem funktionsfähigen Medion NAS verwenden. Es wird 
die Festplatte sang und klang los von allen Daten befreien (d.h. 
löschen).

Stick mit besagtem Inhalt nicht am NAS stecken lassen, ansonsten wird 
beim nächsten Neustart wieder gelöscht. Am besten den Stick nach 
erfolgreicher Benutzung gut wegschliessen oder leeren. Es ist ein Medion 
NAS HDD Clear.

von Tim Friedrich (Gast)


Lesenswert?

das mit dem Löschen werde ich mal versuchen..aber ich glaube ich habe am 
chip rumgespielt..also per telnet...und ich dabei das sysdisk.img 
gelöscht...daher muss ich glaube ne neue firmware draufspielen. ich 
könnte also nicht mit startscript die neue firmware draufspielen?

von Sven B. (ft-)


Lesenswert?

Das bräuchte ein Recovery-Image mit Flasher auf Platte. Das müsste 
erstmal gebaut werden.

Das erinnert mich gerade irgendwie an die Leute, die bei Windows NT und 
neuer NTLDR löschen, weil sie die Platte aufräumen wollen. Und dann 
verzweifelt bei jemanden anrufen, warum der Rechner am nächsten Morgen 
nicht mehr startet.

von Tim Friedrich (Gast)


Lesenswert?

und wenn ich ein sysdisk.img auf den usb stick packe und das an den 
ursprungsort zurückkopiere? (wäre gut wenn mir dann jmd mal den genauen 
pfad sagt)

von Sven B. (ft-)


Lesenswert?

Ich glaube das wird nur jetzt gerade nix, weil alle im Bett sind, die in 
der Nähe ihres Medion NAS sind.

Es muss schon dass zur Firmware passende sein, irgendwas anderes geht da 
nicht.

Oder hast etwa gemeint die NSA210 Firmware muss da drauf geschrieben 
werden.

von Tim Friedrich (Gast)


Lesenswert?

..also das sysdisk.img habe ich da...nur halt der pfad zu dem alten ist 
mir entfallen...

von Sven B. (ft-)


Lesenswert?

Wieso hast das sysdisk.img gespeichert? Und was hast nach dem Speichern 
davon gemacht? gelöscht oder mit was anderem überschrieben.

Das Problem wird nicht der Pfad sein, sondern dass einiges nicht 
eingebunden ist.

von Tim Friedrich (Gast)


Lesenswert?

naja nicht ich habe gemacht sondern jmd anderes...aber egal.
Also wir wollten das sysdisk.img überschreiben..also mit einer 
angepassten Version. Ging nicht. Da wurde es gelöscht aber vorher ein 
backup auf meinen PC gezogen. Nach den löschen stellten wir aber fest 
das ein link auf sysdisk.img lag. Das heißt speicherplatz konnte nicht 
freigemacht werden. Dieser war aber nur begrenzt an der stelle (glaube 
80mb oder so). Naja dann haben wir noch ewig rumprobiert und 
letztendlich neugestartet. Tja und diese Datei wird jetzt vom System 
natürlich gesucht..vergebens..

von Sven B. (ft-)


Lesenswert?

Hast Glück

Ich habe gerade ein Skript nach dem Source Archiv zusammengebaut.

reinstallsysdiskstick wird ein sysdisk.img wieder ins Dateisystem legen.

sysdisk.img muss explizit mit drauf.

Wichtiger Hinweis
ACHTUNG nur verwenden, wenn das NAS nicht korrekt startet. Nicht mit 
einem sysdisk.img aus undefinierter Quelle verwenden (nur Medion NAS)

von Tim Friedrich (Gast)


Lesenswert?

hey danke...ich probier mal...alles in root von dem usb stick 
packen?..also sysdisk.img und deine dateien?

von Sven B. (ft-)


Lesenswert?

genau

ich konnte es leider nicht selber testen, aber wenns klappt dann wird 
dein NAS durchstarten. Aber 10-15min so lange wirds wohl dauern bis es 
installiert ist. Oder warte bis ich noch eine kleine Änderung am Skript 
gemacht habe.

von Sven B. (ft-)


Lesenswert?

Ich habs so verändert, dass bei erfolgreichen Schreiben, dass NAS direkt 
durchbootet.

von Tim Friedrich (Gast)


Lesenswert?

ok danke..ich probier mal..

von Tim Friedrich (Gast)


Lesenswert?

schaltet gleich auf rot...klappt das so mit "cp /sysdisk.img /sysdisk "
weil es bei den anderen usb_key_func.sh meist so da steht: 
/mnt/parnerkey/nsa220_fw/ras.bin ...also das ist jetzt von der 
firmware..das hatte ich mir nur mal angeschaut...

_______________________
nicht probieren;-) für alle anderen

von Sven B. (ft-)


Lesenswert?

ich glaube da hilft nur noch Recovery von SATA Platte aus, weil das mit
der Firmware von den Zyxel Geräten alles nur noch verschlimmert hat.

Aber das baue ich jetzt nicht mehr zusammen.

Ich hoffe doch, dass es bei dir auch um ein Medion NAS geht.

Das usb_key_func.sh ist genau für diesen Zweck erstellt, das kann gar 
nichts anderes als ein sysdisk.img wieder auf das Dateisystem zu 
schieben.

Ich hoffe die Zeile davor ist dir auch aufgefallen.

von Tim Friedrich (Gast)


Lesenswert?

jap es geht um das Medion NAS...alles klar..naja es schiebt halt nix, 
sondern landet gleich bei der der roten LED (klar wird es kurz 
initialisiert...aber da wird nix verschoben)
Danke trotzdem für deine Mühen..vll schauste ja nochmal später drüber;-)
würde mich freuen

von Jens D. (jedie) Flattr this


Lesenswert?

Zu usb_key_func.sh: Ich hatte noch die Idee, das man es ein wenig 
generischer macht. d.h. das man nicht immer die Checksumme anpassen muß. 
Könnte man ganz einfach machen, in dem man in der usb_key_func.sh nicht 
weiter macht als externe Skripte zu starten. Vielleicht in einer 
Reihenfolge wie die Dateinamen sortiert sind oder so.
Dann kann man recht leicht eine Kopie davon machen, eigenen Skript dazu 
packen und fertig.

Zum Thema Recovery: Es wäre nicht schlecht, wenn man ein Image, ähnlich 
dem iomega_HMNHDCE_first_32mb.img macht, welches ein abgespecktes 
Recovery Linux beinhaltet. Vielleicht mit separaten vorgefertigten 
Partitionstabellen oder nicht.
Hat man sein System zerschossen, kann man das Image per dd auf die 
Platte packen und dann sollte man alle Möglichkeiten haben, das System 
neu auf zu setzten...

Sven B. schrieb:
> Schau ins Repo bei mir da liegt ein u-boot von WarheadsSE, dass zum
> Medion NAS passen wird, ist von WarheadsSE's PogoPlugPro
> ArchLinux-Anpassungen.
> (PogoPlugPro 128MB, Medion NAS 128MB)
>
> Alles weitere ist nur Gimmick und muss nun mal nicht von allen gemacht
> werden. (neuerer U-Boot usw.)

Heißt das der ist schon jetzt nutzbar? Den hatte ich IMHO noch nicht 
probiert. Aber wenn dieses uBoot das macht, dann ist ja alles ok!

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Heißt das der ist schon jetzt nutzbar? Den hatte ich IMHO noch nicht
> probiert. Aber wenn dieses uBoot das macht, dann ist ja alles ok!

Das Skript müsste nutzbar sein, ich hatte ja nur den MBR Teil nicht 
gehabt.

Jens D. schrieb:
> Zum Thema Recovery: Es wäre nicht schlecht, wenn man ein Image, ähnlich
> dem iomega_HMNHDCE_first_32mb.img macht, welches ein abgespecktes
> Recovery Linux beinhaltet. Vielleicht mit separaten vorgefertigten
> Partitionstabellen oder nicht.

Braucht doch nur einen U-Boot mit speziellen Environment ;)

Der kann soweit ich weiss auch selbst flashen. Muss man nur ins 
Environment skripten.

Und Partitionen per Raw Write aus U-Boot löschen.

Den Rest kann ja dann die Original-Firmware machen.


Ich tippe so kommt die Firmware auch initial drauf. Die Spuren sieht man 
nur nicht mehr weil die Daten geplättet werden auf der Platte.


Für ArchLinux wäre es etwas anders, da wäre es eher ein 
Installations-Image.

Man könnte die Recovery-Funktion gleich mit einbauen als eine kleine 
Partition, wenn das Hauptsystem nicht startet, dann rein ins Recovery. 
;)

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Zu usb_key_func.sh: Ich hatte noch die Idee, das man es ein wenig
> generischer macht. d.h. das man nicht immer die Checksumme anpassen muß.
> Könnte man ganz einfach machen, in dem man in der usb_key_func.sh nicht
> weiter macht als externe Skripte zu starten. Vielleicht in einer
> Reihenfolge wie die Dateinamen sortiert sind oder so.
> Dann kann man recht leicht eine Kopie davon machen, eigenen Skript dazu
> packen und fertig.

zum Beispiel so:

usb_key_func.sh
1
#!/bin/sh
2
3
exec /mnt/parnerkey/do.sh

Dann wird das usb_key_func.sh ausführungstechnisch ersetzt und man 
kodiert im do.sh so wie man es im usb_key_func.sh machen würde.

Habs mal genauso bei mir unter usb_key_func_do_sh/ angelegt.

von solo (Gast)


Lesenswert?

Sven B. schrieb:
> @solo: Ist zumindest der 3.1 Kernel für PLX7820 gemäss GPL-Bedingungen
> im Source Code verfügbar. Der Kernel für PLX7820 im ArchLinux ARM sollte
> es nämlich nach GPL eigentlich auch sein. NDAs werden von der GPL nicht
> zugelassen.
Bin mir nicht sicher, ob du das als Frage gemeint hast, ich interpretier 
es mal so. Vom NDA betroffen ist nur der stage1-Quelltext, der dann wohl 
keine GPL-Bestandteile hat. Wie gesagt glaube ich, dass Medion 
geschlampert hat und denen der stage1-Code in ihr Quelltext-Paket 
durchgerutscht ist. Gut für uns, schlecht für Medion, die könnten 
deswegen Ärger kriegen.

Einen 3.1-Kernel gibt es von PLX nicht. Seit dem 2.6.31 haben die selber 
nichts mehr gemacht. Das ist die typische Hit-and-Run-Taktik 
zweitklassiger ARM-Buden, die Torvalds schon oft kritisiert hat. Die 
konstruieren ein SoC, hacken in eine x-beliebige Kernel-Version die 
Unterstützung dafür rein, verkaufen das Ding ein paar Jahre und 
vergessen dann alles darüber. Das wird mit dem 7820 genauso werden. 
Iomega, Medion etc. können doch noch ein paar Jahre NAS'en mit dem alten 
Kernel ausliefern. Die Kette reißt erst dann, wenn sie wegen dem alten 
Kernel kein aktuelles Debian mehr nehmen können, deswegen die aktuellen 
Mediensachen (Twonky etc.) nicht mehr laufen, deswegen die aktuellen 
Fernseher nicht mehr korrekt bestreamt werden etc. Dann - und erst dann 
- wird der Murks für den Kunden sichtbar und verkaufsschädigend.

Dann gibts von PLX den 7920 mit SDK auf 3.1er-Kernel-Basis und das Spiel 
geht von vorne los. Die notwendige Qualität, dass das Ganze mainline 
geht und dort gepflegt werden kann, wird nie erreicht. Die 
Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine 
andere Hausnummer als PLX.

Deshalb ist die Community höchstwahrscheinlich auf sich gestellt, was 
neue Kernel betrifft. In dem iomega-Quellcode-Paket sind die Patches 
separat drin. Ich glaube nicht, dass das im SDK direkt von PLX groß 
anders aussieht. Sind etwa 3MB, von denen aber nicht alles für den 7820 
relevant ist, soweit ich das überflogen habe. Die müsste man durchgehen 
und in einen 3.1er reinpatchen, was mal mehr, mal weniger Anpassungen 
benötigt. Die Arch-Leute haben wohl den größten Teil für u.a. USB, SATA 
und Netzwerk schon geschafft. Ich selber kann mangels Kenntnissen nicht 
helfen. Das wäre für mich ein Puzzlespiel nur mit der Form der Steine, 
nicht ihrer Beschriftung.

Ciao,

solo

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Einen 3.1-Kernel gibt es von PLX nicht. Seit dem 2.6.31 haben die selber
> nichts mehr gemacht.

Nein, meine Frage zielte auf ArchLinux ARM ab, da ja von dort die 
Binaries kommen.

Kenne ich allerdings auch von Geräteherstellern die Mentalität. Gerade 
bei DSL-Routern auch gern anzutreffen, da wird dann eine ewig alte 
Kernel-Version immer weiter verwendet. Hab da auch noch ein Gerät was 
ich noch vor mir hab, dass Zeug mal auseinanderzunehmen.

solo schrieb:
> Vom NDA betroffen ist nur der stage1-Quelltext, der dann wohl
> keine GPL-Bestandteile hat. Wie gesagt glaube ich, dass Medion
> geschlampert hat und denen der stage1-Code in ihr Quelltext-Paket
> durchgerutscht ist. Gut für uns, schlecht für Medion, die könnten
> deswegen Ärger kriegen.

Wegen der Kommentare auch ziemlich eindeutig. Alles weisst auf OXNAS 
hin. Ist aber nicht der erste Source der jemals rausgerutscht ist.

Aber ein wirkliches Kunstwerk ist es nicht, ca. 80% könnte man mittels 
GPL-Sourcen herstellen.

von Sven B. (ft-)


Lesenswert?

Ich habe mir gerade die Mühe gemacht mal aus einem NAND-Backup ein 
HDD-Recovery-Image-Builder zu bauen, Die MAC-Adresse muss halt 
eingetragen werden.

Vielleicht mag das mal ausprobieren, am besten auf kaputtgeschriebenen 
NAND.

ACHTUNG

Am laufenden NAS nicht ausprobieren, es sei denn man ist zum Recovery 
selbst in der Lage.

von Johann B. (johann_b)


Lesenswert?

Jens D. schrieb:
> Es geht!!!

Tolle Sache! 8)

Da ich mein NAS allerdings nicht verlieren will, warte ich lieber auf 
die Sicherheitsfreigabe von euch :D Wenn es dann daran geht, die 
Firmware anzupassen, bin ich wieder dabei ;)

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Deshalb ist die Community höchstwahrscheinlich auf sich gestellt, was
> neue Kernel betrifft. In dem iomega-Quellcode-Paket sind die Patches
> separat drin. Ich glaube nicht, dass das im SDK direkt von PLX groß
> anders aussieht. Sind etwa 3MB, von denen aber nicht alles für den 7820
> relevant ist, soweit ich das überflogen habe. Die müsste man durchgehen
> und in einen 3.1er reinpatchen, was mal mehr, mal weniger Anpassungen
> benötigt. Die Arch-Leute haben wohl den größten Teil für u.a. USB, SATA
> und Netzwerk schon geschafft. Ich selber kann mangels Kenntnissen nicht
> helfen. Das wäre für mich ein Puzzlespiel nur mit der Form der Steine,
> nicht ihrer Beschriftung.

Das nehme ich auch an. Deswegen ist es ja schon gut, dass wir 
vollständige Kernel-Sourcen haben.

Beim U-Boot habe ich auch mal eine neuere Version schon 
zusammengestellt, die will ich aber auch erst testen. Und ist ja für 
eine grundsätzliche Inbetriebnahme ja auch erstmal nicht bedeutend. 
Allerdings für später interessant.
Der USB-Code war ziemlich einfach zu übernehmen, war ja nur ein bisschen 
Init-Code. Beim SATA und Ethernet ist es schon etwas komplexer. Habe den 
Ethernet-Code vom U-Boot 1.1.2 halt vollständig auf die neue 
Infrastruktur umgebaut (CONFIG_NET_MULTI für die U-Boot-Bewanderten). 
Ähnliches habe ich beim SATA gemacht.

Gerade der SATA-Code ist beim U-Boot 1.1.2 auch ein ziemliches 
Hackstück.

von Sven B. (ft-)


Lesenswert?

Johann B. schrieb:
> Da ich mein NAS allerdings nicht verlieren will, warte ich lieber auf
> die Sicherheitsfreigabe von euch :D Wenn es dann daran geht, die
> Firmware anzupassen, bin ich wieder dabei ;)

Wir haben ja einen der sich, dass Flash kaputtgeschrieben hat.

von Jens D. (jedie) Flattr this


Lesenswert?

solo schrieb:
> Die
> Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine
> andere Hausnummer als PLX.

Sollte man also bei zukünftigen Anschaffungen darauf achten? Macht wohl 
Sinn, was?

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Sollte man also bei zukünftigen Anschaffungen darauf achten? Macht wohl
> Sinn, was?

Zumindest sollte man darauf achten, dass man die relevanten Sourcen in 
die Finger bekommt.

@solo:
Das Recovery HDD-Image liesse sich auch für PogoPlugPro adaptieren. Aber 
da habe ich kein Flash-Backup für.

@all:
Das MedionNAS Recovery soll nur die Original-Firmware wiederherstellen.

von ElektromAn (Gast)


Lesenswert?

solo schrieb:
> Bin mir nicht sicher, ob du das als Frage gemeint hast, ich interpretier
> es mal so. Vom NDA betroffen ist nur der stage1-Quelltext, der dann wohl
> keine GPL-Bestandteile hat. Wie gesagt glaube ich, dass Medion
> geschlampert hat und denen der stage1-Code in ihr Quelltext-Paket
> durchgerutscht ist. Gut für uns, schlecht für Medion, die könnten
> deswegen Ärger kriegen.
>
> Einen 3.1-Kernel gibt es von PLX nicht. Seit dem 2.6.31 haben die selber
> nichts mehr gemacht. Das ist die typische Hit-and-Run-Taktik
> zweitklassiger ARM-Buden, die Torvalds schon oft kritisiert hat. Die
> konstruieren ein SoC, hacken in eine x-beliebige Kernel-Version die
> Unterstützung dafür rein, verkaufen das Ding ein paar Jahre und
> vergessen dann alles darüber. Das wird mit dem 7820 genauso werden.
> Iomega, Medion etc. können doch noch ein paar Jahre NAS'en mit dem alten
> Kernel ausliefern. Die Kette reißt erst dann, wenn sie wegen dem alten
> Kernel kein aktuelles Debian mehr nehmen können, deswegen die aktuellen
> Mediensachen (Twonky etc.) nicht mehr laufen, deswegen die aktuellen
> Fernseher nicht mehr korrekt bestreamt werden etc. Dann - und erst dann
> - wird der Murks für den Kunden sichtbar und verkaufsschädigend.
>
> Dann gibts von PLX den 7920 mit SDK auf 3.1er-Kernel-Basis und das Spiel
> geht von vorne los. Die notwendige Qualität, dass das Ganze mainline
> geht und dort gepflegt werden kann, wird nie erreicht. Die
> Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine
> andere Hausnummer als PLX.
>
> Deshalb ist die Community höchstwahrscheinlich auf sich gestellt, was
> neue Kernel betrifft. In dem iomega-Quellcode-Paket sind die Patches
> separat drin. Ich glaube nicht, dass das im SDK direkt von PLX groß
> anders aussieht. Sind etwa 3MB, von denen aber nicht alles für den 7820
> relevant ist, soweit ich das überflogen habe. Die müsste man durchgehen
> und in einen 3.1er reinpatchen, was mal mehr, mal weniger Anpassungen
> benötigt. Die Arch-Leute haben wohl den größten Teil für u.a. USB, SATA
> und Netzwerk schon geschafft. Ich selber kann mangels Kenntnissen nicht
> helfen. Das wäre für mich ein Puzzlespiel nur mit der Form der Steine,
> nicht ihrer Beschriftung.
>
> Ciao,
>
> solo

Da hat der Entwickler vom BSP geschlampt und einfach den kompletten 
Source vom SVN ausgecheckt.
Was ja eigentlich ja schon für die Kernel Sourcen seltsam ist, bwz. wer 
benutzt noch SVN als Repo ?
Das zweite Problem das die Sourcen betriff, das so wie es aussieht 
niemals dran gedacht wurde diese Mainline zu bringen. Das sieht man an 
Core USB, VFS und SATA Änderungen, auch ist die Abschaltung des zweiten 
Kerns nicht in dem Platformteil gemacht wurden.

Und nicht nur Marvell, sondern auch Samsung ist ein gutes Beispiel
siehe 
http://events.linuxfoundation.org/events/embedded-linux-conference-europe/dae

von Sven B. (ft-)


Lesenswert?

ElektromAn schrieb:
> Da hat der Entwickler vom BSP geschlampt und einfach den kompletten
> Source vom SVN ausgecheckt.

soll uns nur recht sein, sonst wäre es ja nicht so schön komplett. Auch 
wenn der Source noch überarbeitungswürdig ist.

Ich hatte den SATA-Code jetzt mal doch durchgängiger analysiert und ich 
glaube der Code im Medion-Kernel ist der aktuellere von den 
SATA-Treibern, die wir haben.

ElektromAn schrieb:
> Was ja eigentlich ja schon für die Kernel Sourcen seltsam ist, bwz. wer
> benutzt noch SVN als Repo ?

Alle die für ein verteiltes Repository keine Notwendigkeit haben. 
Deswegen ist es gar nicht so unüblich.

ElektromAn schrieb:
> Das zweite Problem das die Sourcen betriff, das so wie es aussieht
> niemals dran gedacht wurde diese Mainline zu bringen. Das sieht man an
> Core USB, VFS und SATA Änderungen, auch ist die Abschaltung des zweiten
> Kerns nicht in dem Platformteil gemacht wurden.

Dem kann ich nach Durchsicht nur zustimmen. Änderungen am VFS will ich 
schon mal gar nicht haben. Ich möchte persönlich einen SATA-Treiber 
haben, der wie die anderen auch aufgebaut ist.
Da ist aktuell im SATA-Treibercode eine Menge Mist drin, der da einfach 
nichts dauerhaft zu suchen hat. (z.B. Error Injection)

Den SMP-Code will ich auch in Originalform sehen. Nicht dieses 
herumgemurkste Zeug. Auch der USB-Code ist mir noch ein wenig zu sehr 
Bastelwerk.

Ich hatte versucht, den Medion-Kernel zu modularisieren. Das kann man 
aber praktisch durch die Bastelei darin nicht umsetzen.

Ich habe WarheadsSE kontaktiert wie der Stand vom 3.1 Kernel ist und 
leider ist der SATA-Code aktuell unbrauchbar. Ich hab kein Problem damit 
diesen komplett zu überarbeiten. Erstmal schaue ich aber, dass ich die 
Zusammenhänge des SATA-Kerns verstehe. Und dann weiter.

Aktuell ist der Source Code von diesen Teilen im 2.6.31.x keine Freude, 
da er praktisch von keinem ausserhalb PLX so richtig verstanden wird und 
wie ja belegt scheint, hat PLX wohl auch keine wesentliche weitere 
Pflege mehr daran betrieben (neuere Kernel). Also muss zur sinnvollen 
Pflege erstmal der Source richtig aufgeräumt werden. Alles anderes - 
denke ich - ist nur Leben auf Raten.

Mal davon abgesehen, dass der Code sich nicht an Richtlinien des 
Mainline-Kernels orientiert hat.

Es gibt einige Hersteller, die es definitiv besser gemacht haben. In 
einigen anderen Fällen hat die Community nachgeholfen und einen 
aufgeräumten Source Code präsentiert (dank der GPL).

Einiges an PC-Hardware fällt mir dazu ein, aber die Liste bringt hier 
jetzt nichts dem Thema.

von ElektromAn (Gast)


Lesenswert?

Sven B. schrieb:
> Den SMP-Code will ich auch in Originalform sehen. Nicht dieses
> herumgemurkste Zeug. Auch der USB-Code ist mir noch ein wenig zu sehr
> Bastelwerk.
>
> Ich hatte versucht, den Medion-Kernel zu modularisieren. Das kann man
> aber praktisch durch die Bastelei darin nicht umsetzen.
>
> Ich habe WarheadsSE kontaktiert wie der Stand vom 3.1 Kernel ist und
> leider ist der SATA-Code aktuell unbrauchbar. Ich hab kein Problem damit
> diesen komplett zu überarbeiten. Erstmal schaue ich aber, dass ich die
> Zusammenhänge des SATA-Kerns verstehe. Und dann weiter.

Ich glaube ich habe den USB Source gesäubert, muss dieses aber noch 
testen.
Mit SATA und/oder Netzwerk kann ich noch nicht genaues sagen, da ich den 
bl*den* LEON Chip und/oder die seltsamen DMAs nicht verstanden haben.
Auch ist beim SATA das mit dem "aktiven" RAID 0/1 im SATA device 
seltsam. Es gab/gibt auch einen Modus ohne das bl*den* RAiD.

Ausserdem sind viele symbole noch von dem alten Design übernommen worden 
ohne vorher zu prüfen ob diese jemals benutzt werden.

von Lucian M. (lucian_m)


Lesenswert?

Hey Ihr Kernelprofis, das sieht ja ganz schön und langfristig viel 
versprechend aus, was Ihr da vor habt, Respekt, da freue ich mich drauf!

Ich würde noch zu den nice to have Sachen hinzu fügen, RTC, HW 
Monitoring (Temperatur und Fans) welche diese Platform noch unterstützen 
sollen (ich denke über i2c). Hierfür gibt's auch schon Module, man kann 
sie sogar bauen und laden, bloß brauchbar sind sie (noch) nicht. Ob das 
gar nicht in der konkreten Medion Hardware aktiv oder ausgebaut ist, 
oder einfach nur die derzeitigen Sourcen auch vermurkst sind, weiß ich 
nicht.

von Sven B. (ft-)


Lesenswert?

Hier mal eine Aufzählung wo überall im Medion-Kernel was gebastelt 
wurde.

* GIC (Generic Interrupt Controller) Code
** Interrupt Code
* SMP-Code
** CPU Init
* MMU-Handling
** Page Table Handling
** TLB Handling
* VFS-Code
* Netzwerk-Stack

Wobei ich dieses SATA-Direct-Read/Write-Zeugs für äussert kritisch 
ansehe, da es eine Komplexität in den Code einfügt. Das hat den 
Charakter von zwei Treibern an einen Controller, dass braucht 
kompliziertes Handshake zwischen beidem und sorgt für Fehlerkategorien, 
die es nur unübersichtlich machen.

Da sowieso alles über User Space und dann über zwei Context-Switches weg 
muss, bringt diese Optimierung faktisch gar nichts. Insbesondere, da man 
im User-Space dann Informationen über Dateien benötigt, die auch hier 
wieder komplizierte Patches nötig machen. Das macht man meiner Meinung 
nach anders. Ich frage mich nur, warum im Vanilla-Kernel soviel Arbeit 
in einen NoCopy-Stack gesteckt wird. Und dass irgendwelche Leute sich 
trotzdem irgendwas wildes eigenes ausdenken.

Das Stabilitätsproblem, warum nur ein Kern aktiv ist, überrascht mich da 
immer weniger.

Der Code kann so gar nicht Mainline werden.

Meine "Lieblings-Datei": atomic_torture.c
"Atomare Folter" mal grob übersetzt.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> Ich hatte versucht, den Medion-Kernel zu modularisieren. Das kann man
> aber praktisch durch die Bastelei darin nicht umsetzen.
>
> Ich habe WarheadsSE kontaktiert wie der Stand vom 3.1 Kernel ist und
> leider ist der SATA-Code aktuell unbrauchbar. Ich hab kein Problem damit
> diesen komplett zu überarbeiten. Erstmal schaue ich aber, dass ich die
> Zusammenhänge des SATA-Kerns verstehe. Und dann weiter.
>
> Aktuell ist der Source Code von diesen Teilen im 2.6.31.x keine Freude,
> da er praktisch von keinem ausserhalb PLX so richtig verstanden wird und
> wie ja belegt scheint, hat PLX wohl auch keine wesentliche weitere
> Pflege mehr daran betrieben (neuere Kernel). Also muss zur sinnvollen
> Pflege erstmal der Source richtig aufgeräumt werden. Alles anderes -
> denke ich - ist nur Leben auf Raten.

Was ich dabei nicht verstehe: Der alte 2.6er ArchLinuxARM Kernel läuft 
doch. Läuft der nur, weil WarheadsSE die nötige Unterstützung 
implementiert hat? Ist es nicht vernünftiger darauf aufzubauen, als auf 
den Medion Kram?

Wäre noch zu prüfen, wie die Kernel von Iomega oder dem Level One 
GNS-1001 aufgebaut sind. Vielleicht wurde da sauberer Gearbeitet?

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Was ich dabei nicht verstehe: Der alte 2.6er ArchLinuxARM Kernel läuft
> doch. Läuft der nur, weil WarheadsSE die nötige Unterstützung
> implementiert hat? Ist es nicht vernünftiger darauf aufzubauen, als auf
> den Medion Kram?

der 2.6er Kernel läuft weil er auf diesen PLX-Sourcen/Patches aufbaut. 
Und die sind in allen Varianten so verschroben implementiert. Deswegen 
ist ja im ArchLinuxARM-Kernel die XFS-Unterstützung kaputtgepatcht von 
PLX. Weil das noch die ältere Fassung ist.

Nur muss man dann auf alle Zeiten mit den Problemen leben, die die 
besagte Version hat. Inklusive Sicherheitslöchern.

Ich benutze den Medion-Kernel lediglich um den SATA-Core zu verstehen 
und dann zu wissen, was wirklich nötig ist.

Jens D. schrieb:
> Wäre noch zu prüfen, wie die Kernel von Iomega oder dem Level One
> GNS-1001 aufgebaut sind. Vielleicht wurde da sauberer Gearbeitet?

Die Kernel enthalten alle diesen abgedrehten Direct SATA-Kram. Wenn da 
mal was schief geht, dann richtig.

von Sven B. (ft-)


Lesenswert?

Deswegen bekommen wir im Übrigen meiner Meinung nach auch diese Blockade 
beim Gerät, weil Twonky Media dann keinen Zugriff bekommt und dann 
eifrig Busy Waiting geschieht.

Mit dem Code wird das Blockade-Problem beim Draufladen grosser 
Datenbestände nie gelöst werden.

von Lucian M. (lucian_m)


Lesenswert?

Sven B. schrieb:
> Jens D. schrieb:
>> Was ich dabei nicht verstehe: Der alte 2.6er ArchLinuxARM Kernel läuft
>> doch. Läuft der nur, weil WarheadsSE die nötige Unterstützung
>> implementiert hat? Ist es nicht vernünftiger darauf aufzubauen, als auf
>> den Medion Kram?
>
> der 2.6er Kernel läuft weil er auf diesen PLX-Sourcen/Patches aufbaut.
> Und die sind in allen Varianten so verschroben implementiert. Deswegen
> ist ja im ArchLinuxARM-Kernel die XFS-Unterstützung kaputtgepatcht von
> PLX. Weil das noch die ältere Fassung ist.

Noch ein Problem: mit einem "alten" Kernel wirst Du nach und nach nicht 
mehr aktuellere Firmware nutzen können, ganz konkretes aktuelles 
Beispiel, mit der Version des Medion-Kernels kann man kein udev neuer 
wie 164 nutzen, und die Liste kann jeden Monat länger werden, ein wildes 
herumgematsche basierend auf den allrdings "lauffähigen" Sourcen führt 
eher früher als später in die Sackgasse. Deswegen ist das einzig 
Vernünftige das Vorhaben das ganze mainline-tauglich zu kriegen. So habe 
ich das auch damals mit der orion5x Platform von Marvell erlebt als ich 
die Linkstation Pro kaufte, da hatten die ersten Kernel-Hacker an den 
releasten Sourcen auch nicht viel Gutes zu verlieren. Zum Glück hatte 
danach Marvell selbst Leute dafür eingestellt, das ganze "richtig" zu 
machen...

von Jens D. (jedie) Flattr this


Lesenswert?

Dann dürften sich die Problem bei allen Boxen [1] die den selben SoC 
"NAS 7820" Prozessor nutzten zeigen.

[1] siehe: 
http://www.mikrocontroller.net/articles/P89626#.C3.84hnliche_Ger.C3.A4te

von ElektromAn (Gast)


Lesenswert?

Lucian M. schrieb:
> Hey Ihr Kernelprofis, das sieht ja ganz schön und langfristig viel
> versprechend aus, was Ihr da vor habt, Respekt, da freue ich mich drauf!
>
> Ich würde noch zu den nice to have Sachen hinzu fügen, RTC, HW
> Monitoring (Temperatur und Fans) welche diese Platform noch unterstützen
> sollen (ich denke über i2c). Hierfür gibt's auch schon Module, man kann
> sie sogar bauen und laden, bloß brauchbar sind sie (noch) nicht. Ob das
> gar nicht in der konkreten Medion Hardware aktiv oder ausgebaut ist,
> oder einfach nur die derzeitigen Sourcen auch vermurkst sind, weiß ich
> nicht.

RTC ist bei der Medion BOX nicht vorhanden ...
Es fehlt einfach der Chip, das I2C (für RTC) über BitBang/GPIO (eine Art 
Software I2C Schnittstelle) ist nebensächlich.
Das geht zum Teil auch bei anderen SoC so, z.B. für OutOfBand Signaling 
für RGMII (Netzwerkport)

@Sven .B
Das SATA Direct Zeugs ist für die Optimierung von sendfile/readfile. Die 
haben sogar ein Teil den VFS in den Treiber gepackt, um nicht die Daten 
mehrmals im Speicher zu kopieren. Was nach meiner Meinung Blödsinn ist 
wg. MMAP und auch wegen der Firewall, die schmeissen einfach die Pakete 
auf den Port.
Das meiste frisst nach meiner Meinung der Copo (LEON) für TOE weg, da 
dieser mit im internen Bus liegt. Bei Gemini (IB4220) liegt das auf 
der MAC Schicht.

Hmm.
atomic_torture.c nett. Wurde wohl zum Testen des SoC benutzt.

Ich werde mir mal die SATA Sourcen von uBoot ansehen hoffentlich ist da 
keine FW drin für den "internen" RAID Controller ...

Alles was innerhalb /arch/arm/ox820 ist sieht relativ "normal" aus, 
jedenfalls wenn man die kruden Sachen weg lässt.

von Sven B. (ft-)


Lesenswert?

Die Patches im USB EHCI-HCD.c von seiten PLX sind auch völlig unnötig. 
Nur der Init Code ist überhaupt nötig.

SATA im U-Boot hab ich mir schon angeschaut, wird ohne 
Microcode-Firmware betrieben. Ist trotzdem ein ziemlicher Wust.

ElektromAn schrieb:
> Das SATA Direct Zeugs ist für die Optimierung von sendfile/readfile. Die
> haben sogar ein Teil den VFS in den Treiber gepackt, um nicht die Daten
> mehrmals im Speicher zu kopieren. Was nach meiner Meinung Blödsinn ist
> wg. MMAP und auch wegen der Firewall, die schmeissen einfach die Pakete
> auf den Port.

MMAP wurde sogar abgeschaltet. Hab die Stelle schon gesehen.

Wegen den VFS-Patches wurden einige Dateisysteme kaputtgepatcht.

Ich versuche mich gerade daran, den ox820 sata code erstmal 
umzuschreiben und ohne HWRAID zusammenzubauen.
Das Locking im Ursprungs-Code ist eine mittlere Katastrophe. Busy 
Waiting überall wo man hinschaut. Das funktioniert dann vor allem so 
"schön" auf Multi-Core Systemen. Da warten dann beide Kerne andauernd 
aufeinander. Kein Wunder, dass die Kiste so warm wird bei Datentransfer. 
Die CPU müsste eigentlich die meiste Zeit schlafen, was aber mit Busy 
Waiting nicht geht.

ElektromAn schrieb:
> RTC ist bei der Medion BOX nicht vorhanden ...
> Es fehlt einfach der Chip, das I2C (für RTC) über BitBang/GPIO (eine Art
> Software I2C Schnittstelle) ist nebensächlich.
> Das geht zum Teil auch bei anderen SoC so, z.B. für OutOfBand Signaling
> für RGMII (Netzwerkport)

Ich vermute mal, dass auf dem freigelassenen IC-Platz ein paar GPIOs 
ankommen. Da könnt man schon was mit anfangen. RTC-Chips sind nicht 
teuer.

von ElektromAn (Gast)


Lesenswert?

Arrggghhh ....

PLX ist nicht der Hersteller vom SoC bzw. er hat diesen nur Designt ...

SATA, DMA, USB (inkl. OTG) und Ethernet kommt von Synopsis.

von Sven B. (ft-)


Lesenswert?

Lucian M. schrieb:
> So habe
> ich das auch damals mit der orion5x Platform von Marvell erlebt als ich
> die Linkstation Pro kaufte, da hatten die ersten Kernel-Hacker an den
> releasten Sourcen auch nicht viel Gutes zu verlieren. Zum Glück hatte
> danach Marvell selbst Leute dafür eingestellt, das ganze "richtig" zu
> machen..

Marvell hat wenigstens ein paar Leute mit Stolz, die etwas richtig 
machen wollen.

Lucian M. schrieb:
> Noch ein Problem: mit einem "alten" Kernel wirst Du nach und nach nicht
> mehr aktuellere Firmware nutzen können, ganz konkretes aktuelles
> Beispiel, mit der Version des Medion-Kernels kann man kein udev neuer
> wie 164 nutzen, und die Liste kann jeden Monat länger werden, ein wildes
> herumgematsche basierend auf den allrdings "lauffähigen" Sourcen führt
> eher früher als später in die Sackgasse.

Das denke ich auch.

Bei den Versionen mit den Basteleien bin ich auch vorsichtig, 
wahrscheinlich werde ich den gesamten Datenbestand der Platte noch per 
MD5 checken. Nachdem was ich im VFS-Code alles gesehen habe.

Sven B. schrieb:
> Das SATA Direct Zeugs ist für die Optimierung von sendfile/readfile.

Bringt eigentlich nur richtig was bei Apache und FTP. Aber bei NFS 
dürfte das ziemlich unsinnig sein, da solche Protokolle nicht wirklich 
grosse Blöcke übertragen, da steckt dann soviel Overhead dazwischen, 
dass es kaum was bringt. Selbst SMB hat noch einen Protokoll-Overhead 
welches die Block-Übertragung auf maximal 64kB beschränkt.

Und dann kommt noch die gesamte TCP-State Machine dazu.

von Sven B. (ft-)


Lesenswert?

ElektromAn schrieb:
> Arrggghhh ....
>
> PLX ist nicht der Hersteller vom SoC bzw. er hat diesen nur Designt ...
>
> SATA, DMA, USB (inkl. OTG) und Ethernet kommt von Synopsis.

Ist mir auch schon aufgefallen.

PLX hat im Grunde viele Bauteile nur zusammengestellt.

ARM 11MPCore
AMBA-Bus

SATA ist Synopsis
DMA ebenfalls
USB scheint auch von extern zu sein
Ethernet ähnlich

Alle diese Teile kommen über den Weg von Oxford Semiconductors Ltd. in 
den Bestand von PLX. Oxford Semiconductors Ltd. scheint ein 
Firmen-Einkauf seitens PLX zu sein.


Aber das ist eigentlich nicht so ungewöhnlich. Gibt sogenannte 
IP-Core-Lizenzen.

von Sven B. (ft-)


Lesenswert?

Im Übrigen viele Firmen designen zwar ASICs aber lassen diese bei einem 
der Chip-Fabriken fertigen. Ist gängige Praxis.

Nur ganz wenige Chip-designende Firmen haben eine eigene Chip-Fabrik 
(z.B. Intel, NEC, Samsung, AMD usw.)

Wenn ich mich recht entsinne, designt Synopsis auch nur Komponenten.

von Sven B. (ft-)


Lesenswert?

Hab mich bis jetzt am SATA-Code für Kernel 3.1 zu schaffen gemacht und 
das Ergebnis erstmal bei mir im Repo. Muss noch getestet werden.

von Sven B. (ft-)


Lesenswert?

@Lucian M.

habe gerade das geforkte Repo bei dir entdeckt. Ich habe bereits einiges 
an Source zusammengestellt im U-Boot 2011.09. Insbesondere habe ich auch 
dabei festgestellt, dass vielfach Code nicht einfach nur zu portieren 
ist. Ich habe ja schon oben weiter mal die zusammengefassten Fakten zu 
diesem neu zusammengestellten Code aufgelistet. Das Portieren von 1.1.2 
auf 2011.09 ist recht umfangreich: Wegfall von config.mk. Neu ist die 
Steuerung komplett über ein config.h.

Ich habe sowohl am NAND-Code Dinge angepasst als auch am SATA-Code. 
Wobei der SATA-Code erstmal ein direkter Port ist (von ide -> sata 
Kommando). Wohingegen der Ethernet-Code ein vollständiger Port auf 
CONFIG_NET_MULTI ist. Ebenfalls habe ich den USB-Init-Code aus dem 
Kernel in den U-Boot eingebaut. Im Moment würde ich es allerdings nur 
denen besser zum Testen geben, die auch in der Lage sind mit eventuellen 
Fehlern klarzukommen.

von Lucian M. (lucian_m)


Lesenswert?

Ein frohes neues Jahr zusammen!

Sven B. schrieb:
> habe gerade das geforkte Repo bei dir entdeckt. Ich habe bereits einiges
> an Source zusammengestellt im U-Boot 2011.09.

Ja, da wollte ich auch mal 'reingucken, war noch bevor Du hier sagtest 
daß Du mit der aktuellen Version was machst. Da war mir schon längst 
klar, und Michael Kebe auch, daß es für uns gar nicht so einfach sein 
würde... Also werde ich zumindest mit jenem Fork nichts weiter machen...

von Sven B. (ft-)


Lesenswert?

@Lucian M.
Den SATA-Code will ich noch aufräumen, aber erstmal muss er auch 
funktionieren.

Das war auch schon ein ziemlicher Umbau von config.mk auf config.h. Ich 
hatte auch ein Disk Environment-Modul gleich dabei kodiert.

Ich hatte auch die Einschätzung von Michael Kebe gelesen, dass es zu 
viele Unbekannte für ihn gibt.

von Michael (Gast)


Lesenswert?

@Sven B.

Bist du auch schon auf die Problematik mit dem Linker gestoßen, die ich 
beschrieben habe? Sind dir alle Adressen für das Board klar? 
Interessiert mich wie weit da der Stand ist. Kompiliert U-Boot 2011.09 
schon für das Board?

@All

Frohes Neues!

von Sven B. (ft-)


Lesenswert?

@Michael

Ja, er kompiliert und linkt. Es kommt also ein Binary dabei raus. 
Lediglich laufen lassen konnte ich den Code noch nicht. Ich hatte zwar 
auch den ein oder anderen Linker-Fehler aber die waren alle lösbar. 
Insbesondere der SATA-Code benötigte für eine sinnvolle Anbindung einige 
Änderungen. So halt auch der Ethernet-Code. Ebenfalls habe ich auch die 
UART-Adressen verknüpft und den richtigen Treiber ausgewählt.

Der NAND-Code ist besonders stark von Änderungen betroffen, da hier 
bestimmte Funktionen im neueren U-Boot keine Entsprechungen mehr haben.

Die notwendigen Adressen bezüglich Ladeadressen waren für mich leicht 
auszumachen. Zum Beispiel CONFIG_SYS_TEXT_BASE bekam den Wert 
0x60d00000. War auch im alten config.mk als TEXT_BASE zu finden.

Ist aber mit ARM-Hintergrundwissen alles machbar.

Ich hatte mir auch die "hilfreichen" Antworten, die du bekommen hast, 
mal durchgelesen.

@All

Von mir auch ein frohes neues

von Sven B. (ft-)


Lesenswert?

@all

bezüglich Kernel 3.1 Support: Den von mir überarbeiteten SATA-Treiber 
kann man wohl in Kürze als Beta betrachten. Also gibt es bald einen 
sauberen Kernel ohne wilde Hacks. Er scheint erst mal zu laufen, wie mir 
WarheadsSE bestätigt hat.

von Johann B. (johann_b)


Lesenswert?

Jetzt habe ich mal eine Frage:

Die hier im Wiki beschriebene Variante, ALARM per chroot zu nutzen, 
klappt bei mir nicht :(

Der Fehler liegt imho an fehlenden Rechten des "admin"-Kontos:
>~ $ chroot . /bin/bash
> chroot: can't change root directory to .: Operation not permitted
> ~ $ whoami
> admin
> ~ $ su
> su: must be suid to work properly

Habe ich was falsch gemacht, oder stimmt das wirklich? Ich habe übrigens 
die Aldi-Nord-Variante, die etwas teurer war und wohl eine größere 
Platte hat als das Gerät, das ihr scheinbar alle besitzt ;)

von Christian J. (stormracer)


Lesenswert?

Frohes Neues,

@Johan B.

melde dich mal als root an. Passwort ist das gleiche wie bei Admin.
Dann hast du auch volle Rechte.

von Johann B. (johann_b)


Lesenswert?

Aah, danke^^

Ich bin es halt nicht gewohnt, dass man sich als Superuser per PW 
anmelden kann ;)

So klappt es wunderbar :)

Allerdings, was ist mit "ACHTUNG: Der Zugriff auf /dev/sda2 beschädigt 
das RAID" gemeint? In dem System mounte ich ja ohnehin nichts, oder?

von solo (Gast)


Lesenswert?

Jens D. schrieb:
> solo schrieb:
>> Die
>> Kirkwood-Plattform zeigt wie's gehen kann. Aber Marvell ist auch eine
>> andere Hausnummer als PLX.
>
> Sollte man also bei zukünftigen Anschaffungen darauf achten? Macht wohl
> Sinn, was?

Ja, man sollte das recherchieren und bedenken. Vor allem, wenn man auf 
den Komfort von Debian & Co. angewiesen ist. Der ist dauerhaft nur 
gegeben wenn die Hardware wirklich gut unterstützt ist, also mainline 
und große Community.

Mir hat es zunächst gereicht, zu wissen, dass ich ein abgespecktes 
System überhaupt drauf kriege. Notfalls hätte ich später mit buildroot 
was ganz minimales auf altem Kernel stricken können, um noch ein paar 
Jahre hinzukommen. Dass die Hardware nochmal per Aldi unters Volk 
gebracht wird, konnte ich nicht ahnen - kommt mir natürlich jetzt 
gelegen.

@Sven
Große Klasse! Vielen Dank für deine Arbeit.

Ciao,

solo

von Sven B. (ft-)


Lesenswert?

Johann B. schrieb:
> Allerdings, was ist mit "ACHTUNG: Der Zugriff auf /dev/sda2 beschädigt
> das RAID" gemeint? In dem System mounte ich ja ohnehin nichts, oder?

Das Problem ist aber das es ein chroot-System ist, wenn von dort 
irgendwas an gemounteten Dateisystemen geschieht, so wirkt es sich 
insgesamt aus.


Johann B. schrieb:
> Habe ich was falsch gemacht, oder stimmt das wirklich? Ich habe übrigens
> die Aldi-Nord-Variante, die etwas teurer war und wohl eine größere
> Platte hat als das Gerät, das ihr scheinbar alle besitzt ;)

Es handelt sich im Grunde um die gleiche Hardware.
Einziger Unterschied 2TB statt 1,5TB. Alle die ihre 1,5TB Festplatte 
gegen eine 2TB Festplatte ersetzen, haben dann genau das was du auch 
hast.


@solo

Danke fürs Lob.

von Alex S. (alexander_s91)


Lesenswert?

sorry, dass ich hier noch mal so rein platze... ;o) leider sind durch 
meine copy-aktionen diverse berechtigungen in den ordnern abhanden 
gekommen, sodass ich einen teil erstmal wieder auf standard rücksetzen 
müsste. die berechtigungen über die web-oberfläche zu entfernen und neu 
anzulegen funktioniert leider nicht. ebenso kann ich via windows nix an 
deren einstellungen ändern. ich gehe mal stark davon aus, dass es nur 
via telnet mit dem root-account funktionieren wird. könntet ihr mir 
bitte noch verraten, wie ich allen ordnern inkl. unterordnern+dateien 
die standard-berechtigungen der shares zuweisen kann!? sprich: direkt in 
den shares (vorhanden oder neu angelegt) kann ich lesen+schreiben. in 
die darin kopierten ordner hab ich leider keine schreibrechte mehr und 
auch diverse user (root/504 z.b.), mag ich gern entfernen, um erstmal 
wieder ein frisches aufsetzen der accounts vornehmen zu können.

vielleicht besteht die möglichkeit die ordner der sda2 in knoppix zu 
mounten und dann grafisch die user zu bearbeiten? aktuell bekomme ich 
leider beim mounten in telnet, dass das system busy ist!?

~ # mount -t xfs /dev/sda2 /temp
mount: mounting /dev/sda2 on /temp failed: Device or resource busy

danke und ein gesundes neues noch! :o)

von BigMerlin (Gast)


Lesenswert?

Hallo zusammen,

mir ist aufgefallen das die Kiste per Samba schneller ist wie mit FTP...

weiß einer an was das liegt?

von Jens D. (jedie) Flattr this


Lesenswert?

Johann B. schrieb:
> Allerdings, was ist mit "ACHTUNG: Der Zugriff auf /dev/sda2 beschädigt
> das RAID" gemeint? In dem System mounte ich ja ohnehin nichts, oder?

Das gilt nicht für chroot, sondern, wenn man ArchLinuxARM bootet und die 
Platte benutzt. Kann man wahrscheinlich auch abstellen, wenn man das 
RAID auch als solches einbindet.

Johann B. schrieb:
> Ich habe übrigens
> die Aldi-Nord-Variante, die etwas teurer war und wohl eine größere
> Platte hat als das Gerät, das ihr scheinbar alle besitzt ;)

Kannst du mal nachsehen ob die Angaben bei P89626 auch für deines 
gelten. Insbesondere die Angaben bei P89626: Software. Der 
Vollständigkeitshalber könntest du die Info's deiner Platte im Wiki 
einfügen.


@Sven B.: Ich verfolge den Thread im Nachbarforum ( 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1865 ) gute Arbeit. 
Du bist ja recht Fleißig ;)

von Johann B. (johann_b)


Lesenswert?

Jens D. schrieb:
> Kannst du mal nachsehen ob die Angaben bei P89626 auch für deines
> gelten.

Exakt das selbe, soweit ich überprüfen konnte^^

von Alex S. (alexander_s91)


Lesenswert?

vielleicht noch mal ne ganz einfache frage!? ;o) ich habs jetzt 
geschafft meine platte mal wieder im telnet zu mounten (mount -t xfs 
/dev/md4 /temp), allerdings bekomm ich das mount nicht im dateimanager 
(pcmanagerfm) angezeigt, damit ich da endlich wieder grafisch ordnung in 
die rechteverwaltung reinbekommen kann. funktioniert mein vorhaben 
überhaupt?

die standard-shares haben ja root:root, während die erstellten via 
web-gui admin:root haben. nun hab ich durch die ganze kopiererei auch 
1000:1000 und 504:everyone drin, was natürlich total nervt und dazu 
führt, dass ich in besagte ordner nicht mehr schreiben kann. gibt es 
denn einen entspannten kniff, um den standard-shares wieder komplett 
(also auch darin enthaltenen ordnern+dateien) root:root zu erteilen, 
sowie selbiges für die manuell erstellten shares mit admin:root zu 
erreichen und gleichzeitig die ungeliebten 1000 und 504 zu entfernen? 
wie schauen denn die shares auf einem nicht durch ausbau der platte und 
kopier-marathon verhunzten nas aus?

an chmod mag ich mich ehrlich gesagt nicht unbedingt austoben...

von Sven B. (ft-)


Lesenswert?

Alex S. schrieb:
> sprich: direkt in
> den shares (vorhanden oder neu angelegt) kann ich lesen+schreiben. in
> die darin kopierten ordner hab ich leider keine schreibrechte mehr und
> auch diverse user (root/504 z.b.), mag ich gern entfernen, um erstmal
> wieder ein frisches aufsetzen der accounts vornehmen zu können.

root löscht man nicht. Es sei denn man möchte gleich ein Zurücksetzen 
der Einstellungen machen. Wenn du alles neu aufsetzen möchtest, dann 
benutze doch lieber die Funktion "Zurücksetzen auf Werkseinstellungen"

Alex S. schrieb:
> kann ich lesen+schreiben. in
> die darin kopierten ordner hab ich leider keine schreibrechte mehr

chmod a+w -R <ordner-name>

Das Problem wird sein, dass du auch die Eigentümer-Information verändert 
hast. Aber mit obiger Zeile kann jeder schreiben.

Jens D. schrieb:
> @Sven B.: Ich verfolge den Thread im Nachbarforum (
> http://archlinuxarm.org/forum/viewtopic.php?f=29&t=1865 ) gute Arbeit.
> Du bist ja recht Fleißig ;)

Ich möchte nun mal diese zurechtgeschusterte Geschichte loswerden.
Dies Frickelwerk, was PLX und Medion produziert haben, möchte ich ungern 
als Dauerbetriebslösung haben. Insbesondere wenn irgendwas schiefgeht, 
dann ist man mit solchen Lösungen auf sich allein gestellt. Erst recht 
dann wenn der Hersteller-Support ausläuft. (weil abgekündigt oder 
ähnliches). Mit einem sauberen System geschieht das jedenfalls nicht.

Ich werde auch nochmal den Ethernet-Treiber durchgehen und überprüfen.

Für ArchLinuxARM sollten die OX820-Kernel-Module (PLX782x) vorzugsweise 
Modulparameter verwenden, alles andere lässt sich mit Binaries faktisch 
nicht behandeln.

Ich werde auch noch schauen, ob die GPIO-Anbindung LED-Definitionen 
besitzt und wenn nein dann würde ich mir dazu auch die Mühe machen. Im 
SATA-Treiber ist der LED Trigger Support schon drin.

von Alex S. (alexander_s91)


Lesenswert?

>root löscht man nicht. Es sei denn man möchte gleich ein Zurücksetzen
>der Einstellungen machen. Wenn du alles neu aufsetzen möchtest, dann
>benutze doch lieber die Funktion "Zurücksetzen auf Werkseinstellungen"

das war natürlich ungeschickt vom mir ausgedrückt... der user 504 ist 
wohl mitglied der gruppe root, daher auch "/" und nicht "," ;o)
ich führe den werksreset gerade noch einmal durch, kann mir aber nicht 
vorstellen, dass er die rechte der ordner/dateien auf der 
daten-partition zurücksetzt, von daher bin ich noch nicht selbst auf 
diese idee gekommen. wäre natürlich klasse, falls er es doch tun würde!?

von Sven B. (ft-)


Lesenswert?

Alex S. schrieb:
> ich führe den werksreset gerade noch einmal durch, kann mir aber nicht
> vorstellen, dass er die rechte der ordner/dateien auf der
> daten-partition zurücksetzt, von daher bin ich noch nicht selbst auf
> diese idee gekommen. wäre natürlich klasse, falls er es doch tun würde!?

Wahrscheinlich nicht, aber dafür gibt es ja chmod.

von Alex S. (alexander_s91)


Lesenswert?

Sven B. schrieb:
> Wahrscheinlich nicht, aber dafür gibt es ja chmod.

aber wie bekomm ich damit auch wirklich wieder die "ausgangslage" aller 
berechtigungen her? help plz :-) jedenfalls resetted er nach wie vor 
kräftig, womit ich fast davon ausgehe, dass er doch alle dateien anfasst 
und möglicherweise auf root zurücksetzt!?

von Johann B. (johann_b)


Lesenswert?

Da ohnehin keine anderen Benutzer auf dem NAS agieren, kannst du doch 
ohnehin
> chmod 777 ./*
machen oder nicht?

von Sven B. (ft-)


Lesenswert?

Johann B. schrieb:
> Da ohnehin keine anderen Benutzer auf dem NAS agieren, kannst du doch
> ohnehin
>> chmod 777 ./*
> machen oder nicht?

Das muss eher so heissen

chmod -R 0777 ./*

Ohne 0 ist es zudem falsch wegen Oktalschreibweise.

sonst sind es nur die Dateien im aktuellen Ordner und nicht die 
Unterordner.


allerdings sollte bei Alex auch folgendes genügen

chmod -R a+w ./*

a+w => Dadurch werden die write bits für alle gesetzt.

so werden die Änderungen passieren:

0444 => 0666
0555 => 0777

von Alex S. (alexander_s91)


Lesenswert?

aktuell werkelt sie noch vor sich hin und lässt sich nicht mehr pingen. 
weder auf ihrer static 192.168.0.105, noch auf der ausgangs-ip 10.1.1.7 
... das kommt mir irgendwie bekannt vor und wird diesmal nicht von mir 
unterbrochen werden! ;o) sie scheint mit dem werksreset über die web-gui 
also auch am filesystem zu werkeln, sonst würde es ja nicht soooo lange 
für benötigen!? ich werde jedenfalls bis zum spindown der platte warten 
(das hat bisher ohne probs bei mir funktioniert) und dann berichten bzw 
ggf oben genannte tips in die tat umsetzen. bis dato

hoffentlich gibts keinen stromausfall... :oD

von Mijzelf A. (mijzelf)


Lesenswert?

I have adapted the FFP-stick to meet the read-only mount of the Medion. 
Any volunteers to test it? PM me for a download link.

von Sven B. (ft-)


Lesenswert?

Kernel 3.1 Update: Ich habe jetzt ein Stück Code implementiert, welches 
die GPIOs des OX820 am Standard-GPIO-Interface des Kernels anbindet. 
Somit existiert auch eine Brücke zum GPIO LED Support. Über diesen kann 
dann der LED Trigger des SATA-Treibers auf seinen Stamm-GPIO geschaltet 
werden.

Alle weiteren LEDs lassen sich natürlich damit auch bedienen.

Anmerkung: zur Zeit ist es noch ungetestet aber ich werde das noch tun.

Danach habe ich vor den GPIO Event Support einzubauen und dann kann man 
mit den Tastern sich auch bei ArchLinuxARM allerhand Sachen einfallen 
lassen.

von nikolay (Gast)


Lesenswert?

@Sven B.
Hey man du bist echt der Hammer, freue mich echt schon darauf wenn du
sagst "Aufgehts jetzt kann sich jeder den Kernel installieren"

Coole Sache ich freue mich echt das wir hier für das System so fähige 
Leute am start haben.

Macht nur weiter so.

Wenn ihr soweit seit kann man dann das system flashen und auch ohne TFTP 
boot den kernel starten oder ??

MfG der Niko

von solo (Gast)


Lesenswert?

Kann mich nur anschließen.

nikolay schrieb:
> Wenn ihr soweit seit kann man dann das system flashen und auch ohne TFTP
> boot den kernel starten oder ??
Das geht auch jetzt schon, wenn du die Platte ausbauen und an einen 
Linux-PC (sysresccd genügt) stecken kannst, Zugriff auf die serielle 
Konsole hast, dir die Infos's aus dem Thread hier zusammensuchst und 
viel googelst. Im wesentlichen musst du folgendes tun: Du kopierst das 
Image des Medion Kernels und die /lib/modules aus dem Medion System 
raus. Du spielst das Iomega-32MB-Image auf bzw. gehst nach 
http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2146 vor. Du 
korrigierst die Partitionierung. Das iomega-kernel-image überschreibst 
du mit dem rauskopierten Medion-kernel. Du entpackst das 
archlinux-oxnas-rootfs auf die erste Partition. Du kopierst die 
lib/modules aus dem Medion System an die richtige Stelle im neuen 
root-fs. Du bootest und unterbrichst über die serielle Konsole am u-boot 
Prompt. Du korrigierst die Kernel-Start-Parameter (RAM, rootfs) und 
schreibst sie auf die HDD. Danach solltest du Arch booten können, 
möglicherweise ohne Netzwerk, es können noch ein paar Feinarbeiten per 
Serieller Konsole notwendig sein. So solltest du zu einem per ssh 
erreichbaren, permanent von hdd bootenden Archlinux kommen. Auf den 
3.1er Kernel kannst du später umsteigen.

@ft
Dir ist klar, dass dir grade sicherlich ein paar dutzend Leute auf die 
Finger schauen? ;) Ich kann mein NAS leider nicht zur Dev-Box machen und 
deinem git-repo folgen, da ich auch wichtige Daten drauf habe. Deshalb 
muss ich für Kernel-Tests wenigstens die Platte wechseln. Bitte gib ein 
Zeichen, wenn du einen Stand hast, mit dem du halbwegs zufrieden bist!

Ciao,

solo

von Alex S. (alexander_s91)


Lesenswert?

ich meld mich auch mal wieder mit einer erkenntnis zu wort, die dem 
einen oder anderen vielleicht helfen mag. nachdem die nas nun 24h auf 
"wiederherstellung" gemacht hat, hab ich vorhin einfach mal den 
netzwerk!!!-stecker gezogen und siehe da, sie rödelte extremst vor sich 
hin und gipfelte im spindown der festplatte... jetzt werd ich sie wieder 
online nehmen, mal schauen wie es im bezug auf zugriff und 
rechte-verteilung ausschaut. bis später!

von Sven B. (ft-)


Lesenswert?

@solo

Das ist mir klar, dass etliche Leute jetzt darauf warten, den Kernel 
ohne diese wilden PLX-Hacks zu bekommen.

Ich werde auf meiner Box ohnehin ein Setup fahren, wo ich dann die Teile 
auch mal testen kann.

Deswegen verstehe ich auch, dass nicht alle gleich den Kernel 
installieren.


Den Umstieg auf 3.1 sehe ich auch als zukünftigen Schritt, da ja das 
Wegkommen von der Medion-Firmware auch mit dem 2.6er Kernel aus dem 
ArchLinuxARM bereits klappt. Interessierten Leuten, die den Kernel 3.1 
bereits ausprobieren wollen, können dies tun. Ist halt immer eine 
persönliche Abschätzung.

Der SATA-Treiber selbst ist aber soweit nutzbar. (WarheadsSE spielt 
damit schon eifrig in seinen Setups soweit ich das weiss).

Der GPIO-Teil kann dann mit kompiliert werden, muss aber nicht. Ist eine 
Kernel-Config-Option.

Das Thema wichtige Daten wird bei mir auch passieren. Allerdings habe 
ich ja sowohl das 1,5TB NAS als auch die 2TB USB Platte. Da kannst dir 
schon denken, was jetzt in Kürze passiert. 2TB rein und 1,5TB als USB.

Ich muss ohnehin mal schauen, wie die LED class Funktionalität bedient 
wird. Aber das kann ich mir auch beim OpenWRT anschauen, da wird das 
schon gemacht.

von EddieTheEagle (Gast)


Lesenswert?

Hallo,

nur mal zur Info. Habe nach Weihnachten eine Mail an den Medion Support 
bezüglich der NAS Problem (die euch ja bekannt sind) gesendet.
Heute bekam ich Antwort:
"Für die NAS Laufwerke steht ein Firmwareupdate zum Download bereit.
Über Administrator - Wartung - FW Update können Sie die aktualisierte 
Version 1.00 (UZD.2) herunterladen und installieren.
Wir hoffen, Ihnen mit diesen Informationen weitergeholfen zu haben"

Jetzt frage ich mich gerade, ob die mich veräppeln wollen. Erst mal sagt 
der NAS, das es keine Firmware gibt und zweitens ist das doch die 
Auslieferungsfw.

Gruß
Eddie

von Jens D. (jedie) Flattr this


Lesenswert?

EddieTheEagle schrieb:
> Version 1.00 (UZD.2)

Ja das ist keine neuere. Veräppelung ;)

In einem andern Forum hieß es, es soll Anfang 2012 eine neue Version 
geben.

Selbst wenn, ich glaube kaum das die einem Rundrum glücklich machen wird 
;)

von nikolay (Gast)


Lesenswert?

@solo
Danke für die Infos.
Ist es auch denkbar das bei der sache z.B.
ein update Image machbar ist welches ich wie bei einer Fritzbox 
einspiele
und danach hab ich halt arch linux am laufen und nicht dieses 
Zyxel/Medion ding. Oder sind da noch unbekannte im system der NAND Flash 
oder die stag0 zum Beispiel.

Mit deiner Anleitung könnte ich und sicherlich auch andere das ding 
umbasteln nur um eine größeren bereich an leuten ansprechen zu können 
ist es halt zu kompliziert.

Hat sich einer den aufbau des Firmware images von medion angesehen 
welche schritte der durchläuft um das system auf einen neuen stand zu 
flashen.
dies sollte sich für ein arch linux image doch auch benutzen lassen.

Oder sehe ich da was nicht.

Danke und mfg der Niko

von Sven B. (ft-)


Lesenswert?

@nikolay:

Da die Originalfirmware diesen USB-Rettungsstick-Support hat, könnte man 
darüber einen ArchLinux-Installer laufen lassen, welcher dann die 
Festplatte modifiziert.

Der Inhalt im NAND ist danach ohne Bedeutung.

Ich habe mir zwar das Firmware-Update-Format mal zum Teil angeschaut. 
Ist aber aufgrund des zuvor genannten völlig irrelevant.


Deswegen braucht es dort keine Firmware-Update-Datei.

Anders als die FritzBox, welche nur mit Flashes umgehen kann, kann das 
Medion NAS direkt von Platte booten.

von Jens D. (jedie) Flattr this


Lesenswert?

Ein Firmware Update kann über 
https://github.com/jedie/NAS7820-Tools/tree/master/usb_key_func 
realisiert werden.

Ich finde es jedoch besser, ein Alternatives Linux interaktiv zu 
installieren. Also usb_key_func nutzten um telnet zu starten und dann 
soll der User sich einloggen und per Hand ein/zwei install Skripte 
starten.

So ein richtiges Dummuser Update bringt doch nichts wenn eh nur ein 
"Nackes" Linux installiert wird.

von Sven B. (ft-)


Lesenswert?

Ich habe es noch nicht getestet, aber unter
https://github.com/ft-/NAS7820-Tools

habe ich mal einen archlinuxinstaller-medion Image für einen 
FAT-formatierten USB-Stick zusammengestellt.

ACHTUNG

Der Festplatten-Inhalt wird gelöscht.

von Nikolas R. (nikolas_r)


Lesenswert?

@Jens D.
Weil es einfacher und auch Fehler toleranter ist wenn man ein 
automatisches Install image hat. Damit ist auch all den jenen geholfen 
die z.B. für nen Freund (mal schnell) nen arch linux drauf installieren 
um dem z.B. für nen mac dort nen TimeMashine fähiges nas zu erzeugen 
usw.

Es geht hier gar nicht darum meiner Oma am Telefon zu sagen "He du hau 
dir arch linux drauf damit du schön software per pacman nach ziehen 
kannst"

Aber für alle anderen ist die Hürde ihr system erstmal aufschrauben 
usb2serial Adapter anklemmen usw. höher als wenn sie ein image 
einspielen und danach sich um die Applikation kümmern können als die 
zeit zu verwenden das ding umzuinstallieren.

Und des weitern lässt sich so auch ne art arch_linux__p89262 
Distribution mit den einsprechenden Modifikationen zusammen packen ohne 
stunden zu verbringen wer in welchen der vielen Foren jetzt nun wie was 
gemacht hat. Falls wir modifikation für das medion nas benötigen falls 
nicht reicht ja eine Standard ArchLinuxARM-oxnas.

@Sven B.
Cool sven das du da schon nen script gebaut hast, wenn ich das alles 
richtig verstehe geht das aber nur wenn ich per serieller console das 
usb_key_func.sh angebe, oder führt das system die datei aus wenn es 
einen usb stick erkennt.

von Jens D. (jedie) Flattr this


Lesenswert?

Ja ich würde halt 
https://github.com/ft-/NAS7820-Tools/blob/master/archlinuxinstaller-medion/do.sh 
aufteilen. Halt telnet starten und dann muß man den installer an werfen. 
Dann sieht man auch die Ausgaben und ob evtl. was schief läuft. 
Ansonsten ist das ja ohne JTAG ein Blindflug ;)

Außerdem wäre es dumm, wenn man versehentlich den Stick angeschlossen 
läßt ;)

von Nikolas R. (nikolas_r)


Lesenswert?

Gebe dir recht das es Blindflug ist, nur ist es ja auch bei einer 
Installation von einem Medion original Image genauso ein Blindflug.

Und nicht jeder hat ein JTAG Interface rumm liegen.
Ok ihr schon ;-)

Wie läuft es denn mit dem original Image, in dem befindet sich doch 
bestimmt ein zyxel tar und nen installer script oder liege ich da 
falsch?

Und mein Gedanke ist nun so ein image nachzubauen welches halt mit 
deinem install script plus dem arch linux zusammen gepackt ist. Und sich 
evtl. noch sogar als zucker inital per medion web gui installieren 
lässt. (das danach keine webgui mehr da ist, ist klar)

Wäre doch wirklich schön um das system auch bei anderen Leuten 
installieren zu können.

Oder was meint ihr bin ich da aufm Holzweg ???

Wollen wir es nur denen gönnen die sich trauen die Hardware auseinander 
zu nehmen und dann per console rum zubasteln.

MfG der Niko

von Sven B. (ft-)


Lesenswert?

Nikolas R. schrieb:
> Cool sven das du da schon nen script gebaut hast, wenn ich das alles
> richtig verstehe geht das aber nur wenn ich per serieller console das
> usb_key_func.sh angebe, oder führt das system die datei aus wenn es
> einen usb stick erkennt.

Sollte eigentlich automatisch gehen. Aber womöglich stimmt die Checksum 
noch nicht.

Jens D. schrieb:
> Außerdem wäre es dumm, wenn man versehentlich den Stick angeschlossen
> läßt ;)

Sobald ArchLinux läuft passiert nix mehr. Weil ArchLinux sich für diesen 
Stick nicht interessiert. Nur die Medion-Firmware interessiert sich 
dafür aber SATA hat Priorität und somit ist sobald das richtig 
eingerichtet ist, der Stick-Inhalt ohne Funktion.

Deswegen funktioniert der auch nur genau einmal.

Nikolas R. schrieb:
> Und mein Gedanke ist nun so ein image nachzubauen welches halt mit
> deinem install script plus dem arch linux zusammen gepackt ist. Und sich
> evtl. noch sogar als zucker inital per medion web gui installieren
> lässt. (das danach keine webgui mehr da ist, ist klar)

Ist kein tar und hat auch kein install script. Sind nur die Binaries 
und deren MD5 drin und der Updater liegt auf der Seite der bereits 
laufenden Original-Firmware. Darum wird der Weg nicht funktionieren. Wie 
gesagt ich habe mir dass Zeug angeschaut und es ist definitiv nicht 
möglich von dort auf die Festplatte zu kommen.

Die FritzBox hat ein anderes Firmware-Format. Nicht jeder Hersteller 
baut die Firmware auf dieselbe Weise zusammen.

Nikolas R. schrieb:
> Wollen wir es nur denen gönnen die sich trauen die Hardware auseinander
> zu nehmen und dann per console rum zubasteln.

Deswegen der USB-Stick, wenn der einmal richtig gemacht ist, dann 
funktioniert das auch ohne console. Nur diesen kann dann praktisch jeder 
mit einem beliebigen Betriebssystem bauen.

Anleitung z.B. wie folgt für den Anfang:

1. Leg das Zeug aus folgenden Zip auf einen FAT-formatierten Stick.
2. Stecke den Stick an das NAS
3. Starte das NAS neu
4. Warte bis es nochmal neustartet.

Man könnte auch noch die verbliebenen Schritte aus der 
ArchLinux-Installationsanleitung automatisieren. Diese benötigen aber 
nur telnet-Zugang.

von Sven B. (ft-)


Lesenswert?

Jens D. schrieb:
> Ja ich würde halt
> https://github.com/ft-/NAS7820-Tools/blob/master/a...
> aufteilen. Halt telnet starten und dann muß man den installer an werfen.
> Dann sieht man auch die Ausgaben und ob evtl. was schief läuft.
> Ansonsten ist das ja ohne JTAG ein Blindflug ;)

dann packst einfach das do.sh auf einen Stick mit der Erstfassung und 
telnet-Start. Dann hast doch genau das was dir beliebt.

Es ist im Moment der Erstentwurf aber ich würde definitiv den Weg der 
vollautomatisierten Variante gehen, weil das am sichersten ist und 
keinerlei login-Fragen nach sich zieht.

Muss halt nur noch vollständig sein und dann kann das jeder benutzen, um 
eine ArchLinux-Installation in wenigen Minuten drauf zu installieren, 
die im Übrigen gleich vom DHCP eine IP-Adresse holt.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> dann packst einfach das do.sh auf einen Stick mit der Erstfassung und
> telnet-Start. Dann hast doch genau das was dir beliebt.
>
> Es ist im Moment der Erstentwurf aber ich würde definitiv den Weg der
> vollautomatisierten Variante gehen, weil das am sichersten ist und
> keinerlei login-Fragen nach sich zieht.

Wenn ich Zeit hab, werde ich das mal umändern. Ich wollte eigentlich 
auch schon längst die anderen Flash Skripte ein wenig aufbohren...

Wie wäre die Variante:
Man muß eine Datei umbenennen, dann ist es voll automatisch. Im Original 
Zustand muß man allerdings die Installation per telnet machen.

Ich meine es sollte eh nur von Leuten gemacht werden, die eine Telnet 
Verbindung aufbauen können ;)

von Nikolas R. (nikolas_r)


Lesenswert?

Servus Leute,
@Jens hast schon recht so das minimal Verständnis um sich einzuloggen 
und meinetwegen auch nur per Anleitung etwas durchzuführen sollte schon 
da sein.

Die Idee vom Sven gefällt mir schon sehr gut.

Ist es es möglich das in so einer frühen Fase auch schon Meldungen per 
syslog verschickt werden, so könnte man wenn netzwerk vorhanden ist zum 
mindestens ab diesem punkt etwas erhalten un währe nicht ganz so blind.

Da ihr da ja mehr Ahnung habt wie sieht es mit dem 3.1 kernel eure 
Meinung nach aus, werden in diesem kernel auch alle teile die in diesem 
SOC sind angesprochen ??


MfG der Niko

von Lucian M. (lucian_m)


Lesenswert?

Nikolas R. schrieb:
> Da ihr da ja mehr Ahnung habt wie sieht es mit dem 3.1 kernel eure
> Meinung nach aus, werden in diesem kernel auch alle teile die in diesem
> SOC sind angesprochen ??

Apropos, Sven, habe mal Dein git repo geclont, macht es denn Sinn, 
drivers/mtd/nand/ox820_nand.c mit der entsprechenden Medion-typischen 
Partitionierung zu übernehmen? Wenn ja, kann ich Dir mal den 
entsprechenden Patch auf github schicken, falls Du an so 
Klein-Zuarbeiten interessiert bist mach' ich einen Fork.
Ich wollte eigentlich schon mal angucken über UART, wie sich der 3.1er 
Kernel aktuell so tut ;-). Ist denn ox820_pogoplug_defconfig ein guter 
Ausgangspunkt für die Konfiguration?
Geht derzeit die NIC? Wie sieht das mit der Firmware für den 
LEON-Coprocessor aus, kann man die in den sourcen ohne weiteres 
aufnehmen, oder eher nicht?

von Merz (Gast)


Lesenswert?

Hallo Leute,

ich verfolge nun schon seit Weihnachten hier eure Beiträge und finde das 
einfach nur genial was ihr hier auf die Beine stellt.
Jetzt habe ich aber ein paar fragen mal an euch.
Soweit ich das jetzt verstanden hab kann man mittels eines Usb Stick 
ArchLinux auf der Festplatte installieren.
Kriegt man denn die Platte dann noch in den schlafmodus oder rattert die 
dann immer durch?
Sollte mir das alles nicht gefallen kann man so wie ich das jetzt 
verstanden habe das Medion System problemlos wieder draufmachen oder?

Das Medion System hat so eine schöne weboberfläche mit Diaschau und 
Filmwiedergabe ist das dann mit arch auch möglich?

Zum Verwalten habe ich gelesen kann man Webmin draufspielen richtig?
Die ganzen möglichkeiten denke finde ich dann im ArchlLinux Wiki und wie 
man alles installiert oder?

Ich habe 2 gute gründe warum ich schon wechseln will.
1. Nach längerer nicht benutzung des Nas hat man kein zugriff mehr und 
nur ein reboot hilf.
2. Kein DualCore (echt ne frechheit)

Zum schluss ein GROßES DANKE an euch für die tolle arbeit und die zeit 
die ihr investiert habt

von solo (Gast)


Lesenswert?

Nikolas R. schrieb:
> Oder was meint ihr bin ich da aufm Holzweg ???
Nein, definitiv nicht. Ich habe deine Frage als Gelegenheit genutzt, 
auch für andere mal die wesentlichen Schritte zusammen zu schreiben. Das 
wird noch einfacher und defintiv auch ohne serielle Konsole möglich 
sein.

Der Vergleich mit der Fritzbox hinkt allerdings ziemlich: Bei der FB ist 
es kaum möglich, die Kernfunktionalitäten auf einer Standard-Distri 
nachzubauen und man kann/möchte das Gerät eh nur um wenige Funktionen 
ergänzen. Da ist der Weg über Zusatzpakete zur Firmware wesentlich 
attraktiver. Beim Medion NAS liegen diese Dinge anders, und es ist 
besser, eine Standard-Distri drauf zu bringen, die man dann mit deren 
Werkzeugen und Support(!) erweitern kann.

Das bringt uns zum nächsten Punkt: Die Community um ein einzelnes 
spezielles NAS-Gerät ist winzig - selbst wenn es von Aldi verkauft 
wird. Die Community um das SoC des Medion ist schon größer. Da kommen 
noch (interessierte) Iomega-, Zyxel- und Pogoplug-Besitzer dazu. Ohne 
wirklich gute Gründe sollte man keine Gerätespezialisierung betreiben 
und diese Gruppe spalten. Stell dir vor, du hast ein drei Jahre altes 
Medion-One-Klick-Installationsimage, das nicht mehr gepflegt wird und du 
bekommst es wegen irgendeiner Macke nicht mehr bis zu einem aktuellen 
ArchLinux upgedatet. Bei Arch liegen aktuellere Root-FS-Images und 
Kernel - aber du weißt nicht, wie du die zu einem Installer 
zusammenbäckst.

Ein 10-Punkte-Howto zu einem Gerät hat keinen Wartungsaufwand und 
funktioniert (sehr wahrscheinlich) auch in drei Jahren noch mit 
aktuellerer Software. Was ist so schlimm dran, paar Befehle zu tippen - 
musst du hinterher eh, um auch nur einen Bruchteil der NAS-Funktionen 
wieder drauf zu kriegen. Ein "pacman -S samba" reicht übrigens nicht, um 
die Box am Windows Rechner zu sehen.

Ciao,

solo

von Sven B. (ft-)


Lesenswert?

@Jens R.

Glaub mir am Telnet fällt denen eigentlich viel zu viel Mist ein.
Man könnte zwar telnet statt einer Shell einfach das Skript bei Login 
starten lassen. Aber prinzipiell gehe ich davon aus, dass die 
Umbenenn-Variante ruckzuck eine Default-Auto-Variante findet.

Das Problem an den Flash-Skripten ist, dass diese nicht in der 
Firmware-Datei sind. Somit würde es erst irgendwelche Modifikationen am 
DSL-Router und an der Firmware erfordern. Darum fällt die 
Firmware-Update-Methode im Grunde flach. Und es gibt genügend 
DSL-Router, wo die Leute keinen Zugriff auf die Administration haben 
(TR069 sei "dank").

Ich halte eine Installation nur für sinnvoll, die mit dem eigentlichen 
Gerät arbeitet und einen USB-Stick zu präparieren ist nunmal in der 
gleichen Liga wie ein Firmware-Mod bei Linux-Routern einspielen. 
Deswegen muss das Skript sicherlich noch ein paar Ergänzungen bekommen.

@Nikolas R.

soweit ich das sehe ist alles was für SATA-Boot nötig ist auch 
enthalten.

Für folgende Komponenten liegt eine Unterstützung vor.

GPIO (von mir neugebaut, ungetestet, nötig für LED-Trigger in 
SATA-Treiber)
SATA (von mir umgebaut, von WarheadsSE Lauffähigkeit bestätigt)
Ethernet (ist erstmal nur Port seitens ArchLinuxARM-Leuten)
Plattform-Support (Dual-Core, Port seitens ArchLinuxARM-Leuten)


@Lucian M.

Ich habe bei allen Modulen an denen ich gearbeitet habe nicht die 
Medion-Sourcen direkt übernommen sondern auch dabei entsprechend dem 
aktuellen Kernel aufgeräumt.

ox820_pogoplug_defconfig schaltet PCIe Support ein, den muss man noch 
ausschalten. Eine sinnvolle Medion-Kernel Config habe ich noch nicht als 
Default gemacht. Aber da würde ich auch eher sagen, dass dieser Build im 
Rahmen von ArchLinuxARM entsteht.

drivers/mtd/nand/ox820_nand.c ist für SATA-Boot ohne Bedeutung, da 
nichts vom Flash verwendet wird. Selbst das U-Boot Environment lässt 
sich dann auf Platte platzieren.

Dann kann man das Flash unangetastet lassen und hat im Grunde ein Gerät 
welches ausschliesslich durch Modifikationen auf der Festplatte mit 
ArchLinuxARM betrieben wird. Keine Flash-Modifikationen. Und wenn man 
die Platte wechselt kann man wieder den Stick benutzen.

Das ist selbst für die garantiefürchtigen Leute tragfähiger, denn die 
Festplatte ist ohnehin zugänglich durch die USB-Stick-Backdoor.

Das was ich zusammengestellt habe, soll erstmal ein HMNDCE-artiges Setup 
auf das Medion-NAS aufspielen. Damit gibt es dann eine Swap-Partition 
und eine grosse Partition für den Rest.

von Sven B. (ft-)


Lesenswert?

Merz schrieb:
> Sollte mir das alles nicht gefallen kann man so wie ich das jetzt
> verstanden habe das Medion System problemlos wieder draufmachen oder?

Bei der Methode, die ich für den Stick mir denke, reicht es die ersten 
paar Sektoren zu plätten und ein Neustart durchzuführen.

Dann kommt die Medion-Firmware wieder hoch als sei nix gewesen und will 
jungfräulich im WebGUI die Formatieraufforderung bekommen.

solo schrieb:
> Ein 10-Punkte-Howto zu einem Gerät hat keinen Wartungsaufwand und
> funktioniert (sehr wahrscheinlich) auch in drei Jahren noch mit
> aktuellerer Software. Was ist so schlimm dran, paar Befehle zu tippen -
> musst du hinterher eh, um auch nur einen Bruchteil der NAS-Funktionen
> wieder drauf zu kriegen. Ein "pacman -S samba" reicht übrigens nicht, um
> die Box am Windows Rechner zu sehen.

Deswegen mach ich das Skript so offensichtlich mit den Dateien, da kann 
dann jeder später den Kernel recht elegant einsetzen oder das Skript 
bedient sich gar gleich direkt am ArchLinuxARM Server und holt sich auch 
den Kernel dazu. Da haben wir nunmal mit diesen usb_key_func.sh Zeug 
eine Lösung, die wirklich die Installation einfach macht.

Für denjenigen der das eintippen mag, kann ja trotzdem jemand eine 
Anleitung zaubern. Nur haben wir auch einige interessierte 
Linux-Neulinge hier und da sind diese Befehle eben schnell mal falsch 
getippt und wenn der MBR bereits drauf ist, dann gute Nacht (heisst dann 
Platte ausbauen).

Dann passt die ganze Geschichte auch dann noch.

Die dd-Befehle roh zu tippen ist fehleranfällig und ich denke da sind 
einfach zu viele Fehler möglich. Selbst bei WarheadsSE Skripten für den 
PogoPlugPro finden sich Leute, die sich schwer damit tun.


Ich meine wir müssen da eher vergleichbar den OpenWRT-basierten Geräten 
mit solchen Skripten sein. Der Rest ganz simpel ArchLinuxARM mit 
gängigen Kernel-APIs und Userspace-API für Kernel-Funktionen. Nix für 
irgendein Board spezialisiertes.
Oder simpler gesagt, wenn MedionNAS spezifisches notwendig ist, dann ist 
es nur ein Paket mit userspace-Programmen wie jedes andere auch.

von solo (Gast)


Lesenswert?

> Soweit ich das jetzt verstanden hab kann man mittels eines Usb Stick
> ArchLinux auf der Festplatte installieren.
> Kriegt man denn die Platte dann noch in den schlafmodus oder rattert die
> dann immer durch?
Jein. Mit unverändertem Arch läuft sie durch oder viel zu oft wieder an, 
als gesund für die Hardware ist. Mit etwas Handarbeit kriegt man es hin. 
Man muss die Sachen finden, die in die Ramdisk gehören. Das hängt aber 
von den installierten Diensten ab.

> Sollte mir das alles nicht gefallen kann man so wie ich das jetzt
> verstanden habe das Medion System problemlos wieder draufmachen oder?
Nicht nötig, das bleibt im Flash unangetastet drauf. Du kannst im 
laufenden ArchLinux das stage1 von der Platte löschen und neu booten. 
Die Daten sind natürlich dann weg.

> Das Medion System hat so eine schöne weboberfläche mit Diaschau und
> Filmwiedergabe ist das dann mit arch auch möglich?
Theoretisch ja, ist aber aufwändig: Webserver installieren, passende 
(php-)Skripte finden, konfigurieren.

> Zum Verwalten habe ich gelesen kann man Webmin draufspielen richtig?
> Die ganzen möglichkeiten denke finde ich dann im ArchlLinux Wiki und wie
> man alles installiert oder?
So ist es.

Ciao,

solo

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Jein. Mit unverändertem Arch läuft sie durch oder viel zu oft wieder an,
> als gesund für die Hardware ist. Mit etwas Handarbeit kriegt man es hin.
> Man muss die Sachen finden, die in die Ramdisk gehören. Das hängt aber
> von den installierten Diensten ab.

Hier kann man ja spezialisierte Post-Install-Skripte bauen, die ein 
fstab erzeugen bei dem /var zum Beispiel im RAM landet usw.

von solo (Gast)


Lesenswert?

Sven B. schrieb:
> Ich meine wir müssen da eher vergleichbar den OpenWRT-basierten Geräten
> mit solchen Skripten sein. Der Rest ganz simpel ArchLinuxARM mit
> gängigen Kernel-APIs und Userspace-API für Kernel-Funktionen. Nix für
> irgendein Board spezialisiertes.
> Oder simpler gesagt, wenn MedionNAS spezifisches notwendig ist, dann ist
> es nur ein Paket mit userspace-Programmen wie jedes andere auch.
Okay, stimme ich zu. Für euch nicht so wichtig, aber ich sehe die 
Skriptlösung für die HMNHDCE noch nicht so ganz. Man müsste ja dem 
laufenden System das Root-FS unter den Füßen weg ziehen und gegen eines 
vom stick tauschen, um die Platte bearbeiten zu können. Mit pivot_root 
habe ich noch nicht rumgespielt.

Ciao,

solo

von solo (Gast)


Lesenswert?

Sven B. schrieb:
> Hier kann man ja spezialisierte Post-Install-Skripte bauen, die ein
> fstab erzeugen bei dem /var zum Beispiel im RAM landet usw.
var ist zu groß. Da liegt der Paketcache drunter. Ich habe ein Skript 
angepasst, das ausgewählte Unterverzeichnisse von var in die ramdisk 
verschiebt und beim runterfahren wieder zurück schreibt. Bei 
Filesharing-Kram wirds aber verrückt...

Ciao,

solo

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Okay, stimme ich zu. Für euch nicht so wichtig, aber ich sehe die
> Skriptlösung für die HMNHDCE noch nicht so ganz. Man müsste ja dem
> laufenden System das Root-FS unter den Füßen weg ziehen und gegen eines
> vom stick tauschen, um die Platte bearbeiten zu können. Mit pivot_root
> habe ich noch nicht rumgespielt.

Bei der Medion NAS USB-Stick-Lösung ist noch nichts von der Festplatte 
gemountet, somit kann der Stick mit der Platte anstellen was er will.

solo schrieb:
> var ist zu groß. Da liegt der Paketcache drunter. Ich habe ein Skript
> angepasst, das ausgewählte Unterverzeichnisse von var in die ramdisk
> verschiebt und beim runterfahren wieder zurück schreibt. Bei
> Filesharing-Kram wirds aber verrückt...

z.B. würde auch gehen:

ln -s /disk/cache /var/cache

von Sven B. (ft-)


Lesenswert?

Funktioniert auch die USB-Stick-Lösung nur zur Zeit installiert der noch 
kein lauffähiges System, danach heisst es ohne es genauer untersucht zu 
haben. Serielle Konsole haben. Aber wenn das korrigiert ist, dann sollte 
es durchstarten.

von Lucian M. (lucian_m)


Angehängte Dateien:

Lesenswert?

Mein erster Versuch, Sven's Kernel, konfiguriert (siehe Anhang) 
ausgehend von der Pogoplug-Konfig erweitert mit nfsroot-Möglichkeiten 
führte auch zu einem erfolgreichem (wenn auch nicht fehlerfreiem) Booten 
von Gentoo auf der Medion-NAS:
1
medion-nas-gentoo ~ # dmesg
2
[    0.000000] Initializing cgroup subsys cpuset
3
[    0.000000] Initializing cgroup subsys cpu
4
[    0.000000] Linux version 3.1.0ft+ (root@htpc2) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0, pie-0.4.6) ) #3 SMP Thu Jan 5 01:45:30 CET 2012
5
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
6
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
7
[    0.000000] Machine: Oxsemi NAS
8
[    0.000000] 1 memory region
9
[    0.000000] Ignoring unrecognised tag 0x00000000
10
[    0.000000] Memory policy: ECC disabled, Data cache writealloc
11
[    0.000000] On node 0 totalpages: 32768
12
[    0.000000] free_area_init_node: node 0, pgdat c0705800, node_mem_map c0799000
13
[    0.000000]   Normal zone: 256 pages used for memmap
14
[    0.000000]   Normal zone: 0 pages reserved
15
[    0.000000]   Normal zone: 32512 pages, LIFO batch:7
16
[    0.000000] PERCPU: Embedded 8 pages/cpu @c089c000 s10016 r8192 d14560 u32768
17
[    0.000000] pcpu-alloc: s10016 r8192 d14560 u32768 alloc=8*4096
18
[    0.000000] pcpu-alloc: [0] 0 [0] 1
19
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 32512
20
[    0.000000] Kernel command line: raid=autodetect root=/dev/nfs rw nfsroot=192.168.178.67:/usr/armv6j-unknown-linux-gnueabi ip=192.168.178.23:192.168.178.67:192.168.178.1::255.255.255.0::eth0:off console=ttyS0,115200 mac_adr=0x00,0x11,0x41,0x30,0x5B,0x71 elevator=cfq mem=128M poweroutage=yes
21
[    0.000000] PID hash table entries: 512 (order: -1, 2048 bytes)
22
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
23
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
24
[    0.000000] allocated 524288 bytes of page_cgroup
25
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
26
[    0.000000] Memory: 128MB = 128MB total
27
[    0.000000] Memory: 121560k/121560k available, 9512k reserved, 0K highmem
28
[    0.000000] Virtual kernel memory layout:
29
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
30
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
31
[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
32
[    0.000000]     vmalloc : 0xc8800000 - 0xed000000   ( 584 MB)
33
[    0.000000]     lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
34
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
35
[    0.000000]       .text : 0xc0008000 - 0xc0696000   (6712 kB)
36
[    0.000000]       .init : 0xc0696000 - 0xc06d2720   ( 242 kB)
37
[    0.000000]       .data : 0xc06d4000 - 0xc0708a08   ( 211 kB)
38
[    0.000000]        .bss : 0xc0708a2c - 0xc0798d2c   ( 577 kB)
39
[    0.000000] SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
40
[    0.000000] Hierarchical RCU implementation.
41
[    0.000000] NR_IRQS:96 nr_irqs:96 96
42
[    0.000000] OX820_RPS_init_irq: interrupts 64 to 96
43
[    0.000000] Console: colour dummy device 80x30
44
[    0.000000] console [ttyS0] enabled
45
[    0.020000] Calibrating delay loop... 298.59 BogoMIPS (lpj=1492992)
46
[    0.090000] pid_max: default: 32768 minimum: 301
47
[    0.090000] Mount-cache hash table entries: 512
48
[    0.100000] Initializing cgroup subsys cpuacct
49
[    0.100000] Initializing cgroup subsys memory
50
[    0.110000] Initializing cgroup subsys devices
51
[    0.110000] Initializing cgroup subsys freezer
52
[    0.120000] CPU: Testing write buffer coherency: ok
53
[    0.120000] ftrace: allocating 17824 entries in 53 pages
54
[    0.140000] Calibrating local timer... 375.04MHz.
55
[    0.210000] platform_smp_prepare_cpus 33
56
[    0.210000] hw perfevents: enabled with v6mpcore PMU driver, 3 counters available
57
[    0.220000] CPU1: Booted secondary processor
58
[    0.220000] CPU1: Unknown IPI message 0x1
59
[    0.300000] Brought up 2 CPUs
60
[    0.300000] SMP: Total of 2 processors activated (598.42 BogoMIPS).
61
[    0.310000] devtmpfs: initialized
62
[    0.310000] NET: Registered protocol family 16
63
[    0.320000] hw-breakpoint: found 6 breakpoint and 1 watchpoint registers.
64
[    0.320000] hw-breakpoint: maximum watchpoint size is 4 bytes.
65
[    0.340000] bio: create slab <bio-0> at 0
66
[    0.340000] SCSI subsystem initialized
67
[    0.350000] libata version 3.00 loaded.
68
[    0.350000] usbcore: registered new interface driver usbfs
69
[    0.350000] usbcore: registered new interface driver hub
70
[    0.360000] usbcore: registered new device driver usb
71
[    0.360000] cfg80211: Calling CRDA to update world regulatory domain
72
[    0.370000] Switching to clocksource rps-timer2
73
[    0.420000] NET: Registered protocol family 2
74
[    0.430000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
75
[    0.430000] TCP established hash table entries: 4096 (order: 3, 32768 bytes)
76
[    0.440000] TCP bind hash table entries: 4096 (order: 3, 32768 bytes)
77
[    0.450000] TCP: Hash tables configured (established 4096 bind 4096)
78
[    0.450000] TCP reno registered
79
[    0.460000] UDP hash table entries: 128 (order: 0, 4096 bytes)
80
[    0.460000] UDP-Lite hash table entries: 128 (order: 0, 4096 bytes)
81
[    0.470000] NET: Registered protocol family 1
82
[    0.470000] RPC: Registered named UNIX socket transport module.
83
[    0.480000] RPC: Registered udp transport module.
84
[    0.480000] RPC: Registered tcp transport module.
85
[    0.490000] RPC: Registered tcp NFSv4.1 backchannel transport module.
86
[    0.520000] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
87
[    0.520000] JFS: nTxBlock = 949, nTxLock = 7597
88
[    0.530000] SGI XFS with security attributes, no debug enabled
89
[    0.540000] msgmni has been set to 237
90
[    0.550000] io scheduler noop registered
91
[    0.550000] io scheduler deadline registered
92
[    0.550000] io scheduler cfq registered (default)
93
[    0.890000] Serial: 8250/16550 driver, 32 ports, IRQ sharing enabled
94
[    0.910000] serial8250: ttyS0 at MMIO 0x44200000 (irq = 55) is a 16550A
95
[    1.880000] ox820sata: OX820 sata core.
96
[    1.880000] scsi0 : oxnassata
97
[    1.890000] scsi1 : oxnassata
98
[    1.890000] ata1: SATA max UDMA/133 irq 50
99
[    1.890000] ata2: SATA max UDMA/133 irq 50
100
[    1.900000] sata_ox820: Initialized
101
[    1.900000] Probing for Synopsis GMAC, unit 0
102
[    1.910000] eth0: Tuning GMAC 0 RGMII timings
103
[    1.910000] eth0: Unknown PHY, type 0x001cc915
104
[    1.920000] eth0: GMAC ver = 53, vendor ver = 18 at 0xed400000, IRQ 40
105
[    1.920000] eth0: Found PHY at address 7, type 0x001cc915 -> 10/100/1000
106
[    1.930000] eth0: Ethernet addr: 00:30:e0:00:00:00
107
[    1.940000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
108
[    1.940000] Initializing Oxnas-SoC USB Host Controller
109
[    1.950000] oxnas-ehci oxnas-ehci.0: OXNAS EHCI
110
[    1.950000] oxnas-ehci oxnas-ehci.0: new USB bus registered, assigned bus number 1
111
[    1.990000] oxnas-ehci oxnas-ehci.0: irq 39, io mem 0x40200100
112
[    2.010000] oxnas-ehci oxnas-ehci.0: USB 0.0 started, EHCI 1.00
113
[    2.010000] hub 1-0:1.0: USB hub found
114
[    2.020000] hub 1-0:1.0: 2 ports detected
115
[    2.020000] Initializing USB Mass Storage driver...
116
[    2.030000] usbcore: registered new interface driver usb-storage
117
[    2.030000] USB Mass Storage support registered.
118
[    2.040000] mousedev: PS/2 mouse device common for all mice
119
[    2.040000] md: linear personality registered for level -1
120
[    2.050000] md: raid0 personality registered for level 0
121
[    2.050000] md: raid1 personality registered for level 1
122
[    2.060000] cpuidle: using governor ladder
123
[    2.060000] usbcore: registered new interface driver usbhid
124
[    2.070000] usbhid: USB HID core driver
125
[    2.070000] oprofile: using arm/mpcore
126
[    2.080000] TCP cubic registered
127
[    2.080000] NET: Registered protocol family 10
128
[    2.090000] IPv6 over IPv4 tunneling driver
129
[    2.100000] NET: Registered protocol family 17
130
[    2.100000] Registering the dns_resolver key type
131
[    2.110000] VFP support v0.3: not present
132
[    2.110000] drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
133
[    2.140000] eth0: Unknown PHY, type 0x001cc915
134
[    2.140000] Offload is not active on eth0
135
[    2.140000] Alloc'ing ARM descs 10240 bytes
136
[    2.150000] eth0: Resetting GMAC
137
[    2.150000] eth0: GMAC reset complete
138
[    2.160000] eth0: Setting Rx flow control thresholds for LAN port
139
[    2.810000] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
140
[    2.810000] ata1.00: ATA-8: ST1500DL003-9VT16L, CC4A, max UDMA/133
141
[    2.820000] ata1.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 0/32)
142
[    2.830000] ata1.00: configured for UDMA/133
143
[    2.830000] scsi 0:0:0:0: Direct-Access     ATA      ST1500DL003-9VT1 CC4A PQ: 0 ANSI: 5
144
[    2.840000] sd 0:0:0:0: [sda] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB)
145
[    2.850000] sd 0:0:0:0: [sda] 4096-byte physical blocks
146
[    2.850000] sd 0:0:0:0: [sda] Write Protect is off
147
[    2.860000] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
148
[    2.860000] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
149
[    2.890000]  sda: sda1 sda2
150
[    2.890000] sd 0:0:0:0: [sda] Attached SCSI disk
151
[    3.190000] ata2: SATA link down (SStatus 0 SControl 300)
152
[    5.170000] ADDRCONF(NETDEV_UP): eth0: link is not ready
153
[    6.170000] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
154
[    6.190000] IP-Config: Guessing netmask 255.255.255.0
155
[    6.190000] IP-Config: Complete:
156
[    6.190000]      device=eth0, addr=192.168.178.23, mask=255.255.255.0, gw=192.168.178.1,
157
[    6.200000]      host=255, domain=, nis-domain=255.255.0,
158
[    6.210000]      bootserver=192.168.178.67, rootserver=192.168.178.67, rootpath=
159
[    6.220000] md: Waiting for all devices to be available before autodetect
160
[    6.220000] md: If you don't use raid, use raid=noautodetect
161
[    6.230000] md: Autodetecting RAID arrays.
162
[    6.230000] md: Scanned 0 and added 0 devices.
163
[    6.240000] md: autorun ...
164
[    6.240000] md: ... autorun DONE.
165
[    6.290000] VFS: Mounted root (nfs filesystem) on device 0:12.
166
[    6.300000] devtmpfs: mounted
167
[    6.300000] Freeing init memory: 240K
168
[   10.400000] udev[160]: starting version 164
169
[   11.950000] md: bind<sda2>
170
[   11.990000] bio: create slab <bio-1> at 1
171
[   11.990000] md/raid1:md127: active with 1 out of 2 mirrors
172
[   11.990000] md127: detected capacity change from 0 to 1499772813312
173
[   12.890000]  md127: unknown partition table
174
[   16.880000] eth0: no IPv6 routers present
175
medion-nas-gentoo ~ #

von Jens D. (jedie) Flattr this


Lesenswert?

Also ich sehe das so: Solange nach dem ArchLinux Installation keine 
Web-GUI existiert, ist die ganze Sache eh nicht für Otto-Normalo 
benutzbar.

Was nutzt eine "Ein-Klick" installer, wenn danach nur ein nacktes 
ArchLinuxARM läuft?

Mir reicht ein nacktes System, bei dem ich meine benötigten Dienste 
(NFS/Samba) Einrichte und gut.

von Jens D. (jedie) Flattr this


Lesenswert?

Jens D. schrieb:
> Ihr meint den Teil:
>
1
perl <<EOF | dd of="$disk" bs=512
2
>     print "\x00" x 0x1a4;
3
>     print "\x00\x5f\x01\x00";
4
>     print "\x00\xdf\x00\x00";
5
>     print "\x00\x80\x00\x00";
6
>     print "\x00" x (0x1b0 -0x1a4 -12 );
7
>     print "\x22\x80\x00\x00";
8
>     print "\x22\x00\x00\x00";
9
>     print "\x00\x80\x00\x00";
10
> EOF
11
>
>
> Kenne mich leider nicht mit perl aus. Weiß also nicht was da genau
> passiert. Auf der anderen Seite, könnte man das irgendwo machen, wo perl
> installiert ist und dann per dd in einer Datei schreiben und gut...

So ich hab mir das ganze nochmal angesehen. Es wird ein String mit einer 
länge von 444Bytes zusammen gebaut. Hab das Skript mal geändert und die 
Ausgabe von Perl in einer Datei rein geschrieben:
1
#!/bin/bash
2
perl <<EOF | dd of=test.dat bs=512
3
    print "\x00" x 0x1a4;
4
    print "\x00\x5f\x01\x00";
5
    print "\x00\xdf\x00\x00";
6
    print "\x00\x80\x00\x00";
7
    print "\x00" x (0x1b0 -0x1a4 -12 );
8
    print "\x22\x80\x00\x00";
9
    print "\x22\x00\x00\x00";
10
    print "\x00\x80\x00\x00";
11
EOF

0x1a4 ist die Zahl 420, also:
1
print "\x00" x 0x1a4;
sind 420 mal einen NULL String

Lustig ist, das diese Zeile vollkommen überflüssig ist:
1
print "\x00" x (0x1b0 -0x1a4 -12 );
Denn 0x1b0 ist 432 und 0x1a4 ist 420 also: 432 - 420 - 12 sind 0 ! print 
macht also nichts ;)

In Python kann man den String auch so zusammen bauen (die überflüssige 
Zeile weg gelassen):
1
sequnce = "\x00" * 420 + (
2
    "\x00\x5f\x01\x00"
3
    "\x00\xdf\x00\x00"
4
    "\x00\x80\x00\x00"
5
    "\x22\x80\x00\x00"
6
    "\x22\x00\x00\x00"
7
    "\x00\x80\x00\x00"
8
)

Ich frage mich, ob die ersten 420 NULL Bytes überhaupt nötig sind, oder 
einfach nur zum auffüllen da sind. Also ob stage1 wirklich die ganzen 
444Bytes auswertet, oder einfach nur die letzten 24Bytes.

von Jens D. (jedie) Flattr this


Lesenswert?

Ich hab unter 
https://github.com/jedie/NAS7820-Tools/tree/master/sata_start_sequence 
mal ein paar Skripte zu der erzeugung der Start Sequenz hinterlegt. 
Dient ehr der Dokumentation als einen zweck...

Außerdem hab ich P89626: SATA Boot angefangen, um mehr klarheit zu 
schaffen. Muß aber noch ausgebaut werden ;)

von Nikolas R. (nikolas_r)


Lesenswert?

Servus Leute,
@jedie Kritischere bereiche werden so automatisiert und es gibt weniger 
Fehler und gebrickte boxen auf für leien und das man wenn man alles 
manuel machen möchte eine serielle console benötigt.
Klar wäre as noch fein wenn anschließend noch ein script laufen würde 
welches Samba/NFS und so weiter einrichtet aber das muss erstmal nicht 
sein. Es reicht schon die Gewissheit das sich das system ohne Probleme 
umstellen läst.

Übrigens @Sven da fällt mir ein in deinem script könnte man ja noch 
diverse configs vom alt system ins arch rüber kopieren (smb.conf,nfs 
exports hosts usw.) bzw. alt dafür auch die passenden Verzeichnisse 
anlegen. Ich weis das geht jetzt evtl. schon etwas zu weit da die Daten 
durchs umformatieren eh weg sind aber zu-mindestens hätte man nach dem 
um installieren ein laufenden nas server mit den alten freigaben.

@Solo
du hast ja recht :-) das beispiel sollte nur da zu dienen ein 
vereinfachtes Instalations verfahren zu verdeutlichen.

@Lucia Wie gentoo wie lange braucht das teil um sich da durch zu 
compilieren oder warst du ungeduldig und hast fertige binaries 
installiert. Wie ist den so der support für arm unter gentoo ???

von solo (Gast)


Lesenswert?

Sven B. schrieb:
> Bei der Medion NAS USB-Stick-Lösung ist noch nichts von der Festplatte
> gemountet, somit kann der Stick mit der Platte anstellen was er will.
Davon red ich ja. Für das iomega HMNHDCE muss dafür noch eine Lösung 
gefunden werden, was bei euren Boxen nicht der Fall ist.

@Jens D.
> sucht stage1 Bootloader im Flash zuerst auf der SATA Platte nach einem 
alternativen stage1

Du hast da immer noch einen Denkfehler drin. Es gibt keinen Flash auf 
dem iomega HMNHDCE. Da ist gar kein Chip auf dem Board. Wenn keine 
vorbereitete Platte dran hängt, gibt das Ding keinen Mucks von sich, 
kein Lämpchen geht an, keine einzige Zeile auf der Seriellen Konsole - 
nix, nada.

Beim Booten wird deshalb auch nicht von einem stage1 zum alternativen 
gesprungen. Der 7820 lädt seinen stage1 grundsätzlich immer zuerst von 
SATA, auch auf euren Medions. Wenn dort keiner ist, wird er beim Medion 
aus dem Flash geladen, während das HMNHDCE einfach stehen bleibt. Nur 
die Bedeutung der Binärsequenz im ersten Sektor ist noch unklar.

Ich finde es ziemlich genial, einen Rechner fast ab den ersten Bits, die 
überhaupt in der CPU wackeln, von einer austauschbaren Festplatte zu 
starten. Das macht ihn nämlich so gut wie unkaputtbar.

Ciao,

solo

von Jens D. (jedie) Flattr this


Lesenswert?

solo schrieb:
> Du hast da immer noch einen Denkfehler drin. Es gibt keinen Flash auf
> dem iomega HMNHDCE.

Stimmt, aber ich dachte dabei auch ehr an die Medion Box ;) Ich hab 
versucht im Wiki das klar zu stellen. Kannst aber natürlich mit arbeiten 
und selbst abändern ;)

von Lucian M. (lucian_m)


Lesenswert?

Nikolas R. schrieb:
> Wie gentoo wie lange braucht das teil um sich da durch zu
> compilieren oder warst du ungeduldig und hast fertige binaries
> installiert. Wie ist den so der support für arm unter gentoo ???

Also ich war da nicht ungeduldig, sondern habe mir nach ein bisschen 
Recherche einen zur CPU passenden toolchain generiert und damit aus 
einem anderem Gentoo-System (amd64) die für das rootfs benötigten Pakete 
cross-emerged, also kompiliert. Somit sind es ganz aktuelle, ich muß 
nicht auf jemanden warten, mir die zu kompilieren, usw. Natürlich gibt 
es auch Probleme, wie z.B. Pakete die sich nicht cross-kompilieren 
lassen, die habe ich dann nativ auf der NAS erstmal in einem chroot, 
dann später als ich sie über NFS-Root booten konnte, unter wirklich 
nativ gebootetem Gentoo kompiliert. Cross-emergen geht natürlich viel 
schneller als natives Kompilieren, wenn der PC auch aktueller ist.

Support hat für einen eher typischen Gentoo-User einen weiteren Sinn. Er 
erwartet z.B. nicht fertig kompilierte Pakete von irgendwem, weil durch 
die Natur der Sache die immer am Zielsystem bei der Installation, 
konsistent mit den vorgefundenen Abhängigkeiten kompiliert werden. Das 
heißt nicht dass es nicht auch die Möglichkeit gibt, fertige Binaries zu 
installieren. Unter diesen Umständen lernt man dann auch, wie man sich 
selber hilft wenn es ein gewisses Paket, oder eine Version davon nicht 
gibt, man erstellt das Ebuild (ist ein spezielles Skript welches eine 
Paketversion definiert, und zwar von wo die Sourcen heruntergeladen 
werden und wie sie kompiliert und nacher installiert werden) dann 
selber. Support holt man sich durchaus in der Community (Foren, 
Bugtracker, IRC, auch mal ARM-spezifisch wenn ein Paket beim Kompilieren 
oder zur Laufzeit unter ARM zickt.

Nachdem so ein Rootfs gut läuft, kann man es auch anderen mit einer 
Installationsanleitung zur Verfügung stellen (hatte ich schon mal für 
Linkstation Pro gemacht). Die fliessende Aktualisierung des Systems 
macht dann aber jeder Einzelne selber, zumal er auch durch sogenannte 
USE flags beieinflussen kann, welche Features welche Abhängigkeiten beim 
Kompilieren einbinden, um sich nach Eigenen Vorstellungen das System 
maßzuschneidern. Wegen der schwachbrüstigen NAS kann man immer ein 
cross-toolchain dafür zur Hilfe nehemn, aber dafür braucht man auch ein 
Gentoo-PC, danach emerged man die binaries auf die NAS, kompiliert dort 
nativ nur jene Pakete die es unbedingt so wollen...

All dies ist natürlcih nicht jedermanns Sache...

von Sven B. (ft-)


Lesenswert?

@all

ArchLinux:

ist eine gute Basis zwischen Beeinflussbarkeit und Aktualisierbarkeit.
Auch Linux-erfahrene Leute haben irgendwann keine Lust mehr sich jedes 
Paket zu kompilieren.

Debian:

sehr hoher Anspruch an Stabilität (APIs usw.) innerhalb einer 
Distribution. Deshalb auch manche Pakete nur in älteren Versionen oder 
Backports verfügbar.

Gentoo:

erfordert für Aktualisierungen immer Kompilationen. Ist also eher was 
für den Linux-Bewanderten.


Anmerkung:

Ich habe schon mal LFS durchgezogen. Da ist dann die Updatebarkeit 
komplett in eigener Hand. Allerdings bedeutet Updaten dann auch echt 
viel Zeit.
Zum Zeitaufwand liegt Gentoo am nächsten.
Zur Aktualität sind sowohl Gentoo als auch ArchLinux dicht auf LFS 
(sofern man die LFS-Anleitung als Blaupause versteht).

Ich denke eine Binärdistribution wird irgendwann gehäuft sein. Wie sagt 
man so schön: Ausnahmen bestätigen die Regel.

Ich habe kein Problem damit wenn jemand sich lieber mit Gentoo usw. auf 
dem NAS betätigen möchte.

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> Davon red ich ja. Für das iomega HMNHDCE muss dafür noch eine Lösung
> gefunden werden, was bei euren Boxen nicht der Fall ist.

Stimmt bei direkt beim Start gemounteten Dateisystem wie bei der iomega 
HMNDCE wird das tatsächlich schwieriger, pivot_root funktioniert aber 
auch nur bei einer sehr frühen Phase im Bootprozess. Später ist soviel 
eingebunden und gestartet, dass man da schon ein recht üppiges Skript 
zum Alles-Beenden benötigt.

Dazu braucht man eine statische Busybox und dann das pivot_root daraus 
und das erste ist im Grunde ein töte alles was nicht sein darf. Wird nur 
beim /sbin/init schwierig, weil der Kernel diesen am Leben halten will.

Für pivot_root muss erstmal alles beendet werden. Daher ist der 
Knackpunkt den laufenden /sbin/init loszuwerden.

Anonsten klappt das Unmounten nicht.

von Sven B. (ft-)


Lesenswert?

Ich habe den Installer nochmal auf Basis der PogoPlugPro Dateien gebaut.

Mit einer solchen Installation habe ich auch erstmal ein lauffähiges 
System realisiert.

http://www.github.com/ft-/NAS7820-Tools

und dann

archlinuxinstaller-medion-pogoplugpro-based

von Lucian M. (lucian_m)


Lesenswert?

@Sven:

Im 3.1-er Kernel ist derzeit arch/arm/plat-oxnas komplett weg. Das sind 
doch die von Dir und ElektroMan angesprochenen schlecht implementierten 
Tricksereien die Ihr jetzt the right way implementiert oder auch wegen 
geringem Gewinn weglasst? Da war auch der LEON-Support drin, nun tut ja 
die NIC auch ohne, aber kann es damit zu tun haben dass die in der 
Kernel-Kommandozeile übergebene MAC-Adresse nicht angenommen wird?

von solo (Gast)


Lesenswert?

Jens D. schrieb:
> Stimmt, aber ich dachte dabei auch ehr an die Medion Box ;) Ich hab
> versucht im Wiki das klar zu stellen. Kannst aber natürlich mit arbeiten
> und selbst abändern ;)
Der Zaunspfahl traf. ;) Ich habe den Abschnitt umformuliert und ergänzt. 
Wir müssten mal den ganzen Artikel entmüllen und die Umgangssprache 
rausmachen.

Ist das Zeug in Sektor 1 eine Art Parameterspeicher für den ROM-Code im 
SoC? Ein Äquivalent des Ergebnisses von "Einstellungen speichern" im 
PC-BIOS? Zweimal x80 für 128 MiB RAM und 128 MiB Flash? x22 ist der 
Startblock des stage1 in hex...

@ft
Hab dein Skript überflogen, sieht gut aus. Über die Partitionierung und 
ext3 könnte man natürlich endlos diskutieren... ;)

> Stimmt bei direkt beim Start gemounteten Dateisystem wie bei der iomega
> HMNDCE wird das tatsächlich schwieriger, pivot_root funktioniert aber
> auch nur bei einer sehr frühen Phase im Bootprozess.
Ich müsste in der initrd nachschauen, ob man dort irgendwie unterbrechen 
und ein eigenes rootfs unterschieben kann - ähnlich eurem 
usb-parner-dings. Nachteil wäre, dass das mit neueren Firmwares wieder 
geändert werden könnte. Kexec scheidet aus, ist nicht im Kernel drin.

Ciao,

solo

von noxx (Gast)


Lesenswert?

Wäre es später auch denkbar, ein Display am NAS laufen zu lassen? Zwecks 
Info, wie Speicherplatz, RAM und CPU Last, etc
zb dieses: http://linuxnetwork.li.funpic.de/v2_addon_ax206.html

Gruss

von Sven B. (ft-)


Lesenswert?

Lucian M. schrieb:
> Im 3.1-er Kernel ist derzeit arch/arm/plat-oxnas komplett weg. Das sind
> doch die von Dir und ElektroMan angesprochenen schlecht implementierten
> Tricksereien die Ihr jetzt the right way implementiert oder auch wegen
> geringem Gewinn weglasst? Da war auch der LEON-Support drin, nun tut ja
> die NIC auch ohne, aber kann es damit zu tun haben dass die in der
> Kernel-Kommandozeile übergebene MAC-Adresse nicht angenommen wird?

Ich habe gerade den 3.1er Kernel bei mir eingerichtet. Und die 
Netzwerkverbindung tut soweit.

Das mit der MAC-Adresse kommt eher daher, dass bei ArchLinuxARM die 
MAC-Adresse in so einer netten Datei namens /usr/local/mac_addr liegt.

Mein kleines Setup-Skript automatisiert das. Deswegen spürt man das dann 
nicht mehr.

solo schrieb:
> Ist das Zeug in Sektor 1 eine Art Parameterspeicher für den ROM-Code im
> SoC? Ein Äquivalent des Ergebnisses von "Einstellungen speichern" im
> PC-BIOS? Zweimal x80 für 128 MiB RAM und 128 MiB Flash? x22 ist der
> Startblock des stage1 in hex...

Das kann durchaus sein. Ohne SoC-Manual wird man das aber nicht 
rausbekommen.

solo schrieb:
> @ft
> Hab dein Skript überflogen, sieht gut aus. Über die Partitionierung und
> ext3 könnte man natürlich endlos diskutieren... ;)

hab erst mal die PogoPlugPro-Formatierung übernommen + Swap

RAM-Menge ist ja bei PogoPlugPro und Medion NAS erstmal gleich.

solo schrieb:
> Ich müsste in der initrd nachschauen, ob man dort irgendwie unterbrechen
> und ein eigenes rootfs unterschieben kann - ähnlich eurem
> usb-parner-dings. Nachteil wäre, dass das mit neueren Firmwares wieder
> geändert werden könnte. Kexec scheidet aus, ist nicht im Kernel drin.

Vielleicht existiert ja sowas bei HMNDCE

von Lucian M. (lucian_m)


Lesenswert?

Sven B. schrieb:
> Das mit der MAC-Adresse kommt eher daher, dass bei ArchLinuxARM die
> MAC-Adresse in so einer netten Datei namens /usr/local/mac_addr liegt.

Ok, da haben wohl die ArchLinux-guys ein workaround bevorzugt.

Naja, ich habe weiter probiert, und festgestellt dass es doch geht wenn 
man den Parameter mit dem Modul-Namen präfixiert:
1
gmac.mac_adr=0x00,0x11,0x41,0x..,0x..,0x..

von Sven B. (ft-)


Lesenswert?

Lucian M. schrieb:
> Ok, da haben wohl die ArchLinux-guys ein workaround bevorzugt.
>
> Naja, ich habe weiter probiert, und festgestellt dass es doch geht wenn
> man den Parameter mit dem Modul-Namen 
präfixiert:gmac.mac_adr=0x00,0x11,0x41,0x..,0x..,0x..

Die U-Boot-Parameter, dafür zu erzeugen müssen, war wahrscheinlich der 
Grund warum die Datei als Alternative bevorzugt wurde.

von Jens D. (jedie) Flattr this


Lesenswert?

Sven B. schrieb:
> solo schrieb:
>> Davon red ich ja. Für das iomega HMNHDCE muss dafür noch eine Lösung
>> gefunden werden, was bei euren Boxen nicht der Fall ist.
>
> Stimmt bei direkt beim Start gemounteten Dateisystem wie bei der iomega
> HMNDCE wird das tatsächlich schwieriger, pivot_root funktioniert aber
> auch nur bei einer sehr frühen Phase im Bootprozess. Später ist soviel
> eingebunden und gestartet, dass man da schon ein recht üppiges Skript
> zum Alles-Beenden benötigt.

Kann man bei dem iomega HMNDCE nicht auch komplett vom USB Stick booten? 
Was passiert, wenn man die magischen ersten 32MB auf einen USB Stick 
anlegt?

von solo (Gast)


Lesenswert?

Jens D. schrieb:
> Kann man bei dem iomega HMNDCE nicht auch komplett vom USB Stick booten?
Komplett wahrscheinlich nicht, siehe unten. Das ist auch nicht unbedingt 
nötig - images von der Platte in den RAM zu ziehen ist kein Problem. 
Erst wenn ein Root-FS von Platte gemountet wird, entstehen die Fäden an 
denen das laufende System dann hängt und von denen es schwer zu trennen 
ist. Wenn man also in den Skripten der initrd eingreift, reicht das aus. 
Dort könnten alle Mittel vorhanden sein, um ein FS von USB zu mounten. 
Ich habe gestern versucht, die initrd zu entpacken - hat aber nicht 
funktioniert. Vorher kann ich nicht reinschauen, ob dort was 
implemetiert ist analog zu eurem parner-stick-zeugs. kexec wäre noch ein 
guter Weg gewesen, ist aber im Stock-Kernel nicht drin. Falls in der 
initrd nichts brauchbares ist, bleibt wirklich nur noch pivot_root in 
einem so weit wie möglich runtergefahrenen System.

Die "Brick-Gefahr" ist damit hoch für so einen Prozess. Aber das lässt 
sich nicht vermeiden bei einem NAS ganz ohne Flash. Als Notnagel bleibt 
ja immer das Anschließen der Festplatte an einen PC. Und den hat jeder, 
der ein NAS kauft - im Gegensatz zum USB-UART-Adapter. Eine solide 
Vorgehensweise, die Platte am PC zu bespielen, ohne per serieller 
Konsole eingreifen zu müssen, ist deshalb die Hauptsache. Das auch ohne 
Ausbau der Platte hinzukriegen wäre nur ein nettes Add-on.

> Was passiert, wenn man die magischen ersten 32MB auf einen USB Stick
> anlegt?
Ohne es probiert zu haben, aber mit einiger Sicherheit: Nichts. Dazu 
müsste der SoC-ROM-Code in der Lage sein, das USB-Subsystem zu 
initialisieren, einen Stick als Blockdevice zu erkennen und davon zu 
laden. Davon ist in den Dokumenten zum 7820 keine Rede, während SATA, 
SPI und NAND ja explizit aufgeführt sind. Daher glaube ich nicht, dass 
das implementiert ist.

Ciao,

solo

von Jens D. (jedie) Flattr this


Lesenswert?

solo schrieb:
>> Was passiert, wenn man die magischen ersten 32MB auf einen USB Stick
>> anlegt?
> Ohne es probiert zu haben, aber mit einiger Sicherheit: Nichts. Dazu
> müsste der SoC-ROM-Code in der Lage sein, das USB-Subsystem zu
> initialisieren, einen Stick als Blockdevice zu erkennen und davon zu
> laden. Davon ist in den Dokumenten zum 7820 keine Rede, während SATA,
> SPI und NAND ja explizit aufgeführt sind. Daher glaube ich nicht, dass
> das implementiert ist.

Ja, denke ich auch.

Wie ist ein "Recovery" von iomega aus geplant?
Wenn man ein uBoot mit USB unterstützung hat, sollte doch ein booten 
komplett davon funktionieren.

Aber klar. Aus und Einbau im PC tut's auch. Wäre bei Medion ja auch eine 
Option.

von solo (Gast)


Lesenswert?

Jens D. schrieb:
> Wie ist ein "Recovery" von iomega aus geplant?
Gar nicht. Durch Ausschalten im falschen Moment kann das System selber 
nicht beschädigt werden, nur die Datenpartition. Damit kann man in der 
Firmware umgehen. Der einzige denkbare echte Defekt bei 
bestimmungsgemäßem Gebrauch ist ein Hardwarefehler. In der Garantiezeit 
gibts dann ein neues Gerät. Iomega war auch in einigen Fällen kulant und 
hat kaputtgebastelte Geräte ersetzt.

Die Frage ist eher, was Medion eigentlich will. Keine durch den Kunden 
wechselbare Platte und trotzdem ein System auf Flash - das ist an sich 
sinnlos. Ich hatte ja die Seagate Go-Flex-Home da. Das ist auch ein 
1bay-NAS - aber eben mit Dock + Wechselplatte. Das geht nicht vernünftig 
ohne Flash. Das Konzept des Medion-NAS ist dagegen fragwürdig und lässt 
sich wohl am ehesten mit eigener Unsicherheit bei der Firmware erklären.

> Wenn man ein uBoot mit USB unterstützung hat, sollte doch ein booten
> komplett davon funktionieren.
Bringt nichts, denn wenn beim austauschen von u-boot und u-boot-env was 
schief geht, ist das gerät bereits gebrickt. Da kann man ebenso gut auch 
nur die initrd austauschen. Hat dasselbe Risiko, kommt aber ohne 
Neukompilieren von irgendwas gerätespezifischem aus.

Ciao,

solo

von Jens D. (jedie) Flattr this


Lesenswert?

solo schrieb:
> Die Frage ist eher, was Medion eigentlich will. Keine durch den Kunden
> wechselbare Platte und trotzdem ein System auf Flash - das ist an sich
> sinnlos. Ich hatte ja die Seagate Go-Flex-Home da. Das ist auch ein
> 1bay-NAS - aber eben mit Dock + Wechselplatte. Das geht nicht vernünftig
> ohne Flash. Das Konzept des Medion-NAS ist dagegen fragwürdig und lässt
> sich wohl am ehesten mit eigener Unsicherheit bei der Firmware erklären.

Eine GoFlexHome hab ich auch ;) Dort läuft ArchLinuxARM ohne Probleme ;)

Ich denke im Falle von Medion ist es einfach so, das die ein paar 
Komponenten zusammen gewürfelt haben und dabei war hat die Flash 
Variante. Finde ich auch ok. So haben wir beide Möglichkeiten ;)
IMHO ist es so, das Medion auch nicht wirklich das Gerät entwickelt hat. 
IMHO entwickeln die eh nichts. Es wird irgendwo fertig eingekauft und 
den Namen drauf gepackt (Was auch der eigentliche Hersteller macht).
Medion ist IMHO nicht viel mehr als eine Importeur und kein Hersteller 
und schon garnicht ein Entwickler. Aber das sind nur Vermutungen ;)

>> Wenn man ein uBoot mit USB unterstützung hat, sollte doch ein booten
>> komplett davon funktionieren.
> Bringt nichts, denn wenn beim austauschen von u-boot und u-boot-env was
> schief geht, ist das gerät bereits gebrickt.

Wobei es ja noch die beiden Kopien gibt ;) Also die erste so lassen wie 
sie sind und nur den zweiten per "Chain-Loading" nutzten.
Wobei wenn einmal ein uBoot drauf ist, was seinen Zweck erfüllt, dann 
braucht man es ja nicht mehr an zufassen. Wichtiger ist, das man auf 
einfacher weise den Kernel Aktuell halten kann...

von Peter W. (knattel)


Lesenswert?

Jens schrieb:

>  # smartctl --all /dev/sda | grep -i temp
> 190 Airflow_Temperature_Cel 0x0022   043   042   045    Old_age   Always
> FAILING_NOW 57 (0 37 58 54)
> 194 Temperature_Celsius     0x0022   057   058   000    Old_age   Always
> -       57 (0 20 0 0)
>
> Nachdem die Kiste mal auf Temperatur ist braucht sie hier extrem lange
> um wieder abzukuehlen.

Hallo Jens,

bin erstaunt! Wie hast du smartctl auf die Schachtel bekommen? Bist du 
firm und ausgestattet mit crosscompiling? Oder ist dir ein passendes 
binary vor die Füße gefallen? Von Haus aus sehe ich es auf dem 
nas-server nicht, "find" findet es auch nicht. Ein monitoring der 
Temperatur finde ich sehr gut.
Weniger gut, wenn die Schachtel termische Probleme hat.

An smartctl bin ich interessiert, oder - weil ich nicht faul bin, an dem 
Weg dahin, wie ich es selbst compilieren kann. Ist es denn möglich, perl 
und mysql auf der Schachtel zum fliegen zu bringen? Spricht das magere 
RAM dagegen? Gibt es schon Köpfe, die das für diese Platform zustande 
gebracht haben?

von Lucian M. (lucian_m)


Lesenswert?

Peter W. schrieb:
> Wie hast du smartctl auf die Schachtel bekommen? Bist du
> firm und ausgestattet mit crosscompiling? Oder ist dir ein passendes
> binary vor die Füße gefallen? Von Haus aus sehe ich es auf dem
> nas-server nicht, "find" findet es auch nicht. Ein monitoring der
> Temperatur finde ich sehr gut.

Ich glaube mich zu erinnern, das kann man als "offizielles" Paket über 
die WebGUI nachinstallieren, da gibt's 4 Pakete glaube ich, mehr nicht.

von solo (Gast)


Lesenswert?

Jens D. schrieb:
> Wobei es ja noch die beiden Kopien gibt ;) Also die erste so lassen wie
> sie sind und nur den zweiten per "Chain-Loading" nutzten.
Ohne u-boot-prompt per UART-USB-Adapter? Ändern des u-boot-1-env gilt ja 
nicht, da das Gerät im Fehlerfall genauso gebrickt wäre.

> Wobei wenn einmal ein uBoot drauf ist, was seinen Zweck erfüllt, dann
> braucht man es ja nicht mehr an zufassen. Wichtiger ist, das man auf
> einfacher weise den Kernel Aktuell halten kann...
Genau. Deswegen hab ich hier so penetrant auf den SATA-only-Boot-Prozess 
mit Fertigbausteinen von iomega und pogoplug gedrängt. Eure 
Hacker-Energie sollte in den Kernel anstatt U-Boot fließen, bevor sie 
vielleicht abebbt. ;)

Ciao,

solo

von Jens D. (jedie) Flattr this


Lesenswert?

solo schrieb:
> Ohne u-boot-prompt per UART-USB-Adapter? Ändern des u-boot-1-env gilt ja
> nicht, da das Gerät im Fehlerfall genauso gebrickt wäre.

Stimmt. So oder so heißt es Platte ausbauen und korrigieren...

von Sven B. (ft-)


Lesenswert?

solo schrieb:
> ist. Wenn man also in den Skripten der initrd eingreift, reicht das aus.
> Dort könnten alle Mittel vorhanden sein, um ein FS von USB zu mounten.
> Ich habe gestern versucht, die initrd zu entpacken - hat aber nicht
> funktioniert. Vorher kann ich nicht reinschauen, ob dort was

Versuch mal squashfs oder romfs. Nicht alle initrd sind cpio.


solo schrieb:
> Das Konzept des Medion-NAS ist dagegen fragwürdig und lässt
> sich wohl am ehesten mit eigener Unsicherheit bei der Firmware erklären.

Ich nehme an, die haben einfach die Zyxel-Basis so gelassen und haben 
mit Linux mehr oder minder das erste Gerät gebaut.

Jens D. schrieb:
> Ich denke im Falle von Medion ist es einfach so, das die ein paar
> Komponenten zusammen gewürfelt haben und dabei war hat die Flash
> Variante. Finde ich auch ok. So haben wir beide Möglichkeiten ;)
> IMHO ist es so, das Medion auch nicht wirklich das Gerät entwickelt hat.
> IMHO entwickeln die eh nichts. Es wird irgendwo fertig eingekauft und
> den Namen drauf gepackt (Was auch der eigentliche Hersteller macht).
> Medion ist IMHO nicht viel mehr als eine Importeur und kein Hersteller
> und schon garnicht ein Entwickler. Aber das sind nur Vermutungen ;)

Im Grunde ist es Zyxel mit Hardware-Anpassungen.

Peter W. schrieb:
> bin erstaunt! Wie hast du smartctl auf die Schachtel bekommen? Bist du
> firm und ausgestattet mit crosscompiling? Oder ist dir ein passendes
> binary vor die Füße gefallen? Von Haus aus sehe ich es auf dem
> nas-server nicht, "find" findet es auch nicht. Ein monitoring der
> Temperatur finde ich sehr gut.
> Weniger gut, wenn die Schachtel termische Probleme hat.

Bei ArchLinuxARM => pacman -S smartmontools

Bei der zyxel-basierten Medion-Firmware gibt es auch ein SMART-Paket.

Peter W. schrieb:
> An smartctl bin ich interessiert, oder - weil ich nicht faul bin, an dem
> Weg dahin, wie ich es selbst compilieren kann. Ist es denn möglich, perl
> und mysql auf der Schachtel zum fliegen zu bringen? Spricht das magere
> RAM dagegen?

128MB RAM + 512MB Swap sollten definitiv für eine mysql-Installation 
reichen. Läuft bei mir auch schon mit. Nur noch keine Datenbank dort 
eingebaut.

solo schrieb:
> Genau. Deswegen hab ich hier so penetrant auf den SATA-only-Boot-Prozess
> mit Fertigbausteinen von iomega und pogoplug gedrängt. Eure
> Hacker-Energie sollte in den Kernel anstatt U-Boot fließen, bevor sie
> vielleicht abebbt. ;)

Neuerer U-Boot usw. ist auch erstmal Spielerei. Das werde ich zwar 
nochmal machen. Aber nicht unmittelbar.

Das was ich zusammengestellt habe, basiert erstmal auf dem PogoPlugPro 
oxnas_sata_boot.tgz von WarheadsSE, welches im Übrigen voll kompatibel 
bezüglich RAM zum Medion-Gerät ist.

Einen Kernel 3.1 zu haben ist für mich auch erst mal Priorität. Meine 
ersten Laufversuche mit Kernel 3.1 haben schon gezeigt, dass diese ganze 
Direct SATA-Geschichte zur Umgehung des File Cache im Linux-Kernel 
führt.

Soviel zur Bastelei im PLX-Kernel.

Damit kommt die Platte dann praktisch wenige Sekunden nach dem Standby 
wieder hoch. Und das bei einem System auf dem nichtmal ein Syslog läuft.
Also keine Logs usw.

Das habe ich beim 3.1er nicht gehabt. Da blieb sie erstmal längere Zeit 
im Standby bis der Syslog kam. Aber das lässt sich dann ja auch 
anpassen.

von Sven B. (ft-)


Lesenswert?

Lucian M. schrieb:
> Im 3.1-er Kernel ist derzeit arch/arm/plat-oxnas komplett weg. Das sind
> doch die von Dir und ElektroMan angesprochenen schlecht implementierten
> Tricksereien die Ihr jetzt the right way implementiert oder auch wegen
> geringem Gewinn weglasst? Da war auch der LEON-Support drin, nun tut ja
> die NIC auch ohne, aber kann es damit zu tun haben dass die in der
> Kernel-Kommandozeile übergebene MAC-Adresse nicht angenommen wird?

heisst nur jetzt arch/arm/plat-ox820
das habe ich von redsquare und WarheadsSE so übernommen.

Die Tricksereien waren primär in den Dateisystemen und SATA-Treiber.

von Peter W. (knattel)


Lesenswert?

Lucian M. schrieb:

> Ich glaube mich zu erinnern, das kann man als "offizielles" Paket über
> die WebGUI nachinstallieren, da gibt's 4 Pakete glaube ich, mehr nicht.

Danke Lucian für den Hinweis. Hat mir geholfen - habe mir bei der 
Gelegenheit neben den smarttools auch das NFS Paket geholt. Prima - 
schreibe gerade einen 18 GB Molch auf das NAS. Abgesehen davon, dass man 
dafür ein langes Leben braucht, bin ich nach nunmehr 2 Stunden bei 50% 
also gerade mal 9 GB die auf dem NAS gelandet sind. S.M.A.R.T. 
Information 50 Grad Celsius.
Es wird also 4 Stunden dauern ... Nur ein Test und nicht die übliche 
Anforderung. Mit uptime sieht man ja auch immer die "load average" und 
die ist nicht nennenswert 0.10, 0.16, 0.11 Es ändert sich wenig. D.h. 
blödes kopieren stellt für das System keine Last dar. Die Platte wird 
natürlich anderer Meinung sein.

von Sven B. (ft-)


Lesenswert?

Ich habe mir mal die Mühe gemacht, eine üppiger Default Config für das 
Medion NAS im Repo abzulegen.

Ist für SATA-Boot definiert. (ox820_medion_defconfig)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.