Author: wusel

Nachdem ich nun mehrere DockStars mein Eigen nenne und die an verschiedensten PCs hängenden USB-HDDs nun an diesen zusammenführen möchte, habe ich an einem »frischen« DockStar eine neue Methode zur »Befreiung« ausprobiert.
Vorweg: ich benutzte einen selbstgebackenen Linux-Kernel (2.6.32.2 von kernel.org), der um die DockStar-Patches von Alexander Holler, welchen ich auf einer x86-Kiste cross-compile und den ich per tftp mit dem orginalen DockStar-uBoot boote. Aufsetzen eines TFTP-Servers, Patching sowie Cross-compiling des Kernels sind an anderen Stellen im Netz dokumentiert, ich gehe darauf hier nicht ein — unter anderem auch, um nicht falsche Hoffnungen bei Linux-Anfängern zu wecken: der (Unter-) Titel, den Alexander Holler für seinen Artikel gewählt hat – »How to brick your DockStar and void the warranty« – ist kein Scherz; die Gefahr, seinen DockStar zumindest soweit unbrauchbar zu machen, daß man mit einer seriellen Schnittstelle mit TTL-Pegel den Innereien zuleibe rücken muß, ist nach wie vor hoch!
Dies vorausgeschickt, primär als Gedächtnisstütze für mich, mein aktuelles Kochrezept:

1. An anderem Linux-PC auf einem USB-Stick oder einer USB-HDD das Filesystem erzeugen. Ich bin gemäß »Manually unpacking a tar ball of Debian on SheevaPlug« vorgegangen, also Debian Lenny (armel) auf Medium ausgepackt.
2. Dann nicht vergessen, die etc/fstab dort zu editieren, ich habe auf einem 4 GB-USB-Stick 3 GB /dev/sda1 als ext3 und den Rest als /dev/sda2 für Swap:

   /dev/sda1 / ext3 errors=remount-ro 0 1
   /dev/sda2 none swap sw 0 0

3. Die zum Kernel gehörenden lib/modules- und lib/firmware-Dateien aus dem Kernelbau in das neue Filesystem zu kopieren sollte man nicht vergessen ;)
4. Medium vom (x86-) Linuxrechner abmontieren und ggf. beschriften; dann an den ausgeschalteten DockStar stecken und diesen zum ersten Mal booten. Einloggen per ssh und dann blparam holen:

   -bash-3.2# mount -o rw,remount /
   -bash-3.2# cd
   -bash-3.2# wget http://plugapps.com/os/pogoplug/uboot/blparam
   -bash-3.2# chmod 755 ./blparam
   -bash-3.2# cp -p blparam /tmp/.cemnt/mnt_sda1/root/

   Der letzte Befehl kopiert das Binary gleich in die neue Umgebung.

5. Jetzt die Bootparameter anpassen — dabei auch diese Beispielsdaten natürlich an die lokalen Gegebenheiten ;)

   -bash-3.2# ./blparam netmask=255.255.255.0
   -bash-3.2# ./blparam ipaddr=192.168.5.236
   -bash-3.2# ./blparam serverip=192.168.5.2
   -bash-3.2# ./blparam arcNumber=2097
   -bash-3.2# ./blparam bootcmd_tftp='tftp 0x800000 uImage ; setenv bootargs root=/dev/sda1 rw rootdelay=5 rootfstype=ext3 ; bootm 0x800000'
   -bash-3.2# ./blparam bootcmd2b='setenv bootcmd run bootcmd1 ; saveenv ; run bootcmd_original'
   -bash-3.2# ./blparam bootcmd_original='nand read.e 0x800000 0x100000 0x300000; setenv bootargs $(console) $(bootargs_root); bootm 0x800000'
   -bash-3.2# ./blparam bootcmd2='setenv bootcmd run bootcmd2b ; setenv mainlineLinux no ; saveenv ; reset'
   -bash-3.2# ./blparam bootcmd1b='setenv bootcmd run bootcmd2 ; saveenv ; run bootcmd_tftp'
   -bash-3.2# ./blparam bootcmd1='setenv bootcmd run bootcmd1b ; setenv mainlineLinux yes ; saveenv ; reset'
   -bash-3.2# ./blparam bootcmd='run bootcmd1'

6. Nun noch /root/blparam bootcmd="run bootcmd1" >/dev/null 2>&1 nach /tmp/.cemnt/mnt_sda1/etc/rc.local hinzufügen und auch einmal ausführen.
7. Nach einem Reboot sollte nun das neue Linux hochkommen, Zugriff bekommt man wie folgt:
   

   When Debian has started, you can login as user root with the password root.

    

Disclaimer: Worked for me, your mileage may vary, no liability assumed. You may loose your warranty by doing this. You have been warned. Seriously, don’t try this at home!
Mein erster Versuch schlug fehl, nur jeder zweite Boot klappte, und dann in den »DockStar-Modus«; der Grund war schlicht, daß ich das FS auf dem USB-Stick weder bzgl. /etc/fstab angepaßt hatte noch die Module meines Kernels ‘rüberkopiert. Nachdem ich das nachgeholt hatte, bootete mein dockstar-3 sauber wiederholt ins Debian. Weitere Änderungen: ssh-Keys in /etc/ssh/ neugebaut – sonst hätte ja jeder DockStar identische Host-Keys – und natürlich /etc/hostname angepaßt.

Zugriff auf den DockStar per RS-232-TTL-Pegelwandler.

Immerhin, dieser dritte angefaßte DockStar war der Erste, den ich bislang nicht für den Zugang per Console öffnen mußte ;)
Hope this helps; aber, wie gesagt, zur Nachahmung nur dem empfohlen, der sich mit Linux hinreichend auskennt und der auch kein Problem damit hat, den DockStar zu öffnen und an den vorhandenen Pins einen Adapter anzuschließen, um auf die Console zugreifen zu können.
Der Vorteil im obigen Vorgehen ist für mich einerseits, daß ich im sowieso vorhandenen Netz den Kernel per tftp bereitstellen kann und es kein Vertun gibt, von welchem Medium der Kernel nun geholt werden soll (die Reihenfolge der USB-Geräte-Erkennung erscheint mir noch immer teils zufallsgesteuert?), ferner erspare ich mir das Flashen eines zweiten U-Boot in den freien Flash-Bereich des DockStar; evtl. kann man den Bereich ja später für eine initrd nutzen oder ein minimales Root-FS …
[Edit: Unter Punkt 2 stand bis 2010-06-22 02:35 noch »ext2«, was natürlich Blödsinn ist für ein ext3-FS. Das ist mir natürlich nicht aufgefallen, da man ein ext3 ja als ext2 mounten kann, was mein »dockstar-2« auch tapfer gemacht hatte … Ich habe das auf »dockstar-2« (nein, nicht »frogstar-b« ;)) geändert, ihn rebootet … und er kam brav wieder hoch, jetzt mit einem / als ext3. Danke an Detlef, den aufmerksamen Leser!]

Hmm. Was habe ich hier jetzt nicht verstanden?

U-Boot 1.1.4 (Jul 16 2009 - 21:02:16) Cloud Engines (3.4.16)
U-Boot code: 00600000 -> 0067FFF0 BSS: -> 00690D60
Soc: 88F6281 A0 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz
DRAM CAS Latency = 5 tRP = 5 tRAS = 18 tRCD=6
DRAM CS[0] base 0x00000000 size 128MB
DRAM Total size 128MB 16bit width
Flash: 0 kB
Addresses 8M - 0M are saved for the U-Boot usage.
Mem malloc Initialization (8M - 7M): Done
NAND:256 MB
CPU : Marvell Feroceon (Rev 1)
CLOUD ENGINES BOARD: REDSTONE:1.0
Streaming disabled
Write allocate disabled
USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0
[...]
CE>> tftp 0x800000 uImage ; setenv bootargs ${bootargs_usb_root}; bootm 0x800000
Using egiga0 device
TFTP from server 192.168.5.2; our IP address is 192.168.5.5
Filename 'uImage'.
Load address: 0x800000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
#################################################################
########################
done
Bytes transferred = 2448208 (255b50 hex)
## Booting image at 00800000 ...
Image Name: Linux-2.6.32.2
Created: 2010-06-17 0:35:49 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2448144 Bytes = 2.3 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................................................................................................................. done, booting the kernel.
Error: unrecognized/unsupported machine ID (r1 = 0x0000020f).
Available machine support:
ID (hex) NAME
00000690 Marvell DB-88F6281-BP Development Board
00000691 Marvell RD-88F6192-NAS Development Board
00000692 Marvell RD-88F6281 Reference Board
0000078c Marvell 88F6281 GTW GE Board
00000831 Seagate DockStar Board
0000085b QNAP TS-119/TS-219
00000915 Marvell OpenRD Base Board
Please check your kernel config and/or bootloader.

WTF? Wieso schlägt das fehl?

1. Das Image wird per TFTP übertragen
2. Es wird als unkomprimierter Linux Kernel erkannt, die Checksumme stimmt
3. Beim Boot des Kernels – der so sonst vom ext3 des USB-Sticks der 1. Partition an Port 1 geladen wird – wird eine falsche Maschine erkannt‽

Nochmal: WTF?

Ich gebe zu, es hat ein bißchen gedauert seit den ersten Schritten, aber ich mache ja auch gerne eigene Erfahrungen …
In diesem Blogbeitrag geht es um die Zusammenfassung, vielleicht um »lessons learned«; wer alles noch einmal nachlesen will, hier die Historie von »How to brick your DockStar, voiding warranty and installing Ubuntu …«: Part I, Part II, Part III, Part IV, Part V und Part VI ;-)
Angefangen hat alles ja mit dem Wunsch, den etwas lahmen NSLU2 als Fileserver abzulösen; ich komme per NFS von dort, mit einem Debian Lenny als OS-Basis (installiert auf /dev/sda1), nur rund 3-4 MByte/sec, technisch möglich wären (Festplattengeschwindigkeit per USB, Gigibit-Netz) 10-12, bei Einsatz von sshfs – sicherlich nur bezüglich der Ressourcenverschwendung optimal, ist bei gut 1,5 MByte/sec Schicht im Schacht (die NSLU2-CPU ist dann bei 100%).
Idealerweise möchte ich nur den NSLU2 ausschalten, die USB-HDD umstecken, den DHCP-Server anpassen und den DockStar wieder einschalten … Insofern sind »andere« Linux-Lösungen nicht wirklich von Interesse, ich brauche was, was von USB direkt in mein Lenny bootet.
Die Vorarbeit von Alexander Holler bzgl. Patches für die etwas unterschiedliche Hardware des DockStar führte zur Entscheidung, einen eigenen Kernel einzusetzen; schließlich möchte ich ggf. auch mjpeg-streamer o. ä. einsetzen, sofern der DockStar wie erwartet dazu noch Luft hat … Als »How To« für das Kernelbauen unter Ubuntu, meinem präferierten Desktop-OS, habe ich mich an den Hinweisen von plugcomputer.org orientiert — analog zum Bauen von Kerneln bzw. Modulen für meine Sheevas.
Ich habe dann mir erst die Finger verknotet beim Versuch, mittels des DockStar-U-Boot von USB zu booten — dies kann der leider nicht. (Steht zwar auch verschiedentlich geschrieben, aber probieren geht über studieren ;)) Letztlich erfolgreich war dann – in abgewandelter Form, siehe unten – der Plugapps-Ansatz für mich. Hier boote ich also den DockStar einmal an (er muß Internet-Verbindung haben), verbinde mich per SSH und führe die Schritte »Download Blparam« und »Installation«, hier nur die Punkte 1 und 2, aus. im Ergebnis habe ich einen DockStar, der bei jedem zweiten Bootvorgang versucht, über einen sekundären, neueren U-Boot – der leider nicht über Möglichkeiten zur dauerhaften Änderung der Paramater verfügt – vom ersten erkannten USB-Speichermedium »/boot/uImage« zu booten.
Da ich hier meinen eigenen Kernel einsetzten will, habe ich den, wie gesagt. selbst gebaut — und auch meine eigenen Fehler dabei gemacht ;) Merke: für Boot von USB sollten nicht nur das Modul für das Root-FS sowie usb-storage fest im Kernel integriert sein (also nicht als Modul gebaut werden), auch die entsprechenden USB-Low-Level-Treiber (hier: EHCI für USB-2.0) müssen mit reingebacken werden. Nachdem ich deses endlich erkannt hatte, stieß ich auf’s nächste Problem: der »PlugApps-U-Boot« startet den Kernel mit »console=ttyS0,115200 root=/dev/sda1 rootdelay=1 rootfstype=ext2« — mein Root-FS ist allerdings ein ext3, der Fehler »EXT2-fs: sda1: couldn’t mount because of unsupported optional features (4).« also nur logisch.
Lösung für dieses Problem: im »make ARCH=arm menuconfig« unter »Boot options« »console=ttyS0,115200 root=/dev/sda1 rootdelay=10« als »Default kernel command string« eintragen und »Always use the default kernel command string« selektieren. Dann ignoriert der Kernel übergebene Parameter — dies erspart mir, auch noch einen eigenen U-Boot bauen zu müssen …
Nachdem ich meinen Kernel also als »uImage« ins /boot-Verzeichnis der externen USB-HDD am NSLU2 und die Module zu diesem Kernel nach /lib/modules kopiert habe, der erste Bootversuch:

Linux.............................................................................................................................................................. done, booting the kernel.
Linux version 2.6.32.2 (wusel@greebo) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) ) #11 PREEMPT Thu Jun 17 02:35:21 CEST 2010
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053177
CPU: VIVT data cache, VIVT instruction cache
Machine: Seagate DockStar Board
Ignoring unrecognised tag 0x54410009
Memory policy: ECC disabled, Data cache writeback
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10
[...]
Waiting 10sec before mounting root device...
scsi 0:0:0:0: Direct-Access WD 10EAVS External 1.75 PQ: 0 ANSI: 4
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI disk
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with writeback data mode.
VFS: Mounted root (ext3 filesystem) on device 8:1.
Freeing init memory: 120K
INIT: version 2.86 booting
Starting the hotplug events dispatcher: udevd.
Synthesizing the initial hotplug events...done.
Waiting for /dev to be fully populated...done.
Setting the system clock.
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Unable to set System Clock to: Thu Jan 1 00:00:15 UTC 1970 (warning).
Activating swap...Adding 489972k swap on /dev/sda2. Priority:-1 extents:1 across:489972k
done.
Checking root file system...fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
/dev/sda1 has filesystem last checked time in the future, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 23102/1831424 files (1.6% non-contiguous), 346622/7323624 blocks
done.
EXT3 FS on sda1, internal journal
FATAL: Module rtc_dev not found.
Setting the system clock.
Cannot access the Hardware Clock via any known method.
Use the --debug option to see the details of our search for an access method.
Unable to set System Clock to: Thu Jan 1 00:00:50 UTC 1970 (warning).
Cleaning up ifupdown....
Loading kernel modules...done.
Checking file systems...fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
Superblock last mount time is in the future. Fix? yes
Superblock last write time is in the future. Fix? yes
/dev/sda3 has filesystem last checked time in the future, check forced.
Pass 1: Checking inodes, blocks, and sizes
/dev/sda3: |== \ 4.4% 

Tja, Fazit soweit: »there’s still work to do«; die fehlende RTC (»RealTimeClock«; batteriegepufferte Uhr) beim Seagate FreeAgent DockStar wird sicherlich noch Spaß machen; ein fsck über mehrere TB-Filesysteme bei jedem Start ist mehr so ein no-go. Gut, es ist kein grundlegender Unterschied zum NSLU2, denn auch dort hatte ich nach jedem Neustart ein nicht sauberes FS, sodaß der tapfere NSLU2 sich rd. 1h mit dem fsck vergnügte …
Tendentiell liesse sich da sicherlich über die initrd was reißen, wenngleich es natürlich tricky ist; man müßte das älteste Datum des letzten Schreibzugriffes jedes gefundenen Dateisystems nehmen, und dies +1 Sekunde als Initialwert für die Uhr nhemen … Naja, jetzt muß der fsck erst einmal fertig werden und dann steht der erste Speedtest an, ob sich der Aufwand NSLU2 -> DockStar überhaupt lohnt ;)
Aber, so als Erfolgsmeldung: Ubuntu oder Debian auf dem DockStar ist nur ein marginales Problem. Kurzfassung der Schritte:

1. Plugapps-Tools für zweiten U-Boot auf dem DockStar nehmen; »Download Blparam« und »Installation« (hier: Punkte 1 und 2) ausführen.
   Danach hat man einen DockStar, der bei jedem zweiten(!) Boot versucht, von »/dev/sda1« (USB) »/boot/uImage« als Kernel zu laden — was dieser Kernel dann macht, ist dessen Sache; er sollte allerdings auf den SheevaPlug DockStar zugeschnitten sein. Um dauerhaft nur per USB zu booten, muß man im »DockStar-Modus« per »blparam« die Parameter dauerhaft ändern. Dies sollte man aber nur dann tun, wenn man willens und fähig ist, einen gebrickten DockStar nach Gehäuseöffnung per TTL-RS232 zu reaktivieren …
2. DockStar-Kernel-Patches von Alexander Holler in eigenen Kernel einpflegen, feste Kernel-Kommandozeile setzen und diese als Präferenz markieren; »uImage« backen, nach »/boot/« auf dem Zielgerät (USB-Stick oder USB-HDD, »/dev/sda1« aus Sicht des DockStars), die dazugehörigen Module nicht vergessen.

Als OS-Basis bietet sich u. a. das SheevaPlug-FS (Ubuntu) von plugcomputer.org an, oder auch ein Debian natürlich – Voraussetzung ist, daß die Binaries zur Hardware passen ;)

<M> EHCI HCD (USB 2.0) support 

Wie sinnvoll ist es, in einem Kernel, der via USB sein Bootdevice finden soll, die Low-Level-Treiber als Modul zu bauen? Narf, narf, narf ;)
Wie geht der Spruch? »Kaum macht man’s richtig, funktioniert’s«? :)

Uncompressing Linux.............................................................................................................................................................. done, booting the kernel.
Linux version 2.6.32.2 (wusel@greebo) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-68) ) #9 PREEMPT Wed Jun 16 20:44:08 CEST 2010
CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053177
[...]
Kernel command line: console=ttyS0,115200 root=/dev/sda1 rootdelay=10 rootfstype=ext2
[...]
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
orion-ehci orion-ehci.0: Marvell Orion EHCI
orion-ehci orion-ehci.0: new USB bus registered, assigned bus number 1
orion-ehci orion-ehci.0: irq 19, io mem 0xf1050000
orion-ehci orion-ehci.0: USB 2.0 started, EHCI 1.00
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
Initializing USB Mass Storage driver...
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
[...]
usb 1-1: new high speed USB device using orion-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.4: new high speed USB device using orion-ehci and address 3
rtc-mv rtc-mv: internal RTC not ticking
[...]
Waiting 10sec before mounting root device...
scsi 0:0:0:0: Direct-Access A60C0709 Flash Disk 8.07 PQ: 0 ANSI: 2
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 2048000 512-byte logical blocks: (1.04 GB/1000 MiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Assuming drive cache: write through
sda: sda1 sda3
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: [sda] Attached SCSI removable disk
EXT2-fs: sda1: couldn't mount because of unsupported optional features (4).
List of all partitions:
1f00 1024 mtdblock0 (driver?)
1f01 4096 mtdblock1 (driver?)
1f02 32768 mtdblock2 (driver?)
1f03 224256 mtdblock3 (driver?)
0800 1024000 sda driver: sd
0801 805169 sda1
0803 218410 sda3
No filesystem could mount root, tried: ext2
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
[<c002b9fc>] (unwind_backtrace+0x0/0xdc) from [<c0383e4c>] (panic+0x58/0x12c)
[<c0383e4c>] (panic+0x58/0x12c) from [<c0008ec8>] (mount_block_root+0x1c8/0x208)
[<c0008ec8>] (mount_block_root+0x1c8/0x208) from [<c000911c>] (prepare_namespace+0x120/0x178)
[<c000911c>] (prepare_namespace+0x120/0x178) from [<c00085bc>] (kernel_init+0xdc/0x110)
[<c00085bc>] (kernel_init+0xdc/0x110) from [<c0027444>] (kernel_thread_exit+0x0/0x8)

Na, ok, fast ;) ext2 ankündigen, ext3 liefern ist ja auch unfair, irgendwie …