DockStar: boot per tftp?

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?

How to brick your DockStar, voiding warranty and installing Ubuntu … (Conclusion)

Update 2010-10-19: Der folgender Artikel ist nur noch von historischer Bedeutung; das aktuelle Vorgehen kommt bei mir ohne Consolenzugriff oder Geräteöffnung aus. Es ist zwar noch nicht verskriptet, aber immerhin habe ich mit jenem Verfahren schon >5 Dockstars zu kleinen Sheevas gemacht …
···

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 ;)

Schuppen und Augen

<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 …

Why I don't belive in the PSU being the problem in SheevaPlugs

There is some discussion going on regarding dead SheevaPlug-PSUs, reworked PSUs for the new GuruPlug and why Sheevas and Gurus are dying more and more frequently the older (talking about weeks here) they get.
Personally, I own two SheevaPlugs, one purchased by mid-December 2009, the other one was delivered around January 2010. Well, both PSUs already died, in both it’s the same capacitor in the PSU that shows visual anomalies. And because of what I’ve seen after opening the PSUs, I personally don’t expect a replacement PSU to last much longer than 3 to 6 months each :(
From what can be learned from the issues of the GuuPlug, it’s not the PSU which heats up the box but the CPU; therefore I suspect, as SheevaPlug is built in some way similar to GuruPlug, that it’s the CPU which is literally frying the components of the PSU — until they finally give up and die. Thus, a replacement PSU would be boiled as well — and at least according to German law, 6 months after purchase it’s the customer who has to bring prove that a defect was there at the time of purchase to claim replacements free of charge …

So, what to do? The most sensible thing to do right now, in my opinion, would be to address the (European) seller asking for a full refund both on SheevaPlugs as well as GuruPlugs, as they are proven to be unfit for the duty intended; they might not last longer that 3-6 months until burnung out — which was not advertized back then …
If you actually use them, your situation might be different; in that case, I’d request a preload of PSU replacements for the usual time electronic devices work/ran/stay usable, based on my experience I’ll need a new PSU every 3rd to 4th month, i. e. four per year. Thinking about using the SheevaPlugs for 4 to 5 years, I’d need a supply of 16 to 20 in total per Sheeva … And maybe I’d still lrequest a partial refund due to the lack of usability during each PSU failure and the time I need to spend replacing PSUs myself …
To be honest: I strongly assume that, if checked before Marketing started, they wouldn’t be allowed to be distributed within th EU at all, with all that heat and the heated PSU becoming a risk of fire …

(Edited: Some typos corrected.)

Erfahrungen mit GlobalScales Guru- und SheevaPlugs …

Ich war ja lange Zeit ein Fan dieser sog. »PlugComputer«; das Bild allerdings hat sich nun schlagartig gewandelt. Denn auch bei meinem grade mal ein halbes Jahr alten ersten SheevaPlug hat’s das Netzteil zerrissen, ein Ersatznetzteil wird lt. Aussage des Händlers NewIT voraussichtlich erst in vier Wochen bereit stehen. Aus diesem Grunde habe ich gestern per Express von Amazon für EUR 21,– eine USB-2-IDE/SATA-Lösung bestellt, die just in time heute geliefert und deren Netzteil heute abend jenen SheevaPlug reanimiert hat (es war die günstigste, schnell verfügbare 5V-Quelle …).
Zwei von zwei SheevaPlugs haben also nicht länger als 6 Monate funktioniert — Crap in Serie möchte man meinen. Aber es kommt ja noch besser: der SheevaPlug-Nachfolger GuruPlug ist das Paradebeispiel für ein Gerät, welches »broken by design« ist. Das folgende habe ich grade im NewIT-Forum gepostet:

According to a German user who directly ordered at GlobalScale, his GuruPlug Plus died (of heat) yesterday. Talking to his sales representative at GS, he was told to receive a new GP Plus with an “allegedly reworked board and power supply” shortly. Similar I’ve read in another forum the other day.
This leads to the question: why ist GlobalScale not talking to NewIT anymore or what is NewIT not telling it’s customers? Sorry folks, I’m rather fed up by now with GlobalScale’s crap.
I just revived my SheevaPlug of December 2009, which died last Sunday, by a €21 amazon express delivery of an 5V-PSU, as, as Jason told me, a replacement PSU from GlobalScale will need additional 4 WEEKS. I own 2 SheevaPlugs (via NewIT), both suffered death of the PSU already.
And now this GuruPlug nighmare: reworked PSU already included, but the 2 Gigabit ports are only working at 100? The CPU is burning like hell, there’s no way a reworked PSU seems to cure that design flaw, does it? Please see http://plugcomputer.org/plugforum/index.php?topic=1735.msg10695#msg10695
And, just by coincidence, I was pointed from a post at plugcomputer.org to http://www.newit.co.uk/forum/index.php/topic,323.msg2025.html#msg2025 – nice to inform your still-waiting GP customers, but what about the ones that already received the broken-by-design version?
I really liked the service of NewIT, referred other people to them; but, frankly, Jason & all: this information policy sucks big time Sad You at least should have had the guts to post that information to your GuruPlug-Info-thread (http://www.newit.co.uk/forum/index.php/topic,419.0.html)

Der GuruPlug entwickelt sich mehr und mehr zum Anti-Produkt für PlugComputer; ein Treppenwitz ist letztlich auch das, was angeblich alles verändert werden sol.

There a few changes to the GuruPlug Servers, these include:

  • A new inductor on the motherboard
  • A new daughterboard with a new power management chip
  • More vents on the units
  • A new external power supply unit

 
Von Software kannte ich ja den Begriff »Bananaware«; wie nennt man das bei Hardware?
Wie auch immer: bis auf weiteres kann ich aus eigener Erfahrung alsi nur von Anschaffung und Einsatz dieser Hardware abraten :(

How to brick your DockStar, voiding warranty and installing Ubuntu … (Part VI)

Ich entleihe mir hier von Alexander Holler mal die Pin-Belegung des Pin-Headers im Seagate FreeAgent DockStar:

 9 7 5 3 1
10 8 6 4 2
RX TX GND 3.3V!

Hintergrund: Ich versuche nun dann doch, mal über dokumentierte Wege den DockStar zu einem Multi-Purpose-Gerät zu machen:

[...]
bash-3.2# ./pogo_u-boot_install.sh
Ready? Press ENTER to start, CTRL-C to quit!
Downloading new bootloader and verifying it...
Writing new bootloader...
Setting new boot configuration...
What device are you installing on? Type only the number of your device and pres.
1. Pogoplug v1 - Brick
2. Pogoplug v2 - Pink
3. DockStar
3
Writing DockStar Bootloader...
Installation is complete.
Continue by installing Plugbox Linux to a USB drive.
Reboot with '/sbin/reboot/' when you are ready.
Your LED will be red, organge, or off completely when booting Plugbox.
Just in case you chose the wrong device, just re-run the installer.

… allerdings noch mit meinem eigenen uImage:

bash-3.2# /sbin/reboot
The system is going down NOW!
Sending SIGTERM to all processes
Requesting system reboot
[ 615.770000] md: stopping all md devices.
[ 616.770000] Restarting system.
[ 616.770000] Reseting !!
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
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
NAND read: device 0 offset 0x2500000, size 0x40000
Reading data from 0x253f800 – 100% complete.
262144 bytes read: OK
## Starting application at 0x00C00000 ...
U-Boot 2009.11-00432-g1650ec9-dirty (Mar 07 2010 - 22:13:20)
PlugApps Pogoplug
SoC: Kirkwood 88F6281_A0
DRAM: 128 MB
NAND: 256 MiB
Using default environment
In: serial
Out: serial
Err: serial
Net: egiga0
88E1116 Initialized on egiga0
Hit any key to stop autoboot: 0
(Re)start USB...
USB: Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... 3 USB Device(s) found
scanning bus for storage devices... 1 Storage Device(s) found
Loading file "/boot/uImage" from usb device 0:1 (usbda1)
** File not found /boot/uImage
## Booting kernel from Legacy Image at 00800000 ...
Image Name: Linux-2.6.22.18
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1976384 Bytes = 1.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................

WTF? Ah, super; mein sda1 ist /boot und sieht so aus:

-sh-3.2# ls -la /tmp/.cemnt/mnt_sda1
drwxr-xr-x 4 root root 1024 Mar 8 2010 .
drwxr-xr-x 4 root root 160 Jan 1 00:00 ..
drwxr-xr-x 2 root root 1024 Jan 1 00:00 .cedata
-rw-r--r-- 1 root root 30 Mar 8 2010 .ceid
drwx------ 2 root root 12288 Mar 8 2010 lost+found
-rwxr-xr-x 1 root root 262144 Mar 8 2010 u-boot.bin.pagesize
-rw-r--r-- 1 1000 1000 2421824 Mar 8 2010 uImage

Hachja. mit »cd /tmp/.cemnt/mnt_sda1; ln -s . boot« also nochmal probieren ;)

USB 0: host mode
PEX 0: interface detected no Link.
Net: egiga0 [PRIME], egiga1
Hit any key to stop autoboot: 0
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
NAND read: device 0 offset 0x100000, size 0x300000
Reading data from 0x3ff800 – 100% complete.
3145728 bytes read: OK
## Booting image at 00800000 ...
Image Name: Linux-2.6.22.18
Created: 2009-08-31 23:31:05 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1976384 Bytes = 1.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................
[ 0.000000] Linux version 2.6.22.18 (bdietrich@brad-ux) (gcc version 4.2.1) 9
[ 0.000000] CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053177
[ 0.000000] Machine: Feroceon-KW
[ 0.000000] Using UBoot passing parameters structure
[...]
[ 18.270000] XCE: BLPARAMS: reading 2048 bytes @ a1800
[ 23.630000] XCE: XCE: LED -> CONNECTED
[ 26.570000] kjournald starting. Commit interval 5 seconds
[ 26.710000] EXT3 FS on sda2, internal journal
[ 26.710000] EXT3-fs: recovery complete.
[ 26.890000] EXT3-fs: mounted filesystem with ordered data mode.
Sending discover...
Sending select for 192.168.5.243...
Lease of 192.168.5.243 obtained, lease time 21600
HWADDR 00 0x10 0x75 0x1a 0x72 0x0d
PIP0 114
PIP1 13
eth0 Link encap:Ethernet HWaddr 00:10:75:00:00:00
inet addr:192.168.5.243 Bcast:192.168.5.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:532
RX bytes:702 (702.0 B) TX bytes:1180 (1.1 KiB)
Interrupt:11
eth0:0 Link encap:Ethernet HWaddr 00:10:75:00:00:00
inet addr:169.254.114.13 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interrupt:11
Loading fs modules: Success
Loading tun.ko: Success
Loading xce.ko: Success
Starting hbplug: Success
starting pid 361, tty '': '/bin/sh'
[...]
-sh-3.2# df -h
Filesystem Size Used Available Use% Mounted on
/dev/mtdblock2 32.0M 16.9M 15.1M 53% /
/dev/sda1 10.4M 2.7M 7.5M 26% /new_root
none 61.6M 12.0k 61.5M 0% /tmp
/tmp/.cemnt/sda1 10.4M 2.7M 7.5M 26% /tmp/.cemnt/mnt_sda1
/tmp/.cemnt/sda2 763.3M 312.9M 434.9M 42% /tmp/.cemnt/mnt_sda2
-sh-3.2# ls -la /new_root/
drwxr-xr-x 4 root root 1024 Jan 1 00:02 .
drwxr-xr-x 15 root root 0 Jan 1 1970 ..
drwxr-xr-x 2 root root 1024 Jan 1 00:00 .cedata
-rw-r--r-- 1 root root 30 Mar 8 2010 .ceid
lrwxrwxrwx 1 root root 4 Jan 1 00:02 boot -> .
drwx------ 2 root root 12288 Mar 8 2010 lost+found
-rwxr-xr-x 1 root root 262144 Mar 8 2010 u-boot.bin.pagesize
-rw-r--r-- 1 1000 1000 2421824 Mar 8 2010 uImage 

Naja, noch nicht ganz das, was es werden sollte, aber immerhin, es bootet schon mal wieder durch in ein Linux ;)

Another SheevaPlug (-PSU?) bites the dust …

Yepp. War ja klar. Am 12.07.2009 habe ich ihn bekommen — am 13.06.2010 um 17:06 streicht auch mein zweiter SheevaPlug, der Erstkauf, die Segel. Das er »weg« was, hatte ich zwar schon früher am Abend bemerkt, ob der WM aber erst jetzt mich aufgemacht, ihn mal – untypischerweise – zu Powercyclen. Nur leider ist das Kistchen komplett tot, da gibt’s nix zu cyclen …
Also habe ich soeben ein Ersatznetzteil per Mail angefordert, mal sehen, ob NewIT auch diesmal kundenfreundlich und schnell helfen möchte und kann. Auch dieser Plug ist, sogar »ab Händler«, ein UBIFS-System, sodaß einfaches Austauschen der SC-Karte und Weiterarbeit mit einem Ersatz-Sheeva ausscheidet.
So schick das System ja ist — die Nachteile, insbesondere bedingt durch die beschissene Produktqualität seitens GlobalScale, scheinen doch jegliche Vorteile des In-Flash-OS aufzuheben :( Und zu »GlobalScale« fällt mir dann wirklich nur noch der Spruch mit Programmierern und dem Specht ein … *sigh*

Dinge gibt's

Das von dir hochgeladene Video enthält Bearbeitungslisten. Dadurch können möglicherweise Probleme bei der Synchronisierung von Audio und Video auftreten. Weitere Informationen findest du in diesem Artikel.
Bei der von dir hochgeladenen MOV/MP4-Datei befindet sich der Index am Ende. Wir bevorzugen es, wenn du die Datei vor dem Hochladen so bearbeitest, dass sich der Index am Beginn der Datei befindet. In diesem Artikel findest du weitere Informationen.

Und die kodierte Datei (vei YouTube; lokal spielt mplayer die Quelle 1a ab) ist murks, anfangs nur grauer Pixelschleim :( Tja, einfach aus einem mit motion erstellten MPG1-Timelapse mit ffmpeg ein kürzeres x.264-File samt Sound zu machen und dann bei YouTube hochzuladen, dies war nicht von Erfolg gekrönt …

How to brick your DockStar, voiding warranty and installing Ubuntu … (Part V)

Moinsen,
damit der Spannungsbogen nicht einbricht:

CE>> run bootcmd_MLL_no
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
CE>> nand read.e 0x800000 0x100000 0x300000; setenv bootargs console=ttyS0,115200 root=/dev/mtdblock2 ro; bootm 0x800000
[...]
Starting kernel ...
Uncompressing Linux............................................................................................................................ done, booting the kernel.
[ 0.000000] Linux version 2.6.22.18 (bdietrich@brad-ux) (gcc version 4.2.1) #57 Mon Aug 31 16:31:01 PDT 2009
[ 0.000000] CPU: ARM926EJ-S [56251311] revision 1 (ARMv5TE), cr=00053177
[...]
starting pid 347, tty '': '/bin/sh'
-sh-3.2# [ 20.220000] XCE: BLPARAMS: reading 2048 bytes @ a0000
[ 20.230000] XCE: BLPARAMS: reading 2048 bytes @ a0800
[ 20.230000] XCE: BLPARAMS: reading 2048 bytes @ a1000
[ 20.240000] XCE: BLPARAMS: reading 2048 bytes @ a1800
[ 25.480000] XCE: – 'led0=1'

Und:

wusel@greebo:~$ ssh root@dockstar-1
root@dockstar-1's password:
sh: /usr/X11R6/bin/xauth: No such file or directory
-bash-3.2# uname -a
Linux Pogoplug 2.6.22.18 #57 Mon Aug 31 16:31:01 PDT 2009 armv5tejl unknown
-bash-3.2# 

Erstmal wieder reanimiert, das Schätzchen. Lessons learned: USB-Boot kann das beknackte U-Boot des DockStar in der Tat nicht, also wird wohl am erprobten und dokumentierten Weg nun keiner vorbeiführen ;-)

How to brick your DockStar, voiding warranty and installing Ubuntu … (Part IV)

Södale, ich habe nun einfach schnell ‘ne Pizzaschachtel (FSC Scenic Xs) installiert, die hat noch die guten alten RS‐232-Ports, an die ich meinen Conrad C-Control-Programmer dran hängen kann, der letztlich mit den Zugang zur seriellen Schnittstelle des DockStar liefert. Und was sehen meine entzündeten Augen?

 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
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
Unknown command 'usb' - try 'help'
** Block device usb 0 not supported
## Booting image at 00800000 ...
Bad Magic Number
CE>> 

Nunja. Nicht schön, aber …

CE>> help
? - alias for 'help'
base - print or set address offset
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootext2 dev:boot_part1,boot_part2 addr boot_image linux_dev_name
bootm - boot application image from memory
bootp - boot image via network using BootP/TFTP protocol
bubt - Burn an image on the Boot Nand Flash.
chpart - change active partition
cmp - memory compare
cmpm - Compare Memory
cp - memory copy
cpumap - Display CPU memory mapping settings.
crc32 - checksum calculation
date - get/set/reset date & time
dclk - Display the MV device CLKs.
dhcp - invoke DHCP client to obtain IP/boot params
diskboot- boot from IDE device
echo - echo args to console
eeprom - EEPROM sub-system
erase - erase FLASH memory
ext2load- load binary file from a Ext2 filesystem
ext2ls - list files in a directory (default /)
fi - Find value in the memory.
flinfo - print FLASH memory information
fsinfo - print information about filesystems
fsload - load binary file from a filesystem image
g - start application at cached address 'addr'(default addr 0x40000)
go - start application at address 'addr'
help - print online help
icrc32 - checksum calculation
ide - IDE sub-system
iloop - infinite loop on address range
imd - i2c memory display
imm[.b, .s, .w, .l] - i2c memory modify (auto-incrementing)
imw - memory write (fill)
inm - memory modify (constant address)
iprobe - probe to discover valid I2C chip addresses
ir - reading and changing MV internal register values.
loop - infinite loop on address range
ls - list files in a directory (default /)
map - Diasplay address decode windows
md - memory display
me - PCI master enable
mm - memory modify (auto-incrementing)
mp - map PCI BAR
mtdparts- define flash/nand partitions
mtest - simple RAM test
mv_diag - perform board diagnostics
mw - memory write (fill)
nand - NAND sub-system
nboot - boot from NAND device
nbubt - Burn a boot loader image on the Boot Nand Flash.
nm - memory modify (constant address)
pci - list and access PCI Configuration Space
phyRead - Read PCI-E Phy register
pciePhyWrite - Write PCI-E Phy register
phyRead - Read Phy register
phyWrite - Write Phy register
ping - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
protect - enable or disable FLASH write protection
rarpboot- boot image via network using RARP/TFTP protocol
reset - Perform RESET of the CPU
resetenv - Return all environment variable to default.
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
se - PCI Slave enable
setenv - set environment variables
sflash - read, write or erase the external SPI Flash.
sg - scanning the PHYs status
sp - Scan PCI bus.
tftpboot- boot image via network using TFTP protocol
version - print monitor version
CE>> 

… noch scheint nicht aller Tage Abend zu sein. Ok, der nächste Schritt wird jetzt etwas dauern, denn nun muß ich wohl mich erstmal ein wenig einlesen, wie ich diese selbts beigefügte Scharte wieder auswetze ;) (Interessant, daß es ein »Cloud Engines«-Board ist; hat Seagate also echt nur dazugekauft? Witzig …)
Oh. Das scheint ja simpel zu sein:

CE>> run bootcmd_MLL_no; run oldbootcmd
Saving Environment to NAND...
Erasing Nand...Writing to Nand... done
NAND read: device 0 offset 0x100000, size 0x300000
Reading data from 0x3ff800 – 100% complete.
3145728 bytes read: OK
## Booting image at 00800000 ...
Image Name: Linux-2.6.22.18
Created: 2009-08-31 23:31:05 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1976384 Bytes = 1.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................

Das waren dann erstmal die letzten Worte; mal Ethernet ankabeln, ob die Box da gesprächiger ist.