Erhalte Meldung: ** Block device usb 0 not supported
Maggus
bei der heutigen Installation des Debian Linux bin ich nach folgender
Beschreibung vorgegangen:
http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html
Leider erhalte ich jetzt beim booten u.a. Meldung
Kai, Du hast wohl auch diese Meldung erhalten aber in einem Deiner
blogdoch Einträge finde ich keine Lösung für das Problem. Was ist da
fehlgelaufen und wie komm ich da jetzt weiter?
hG Markus
########################################################
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
Unknown command 'usb' - try 'help'
** Block device usb 0 not supported
** Block device usb 0 not supported
## Booting image at 00800000 ...
Bad Magic Number
CE>>
########################################################
Dirk Tostmann
Du nutzt den Original Bootloader ab 0x00000. Der kann nicht von USB booten ...
Daher nutzt man den Umweg mit dem zweiten, moderneren u-boot ab 0xc0000. Hast Du den (noch) drauf?
Oder was passiert wenn Du eingibts:
nand read.e 0xc00000 0x2500000 0x40000; go 0xc00000
Maggus
Es schein als ob das Boot-Image nich vorhanden ist!
Auf dem Usb-Stick ist die Struktur wie folgt:
mars:/ # mount /dev/sdd2 /mnt
mars:/ # cd mnt
mars:/mnt # ls
bin boot dev etc home lib lost+found media mnt opt proc
root sbin selinux srv sys tmp usr var
mars:/mnt # mount /dev/sdd1 /mnt/boot
mars:/mnt # cd boot
mars:/mnt/boot # ls -la
insgesamt 14164
drwxr-xr-x 4 root root 1024 13. Jun 14:38 .
drwxr-xr-x 21 root root 4096 23. Nov 2009 ..
drwxr-xr-x 2 root root 1024 25. Jun 15:56 boot
-rw-r--r-- 1 root root 85107 22. Mai 22:57 config-2.6.32-5-kirkwood
lrwxrwxrwx 1 root root 28 25. Jun 16:00 initrd.img ->
initrd.img-2.6.32-5-kirkwood
-rw-r--r-- 1 root root 5217825 13. Jun 14:29 initrd.img-2.6.32-5-
kirkwood
drwxr-xr-x 2 root root 12288 26. Apr 2009 lost+found
-rw-r--r-- 1 root root 1009318 22. Mai 22:57 System.map-2.6.32-5-
kirkwood
-rw-r--r-- 1 root root 1444216 13. Jun 14:32 uImage
-rw-r--r-- 1 root root 5217889 13. Jun 14:32 uInitrd
lrwxrwxrwx 1 root root 25 25. Jun 16:00 vmlinuz ->
vmlinuz-2.6.32-5-kirkwood
-rw-r--r-- 1 root root 1444152 22. Mai 22:52 vmlinuz-2.6.32-5-
kirkwood
mars:/mnt/boot #
Ich habe das mal ausgeführt und hier ist das Ergebnis.
Ich erkenne den Fehler leider nicht.
hG, Markus
#######################################################
CE>> nand read.e 0xc00000 0x2500000 0x40000; go
0xc00000
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
0
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
Wrong Image Format for bootm
command
ERROR: can't get kernel
image!
resetting ...
Dirk Tostmann
Am 25.06.2010 um 16:48 schrieb Maggus:
> Ich habe das mal ausgeführt und hier ist das Ergebnis.
> Ich erkenne den Fehler leider nicht.
Alles prima!
nand read.e 0xc00000 0x2500000 0x40000; go 0xc00000
lädt den neuen Bootloader, der dann per USB bootet (versucht).
Dein Problem ist die Partitionierung des Sticks. Mach mal besser nur eine Partition und dort das rootfs und kern platzieren.
So wie Du es jetzt hast müßte der uImage-File nach /mnt/boot/boot/
und rootfs= so gesetzt werden, daß er sda2 mounted.
Das kann doch unmöglich so in der Anleitung gestanden haben, oder?
Da Du ja Zugang per Console hast empfehle ich zuerst mal das Env. des ersten Bootloader zu fixen:
setenv bootcmd 'nand read.e 0xc00000 0x2500000 0x40000; go 0xc00000'
saveenv
reset
dann den Kern (uImage) bewegen, oder gleich einen Stick mit nur einer Partition nehmen.
Gruß!
Maggus
also wenn ich da kein Ausführungsfehler gemacht habe steht das genau so in der Anleitung.
Ich werde Dein Vorschlag jetzt mal umsetzen. Danke.
Hier ein Auszug aus der Anleitung (http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html):
*** Schnipp ***
...
I used the following layout:
Device Boot Start End Blocks Id System /dev/sda1 * 1 14 112423+ 83 Linux /dev/sda2 15 210 1574370 83 Linux /dev/sda3 211 251 329332+ 82 Linux swap
Use fdisk to partition your disk (let's call the disk sda for now; remember, if you want to use an SD card, you have to use /dev/mmcblk0). Mark sda1 as a bootable partition (press the key a in fdisk) and make sure that the partition is labled as a Linux partition (type 83). Mark the third partition as a swap partition (type 82). Now format the drive:
% mkfs.ext2 -I 128 /dev/sda1 % mkfs.ext2 /dev/sda2 % mkswap /dev/sda3
Mount the disk somewhere:
% mount /dev/sda2 /mnt % mkdir /mnt/boot % mount /dev/sda1 /mnt/boot ... ... % cd /mnt % tar -xjvf ~/base.tar.bz2
hG, Markus
Kai 'wusel' Siering
> Am 25.06.2010 um 16:48 schrieb Maggus:
>
>> Ich habe das mal ausgeführt und hier ist das Ergebnis.
>> Ich erkenne den Fehler leider nicht.
>
[...]
> Das kann doch unmöglich so in der Anleitung gestanden haben, oder?
Ich denke mal, hier kommen dann verschiedene Kochrezepte zusammen ...
ahsoftware.de nimmt 3 Partitionen (/boot, /, swap), plugapps.com nimmt
1 Partition für / inkl. /boot ...
Wichtig ist denke ich mal, die Grundlagen klar zu machen:
- Der Bootloader im DockStar *kann nicht von USB booten*
- Im DockStar ist eine Flash-Partition unbenutzt, in diese flasht man
bei den gängigen Anleitungen einen neuen Bootloader, der allerdings
*nicht* von außen über Environmentvariablen zu manipulieren - sprich:
geht man den ahsoftware.de-Weg und ändert nichts, ist ein USB-Gerät
mit 3 Partitionen gefragt; bei plugapps.com nur (genau) eine (ok, swap
als Partition >1 stört da nicht)
- Ohne flashen eines neuen Bootloaders kann man *nur* vom Flash oder
vom Netz per tftp booten -- was anderes kann die DockStar-U-Boot-Ver-
sion eben nicht! Da ich die Infrastruktur sowieso schon habe, booten
meine DockStars jetzt vom Netz per tftp -- *hier* kann ich entweder
einen Kernel nehmen, der die Commandline vom U-Boot des DockStars be-
kommt oder einen mit fester Commandline.
- *Theoretisch* müßte man U-Boot vom DockStar austauschen können; macht
man da aber einen Fehler, ist es ein (jetzt nicht mehr sooo) teurer
Briefbeschwerer, ein »brick«! Daher Finger weg und daher beschreibt das
Vorgehen auch noch niemand ...
> Da Du ja Zugang per Console hast empfehle ich zuerst mal das Env. des ersten
> Bootloader zu fixen:
>
> setenv bootcmd 'nand read.e 0xc00000 0x2500000 0x40000; go 0xc00000'
> saveenv
> reset
>
> dann den Kern (uImage) bewegen, oder gleich einen Stick mit nur einer Partition nehmen.
Ack. Und immer nur 1 Kochrezept folgen ;)
kai
Kai 'wusel' Siering
> Am 25.06.2010 17:43, schrieb Dirk Tostmann:
>> Am 25.06.2010 um 16:48 schrieb Maggus:
>>
>> nand read.e 0xc00000 0x2500000 0x40000; go 0xc00000
>>
>> lädt den neuen Bootloader, der dann per USB bootet (versucht).
>>
>> Dein Problem ist die Partitionierung des Sticks. Mach mal besser nur eine Partition und dort das rootfs und kern platzieren.
>>
>> So wie Du es jetzt hast müßte der uImage-File nach /mnt/boot/boot/
>> und rootfs= so gesetzt werden, daß er sda2 mounted.
>>
>> Das kann doch unmöglich so in der Anleitung gestanden haben, oder?
> also wenn ich da kein Ausführungsfehler gemacht habe steht das genau so
> in der Anleitung.
> Ich werde Dein Vorschlag jetzt mal umsetzen. Danke.
>
> Hier ein Auszug aus der Anleitung
> (http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html):
Ahja, das Kochrezept Nummer 3 ;)
Wie ich schon schrieb: USB-Boot *kann der DockStar nicht*, Punkt.
Man kann ihn aber austricksen, indem man etwas bootet, was von USB
booten kann -- jenen 2. U-Boot eben z. B. von plugapps.com. (cyrius.com
unterstützt den DockStar nicht!)
Der 2. U-Boot ist aber *nicht* konfigurierbar. Der bootet *immer* von
/dev/sdaX und zwar das File, was fest hinterlegt wurde.
http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html ist nur
insofern für den DockStar von Interesse, als dort ein *Debian Lenny*-
Archiv bereitgestellt wird für die Kirkwood-CPU-Architektur. Von jener
Seite ist insofern *nur* folgendes für den DockStar ggf. interessant:
> Downloading and installing the Debian base system
>
> Download the compressed base system (about 125 MB; it will require about 365 MB of disk space when you unpack it). This contains a basic system with a standard set of packages of Debian 5.0.4 (lenny, 2010-06-13).
>
> % wget http://people.debian.org/~tbm/sheevaplug/lenny/base.tar.bz2
*Dieses* Archiv ist dann in die vom Kernel zu bootende Root-Partition
zu kopieren, ggf. anzupassen (etc/fstab, etc/hostname, etc/ssh/*key*),
die Partition dann sauber vom Host abzumontieren und dann ab dafür,
ran an den DockStar.
Ich seh' schon, es fehlt noch an detailierteren Schritten, sonst
verheddern sich noch mehr Leute an den verschiedenen HowTos :(
kai
Dirk Tostmann
Am 25.06.2010 um 18:51 schrieb Kai 'wusel' Siering:
> Wie ich schon schrieb: USB-Boot *kann der DockStar nicht*, Punkt.
Also ich, falls wen das interessiert, boote meine Docks mit Standard-Kernen von http://sheeva.with-linux.com/
und einem UBIFS Debian Base Image (plus für obigen Kern passende Modules) aus den internen NAND.
Damit nutze ich vorhandenen Speicher (interne 256MB "Festplatte"), brauche keine extra Sticks und komm' mit dem Original-Bootloader hin. USB Sticks kann man später immernoch "einhängen", wem 256 MB nicht reichen. Das hat zudem Geschwindigkeitsvorteile.
Dazu BRAUCHT MAN aber neben der SERIELLEN KONSOLE, einen TFTP und NFS Server (basically 'ne zweite Linuxbox).
Weg in etwa so (genauere Kochanleitung bei Bedarf):
1. aktuelles uImage von http://sheeva.with-linux.com/ mit bootloader per tftp auf dock holen und nach 0x100000 schreiben.
2. diesen Kern booten und Hilfs-rootfs per NFS mounten um damit nur dass:
3. dort das vorbereitete ubifs.img zu schreiben
flash_eraseall /dev/mtd2
ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
4. bootargs anpassen = .... ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"
(2.+3. geht bestimmt auch anders - effektiv will man ja nur ubifs.img ab 0x500000 ins NAND schreiben - war für mich aber das Einfachste)
(Vorsicht bei 1. - Die Sheeva-Kerne haben (per default) nur drei Partitions, somit wird der Platz für den zweiten Bootloader "genommen" - braucht man aber auch nicht mehr, dafür hat man 252MB rootfs!)
Maggus
> Also ich, falls wen das interessiert, boote meine Docks mit
> Standard-Kernen von http://sheeva.with-linux.com/
>
> Damit nutze ich vorhandenen Speicher (interne 256MB "Festplatte"), brauche keine extra Sticks und komm' mit dem Original-Bootloader hin. USB Sticks kann man sp�ter immernoch "einh�ngen", wem 256 MB nicht reichen. Das hat zudem Geschwindigkeitsvorteile.
>
> Dazu BRAUCHT MAN aber neben der SERIELLEN KONSOLE, einen TFTP und NFS Server (basically 'ne zweite Linuxbox).
>
> Weg in etwa so (genauere Kochanleitung bei Bedarf):
>
> 1. aktuelles uImage von http://sheeva.with-linux.com/ mit bootloader per tftp auf dock holen und nach 0x100000 schreiben.
> 2. diesen Kern booten und Hilfs-rootfs per NFS mounten um damit nur dass:
> 3. dort das vorbereitete ubifs.img zu schreiben
> flash_eraseall /dev/mtd2
> ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
> 4. bootargs anpassen = .... ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs"
>
>
> (Vorsicht bei 1. - Die Sheeva-Kerne haben (per default) nur drei Partitions, somit wird der Platz f�r den zweiten Bootloader "genommen" - braucht man aber auch nicht mehr, daf�r hat man 252MB rootfs!)
>
>
Hallo Dirk,
ich m�chte mit meinem Dockstar, und falls es notwendig und sinvoll ist
mit einem zweiten, meine Haussteuerung (FHT's und FS20 Devices) via CUL
und Fhem betreiben. CUL und Fhem rennen z.Zt. auf einem PC unter
OpenSuse 11.2 einwandfrei.
Ich habe mir den Dockstar ausgesucht, da er sehr stromsparend ist und
keine bekannten Problem mit der "Beriebstemperatur" hat. Der g�nstige
Preis war auch reizvoll ;-)
Ich war mir eigentlich sicher, dass ich Anhand der gefundenen
Anleitungen das Teil zum laufen bringe, habe aber nicht ber�cksichtigt,
dass viele Wege nach Rom f�hren und bis dahin sich so mancher Weg auch
mal kreuzt :-)
Also wenn Du eine Kochanleitung f�r mich hast wie ich meinen CUL und
fhem auf einem oder mehreren Dockstars zum laufen bringe w�re ich Dir
sehr dankbar.
hG, Markus
Kai 'wusel' Siering
> Also ich, falls wen das interessiert, boote meine Docks mit Standard-Kernen
> von http://sheeva.with-linux.com/ und einem UBIFS Debian Base Image (plus
> für obigen Kern passende Modules) aus den internen NAND.
Hmm, macht die andere GPIO-Belegung und ein IIRC anderes Layout im Flash
zwischen DockStar und SheevaPlug da keine Probleme? (Das sind so die Be-
reiche, wo ich noch weniger firm bin ...) Weil: dann wäre das ja cool,
denn die haben ja alle möglichen Module mit dabei, sodaß man sich von da-
her (ich möchte ja auch USB-Cams usw. am DockStar betreiben) das Selbst-
bruzzeln des Kernels sparen könnte.
> Damit nutze ich vorhandenen Speicher (interne 256MB "Festplatte"), brauche
> keine extra Sticks und komm' mit dem Original-Bootloader hin. USB Sticks
> kann man später immernoch "einhängen", wem 256 MB nicht reichen. Das hat
> zudem Geschwindigkeitsvorteile.
Was, einen Stick zu nehmen oder das Flash per UBIFS? Meine Sheevas laufen
ja prinzipiell so (UBIFS-root), und nur für's Booten reichen 258 MB auch
locker aus ;) Das wäre mein nächster Schritt, Kernel und Root-FS auf dem
DockStar, Rest dann per USB.
Aber dmesg legt ein anderes Layout nahe:
SheevaPlug:
Creating 2 MTD partitions on "orion_nand":
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000020000000 : "rootfs"
DockStar:
Creating 4 MTD partitions on "orion_nand":
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000002500000 : "root"
0x000002500000-0x000010000000 : "data"
> Dazu BRAUCHT MAN aber neben der SERIELLEN KONSOLE, einen TFTP und NFS Server (basically 'ne zweite Linuxbox).
Könnte auch 'n Plug/DockStar sein ;) Braucht man das einmalig oder dauerhaft? Mir
scheint dauerhaft bzgl. TFTP, oder wo läßt Du den Kernel?
> Weg in etwa so (genauere Kochanleitung bei Bedarf):
*meld*
kai
Dirk Tostmann
Am 25.06.2010 um 22:08 schrieb Kai 'wusel' Siering:
> Hmm, macht die andere GPIO-Belegung und ein IIRC anderes Layout im Flash
> zwischen DockStar und SheevaPlug da keine Probleme? (Das sind so die Be-
> reiche, wo ich noch weniger firm bin ...) Weil: dann wäre das ja cool,
Ist cool und macht keine Probleme, ich habs ja so am laufen.
Wer mit solchen Kernen arbeiten möchte und Wert auf mtd3 legt kann mittels mtdparts= (in bootargs) dem Kern die ursprünglichen Regionen im NAND des Dockstar so "erklären":
mtdparts=orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0x2000000@0x500000(rootfs),0xDB00000@0x2500000(data)
TFTP brauchst Du nur um den Kern im NAND per u-boot zu tauschen:
setenv ipaddr 10.10.12.243;setenv gatewayip 10.10.12.1;setenv netmask 255.255.255.0;setenv serverip 10.10.12.125
tftpboot 0x800000 uImage
nand erase 0x100000 0x400000
nand write.e 0x800000 0x100000 0x400000
Dann Kopp machen wie das ubifs.img nach mtd2 kommt ... WIe oben per RAM dürfte wegen Größe ausfallen ...
Da geht NFS gut, aber auch booten per USB. Hauptsache mtd2 ist nicht gemounted:
flash_eraseall /dev/mtd2
ubiformat /dev/mtd2 -s 512 -f /wo/auch/immer/ubi.img -y
und bootargs_root nicht vergessen anzupassen:
setenv bootargs_root 'ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'
P.S.: Ich benutze diese
mtdparts=orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0xFAC0000@0x500000(rootfs)
So hab ich mir den zweiten u-boot etwas nach hinten verlegt um mehr Platz fürs rootfs zu schaffen:
tftpboot 0xc00000 mtd3_u-boot.bin
nand erase 0xFFC0000 0x40000
nand write.e 0xc00000 0xFFC0000 0x40000
setenv bootcmd_usb 'nand read.e 0xc00000 0xFFC0000 0x40000; go 0xc00000'
Nur brauchst Du diesen u-boot wenns geklappt hat nimmer ...
Kai 'wusel' Siering
da auch mein Hirn ... ;) Drum bitte ein kurzer Kommentar, ob ich
Dich richtig verstanden habe:
On 06/25/2010 10:40 PM, Dirk Tostmann wrote:
[...]
Also: Du bootest einen Linux-Kernel über TFTP, der ein NFS-Root mounted,
um damit sowohl den Kernel auszutauschen (/dev/mtd1 auf einem DockStar)
als auch ein neues (UBIFS-) Root-FS in den ungenutzten Bereich (/dev/mtd3)
des DockStars zu zaubern?
Sofern ich das richtig sehe: warum klatscht Du den nicht einfach anstelle
des DockStar-Roots nach, äh, /dev/mtd2?
Nochmal zur Erinnerung, bei mir sieht ein DockStar im NAND so aus:
0x000000000000-0x000000100000 : "u-boot"
0x000000100000-0x000000500000 : "uImage"
0x000000500000-0x000002500000 : "root"
0x000002500000-0x000010000000 : "data"
Wobei, vielleicht verstehe ich ja das »Damit nutze ich vorhandenen
Speicher (interne 256MB "Festplatte"), brauche keine extra Sticks
und komm' mit dem Original-Bootloader hin.« auch falsch und Du machst
das DockStar-Geraffel (uImage, root) platt?
> Wer mit solchen Kernen arbeiten möchte und Wert auf mtd3 legt kann mittels mtdparts= (in bootargs) dem Kern die ursprünglichen Regionen im NAND des Dockstar so "erklären":
>
> mtdparts=orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0x2000000@0x500000(rootfs),0xDB00000@0x2500000(data)
> P.S.: Ich benutze diese
> mtdparts=orion_nand:0x100000@0x0(u-boot),0x400000@0x100000(uImage),0xFAC0000@0x500000(rootfs)
> So hab ich mir den zweiten u-boot etwas nach hinten verlegt um mehr Platz fürs rootfs zu schaffen:
Den Part verstehe ich noch nicht; bin halt simpel gestrickt, der NAND-Flash-Bereich
ist imho einfach nur ein (nichtflüchtiger) Speicher. Wer da wie solche Einteilungen
und Bezeichnungen setzt, habe ich noch nicht wirklich verstanden, insbesonder auch
nicht, wie U-Boot und Kernel da zusammenspielen und schlußendlich User-Space-Tools
wie flash_eraseall oder ubiformat. Pointer auf Erklärungen oder so wären nett ;)
Weil: hier harren rd. 6 DockStars einer neuen Aufgabe (für's PogpPlugging werde ich
den originalen PogoPlug nutzen, den mit lebenslanger Pogo-»Nutzungslizenz« ;)); und
wenn TFTP auch cool ist, die vollkommen Standalone nutzen zu können wäre cooler und
den DockStar-Kram brauche ich eh' nicht, kann also von non-evasive zu most-evasive
so langsam mal wechseln ;)
kai
Dirk Tostmann
Am 26.06.2010 um 15:41 schrieb Kai 'wusel' Siering:
> Sofern ich das richtig sehe: warum klatscht Du den nicht einfach anstelle
> des DockStar-Roots nach, äh, /dev/mtd2?
Mach ich doch! Wenn Du einen SheevaPlug-Kern bootest ist ja in mtd2 alles Restliche des NAND !
Ich schreib mal was zusammen (in den nächsten Tagen) - aber eigentlich gehört das nicht zu diesem Thema, hier gings ja eher um USB booten, das ist für einen Einsteiger sicherlich unkomplizierter als per TFTP/NFS einen Dockstar komplett "nackig" zu machen ...
Kai 'wusel' Siering
Naja, »dockpluggers« impliziert nicht zwingend, daß nur USB-Boot gesucht wird.
Aus meiner Sicht der Dinge gibt es derzeit mehrere Ansätze, den DockStar
»anders« zu nutzen. Den Orginalkram draufzulassen und von USB ein »echtes«
Linux zu booten ist sicherlich schon mal nett; aber zumindest, wer auf U-
Boot-Ebene (mit TTL-Serieller) am DockStar herumdoktorn kann/will/mag, der
mag sich auch einen autarken Debian-DockStar wünschen. IMHO. Für mich trifft
das sicher zu ;)
Nachdem ein DockStar mittlerweile meinen »produktiven« NSLU2 ersetzt hat —
und ich hochzufrieden damit bin, der Perfomanceboost ist einfach nur gigantisch —
und ein zweiter 2 weiter USB-HDDs von »irgendwelchen« Desktops (die daher
auch 24/7 liefen) abgezogen hat, werde ich als nächstens meine einen SheevaPlug,
der als USB-Cam-Server dient, nun durch einen DockStar ersetzen und den flexi-
bleren SheevaPlug anderweitig einsetzen. Allerdings gehen mir die USB-Sticks
aus ;)
kai
Kai 'wusel' Siering
On 06/25/2010 07:39 PM, Dirk Tostmann wrote:
> Also ich, falls wen das interessiert, boote meine Docks mit Standard-Kernen
> von http://sheeva.with-linux.com/ und einem UBIFS Debian Base Image (plus
> für obigen Kern passende Modules) aus den internen NAND.
>
> Damit nutze ich vorhandenen Speicher (interne 256MB "Festplatte"), brauche
> keine extra Sticks und komm' mit dem Original-Bootloader hin. USB Sticks
> kann man später immernoch "einhängen", wem 256 MB nicht reichen. Das hat
> zudem Geschwindigkeitsvorteile.
>
> Dazu BRAUCHT MAN aber neben der SERIELLEN KONSOLE, einen TFTP und NFS Server
> (basically 'ne zweite Linuxbox).
>
> Weg in etwa so (genauere Kochanleitung bei Bedarf):
>
> 1. aktuelles uImage von http://sheeva.with-linux.com/ mit bootloader per tftp auf dock holen und nach 0x100000 schreiben.
> 2. diesen Kern booten und Hilfs-rootfs per NFS mounten um damit nur dass:
Hmm. Ich komme bis ...
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.5.235, mask=255.255.255.0, gw=255.255.255.255,
host=DB88FXX81, domain=, nis-domain=(none),
bootserver=192.168.5.2, rootserver=192.168.5.245, rootpath=
Waiting 5sec before mounting root device...
eth0: link up, 1000 Mb/s, full duplex, flow control disabled
Looking up port of RPC 100003/2 on 192.168.5.245
Looking up port of RPC 100005/1 on 192.168.5.245
VFS: Mounted root (nfs filesystem) on device 0:12.
Freeing init memory: 140K
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.
nfs: server 192.168.5.245 not responding, still trying
... bevor ich mir den Wolf suche (gestern abend ist ein fehlendes "saveenv" nach
dem Setzen von mainlineLinux Grund für Mißerfolg gewesen): Any clues/hints? NFS
an sich scheint ja zu tun ("VFS: Mounted root (nfs filesystem) on device 0:12.")
oder sehe ich das falsch? Der NFS-Server sieht's jedenfalls auch so:
nslug-1:/nfs/DockStar_tmp# showmount -a|grep nfs
192.168.5.235:/nfs/DockStar_tmp
Danke & Ciao,
kai
Maggus
>
> Aus meiner Sicht der Dinge gibt es derzeit mehrere Ansätze, den DockStar
> »anders« zu nutzen. Den Orginalkram draufzulassen und von USB ein »echtes«
> Linux zu booten ist sicherlich schon mal nett; aber zumindest, wer auf U-
> Boot-Ebene (mit TTL-Serieller) am DockStar herumdoktorn kann/will/mag, der
> mag sich auch einen autarken Debian-DockStar wünschen. IMHO. Für mich trifft
> das sicher zu ;)
Ich bin übrigens allen dankbar die Ihre Erfahrungen anderen
Interessierten mitteilen, da ich selbst leider nur sehr eingeschränkt
in der Lage bin, wie im Fall Debian-Dockstar, mir solche Lösungswege
auszudenken. Mir ist klar, dass so ein Lösungsweg einem
Elektroingenieur oder Informatiker etwas einfacher fällt - aber auch
er/sie müssen Zeit dafür investieren.
Das Risiko einer womöglich fehlerhaften Umsetzung einer Kochanleitung
liegt natürlich ganz klar auf meiner Seite ;-)
hG, Markus
Dirk Tostmann
Am 29.06.2010 um 08:30 schrieb Kai 'wusel' Siering:
> nfs: server 192.168.5.245 not responding, still trying
Du mußt in /etc/network/interfaces, der NFS-Root, eine Neukonfiguration von eth0 verhindern. Also einfach "auto eth0" auskommentieren.
Sonst zägst Du Dir den Ast weg, auf dem zu sitzt ...
Kai 'wusel' Siering
Lustigerweise geht's, wenn ich vom NFS-Server die IP anpinge ... DANN
komme ich mit dem Lenny-Filesystem von tbm, per NFS exportiert (dieses:
http://people.debian.org/~tbm/sheevaplug/lenny/base.tar.bz2) immerhin
bis ...
> Activating swap...done.
> Checking root file system...fsck 1.41.3 (12-Oct-2008)
> e2fsck 1.41.3 (12-Oct-2008)
> fsck.ext2: No such device or address while trying to open /lib/init/rw/rootdev
> Possibly non-existent or swap device?
> fsck died with exit status 8
> failed (code 8).
> An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be performed in maintenance mode with the root filesystem mounted in read-only mode. failed!
> The root filesystem is currently mounted in read-only mode. A maintenance shell will now be started. After performing system maintenance, press CONTROL-D to terminate the maintenance shell and restart the system. (warning).
> Give root password for maintenance
> (or type Control-D to continue):
;) Erstaunlich, hätte nicht gedacht, daß lenny so leicht auf die Bretter zu
schicke ist. Aber das lag wohl an der gelieferten /etc/fstab bzw. mtab ...
Nach Auskommentieren der eth0-Zeilen in /etc/interfaces und auch dem Aufräumen
von /etc/fstab und Löschen von /etc/mtab sieht's gut aus:
debian:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00400000 00020000 "uImage"
mtd2: 0fb00000 00020000 "root"
So, und wie erstelle ich nun »trocken« ein UBIFS-Image oder brate ich das direkt
1x in /dev/mtd2 und ziehe davon dann ein Image? Kann man nicht den ungenutzten Be-
reich auch noch irgendwie nutzen?
kai
Dirk Tostmann
Am 29.06.2010 um 13:18 schrieb Kai 'wusel' Siering:
> So, und wie erstelle ich nun »trocken« ein UBIFS-Image oder brate ich das direkt
> 1x in /dev/mtd2 und ziehe davon dann ein Image?
UBI aus "/tmp/myroot" erstellen:
mkfs.ubifs -r /tmp/myroot -m 2048 -e 129024 -c 4096 -o ubifs.img -x zlib
ubinize -o ubi.img -m 2048 -p 128KiB -s 512 ubi.cfg
cat ubi.cfg
[ubifs]
mode=ubi
image=ubifs.img
vol_id=0
vol_size=200MiB
vol_type=dynamic
vol_name=rootfs
vol_flags=autoresize
(UBI Tools sind zum Teil nur in "testing" von lenny)
und dann mtd2 "formatieren":
flash_eraseall /dev/mtd2
ubidetach /dev/ubi_ctrl -m 2 # falls nötig
ubiformat /dev/mtd2 -s 512 -f /ubi.img -y
> Kann man nicht den ungenutzten Be-
> reich auch noch irgendwie nutzen?
Ich denke Du kannst "vol_size" in ubi.cfg anpassen. Ich habe eine eher pessimistischen Wert gewählt ...