PlomWiki: Zur Start-Seite Suche Letzte Änderungen (Feed) Letzte Kommentare (Feed)
Impressum Datenschutz-Erklärung

Versions-Geschichte: "SheevaPlug"

Ansicht Bearbeiten Anzeige-Titel setzen Versions-Geschichte Seiten-Passwort setzen AutoLink-Anzeige ein-/ausschalten
2011-03-22 02:39:55 (rückgängig machen): GlobalReplace: list formatting (Admin):
6,14c6,14
- * joe
- * more
- * udev (damit der USB-Stick nach Erkennung durch den Kernel ein Device kriegt)
- * ftp
- * cron
- * screen
- * irssi (und das hat gleich noch perl mit reingeholt)
- * less
- * locales (für dpkg-reconfigure locales; unbenutzte Locales nehmen jetzt einige Megabyte weg, aber ich trau mich nicht, [[localepurge]] zu verwenden, siehe Link)
+ *] joe
+ *] more
+ *] udev (damit der USB-Stick nach Erkennung durch den Kernel ein Device kriegt)
+ *] ftp
+ *] cron
+ *] screen
+ *] irssi (und das hat gleich noch perl mit reingeholt)
+ *] less
+ *] locales (für dpkg-reconfigure locales; unbenutzte Locales nehmen jetzt einige Megabyte weg, aber ich trau mich nicht, [[localepurge]] zu verwenden, siehe Link)
2010-09-17 19:12:15 (rückgängig machen): (plomlompom):
7a8
+ * udev (damit der USB-Stick nach Erkennung durch den Kernel ein Device kriegt)
2010-09-17 01:11:02 (rückgängig machen): (plomlompom):
13c13
- * locales (für dpkg-reconfigure locales; unbenutzte Locales nehmen jetzt einige Megabyte weg, aber ich trau mich nicht, [[localepurge]] zu verwenden)
+ * locales (für dpkg-reconfigure locales; unbenutzte Locales nehmen jetzt einige Megabyte weg, aber ich trau mich nicht, [[localepurge]] zu verwenden, siehe Link)
2010-09-17 01:10:31 (rückgängig machen): (plomlompom):
12a13
+ * locales (für dpkg-reconfigure locales; unbenutzte Locales nehmen jetzt einige Megabyte weg, aber ich trau mich nicht, [[localepurge]] zu verwenden)
2010-09-16 22:47:43 (rückgängig machen): (plomlompom):
11a12
+ * less
2010-09-16 21:04:59 (rückgängig machen): (plomlompom):
10a11
+ * irssi (und das hat gleich noch perl mit reingeholt)
2010-09-16 20:46:40 (rückgängig machen): (plomlompom):
9a10
+ * screen
2010-09-16 20:45:19 (rückgängig machen): (plomlompom):
5c5
- Weitere neben der deboostrap-minbase-Installation installierte Pakete (jeweils mit "--no-install-recommended"):
+ Weitere neben der deboostrap-minbase-Installation installierte Pakete (jeweils mit "--no-install-recommends"):
2010-09-16 20:36:14 (rückgängig machen): (plomlompom):
3a4,9
+ 
+ Weitere neben der deboostrap-minbase-Installation installierte Pakete (jeweils mit "--no-install-recommended"):
+ * joe
+ * more
+ * ftp
+ * cron
2010-09-16 20:35:50 (rückgängig machen): (plomlompom):
3,542c3
- !! Serielle Verbindung zu meinem SheevaPlug
- 
- So ein SheevaPlug ist ja erstmal ein weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Buchstaben-Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
- 
- Ich verbinde meinen Laptop (auf dem ein Debian GNU/Linux läuft) via USB-Kabel mit dem SheevaPlug. Meines Laptop-Debians Kernel erkennt diese neue Verbindung und leitet sie intern auf etwas weiter, das er "ttyUSB0" nennt:
- 
-  $ dmesg                        # Log der letzten Kernel-Nachrichten ausgeben
- (...)
-  ''[237247.840070] usb 5-1: '''new full speed USB device''' using uhci_hcd and address 40''
-  ''[237248.051109] usb 5-1: New USB device found, idVendor=9e88, idProduct=9e8f''
-  ''[237248.051118] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3''
-  ''[237248.051124] usb 5-1: Product: '''SheevaPlug''' JTAGKey FT2232D B''
-  ''[237248.051129] usb 5-1: Manufacturer: FTDI''
-  ''[237248.051134] usb 5-1: SerialNumber: FTSJA9Q3''
-  ''[237248.051332] usb 5-1: configuration #1 chosen from 1 choice''
-  ''[237248.060243] usb 5-1: Ignoring serial port reserved for JTAG''
-  ''[237248.065218] ftdi_sio 5-1:1.1: FTDI USB Serial Device converter detected''
-  ''[237248.065270] usb 5-1: Detected FT2232C''
-  ''[237248.065275] usb 5-1: Number of endpoints 2''
-  ''[237248.065280] usb 5-1: Endpoint 1 MaxPacketSize 64''
-  ''[237248.065285] usb 5-1: Endpoint 2 MaxPacketSize 64''
-  ''[237248.065289] usb 5-1: Setting MaxPacketSize 64''
-  ''[237248.066200] usb 5-1: FTDI USB Serial Device converter '''now attached to ttyUSB0'''''
- 
- Auf dieses "ttyUSB0" kann ich im Dateisystem meines Debians zugreifen: es liegt unter /dev/ttyUSB0. Ich setze das Programm "screen" darauf an:
- 
-  $ screen /dev/ttyUSB0 115200   # "115200" ist die erwartbare Baudrate der Verbindung
- 
- Aus irgendwelchen Gründen erzeugt "screen" nicht sofort eine zufriedenstellende Anzeige: Ich muss ein-zwei mal Enter drücken. Dann aber sollte sich meine Konsole dank "screen" in einen Terminal zu dem verwandeln, was der SheevaPlug an seiner seriellen Schnittstelle bereithält. Der Bootloader des SheevaPlug etwa, "U-Boot", wird mit der Voreinstellung ausgeliefert, eine serielle Schnittstelle auf sich offenzuhalten und mit einer Baudrate von 115200 zu beliefern (daher kommt die Zahl im obigen Befehl). 
- 
- Achtung: das USB-Kabel rutscht sehr leicht aus dem SheevaPlug raus. Wenn's nicht funktioniert also besser mal nachgucken, ob's richtig drinne steckt.
- 
- !! U-Boot-Bootloader updaten
- 
- Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Meine geringfügigen Abweichungen, allein durch Fehleranfälligkeit meinerseits, erfordern aber dennoch nochmal einen Nachvollzug (aus dem Gedächtnis rekonstruiert, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
- 
- Ich brauchte erstmal ein Binary für den neuen Bootloader. Ich wähnte mich zuerst besonders schlau und dachte mir, ich fände ein aktuelleres als das von Michlmayer verlinkte "U-Boot 3.4.27+pingtoo binary"; aber das, was ich nach endlosem Umhersuchen in den PlugComputer-Foren stolz mein eigen nannte, stellte sich im Nachhinein als eben dasselbe heraus. Der nächste Fehler, den ich machte, war, es im versuchten Befolgen von Michlmayers Anweisungen in Unachtsamkeit in "u-boot.bin" statt "uboot.bin" zu benennen, was später einige Verwirrung beim buchstabengetreuen Kopieren von Befehlen stiften würde; das hab ich in diesem Nachvollzug aber bereits auskorrigiert.
- 
- Ich entschied mich unter den beiden von Michlmayer angebotenen Methoden für Installation via USB-Stick. Ein FAT-formatierter USB-Stick wurde verwandt, und ich glaubte mich in Besitz eines eben solchen, kopierte "uboot.bin" drauf, rammte den USB-Stick danach in Sheevas Ritze und gab im U-Boot-Prompt korrekt Folgendes ein:
- 
-  Marvell>> usb start
-  Marvell>> fatload usb 0:1 0x0800000 uboot.bin
- 
- Die erste Zeile zeitigte den gewünschten Erfolg, der USB-Stick wurde erkannt. Die zweite Zeile -- grob lesbar als "fatload (lade von einem FAT-Dateisystem ...) usb 0:1 (... am USB-Interface soundso ...) 0x0800000 (... auf Arbeitsspeicheradresse soundso ...) uboot.bin (... diese Datei)" -- jedoch spuckte beim ersten Durchgang irgendeine Fehlermeldung aus. Nach viel Umhergooglen schälte sich der Verdacht heraus, das könnte an der FAT-Partition auf dem USB-Stick liegen. Offenbar hat U-Boot Probleme mit den Partitionen, wie sie zumindest mein Debian bastelt, wenn ich "cfdisk" und "mkfs.vfat" anwende. 
- 
- Aus irgendwelchen Gründen lies sich das Problem durch erhebliche Verkleinerung der Partition auf dem USB-Stick und Verwendung von FAT16 anstatt einer neueren FAT-Version lösen; für auch alle weiteren Datei-Transfers in den kommenden Abschnitten reicht locker eine Partition von zweihundert Megabyte Größe. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x0800000 im Arbeitsspiecher geschrieben.
- 
- Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs überschreibt. Hier muss der Bootloader liegen. Insofern kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
- 
-  Marvell>> nand erase 0x0 0xa0000
-  Marvell>> nand write 0x0800000 0x0 0xa0000
- 
- Ich nehme das mal auseinander: "nand erase (lösche den Bereich ...) 0x0 (... der hier startet ...) 0xa0000 ( ...mit dieser Länge)"; "nand write (Bereich beschreiben: ...) 0x0800000 (... das, was an dieser Arbeitsspeicheradresse liegt, soll ...) 0x0 (... beginnend dieser Stelle in den NAND-Speicher geschrieben werden, und zwar ...) 0xa0000 (... zu dieser Länge)". Danach dann ...
- 
-  Marvell>> reset
- 
- ... und der U-Boot-Bootloader sollte in einer geupdateten Version neustarten.
- 
- !! U-Boot einen Kernel zum Booten geben
- 
- Als Nächstes habe ich ausprobiert, von U-Boot aus einen neuen Kernel zu booten. Wohlgemerkt, nur einen neuen Kernel; was danach an Dateisystem hätte liegen können, hatte ich zu dem Zeitpunkt schon bis ins Unlesbare korrumpiert, so dass der Kernel erstmal ins Nichts würde booten müssen.
- 
- http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash gibt einige brauchbare Hinweise und Beispiele zum Schreiben eines Kernels in den NAND-Flash des SheevaPlugs, setzt aber die Verwendung des "Trivial File Transfer Protocol" voraus, mit dem mich vertraut zu machen (oder für das gar einen Server auf meinem Debian-Laptop einzurichten?) ich zu faul bin. Stattdessen setze ich auf die bereits beim Updaten des U-Boot-Bootloaders bewährte Methode, im Bootloader Dateien über einen FAT-USB-Stick einzulesen (nähere Details siehe oben "U-Boot-Bootloader updaten").
- 
- Ich ziehe also ein SheevaPlug-geeignetes Kernel-"uImage" auf meinen USB-Stick. Ein "uImage" ist in diesem Fall ein Linux-Kernel-Image, dem noch einige Zusatz-Daten rangepappt sind, die es U-Boot-freundlicher machen; "uboot-mkimage" wäre das Tool der Wahl, wenn man sich selber ein Linux-Kernel-Image solcherart u-Boot-kompatibel verpacken möchte. Ich nehme für den Anfang mal "sheeva-2.6.35.3-uImage", zu finden hier: http://sheeva.with-linux.com/sheeva/ Also rauf auf den USB-Stick damit und den USB-Stick in Sheevas Loch gestoßen! Danach, im U-Boot-Prompt, wird der USB-Stick initialisiert:
- 
-  Marvell>> usb start
-  ''(Re)start USB...''
-  ''USB:   scanning bus for devices... 2 USB Device(s) found''
-  ''Waiting for storage device(s) to settle before scanning...''
-  ''1 Storage Device(s) found''
- 
- (Warum zwei USB-Devices? Na weil ich gleichzeitig via USB-Kabel mit dem SheevaPlug verbunden bin, um via "screen" von meinem Debian-Laptop ein Terminal-Fenster hinein zu haben.) Schauen wir uns nun auf dem USB-Stick mal um:
- 
-  Marvell>> fatls usb 0:1 /
-  ''  2795912   sheeva-2.6.35.3-uimage''
-  
-  ''1 file(s), 0 dir(s)''
- 
- Vorgelesen: "fatls (liste Segmente in einem FAT-Dateisystem auf ...) usb 0:1 (... das sich an diesem USB-Interface befinden ...) / (... und zwar im Root-Verzeichnis)" Hier sehe ich die Datei, die ich als Nächstes in den Arbeitsspeicher einlesen will:
- 
-  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
-  ''reading sheeva-2.6.35.3-uimage''
-  ''.....................................................................''
-  ''.....................................................................''
-  ''.....................................................................''
-  ''..................................................................''
-  
-  ''2795912 bytes read''
- 
- Ich habe das uImage jetzt in den Arbeitsspeicher an Adresse 0x2000000 eingelesen. (Die Adresse habe ich aus http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash übernommen, k.A., was der Toleranzbereich für eine andere Position wäre.) Bevor ich jetzt U-Boot anweise, das an dieser Stelle gelegene Image zu booten, überprüfe ich nochmal, ob an der Adresse jetzt tatsächlich das liegt, was da liegen soll, und zwar mittels "iminfo":
- 
-  Marvell>> iminfo 0x2000000
-  
-  ''## Checking Image at 02000000 ...''
-  ''   Image Name:   Linux-2.6.35.3''
-  ''   Created:      2010-08-21   0:22:34 UTC''
-  ''   Image Type:   ARM Linux Kernel Image (uncompressed)''
-  ''   Data Size:    2795848 Bytes =  2.7 MB''
-  ''   Load Address: 00008000''
-  ''   Entry Point:  00008000''
-  ''   Verifying Checksum ... OK''
- 
- "iminfo" ist ein U-Boot-Programm, das sich an eben den Zusatz-Kopfdaten abzuarbeiten scheint, die "uboot-mkimage" einem Image aufbürdet, wenn es in ein uImage umwandelt. Sieht ja soweit alles ok aus. 
- 
- ('''Nachtrag''': Alle Welt sagt, man solle bei Verwendung von etwas Anderem als dem mitgelieferten Kernel auch noch Folgendes setzen (ohne dass ich auch nur halbwegs verstehen würde, warum):
- 
-  Marvell>> setenv mainlineLinux yes
-  Marvell>> setenv arcNumber 2097
- 
- Das hab ich hier an der Stelle wohl ursprünglich aufzuführen vergessen, weil ich diese Umgebungsvariable bei früheren Versuchen schon gesetzt ''und gespeichert'' hatte, so dass ich sie nicht mehr neu setzen brauchte. Ob der Kernel auch ohne booten würde, bin ich jetzt auszuprobieren zu faul.)
- 
- Also booten wir mal! Das geht ganz einfach, indem ich das Programm "bootm" auf besagte Arbeitsspeicheradresse jage. "bootm" scheint nochmal "iminfo" aufzurufen und schiebt danach den Kernel-Code durch den Prozessor:
- 
-  Marvell>> bootm 0x2000000
-  ''## Booting image at 02000000 ...''
-  ''   Image Name:   Linux-2.6.35.3''
-  ''   Created:      2010-08-21   0:22:34 UTC''
-  ''   Image Type:   ARM Linux Kernel Image (uncompressed)''
-  ''   Data Size:    2795848 Bytes =  2.7 MB''
-  ''   Load Address: 00008000''
-  ''   Entry Point:  00008000''
-  ''   Verifying Checksum ... OK''
-  ''OK''
-  
-  ''Starting kernel ...''
-  
-  ''Uncompressing Linux... done, booting the kernel.''
-  ''Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010''
- (...)
- 
- Es folgen jetzt die fünf Milliarden Bildschirme eines Bootvorganges voller kryptischer Meldungen über initialisierte Speicher, Treiber usw. Gegen Ende kommt dann die erwartbare Todesmeldung, weil der Kernel leider nichts Root-Dateisystem-Brauchbares vorfindet:
- 
-  ''No filesystem could mount root, tried:  ext3 ext2 ext4 cramfs vfat msdos jfs''
-  ''Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)''
- 
- Aber hey, bis hierher ist ja schonmal ganz schön weit ;-)
- 
- Lust, den Kernel permanent zu schreiben? Dann mal rasch im Schnelldurchlauf:
- 
-  Marvell>> usb start
-  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
-  Marvell>> nand erase 0x100000 0x400000
-  Marvell>> nand write 0x2000000 0x100000 0x400000
-  Marvell>> setenv mainlineLinux yes
-  Marvell>> setenv arcNumber 2097
-  Marvell>> saveenv
- 
- Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich vielleicht im übernächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung eventuell auch für vollen Boot-Erfolg noch notwendig sein könnte; alles im übernächsten Abschnitt näher erörtert. Um bis dahin zu gelangen, sollte es erstmal reichen, obige Zeilen zu setzen, selbst wenn der Kernel jetzt noch nicht zufriedenstellend bootet.
- 
- !! Ein minimales Debian installieren, Schritt 1: das Dateisystem-Image bauen
- 
- Gut, ein Kernel ist also drauf auf dem SheevaPlug-internen NAND-Flash-Speicher, aber er hat noch nichts zum Reinbooten. Da helf ich natürlich gerne nach. Weitere wertvolle Hilfen gaben mir dabei folgende Tutorials / Infosammlungen, von denen sich aber keines eins zu eins hier abgebildet findet:
- * http://blog.bofh.it/debian/id_265
- * http://www.digriz.org.uk/kirkwood
- * http://www.linux-mtd.infradead.org/index.html
- 
- Zuerst baue ich auf meinem Laptop-Debian ein kleines Debian-Dateisystem mit dem Programm "debootstrap":
- 
-  # debootstrap --foreign --arch=armel --variant=minbase --include=netbase,iproute,ifupdown,dhcp-client stable debian-stable/
-  ''I: Retrieving Release''
-  ''I: Retrieving Packages''
-  ''I: Validating Packages''
-  ''I: Resolving dependencies of required packages...''
-  ''I: Resolving dependencies of base packages...''
-  ''I: Found additional base dependencies: debian-archive-keyring dhcp3-client dhcp3-common gnupg gpgv libbz2-1.0 libreadline5 libusb-0.1-4 net-tools readline-common ''
-  ''I: Checking component main on http://ftp.us.debian.org/debian...''
-  ''I: Retrieving libacl1''
-  ''I: Validating libacl1''
-  ''I: Retrieving apt''
- (...)
-  ''I: Extracting mount...''
-  ''I: Extracting util-linux...''
-  ''I: Extracting zlib1g...''
- 
- Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines '''minimalen''' Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System unkomprimiert ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Programm-Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einer zweiten Stufe später/dort vorgenommen werden wird. Der Parameter "--include=netbase,iproute,ifupdown,dhcp-client" fügt der Minimal-Auswahl ein paar zusätzliche Pakete hinzu, die es mir im fertigen System erlauben werden, eine Internet-Verbindung herzustellen, so dass mit apt-get weitere Debian-Pakete reingeholt werden können.
- 
- Jetzt habe ich, im Verzeichnis debian-stable/, einen Debian-Verzeichnisbaum vor mir liegen, aber wie krieg ich den auf den SheevaPlug? So mächtig der U-Boot-Bootloader auch ist, er kann nicht einfach einen solchen Verzeichnisbaum in seinen rohen Flash-Speicher schreiben. Ich muss das Ganze verpacken in das Byte für Byte in den Speicher zu schreibende Image eines Dateisystems, das mit den Eigenheiten des NAND-Flash-Speichers im SheevaPlug kompatibel ist.
- 
- Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend erfordert er auch eigensinnige Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils" (MTD, Memory Technology Devices, ist ein Linux-Projekt, um die Flash-Speicher-Welt zu erschließen), das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien mit Fehlermeldungen durchratterte, die offenbar aus meinem debian-stable/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
- 
- Mein zweiter Versuch galt UBIFS, das das neuere und bessere und hippere JFFS2 sein soll. Gleichzeitig ist es aber auch irgendwie komplizierter; im Gegensatz zu JFFS2 handelt man sich damit nämlich nicht nur einfach ein "mkfs.ubifs" ein, sondern eine ganze Kette von Tools, die übereinandergestülpt werden müssen. Denn eigentlich ist UBIFS nur ein Aufsatz auf UBI (Unsorted Block Devices), einer Schichtung über dem rohen Flash-Speicher, die schonmal ein bisschen was von dem Bodendreck wegabstrahiert, und UBIFS ist dann erst die nächste Abstraktionsstufe. Man muss über den rohen Flash-Speicher ein UBI-Device layern, in diesem UBI-Device dann einzelne Volumes anlegen, und in diesen Volumes kann man dann ein UBIFS-Dateisystem laufen lassen. Puh! Nach viel Rumprobieren und Umwegen hab ich dann aber doch eine grobe Vereinfachung gefunden, die wie folgt aussieht: 
- 
- Zuerst würge ich das debian-stable/-Verzeichnis in das Image eines UBIFS-Dateisystems:
- 
-  # mkfs.ubifs -v -r debian-stable/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img
-  ''mkfs.ubifs''
-  ''        root:         debian-stable/''
-  ''        min_io_size:  2048''
-  ''        leb_size:     129024''
-  ''        max_leb_cnt:  4096''
-  ''        output:       ubifs.img''
-  ''        jrn_size:     8388608''
-  ''        reserved:     0''
-  ''        compr:        zlib''
-  ''        keyhash:      r5''
-  ''        fanout:       8''
-  ''        orph_lebs:    1''
-  ''        super lebs:   1''
-  ''        master lebs:  2''
-  ''        log_lebs:     5''
-  ''        lpt_lebs:     2''
-  ''        orph_lebs:    1''
-  ''        main_lebs:    543''
-  ''        gc lebs:      1''
-  ''        index lebs:   9''
-  ''        leb_cnt:      554''
-  ''        UUID:         7C78CF08-339A-4570-84DE-DED2AAA0AD89''
-  ''Success!''
- 
- Wie man an den ganzen seltsamen Parametern zum Befehl und an der beim Image-Erzeugen ausgepuckten Liste von Werten sieht, kann man nicht mal eben so ein UBIFS-Image erzeugen, sondern muss diverse Größen beilegen, die der zu beschreibenden Speichergeometrie eigen sind. Was die Parameter-Angaben im Einzelnen bedeuten, lässt sich durch "mkfs.ubifs --help" rausfinden; ich habe sie 1:1 von http://www.digriz.org.uk/kirkwood übernommen, der für ziemlich genau die gleiche Situation / das gleiche Gerät baute.
- 
- Die Erledigung des ganzen restlichen Überbaus lässt sich mit dem Programm "ubinize" abkürzen. Dieses soll ein Image erzeugen, das man einfach so ohne weiteres Rumbasteln in den rohen Flash-Speicher schreiben kann, um ein von modernen Linux-Kernels bootbares UBI/UBIFS-Dateisystem zu erhalten. Nun wäre es natürlich zu einfach, wenn dafür einfach ein "ubinize" auf das ubifs.img reichen würde; man muss auch hier die mehr oder weniger gleichen Parameter zur Speichergeometrie eingeben und außerdem auch noch eine Konfigurationsdatei anlegen, die das ganze UBI-Organisations-Zeugs zwischen Device und Volumes und Dateisystemen usw. beschreibt. Diese Datei "ubi.cfg" sah in meinem Fall so aus:
- 
-  $ cat ubi.cfg
-  ''[ubifs]''
-  ''mode=ubi''
-  ''image=ubifs.img''
-  ''vol_id=0''
-  ''vol_size=160MiB''
-  ''vol_type=dynamic''
-  ''vol_name=rootfs''
-  ''vol_flags=autoresize''
- 
- Es wird also aus dem "image=ubifs.img" ein "[ubifs]"-Volume gebaut mit dem Namen "rootfs". Wie man vor allem an der etwas beliebigen Angabe "vol_size=160MiB" sieht, hab ich auch diese Zeilen irgendwo weggeklaut, ich weiß nur nicht mehr, woher. Wenn ich es richtig verstanden habe, ist diese Größen-Angabe aufgrund des "vol_flags=autoresize" einigermaßen egal und sollte wohl nur ungefähr groß genug sein, damit das ubifs.img reinpasst; aber ich lasse mich gerne eines Besseren belehren. Das "vol_type=dynamic" besagt, dass das Dateisystem nicht nur lesbar (das wäre "static"), sondern auch beschreibbar sein möge. Was genau "mode=ubi" entscheidet und ob es überhaupt notwendig ist, hab ich keine Ahnung :-)
- 
- Mit dieser Datei in der Hand kann ich jetzt "ubinize" anwerfen:
- 
-  # ubinize -v -m 2048 -p 128KiB -s 512 ubi.cfg -o ubi.img
-  ''ubinize: LEB size:      129024''
-  ''ubinize: PEB size:      131072''
-  ''ubinize: min. I/O size: 2048''
-  ''ubinize: sub-page size: 512''
-  ''ubinize: VID offset:    512''
-  ''ubinize: data offset:   2048''
-  ''ubinize: loaded the ini-file "ubi.cfg"''
-  ''ubinize: count of sections: 1''
- 
-  ''ubinize: parsing section "ubifs"''
-  ''ubinize: mode=ubi, keep parsing''
-  ''ubinize: volume type: dynamic''
-  ''ubinize: volume ID: 0''
-  ''ubinize: volume size: 167772160 bytes''
-  ''ubinize: volume name: rootfs''
-  ''ubinize: volume alignment: 1''
-  ''ubinize: autoresize flags found''
-  ''ubinize: adding volume 0''
-  ''ubinize: writing volume 0''
-  ''ubinize: image file: ubifs.img''
- 
-  ''ubinize: writing layout volume''
-  ''ubinize: done''
- 
- Heraus kommt eine Datei "ubi.img", die ich jetzt theoretisch so 1:1 in den NAND-Speicher schreiben können müsste. Sie enthält die 100 MiB debian-stable/ auf unter 70 MiB runterkomrpimiert.
- 
- !! Ein minimales Debian installieren, Schritt 2: Image in den NAND-Speicher schreiben, booten
- 
- Das fertige "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder in den U-Boot-Bootloader-Prompt vom SheevaPlug ...
- 
-  Marvell>> usb start
-  ''(Re)start USB...''
-  ''USB:   scanning bus for devices... 2 USB Device(s) found''
-  ''Waiting for storage device(s) to settle before scanning...''
-  ''1 Storage Device(s) found''
-  ''Marvell>> fatls usb 0:1 /''
-  '' 72876032   ubi.img''
-  
-  ''1 file(s), 0 dir(s)''
- 
- Alles da, prima. Also rein in den ArbeitsSpeicher damit ...
- 
-  Marvell>> fatload usb 0:1 0x800000 ubi.img
-  ''reading ubi.img''
-  ''.........................''
-  ''.....................................................................''
-  ''.....................................................................''
- (...)
-  ''72876032 bytes read''
- 
- ... und dann den ganzen internen NAND-Speicher nach dem Kernel leer machen, tabula rasa über allem, was vorher da war an Dateisystemen, damit das Image Platz hat, sich frei zu entfalten:
- 
-  Marvell>> nand erase 0x500000 0x1fb00000
-  
-  ''NAND erase: device 0 offset 0x500000, size 0x1fb00000''
-  ''Skipping bad block at  0x09660000''                                          
-  ''Skipping bad block at  0x09760000''                                          
-  ''Skipping bad block at  0x0fba0000''                                          
-  ''Skipping bad block at  0x110c0000''                                          
-  ''Skipping bad block at  0x12420000''                                          
-  ''Skipping bad block at  0x126e0000''                                          
-  ''Skipping bad block at  0x16920000''                                          
-  ''Skipping bad block at  0x1a1c0000''                                          
-  ''Skipping bad block at  0x1aca0000''                                          
-  ''Skipping bad block at  0x1bdc0000''                                          
-  ''Skipping bad block at  0x1c900000''                                    
-  ''Erasing at 0x1ffe0000 -- 100%25 complete.''
-  ''OK''
- 
- Zwei Anmerkungen zu diesem Schritt: Erstens ist die "size" von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher in Sachen Bootloader- und Kernel-Update stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich sollte sie allerdings im Hinterkopf behalten, wenn ich ein sich breiter über den Speicher ausbreitendes Image schreibe:
- 
-  Marvell>> nand write.e 0x800000 0x500000 0x4580000
-  
-  ''NAND write: device 0 offset 0x500000, size 0x4580000''
-  
-  ''Writing data at 0x4a7f800 -- 100%25 complete.''
-  '' 72876032 bytes written: OK''
- 
- Erklärung: Ich habe "nand write.e" genommen statt "nand write", weil ersteres schlechte Blöcke einfach überspringt, anstatt schockiert vor ihnen anzuhalten und abzubrechen. (In diesem konkreten Fall ist das Image zu klein, um beim Schreiben auf einen Bad Block zu stoßen, aber nur für den Fall ... lieber immer diesen Befehl benutzen.) Geschrieben wird das im Arbeitsspeicher an Adresse 0x800000 liegende auf den Bereich ab Adresse 0x500000, und zwar zur Länge 0x4580000. Wo kommt die her? Sie ist die Länge des Images in Bytes dargestellt im Hexadezimalsystem; im Dezimalsystem war's noch die Ziffernfolge 72876032. Fürs rasche Umrechnen zwischen beiden Darstellungsweisen gibt es sicher Millionen Dienstleister, zum Beispiel diese Webseite, die ich verwendet habe: http://www.statman.info/conversions/hexadecimal.html
- 
- So, und jetzt? Reicht das, damit der Kernel booten kann? Nein, natürlich nicht. Denn woher soll er wissen, dass das Dateisystem für ihn an 0x500000 beginnt? Ich muss ihn aufklären. Das tu ich mit der Umgebungsvariable "bootargs", die dem Kernel Boot-Parameter übergibt:
- 
-  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
-  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
-  tfs rootfstype=ubifs
-  Marvell>> saveenv
-  ''Saving Environment to NAND...''
-  ''Erasing Nand...Writing to Nand... done''
- 
- "console=ttyS0,115200" ist eigentlich nicht Boot-relevant, sagt dem Kernel aber, dass er an die serielle Schnittstelle des SheevaPlug mit 115200 Baud seine Ausgabe lenken soll, was es mir erlaubt, via USB-Kabel und "screen /dev/ttyUSB0 115200" in den Kernel-Bootvorgang reinzugucken, also schonmal extrem praktisch ist. 
- 
- "mtdparts=" (MTD Part[ition]s) kündigt nichts Geringeres an als eine ganze Partitionstabelle: Der interne Flash-Speicher wird vom Kernel an der Bezeichnung "orion_nand" erkannt (bzw. bei Problemen stattdessen mal "nand_mtd" ausprobieren; was hier greift, scheint abhängig vom Kernel in der selben Logik zu stecken wie der Wechsel zu "mainlineLinux yes" und "arcNumber 2097", den ich ja auch schon nicht verstanden habe), es folgen Festlegungen der Positionen und Größen seiner Partitionen (nach dem Muster "Größe"@"Position"), wobei jede Partition auch noch in Klammern einen Namen hinterhergeworfen bekommt.
- 
- "ubi.mtd=2" kennzeichnet die zweite dieser MTD-Partitionen als UBI. "root=ubi0:rootfs" benennt innerhalb dieser UBI-Partition das erste (nullte) Volume mit dem Namen "rootfs" als die Unter-Partition, die dem Kernel als Root-Partition zu übergeben ist. "rootfstype" sagt dem Kernel, dass er seine Root-Partition als Dateisystem UBIFS booten soll.
- 
- Gucken wir mal in den Kernel, wie er bootet, nachdem ich mit "reset" jetzt den SheevaPlug neu starte:
- 
-  ''Starting kernel ...''
-  
-  ''Uncompressing Linux... done, booting the kernel.''
-  ''Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010''
- 
- Bis hierhin alles ok. Ein bisschen später dann:
- 
-  ''NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)''
-  ''Scanning device for bad blocks''
-  ''Bad eraseblock 1203 at 0x000009660000''
-  ''Bad eraseblock 1211 at 0x000009760000''
-  ''Bad eraseblock 2013 at 0x00000fba0000''
-  ''Bad eraseblock 2182 at 0x0000110c0000''
-  ''Bad eraseblock 2337 at 0x000012420000''
-  ''Bad eraseblock 2359 at 0x0000126e0000''
-  ''Bad eraseblock 2889 at 0x000016920000''
-  ''Bad eraseblock 3342 at 0x00001a1c0000''
-  ''Bad eraseblock 3429 at 0x00001aca0000''
-  ''Bad eraseblock 3566 at 0x00001bdc0000''
-  ''Bad eraseblock 3656 at 0x00001c900000''
- 
- Ok, die selben bösen Blöcke wie erwartet. Unmittelbar darauf:
- 
-  ''Creating 3 MTD partitions on "orion_nand":''
-  ''0x000000000000-0x000000100000 : "u-boot"''
-  ''0x000000100000-0x000000500000 : "uImage"''
-  ''0x000000500000-0x000020000000 : "root"''
- 
- Hier sehen wir die Partitionstabelle, die wir als Boot-Argument mit übergeben haben.
- 
- Unmittelbar darauf treten wir offenbar in die schöne UBI-Welt ein:
- 
-  ''UBI: attaching mtd2 to ubi0''
-  ''UBI: physical eraseblock size:   131072 bytes (128 KiB)''
-  ''UBI: logical eraseblock size:    129024 bytes''
-  ''UBI: smallest flash I/O unit:    2048''
-  ''UBI: sub-page size:              512''
-  ''UBI: VID header offset:          512 (aligned 512)''
-  ''UBI: data offset:                2048''
-  '''''UBI: volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs'''''
-  ''UBI: attached mtd2 to ubi0''
-  ''UBI: MTD device name:            "root"''
-  '''''UBI: MTD device size:            507 MiB'''''
-  ''UBI: number of good PEBs:        4045''
-  '''''UBI: number of bad PEBs:         11'''''
-  ''UBI: max. allowed volumes:       128''
-  ''UBI: wear-leveling threshold:    4096''
-  ''UBI: number of internal volumes: 1''
-  ''UBI: number of user volumes:     1''
-  ''UBI: available PEBs:             0''
-  ''UBI: total number of reserved PEBs: 4045''
-  ''UBI: number of PEBs reserved for bad PEB handling: 40''
-  '''''UBI: max/mean erase counter: 1/0'''''
-  ''UBI: image sequence number: 0''
-  ''UBI: background thread "ubi_bgt0d" started, PID 462''
- 
- Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. Die dritte hervorgehobene Stelle zählt nochmal die bösen Blöcke auf; hier sollte ich drauf achten, dass diese nicht durch irgendwelche Probleme unverhältnismäßig schnell mehr werden.
- 
- Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist schließlich endlich! "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass der hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen könnte UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen ("wear leveling").  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch verschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format Gucken wir jetzt erstmal weiter, zum Ende des Kernel-Monologs:
- 
-  ''UBIFS: mounted UBI device 0, volume 0, name "rootfs"''
-  '''''UBIFS: file system size:   514805760 bytes (502740 KiB, 490 MiB, 3990 LEBs)'''''
-  '''''UBIFS: journal size:       9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)'''''
-  ''UBIFS: media format:       w4/r0 (latest is w4/r0)''
-  ''UBIFS: default compressor: zlib''
-  ''UBIFS: reserved for root:  0 bytes (0 KiB)''
-  '''''VFS: Mounted root (ubifs filesystem) on device 0:13.'''''
-  ''Freeing init memory: 140K''
-  '''''INIT: version 2.86 booting'''''
-  '''''INIT: No inittab file found'''''
-  
-  '''Enter runlevel: '''
- 
- Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Die 490 MiB sind "3990 LEBs", also "logical erase blocks"; diese sind wegen UBI-Metadaten stets ein bisschen kleiner als die "physical erase blocks" im Speicher. Rundet man die LEBs (je 126 KiB) auf PEBs (je 128 KiB) auf, kommen wir schon auf 498 MiB. Das ebenfalls Metadaten-reiche "Journal" von UBIFS verschlingt, wie die zweite hervorgehobene Zeile zeigt, auch nochmal 8 MiB. Fehlt noch ein MiB; der dürfte locker (wenn auch nicht ganz genau; irgendwer hat hier irgendwo abgerundet) in den elf "bad blocks" aufgehen.
- 
- Die dritte hervorgehobene Zeile kündet vom Erfolg meines Vorhabens: Yay, in dem Image, was ich in den Speicher geschrieben habe, findet der Kernel tatsächlich irgendeine Verzeichniswurzel, in die er hineinbooten kann! Die verbleibenden hervorgehobenen Zeilen dämpfen die Freude dann wieder etwas: Der Kernel möchte gerne an den "init"-Prozess abgeben. Der braucht aber eine Datei /etc/inittab, um sich zu orientieren; ohne die weiß er nicht viel zu tun. Im "Enter runlevel: "-Prompt könnte ich ein bestimmtes "Runlevel", also den Index eines Katalogs an weiteren aufzurufenden Schritten spezifieren; aber ohne inittab gibt es keine solchen Kataloge. Offenkundig ist das System doch noch nicht ganz aus sich selbst heraus bootbar; aber keine Sorge, es läuft alles nach Plan.
- 
- !! Ein minimales Debian installieren, Schritt 3: Dateisystem in eine funktionstüchtige Form bringen
- 
- Ich verweise zurück auf den "--foreign"-Parameter, den ich zu Anfang dem "debootstrap"-Befehl übergab: Der weist debootstrap an, den Bau des Systems in zwei Stufen zu unterteilen. Der erste davon kann egal wo stattfinden und baut ein System, das auch schon ans Ziel geflasht werden kann; dort braucht es aber einen Kernel, der reinbootet und an einen Benutzer übergibt, der notwendige Schritte ausführen kann, um das System fertig zu bekommen. Genaugenommen muss vor Ort in dem Dateisystem dann nämlich "debootstrap --second-stage" aufgerufen werden.
- 
- Aber ich kann ja nichts weiter eintippen als ein nicht vorhandenes Runlevel! Wie soll ich da irgendwas im System machen, geschweige denn "debootstrap --second-stage" aufrufen? Ganz einfach: Ich weise den Kernel an, als Init eine Shell zu öffnen, anstatt nach einer Inittab zu suchen, die noch gar nicht da ist. Mit dem Boot-Parameter "init=[Programmpfad]" kann ich den Kernel anweisen, seinen Init-Prozess ein Programm im Verzeichnisbaum aufzurufen. Also erweitere ich im U-Boot-Prompt die "bootargs"-Umgebungsvariable:
- 
-  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
-  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
-  tfs rootfstype=ubifs init=/bin/bash
-  Marvell>> saveenv
-  Marvell>> reset
- 
- Beim nächsten Boot sieht alles schon freundlicher aus: 
- 
-  ''VFS: Mounted root (ubifs filesystem) on device 0:13.''
-  ''Freeing init memory: 140K''
-  I have no name!@(none):/# 
- 
- Um zu testen, ob ich wirklich Befehle ausführen kann und das von debootstrap gebaute Dateisystem vor mir habe, geb ich mal "ls" ein:
- 
-  # ls
-  ''bin   debootstrap  etc   lib  proc  sbin     sys  usr''
-  ''boot  dev          home  mnt  root  selinux  tmp  var''
- 
- Prima! Alles da, wo es sein sollte. Dann machen wir uns mal an die Arbeit. Das debootstrap-Programm liegt intuitiverweise im Verzeichnis /debootstrap/:
- 
-  # /debootstrap/debootstrap --second-stage
-  ''I: Installing core packages...''
-  ''I: Unpacking required packages...''
-  ''I: Unpacking libacl1...''
-  ''I: Unpacking libattr1...''
- (...)
-  ''I: Base system installed successfully.''
- 
- Er entpackt und konfiguriert fleißig bis zur abschließenden Erfolgsmeldung. Und damit ist theoretisch das Debian fertig eingerichtet. Sogar eine inittab ist jetzt unter /etc/inittab vorhanden.
- 
- Aber halt! Eine kleine Sachen muss jetzt noch angepasst werden, um weiter Freude an der Installation zu haben. Ich teile dem System mit, dass init beim Initialisieren ein TTY an der seriellen Schnittstelle aufmachen soll, mit der Baudrate 115200. Genau für sowas ist die inittab da:
- 
-  # echo 'T0:2345:respawn:/sbin/getty -L ttyS0 115200 linux' >> /etc/inittab
-  # mknod -m 660 /dev/ttyS0 c 4 64
-  # sync
- 
- In der ersten Zeile weise ich an, dass für die "runlevel" / Boot-Stufen 2,3,4,5 das Programm /sbin/getty ein TTY am Device ttyS0 mit der erwünschten Baudrate eröffnen soll. Das Device ttyS0 allerdings existiert gar nicht ohne Weiteres; ich muss es erst anlegen. Das mache ich in der zweiten Zeile. Und in der dritten Zeile stelle ich sicher, dass diese Veränderungen auch wirklich vom Kernel in den permanenten Speicher und nicht nur in einen Cache geschrieben wurden.
- 
- Nun wieder von vorne, in den Boot-Loader. Dort nehme ich das "init=/bin/bash" wieder aus der "bootargs"-Umgebungsvariable raus:
- 
-  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
-  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
-  tfs rootfstype=ubifs
-  Marvell>> saveenv
- 
- Dann wird nochmal neu gebootet, und siehe da:
- 
-  ''INIT: version 2.86 booting''
- (...)
-  ''INIT: Entering runlevel: 2''
-  
-  ''Debian GNU/Linux 5.0 plom-pad ttyS0''
-  
-  plom-pad login:
- 
- Init scheint alles vorzufinden, was es sucht, und ist außerdem so nett, mir einen Login-Prompt an den ttyS0 zu legen.
- 
-  plom-pad login: root
- 
-  ''Linux plom-pad 2.6.35.3 #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010 armv5tel''
-  
-  ''The programs included with the Debian GNU/Linux system are free software;''
-  ''the exact distribution terms for each program are described in the''
-  ''individual files in /usr/share/doc/*/copyright.''
-  
-  ''Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent''
-  ''permitted by applicable law.''
-  plom-pad:~# 
- 
- Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden. 
- 
- Eine andere Irritation ist der Hostname "plom-pad"; den hat debootstrap offenbar direkt vom System übernommen, auf dem es ausgeführt wurde, meinem Debian-bespielten Thinkpad. Ich korrigiere das mal rasch:
- 
-  # echo "plom-plug" > /etc/hostname
- 
- Jedenfalls hab ich jetzt ein System, das läuft und das ausgebaut werden kann. Apropos Ausbau, ich eröffne meiner Installation mal den Zugang zum Debian-Paket-Management:
- 
-  # echo "deb ftp://ftp.de.debian.org/debian/ stable main" > /etc/apt/sources.list
- 
- Die sources.list enthält in der aufgezeigten Form die Schlüssel zu den Debian-Paket-Repositories. Wie man an der URL sehen kann, liegen die im großen weiten Internet. Also brauche ich auch darauf Zugriff. Jetzt sollte sich auszahlen, dass ich vorhin beim debootstrap als "--include=" diverse Internet-Pakete angab. Ich stecke also das Ethernet-Kabel von meinem Router in den Sheeva-Plug und aktiviere den DHCP-Client, der diese Netzverbindung erkennen und das System dementsprechend anpassen sollte:
- 
-  # dhclient
-  ''Internet Systems Consortium DHCP Client V3.1.1''
-  ''Copyright 2004-2008 Internet Systems Consortium.''
-  ''All rights reserved.''
-  ''For info, please visit http://www.isc.org/sw/dhcp/''
- 
-  ''Listening on LPF/eth0/00:50:43:01:69:d3''
-  ''Sending on   LPF/eth0/00:50:43:01:69:d3''
-  ''Sending on   Socket/fallback''
-  ''eth0: link up, 100 Mb/s, full duplex, flow control disabled''
-  ''DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3''
-  ''DHCPOFFER from 192.168.0.1''
-  ''DHCPREQUEST on eth0 to 255.255.255.255 port 67''
-  ''DHCPACK from 192.168.0.1''
-  ''bound to 192.168.0.4 -- renewal in 115431 seconds.''
- 
- Nun weise ich das Debian-Paket-Management "apt" an, aus den in der sources.list verzeichneten Quellen sich einen Index verfügbarer Debian-Pakete zu ziehen:
- 
-  # apt-get update
-  ''Get:1 ftp://ftp.de.debian.org stable Release.gpg [1033B]''
-  ''Get:2 ftp://ftp.de.debian.org stable Release [73.8kB]''
-  ''Get:3 ftp://ftp.de.debian.org stable/main Packages [6675kB]''
-  ''Fetched 6750kB in 14s (469kB/s)''                                                
-  ''Reading package lists... Done''
- 
- Und um zu sehen, ob alles gut läuft, zieh ich gleich mal zur Probe ein solches Paket:
- 
-  # apt-get install joe 
-  ''Reading package lists... Done''
-  ''Building dependency tree... Done''
-  ''The following NEW packages will be installed:''
-  ''  joe''
-  ''0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.''
-  ''Need to get 382kB of archives.''
-  ''After this operation, 1180kB of additional disk space will be used.''
-  ''Get:1 ftp://ftp.de.debian.org stable/main joe 3.5-2 [382kB]''
-  ''Fetched 382kB in 1s (245kB/s)''
-  ''debconf: delaying package configuration, since apt-utils is not installed''
-  ''Selecting previously deselected package joe.''
-  ''(Reading database ... 6043 files and directories currently installed.)''
-  ''Unpacking joe (from .../archives/joe_3.5-2_armel.deb) ...''
-  ''Setting up joe (3.5-2) ...''
- 
- !! Nachträge
- 
- Um künftig von der seriellen Verbindung unabhängig zu sein, zuerst dafür sorgen, dass sich der SheevaPlug nach jedem Neustart selbständig mit ''dhclient'' ins Netz einwählt, also einen Aufruf "''dhclient''" in die /etc/rc.local schreiben; und danach mit "''apt-get --no-install-recommends install ssh''" SSH installieren.
- 
- Um einem im SheevaPlug erkannten USB-Stick einen Geräteknoten unter /dev/ zuzuweisen, noch mit "''apt-get install udev''" udev installieren. Mit "''mkdir /mnt/usbstick''" ein Verzeichnis anlegen und in die etc/rc.local den folgenden Befehl schreiben, um bei jedem Neustart den USB-Stick darauf zu mounten: "''mount /dev/sda1 /mnt/usbstick -o noatime''"
- 
- Halte die Systemzeit mit ntpd aktuell: "''apt-get --no-install-recommends install ntp''".
+ [[SheevaPlugInstallation]]
2010-09-15 16:24:27 (rückgängig machen): (plomlompom):
540a541,542
+ 
+ Halte die Systemzeit mit ntpd aktuell: "''apt-get --no-install-recommends install ntp''".
2010-09-15 16:11:23 (rückgängig machen): (plomlompom):
540c540
- Um einem im SheevaPlug erkannten USB-Stick einen Geräteknoten unter /dev/ zuzuweisen, noch mit "''apt-get install udev''" udev installieren.
+ Um einem im SheevaPlug erkannten USB-Stick einen Geräteknoten unter /dev/ zuzuweisen, noch mit "''apt-get install udev''" udev installieren. Mit "''mkdir /mnt/usbstick''" ein Verzeichnis anlegen und in die etc/rc.local den folgenden Befehl schreiben, um bei jedem Neustart den USB-Stick darauf zu mounten: "''mount /dev/sda1 /mnt/usbstick -o noatime''"
2010-09-15 15:50:34 (rückgängig machen): (plomlompom):
540c540
- Um einen USB-Stick im SheevaPlug zu erkennen, noch mit "''apt-get install udev''" udev installieren.
+ Um einem im SheevaPlug erkannten USB-Stick einen Geräteknoten unter /dev/ zuzuweisen, noch mit "''apt-get install udev''" udev installieren.
2010-09-15 15:49:59 (rückgängig machen): (plomlompom):
536c536,540
- '''Nachtrag:''' Um künftig von der seriellen Verbindung unabhängig zu sein, zuerst dafür sorgen, dass sich der SheevaPlug nach jedem Neustart selbständig mit ''dhclient'' ins Netz einwählt, also einen Aufruf "''dhclient''" in die /etc/rc.local schreiben; und danach mit "''apt-get --no-install-recommends install ssh''" SSH installieren.
+ !! Nachträge
+ 
+ Um künftig von der seriellen Verbindung unabhängig zu sein, zuerst dafür sorgen, dass sich der SheevaPlug nach jedem Neustart selbständig mit ''dhclient'' ins Netz einwählt, also einen Aufruf "''dhclient''" in die /etc/rc.local schreiben; und danach mit "''apt-get --no-install-recommends install ssh''" SSH installieren.
+ 
+ Um einen USB-Stick im SheevaPlug zu erkennen, noch mit "''apt-get install udev''" udev installieren.
2010-09-15 15:08:15 (rückgängig machen): (plomlompom):
536c536
- '''Nachtrag:''' Um künftig von der seriellen Verbindung unabhängig zu sein, zuerst dafür sorgen, dass sich der SheevaPlug nach jedem Neustart selbständig mit ''dhclient'' ins Netz einwählt, also einen Aufruf ''"dhclient"'' in die /etc/rc.local schreiben; und danach mit ''"apt-get --no-install-recommends install ssh"'' SSH installieren.
+ '''Nachtrag:''' Um künftig von der seriellen Verbindung unabhängig zu sein, zuerst dafür sorgen, dass sich der SheevaPlug nach jedem Neustart selbständig mit ''dhclient'' ins Netz einwählt, also einen Aufruf "''dhclient''" in die /etc/rc.local schreiben; und danach mit "''apt-get --no-install-recommends install ssh''" SSH installieren.
2010-09-15 15:07:52 (rückgängig machen): (plomlompom):
534a535,536
+ 
+ '''Nachtrag:''' Um künftig von der seriellen Verbindung unabhängig zu sein, zuerst dafür sorgen, dass sich der SheevaPlug nach jedem Neustart selbständig mit ''dhclient'' ins Netz einwählt, also einen Aufruf ''"dhclient"'' in die /etc/rc.local schreiben; und danach mit ''"apt-get --no-install-recommends install ssh"'' SSH installieren.
2010-08-28 01:45:57 (rückgängig machen): (plomlompom):
448c448
- In der ersten Zeile weiße ich an, dass für die "runlevel" / Boot-Stufen 2,3,4,5 das Programm /sbin/getty ein TTY am Device ttyS0 mit der erwünschten Baudrate eröffnen soll. Das Device ttyS0 allerdings existiert gar nicht ohne Weiteres; ich muss es erst anlegen. Das mache ich in der zweiten Zeile. Und in der dritten Zeile stelle ich sicher, dass diese Veränderungen auch wirklich vom Kernel in den permanenten Speicher und nicht nur in einen Cache geschrieben wurden.
+ In der ersten Zeile weise ich an, dass für die "runlevel" / Boot-Stufen 2,3,4,5 das Programm /sbin/getty ein TTY am Device ttyS0 mit der erwünschten Baudrate eröffnen soll. Das Device ttyS0 allerdings existiert gar nicht ohne Weiteres; ich muss es erst anlegen. Das mache ich in der zweiten Zeile. Und in der dritten Zeile stelle ich sicher, dass diese Veränderungen auch wirklich vom Kernel in den permanenten Speicher und nicht nur in einen Cache geschrieben wurden.
2010-08-28 01:35:10 (rückgängig machen): (plomlompom):
481c481,483
- Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden. Eine andere Irritation ist der Hostname "plom-pad"; den hat debootstrap offenbar direkt vom System übernommen, auf dem es ausgeführt wurde, meinem Debian-bespielten Thinkpad. Ich korrigiere das mal rasch:
+ Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden. 
+ 
+ Eine andere Irritation ist der Hostname "plom-pad"; den hat debootstrap offenbar direkt vom System übernommen, auf dem es ausgeführt wurde, meinem Debian-bespielten Thinkpad. Ich korrigiere das mal rasch:
2010-08-28 01:34:36 (rückgängig machen): (plomlompom):
481c481,485
- Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden. Aber Hauptsache, man hat jetzt ein System, das läuft und das ausgebaut werden kann. Apropos Ausbau, ich eröffne meiner Installation mal den Zugang zum Debian-Paket-Management:
+ Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden. Eine andere Irritation ist der Hostname "plom-pad"; den hat debootstrap offenbar direkt vom System übernommen, auf dem es ausgeführt wurde, meinem Debian-bespielten Thinkpad. Ich korrigiere das mal rasch:
+ 
+  # echo "plom-plug" > /etc/hostname
+ 
+ Jedenfalls hab ich jetzt ein System, das läuft und das ausgebaut werden kann. Apropos Ausbau, ich eröffne meiner Installation mal den Zugang zum Debian-Paket-Management:
2010-08-28 01:26:42 (rückgängig machen): (plomlompom):
503c503
- Und weiter:
+ Nun weise ich das Debian-Paket-Management "apt" an, aus den in der sources.list verzeichneten Quellen sich einen Index verfügbarer Debian-Pakete zu ziehen:
512c512
- Und weiter: 
+ Und um zu sehen, ob alles gut läuft, zieh ich gleich mal zur Probe ein solches Paket:
2010-08-28 01:24:25 (rückgängig machen): (plomlompom):
481c481,528
- Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. (Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden.)
+ Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden. Aber Hauptsache, man hat jetzt ein System, das läuft und das ausgebaut werden kann. Apropos Ausbau, ich eröffne meiner Installation mal den Zugang zum Debian-Paket-Management:
+ 
+  # echo "deb ftp://ftp.de.debian.org/debian/ stable main" > /etc/apt/sources.list
+ 
+ Die sources.list enthält in der aufgezeigten Form die Schlüssel zu den Debian-Paket-Repositories. Wie man an der URL sehen kann, liegen die im großen weiten Internet. Also brauche ich auch darauf Zugriff. Jetzt sollte sich auszahlen, dass ich vorhin beim debootstrap als "--include=" diverse Internet-Pakete angab. Ich stecke also das Ethernet-Kabel von meinem Router in den Sheeva-Plug und aktiviere den DHCP-Client, der diese Netzverbindung erkennen und das System dementsprechend anpassen sollte:
+ 
+  # dhclient
+  ''Internet Systems Consortium DHCP Client V3.1.1''
+  ''Copyright 2004-2008 Internet Systems Consortium.''
+  ''All rights reserved.''
+  ''For info, please visit http://www.isc.org/sw/dhcp/''
+ 
+  ''Listening on LPF/eth0/00:50:43:01:69:d3''
+  ''Sending on   LPF/eth0/00:50:43:01:69:d3''
+  ''Sending on   Socket/fallback''
+  ''eth0: link up, 100 Mb/s, full duplex, flow control disabled''
+  ''DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3''
+  ''DHCPOFFER from 192.168.0.1''
+  ''DHCPREQUEST on eth0 to 255.255.255.255 port 67''
+  ''DHCPACK from 192.168.0.1''
+  ''bound to 192.168.0.4 -- renewal in 115431 seconds.''
+ 
+ Und weiter:
+ 
+  # apt-get update
+  ''Get:1 ftp://ftp.de.debian.org stable Release.gpg [1033B]''
+  ''Get:2 ftp://ftp.de.debian.org stable Release [73.8kB]''
+  ''Get:3 ftp://ftp.de.debian.org stable/main Packages [6675kB]''
+  ''Fetched 6750kB in 14s (469kB/s)''                                                
+  ''Reading package lists... Done''
+ 
+ Und weiter: 
+ 
+  # apt-get install joe 
+  ''Reading package lists... Done''
+  ''Building dependency tree... Done''
+  ''The following NEW packages will be installed:''
+  ''  joe''
+  ''0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.''
+  ''Need to get 382kB of archives.''
+  ''After this operation, 1180kB of additional disk space will be used.''
+  ''Get:1 ftp://ftp.de.debian.org stable/main joe 3.5-2 [382kB]''
+  ''Fetched 382kB in 1s (245kB/s)''
+  ''debconf: delaying package configuration, since apt-utils is not installed''
+  ''Selecting previously deselected package joe.''
+  ''(Reading database ... 6043 files and directories currently installed.)''
+  ''Unpacking joe (from .../archives/joe_3.5-2_armel.deb) ...''
+  ''Setting up joe (3.5-2) ...''
2010-08-28 01:10:54 (rückgängig machen): (plomlompom):
481c481
- Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand.
+ Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. (Evtl. nicht der sicherste dauerhafte Zustand, demnächst sollte ein Passwort gesetzt werden.)
2010-08-28 01:09:41 (rückgängig machen): (plomlompom):
410c410
- Aber ich kann ja nichts weiter eintippen als ein nicht vorhandenes Runlevel! Wie soll ich da irgendwas im System machen, geschweige denn "debootstrap --second-stage" aufrufen? Ganz einfach: Ich weiße den Kernel an, als Init eine Shell zu öffnen. Mit dem Boot-Parameter "init=[Programmpfad]" kann ich den Kernel anweisen, seinen Init-Prozess ein Programm im Verzeichnisbaum aufzurufen. Also erweitere ich im U-Boot-Prompt die "bootargs"-Umgebungsvariable:
+ Aber ich kann ja nichts weiter eintippen als ein nicht vorhandenes Runlevel! Wie soll ich da irgendwas im System machen, geschweige denn "debootstrap --second-stage" aufrufen? Ganz einfach: Ich weise den Kernel an, als Init eine Shell zu öffnen, anstatt nach einer Inittab zu suchen, die noch gar nicht da ist. Mit dem Boot-Parameter "init=[Programmpfad]" kann ich den Kernel anweisen, seinen Init-Prozess ein Programm im Verzeichnisbaum aufzurufen. Also erweitere ich im U-Boot-Prompt die "bootargs"-Umgebungsvariable:
424c424
- Um zu testen, ob ich wirklich Befehle ausführen kann und das von debootstrap gebaute Dateisystem vor mir habe, gebe ich "ls" ein:
+ Um zu testen, ob ich wirklich Befehle ausführen kann und das von debootstrap gebaute Dateisystem vor mir habe, geb ich mal "ls" ein:
430c430
- Prima! Dann machen wir uns mal an die Arbeit. Das debootstrap-Programm liegt intuitiverweise im Verzeichnis /debootstrap/:
+ Prima! Alles da, wo es sein sollte. Dann machen wir uns mal an die Arbeit. Das debootstrap-Programm liegt intuitiverweise im Verzeichnis /debootstrap/:
440c440
- Er entpackt und konfiguriert fleißig bis zur abschließenden Erfolgsmeldung. Und damit ist theoretisch das Debian fertig eingerichtet. Sogar eine inittab ist jetzt unter /etc/inittab vorhanden!
+ Er entpackt und konfiguriert fleißig bis zur abschließenden Erfolgsmeldung. Und damit ist theoretisch das Debian fertig eingerichtet. Sogar eine inittab ist jetzt unter /etc/inittab vorhanden.
445a446
+  # sync
447c448
- In der ersten Zeile weiße ich an, dass für die "runlevel" / Boot-Stufen 2,3,4,5 das Programm /sbin/getty ein TTY am Device ttyS0 mit der erwünschten Baudrate eröffnen soll. Das Device ttyS0 allerdings existiert gar nicht ohne Weiteres; ich muss es erst anlegen. Das mache ich in der zweiten Zeile.
+ In der ersten Zeile weiße ich an, dass für die "runlevel" / Boot-Stufen 2,3,4,5 das Programm /sbin/getty ein TTY am Device ttyS0 mit der erwünschten Baudrate eröffnen soll. Das Device ttyS0 allerdings existiert gar nicht ohne Weiteres; ich muss es erst anlegen. Das mache ich in der zweiten Zeile. Und in der dritten Zeile stelle ich sicher, dass diese Veränderungen auch wirklich vom Kernel in den permanenten Speicher und nicht nur in einen Cache geschrieben wurden.
2010-08-28 01:01:09 (rückgängig machen): (plomlompom):
404c404
- Die dritte hervorgehobene Zeile kündet vom Erfolg meines Vorhabens: Yay, in dem Image, was ich in den Speicher geschrieben habe, findet der Kernel tatsächlich irgendeine Verzeichniswurzel, in die er hineinbooten kann! Die verbleibenden hervorgehobenen Zeilen dämpfen die Freude dann wieder etwas: Der Kernel möchte gerne an den "init"-Prozess abgeben. Der braucht aber eine Datei /etc/inittab, um sich zu orientieren; ohne die weiß er nicht viel zu tun. Im "Enter runlevel: "-Prompt könnte ich ein bestimmtes "Runlevel", also einen bestimmten Katalog an weiteren aufzurufenden Schritten spezifieren; aber ohne inittab gibt es keine solchen Kataloge.
+ Die dritte hervorgehobene Zeile kündet vom Erfolg meines Vorhabens: Yay, in dem Image, was ich in den Speicher geschrieben habe, findet der Kernel tatsächlich irgendeine Verzeichniswurzel, in die er hineinbooten kann! Die verbleibenden hervorgehobenen Zeilen dämpfen die Freude dann wieder etwas: Der Kernel möchte gerne an den "init"-Prozess abgeben. Der braucht aber eine Datei /etc/inittab, um sich zu orientieren; ohne die weiß er nicht viel zu tun. Im "Enter runlevel: "-Prompt könnte ich ein bestimmtes "Runlevel", also den Index eines Katalogs an weiteren aufzurufenden Schritten spezifieren; aber ohne inittab gibt es keine solchen Kataloge. Offenkundig ist das System doch noch nicht ganz aus sich selbst heraus bootbar; aber keine Sorge, es läuft alles nach Plan.
406c406,408
- Wie, ist da vielleicht doch kein bootbares Unix in dem geflashten Image? Naja, noch kein richtig bootbares. Ich verweise zurück auf den "--foreign"-Parameter, den ich zu Anfang dem "debootstrap"-Befehl übergab: Der weist debootstrap an, den Bau des Systems in zwei Stufen zu unterteilen. Der erste davon kann egal wo stattfinden und baut ein System, das auch schon ans Ziel geflasht werden kann; dort braucht es aber einen Kernel, der reinbootet und an einen Benutzer übergibt, der notwendige Schritte ausführen kann, um das System fertig zu bekommen. Genaugenommen muss vor Ort in dem Dateisystem dann nämlich "debootstrap --second-stage" aufgerufen werden.
+ !! Ein minimales Debian installieren, Schritt 3: Dateisystem in eine funktionstüchtige Form bringen
+ 
+ Ich verweise zurück auf den "--foreign"-Parameter, den ich zu Anfang dem "debootstrap"-Befehl übergab: Der weist debootstrap an, den Bau des Systems in zwei Stufen zu unterteilen. Der erste davon kann egal wo stattfinden und baut ein System, das auch schon ans Ziel geflasht werden kann; dort braucht es aber einen Kernel, der reinbootet und an einen Benutzer übergibt, der notwendige Schritte ausführen kann, um das System fertig zu bekommen. Genaugenommen muss vor Ort in dem Dateisystem dann nämlich "debootstrap --second-stage" aufgerufen werden.
2010-08-28 00:56:20 (rückgängig machen): (plomlompom):
368c368
-  ''UBI: volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs''
+  '''''UBI: volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs'''''
371c371
-  ''UBI: MTD device size:            507 MiB''
+  '''''UBI: MTD device size:            507 MiB'''''
373c373
-  ''UBI: number of bad PEBs:         11''
+  '''''UBI: number of bad PEBs:         11'''''
381c381
-  ''UBI: max/mean erase counter: 1/0''
+  '''''UBI: max/mean erase counter: 1/0'''''
385c385
- Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. Die dritte hervorgehobene Stelle zählt nochmal die bösen Blöcke auf; hier sollte ich drauf achten, dass diese nicht durch irgendeinen Fehler unverhältnismäßig schnell mehr werden.
+ Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. Die dritte hervorgehobene Stelle zählt nochmal die bösen Blöcke auf; hier sollte ich drauf achten, dass diese nicht durch irgendwelche Probleme unverhältnismäßig schnell mehr werden.
387c387
- Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass der hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen könnte UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen ("wear leveling").  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch verschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format Gucken wir jetzt erstmal weiter, zum Ende des Kernel-Monologs:
+ Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist schließlich endlich! "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass der hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen könnte UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen ("wear leveling").  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch verschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format Gucken wir jetzt erstmal weiter, zum Ende des Kernel-Monologs:
2010-08-28 00:53:49 (rückgängig machen): (plomlompom):
359c359
- Unmittelbar darauf:
+ Unmittelbar darauf treten wir offenbar in die schöne UBI-Welt ein:
368,377c368
-  '''''UBI warning: ubi_scan: 3500 PEBs are corrupted'''''
-  ''corrupted PEBs are: 545 546 547 548 549 550 551 552 553 554 555''
-  ''556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571''
-  ''572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587''
-  ''588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603''
- (usw. usf. bis zur Nummer 4055)
- 
- Huch! Das sieht gefährlich aus. Rechnen wir mal nach (PEB = Physical Eraseblock = 128 KiB), sind 3500 PEBs aber ungefähr der ganze Bereich, der vorhin mit leerem Arbeitsspeicher überschrieben wurde. Beim nächsten Boot ist diese Meldung verschwunden; UBI hat dann offenbar diesen Bereich als verloren abgeschrieben und tabula-rasa-erneuert unter sein UBI-Diktat gebracht. (Oder auch nicht; ich bin noch nicht soweit im Experimentieren, um das abschließend beurteilen zu können. Vielleicht ist auch alles als kaputt und nicht benutzbar markiert, das wär natürlich doof ;-) ) Als Nächstes:
- 
-  ''UBI: '''volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs'''''
+  ''UBI: volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs''
380c371
-  ''UBI: '''MTD device size:            507 MiB'''''
+  ''UBI: MTD device size:            507 MiB''
382c373
-  ''UBI: '''number of bad PEBs:         11'''''
+  ''UBI: number of bad PEBs:         11''
390c381
-  ''UBI: '''max/mean erase counter: 1/0'''''
+  ''UBI: max/mean erase counter: 1/0''
2010-08-28 00:42:23 (rückgängig machen): (plomlompom):
258c258
- !! Ein minimales Debian installieren, Schritt 2: Dateisystem-Image in den NAND-Speicher schreiben
+ !! Ein minimales Debian installieren, Schritt 2: Image in den NAND-Speicher schreiben, booten
323c323
- "mtdparts=" (MTD Part[ition]s) kündigt nichts Geringeres an als eine ganze Partitionstabelle: Der interne Flash-Speicher wird vom Kernel an der Bezeichnung "orion_nand" erkannt (bzw. bei Problemen stattdessen mal "nand_mtd" ausprobieren; was hier greift, scheint abhängig vom Kernel in der selben Logik zu stecken wie der Wechsel zu "mainlineLinux yes" und "arcNumber 2097"), es folgen Festlegungen der Positionen und Größen seiner Partitionen (nach dem Muster Größe@Position), wobei jede Partition auch noch in Klammern einen Namen hinterhergeworfen bekommt.
+ "mtdparts=" (MTD Part[ition]s) kündigt nichts Geringeres an als eine ganze Partitionstabelle: Der interne Flash-Speicher wird vom Kernel an der Bezeichnung "orion_nand" erkannt (bzw. bei Problemen stattdessen mal "nand_mtd" ausprobieren; was hier greift, scheint abhängig vom Kernel in der selben Logik zu stecken wie der Wechsel zu "mainlineLinux yes" und "arcNumber 2097", den ich ja auch schon nicht verstanden habe), es folgen Festlegungen der Positionen und Größen seiner Partitionen (nach dem Muster "Größe"@"Position"), wobei jede Partition auch noch in Klammern einen Namen hinterhergeworfen bekommt.
2010-08-28 00:37:53 (rückgängig machen): (plomlompom):
173a174,176
+  ''I: Extracting mount...''
+  ''I: Extracting util-linux...''
+  ''I: Extracting zlib1g...''
2010-08-28 00:37:14 (rückgängig machen): (plomlompom):
298c298
- Zwei Anmerkungen zu diesem Schritt: Erstens ist die "size" von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Alles, was vorher noch im Rest des Speichers lag, ist jetzt weg. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich muss sie allerdings im Hinterkopf behalten, wenn ich als Nächstes das Image schreibe:
+ Zwei Anmerkungen zu diesem Schritt: Erstens ist die "size" von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher in Sachen Bootloader- und Kernel-Update stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich sollte sie allerdings im Hinterkopf behalten, wenn ich ein sich breiter über den Speicher ausbreitendes Image schreibe:
300c300
-  Marvell>> nand write.e 0x800000 0x500000 0x1fb00000
+  Marvell>> nand write.e 0x800000 0x500000 0x4580000
302c302
-  ''NAND write: device 0 offset 0x500000, size 0x1fb00000''
+  ''NAND write: device 0 offset 0x500000, size 0x4580000''
304,317c304,305
-  ''Bad block at 0x9660000 in erase block from 0x9660000 will be skipped''
-  ''Bad block at 0x9760000 in erase block from 0x9760000 will be skipped''
-  ''Bad block at 0xfba0000 in erase block from 0xfba0000 will be skipped''
-  ''Bad block at 0x110c0000 in erase block from 0x110c0000 will be skipped''
-  ''Bad block at 0x12420000 in erase block from 0x12420000 will be skipped''
-  ''Bad block at 0x126e0000 in erase block from 0x126e0000 will be skipped''
-  ''Bad block at 0x16920000 in erase block from 0x16920000 will be skipped''
-  ''Bad block at 0x1a1c0000 in erase block from 0x1a1c0000 will be skipped''
-  ''Bad block at 0x1aca0000 in erase block from 0x1aca0000 will be skipped''
-  ''Bad block at 0x1bdc0000 in erase block from 0x1bdc0000 will be skipped''
-  ''Bad block at 0x1c900000 in erase block from 0x1c900000 will be skipped''
-  ''Writing data at 0x1fc4e000 --  99%25 complete.''
-  ''Data did not fit into device, due to bad blocks''
-  '' 531628032 bytes written: ERROR''
+  ''Writing data at 0x4a7f800 -- 100%25 complete.''
+  '' 72876032 bytes written: OK''
319c307
- Ui, "ERROR", das sieht gefährlich aus! Es ist aber nur halb so schlimm. Erklärung: Ich hätte hier die Wahl zwischen "nand write" und "nand write.e" als Methoden gehabt, um das bei 0x800000 im Arbeitsspeicher lokalisierte UBI-Image an 0x500000 zu schreiben. "nand write" bricht allerdings ab, sobald es einem Bad Block begegnet; "nand write.e" dagegen überspringt die bösen Blöcke einfach. Nun gab ich als zu schreibende Länge ja 0x1fb00000 an; also alles im Arbeitsspeicher ab 0x800000 bis auf die nächsten 0x1fb00000 Stellen. Eigentlich interessiert nur der Anfangsteil dieser Länge, denn hier liegen die Image-Daten; der Rest ist Leere und egal. Da 0x1fb00000 die gesamte verbleibende Länge des Speichers abbildete, hätte es genau reingepasst; wenn nicht die bösen Blöcke übersprungen worden wären. So ist das Schreiben dieser Länge nicht ganz vollständig; am Ende fehlt aber auch nichts Wichtiges. Eleganter wäre es vielleicht gewesen, nachzurechnen, um wieviel kürzer die zu schreibende Länge durch die elf bösen Blöcke werden müsste, aber ich hab Besseres zu tun.
+ Erklärung: Ich habe "nand write.e" genommen statt "nand write", weil ersteres schlechte Blöcke einfach überspringt, anstatt schockiert vor ihnen anzuhalten und abzubrechen. (In diesem konkreten Fall ist das Image zu klein, um beim Schreiben auf einen Bad Block zu stoßen, aber nur für den Fall ... lieber immer diesen Befehl benutzen.) Geschrieben wird das im Arbeitsspeicher an Adresse 0x800000 liegende auf den Bereich ab Adresse 0x500000, und zwar zur Länge 0x4580000. Wo kommt die her? Sie ist die Länge des Images in Bytes dargestellt im Hexadezimalsystem; im Dezimalsystem war's noch die Ziffernfolge 72876032. Fürs rasche Umrechnen zwischen beiden Darstellungsweisen gibt es sicher Millionen Dienstleister, zum Beispiel diese Webseite, die ich verwendet habe: http://www.statman.info/conversions/hexadecimal.html
2010-08-28 00:26:21 (rückgängig machen): (plomlompom):
257c257
- Das fertige "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder in den U-Boot-Bootloaderprompt vom SheevaPlug ...
+ Das fertige "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder in den U-Boot-Bootloader-Prompt vom SheevaPlug ...
265c265
-  '' 71434240   ubi.img''
+  '' 72876032   ubi.img''
271a272,277
+  ''reading ubi.img''
+  ''.........................''
+  ''.....................................................................''
+  ''.....................................................................''
+ (...)
+  ''72876032 bytes read''
273c279
- ... und dann den ganzen internen NAND-Speicher nach dem Kernel leer machen, damit das Image eine schöne Tabula rasa hat, um sich zu entfalten:
+ ... und dann den ganzen internen NAND-Speicher nach dem Kernel leer machen, tabula rasa über allem, was vorher da war an Dateisystemen, damit das Image Platz hat, sich frei zu entfalten:
2010-08-28 00:20:36 (rückgängig machen): (plomlompom):
162a163,173
+  ''I: Retrieving Release''
+  ''I: Retrieving Packages''
+  ''I: Validating Packages''
+  ''I: Resolving dependencies of required packages...''
+  ''I: Resolving dependencies of base packages...''
+  ''I: Found additional base dependencies: debian-archive-keyring dhcp3-client dhcp3-common gnupg gpgv libbz2-1.0 libreadline5 libusb-0.1-4 net-tools readline-common ''
+  ''I: Checking component main on http://ftp.us.debian.org/debian...''
+  ''I: Retrieving libacl1''
+  ''I: Validating libacl1''
+  ''I: Retrieving apt''
+ (...)
2010-08-28 00:16:22 (rückgängig machen): (plomlompom):
226c226
-  
+ 
238c238
-  
+ 
2010-08-28 00:14:18 (rückgängig machen): (plomlompom):
192c192
-  ''        main_lebs:    532''
+  ''        main_lebs:    543''
195,196c195,196
-  ''        leb_cnt:      543''
-  ''        UUID:         DE02F8ED-2032-4F63-AAB5-DE0DC9524908''
+  ''        leb_cnt:      554''
+  ''        UUID:         7C78CF08-339A-4570-84DE-DED2AAA0AD89''
2010-08-28 00:12:05 (rückgängig machen): (plomlompom):
162c162
-  # debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/
+  # debootstrap --foreign --arch=armel --variant=minbase --include=netbase,iproute,ifupdown,dhcp-client stable debian-stable/
164c164
- Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines '''minimalen''' Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System unkomprimiert ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Programm-Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einer zweiten Stufe später/dort vorgenommen werden wird.
+ Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines '''minimalen''' Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System unkomprimiert ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Programm-Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einer zweiten Stufe später/dort vorgenommen werden wird. Der Parameter "--include=netbase,iproute,ifupdown,dhcp-client" fügt der Minimal-Auswahl ein paar zusätzliche Pakete hinzu, die es mir im fertigen System erlauben werden, eine Internet-Verbindung herzustellen, so dass mit apt-get weitere Debian-Pakete reingeholt werden können.
2010-08-27 21:32:21 (rückgängig machen): (plomlompom):
431c431
-  I have no name!@(none):/# /debootstrap/debootstrap --second-stage
+  # /debootstrap/debootstrap --second-stage
2010-08-27 19:50:51 (rückgängig machen): (plomlompom):
151c151
- Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich vielleicht im übernächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung eventuell auch für vollen Boot-Erfolg noch notwendig sein könnte; alles im übernächsten Abschnitt näher erörtert. Um bis dahin zu gelangen, sollte es erstmal reichen, obige Zeilen zu setzen, selbst wenn der Kernel dann noch nicht zufriedenstellend bootet.
+ Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich vielleicht im übernächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung eventuell auch für vollen Boot-Erfolg noch notwendig sein könnte; alles im übernächsten Abschnitt näher erörtert. Um bis dahin zu gelangen, sollte es erstmal reichen, obige Zeilen zu setzen, selbst wenn der Kernel jetzt noch nicht zufriedenstellend bootet.
2010-08-27 19:50:27 (rückgängig machen): (plomlompom):
151c151
- Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich vielleicht im nächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung eventuell auch für vollen Boot-Erfolg noch notwendig sein könnte; alles im nächsten Abschnitt näher erörtert. Um in den einzusteigen, sollte es reichen, obige Zeilen zu setzen, selbst wenn der Kernel dann noch nicht zufriedenstellend booten sollte.
+ Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich vielleicht im übernächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung eventuell auch für vollen Boot-Erfolg noch notwendig sein könnte; alles im übernächsten Abschnitt näher erörtert. Um bis dahin zu gelangen, sollte es erstmal reichen, obige Zeilen zu setzen, selbst wenn der Kernel dann noch nicht zufriedenstellend bootet.
2010-08-27 16:48:00 (rückgängig machen): (plomlompom):
248c248
-  Marvell>> usb start''
+  Marvell>> usb start
2010-08-27 16:46:57 (rückgängig machen): (plomlompom):
244c244
- !! Ein minimales Debian installieren: Dateisystem-Image in den NAND-Speicher schreiben
+ !! Ein minimales Debian installieren, Schritt 2: Dateisystem-Image in den NAND-Speicher schreiben
2010-08-27 16:45:51 (rückgängig machen): (plomlompom):
242c242
- Heraus kommt eine Datei "ubi.img", die ich jetzt theoretisch so 1:1 in den NAND-Speicher schreiben können müsste.
+ Heraus kommt eine Datei "ubi.img", die ich jetzt theoretisch so 1:1 in den NAND-Speicher schreiben können müsste. Sie enthält die 100 MiB debian-stable/ auf unter 70 MiB runterkomrpimiert.
244c244
- !! Ein minimales Debian installieren: Rest
+ !! Ein minimales Debian installieren: Dateisystem-Image in den NAND-Speicher schreiben
246c246
- Das fertige (und auf unter 70 MiB runterkomprimierte) "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder in den U-Boot-Bootloaderprompt vom SheevaPlug ...
+ Das fertige "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder in den U-Boot-Bootloaderprompt vom SheevaPlug ...
2010-08-27 16:43:22 (rückgängig machen): (plomlompom):
164c164
- Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines '''minimalen''' Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Programm-Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einer zweiten Stufe später/dort vorgenommen werden wird.
+ Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines '''minimalen''' Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System unkomprimiert ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Programm-Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einer zweiten Stufe später/dort vorgenommen werden wird.
168c168
- Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend gibt es auch eigene dafür spezialisierte Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils" (MTD, Memory Technology Devices, ist ein Linux-Projekt, um die Flash-Speicher-Welt zu erschließen), das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien durchratterte, die offenbar aus meinem debian-stable/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
+ Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend erfordert er auch eigensinnige Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils" (MTD, Memory Technology Devices, ist ein Linux-Projekt, um die Flash-Speicher-Welt zu erschließen), das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien mit Fehlermeldungen durchratterte, die offenbar aus meinem debian-stable/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
170c170
- Mein zweiter Versuch galt UBIFS, das irgendwie das neuere und bessere und hippere JFFS2 sein soll. Gleichzeitig ist es aber auch irgendwie komplizierter; im Gegensatz zu JFFS2 handelt man sich damit nämlich nicht nur einfach ein "mkfs.ubifs" ein, sondern eine ganze Kette von Tools, die übereinandergestülpt werden müssen. Denn eigentlich ist UBIFS nur ein Aufsatz auf UBI (Unsorted Block Devices), einer Schichtung über dem rohen Flash-Speicher, die schonmal ein bisschen was von dem Bodendreck wegabstrahiert, und UBIFS ist dann erst die nächste Abstraktionsstufe. Man muss also irgendwie über den rohen Flash-Speicher ein UBI-Device layern, in diesem UBI-Device dann einzelne Volumes anlegen, und in diesen Volumes kann man dann ein UBIFS-Dateisystem laufen lassen. Puh! Nach viel Rumprobieren und Umwegen hab ich dann aber doch eine grobe Vereinfachung gefunden, die wie folgt aussieht: 
+ Mein zweiter Versuch galt UBIFS, das das neuere und bessere und hippere JFFS2 sein soll. Gleichzeitig ist es aber auch irgendwie komplizierter; im Gegensatz zu JFFS2 handelt man sich damit nämlich nicht nur einfach ein "mkfs.ubifs" ein, sondern eine ganze Kette von Tools, die übereinandergestülpt werden müssen. Denn eigentlich ist UBIFS nur ein Aufsatz auf UBI (Unsorted Block Devices), einer Schichtung über dem rohen Flash-Speicher, die schonmal ein bisschen was von dem Bodendreck wegabstrahiert, und UBIFS ist dann erst die nächste Abstraktionsstufe. Man muss über den rohen Flash-Speicher ein UBI-Device layern, in diesem UBI-Device dann einzelne Volumes anlegen, und in diesen Volumes kann man dann ein UBIFS-Dateisystem laufen lassen. Puh! Nach viel Rumprobieren und Umwegen hab ich dann aber doch eine grobe Vereinfachung gefunden, die wie folgt aussieht: 
172c172
- Zuerst lege ich würge ich das debootstrap/-Verzeichnis in das Image eines UBIFS-Dateisystems:
+ Zuerst würge ich das debian-stable/-Verzeichnis in das Image eines UBIFS-Dateisystems:
199c199
- Wie man an den ganzen seltsamen Parametern zum Befehl und an der beim Image-Erzeugen ausgepuckten Liste von Werten sieht, kann man nicht mal eben so ein UBIFS-Image erzeugen, sondern man muss diverse speichergeometrische Informationen belegen. Was die Parameter-Angaben im Einzelnen bedeuten, lässt sich durch "mkfs.ubifs --help" rausfinden; ich habe sie 1:1 von http://www.digriz.org.uk/kirkwood übernommen, der für ziemlich genau die gleiche Situation / das gleiche Gerät baute.
+ Wie man an den ganzen seltsamen Parametern zum Befehl und an der beim Image-Erzeugen ausgepuckten Liste von Werten sieht, kann man nicht mal eben so ein UBIFS-Image erzeugen, sondern muss diverse Größen beilegen, die der zu beschreibenden Speichergeometrie eigen sind. Was die Parameter-Angaben im Einzelnen bedeuten, lässt sich durch "mkfs.ubifs --help" rausfinden; ich habe sie 1:1 von http://www.digriz.org.uk/kirkwood übernommen, der für ziemlich genau die gleiche Situation / das gleiche Gerät baute.
201c201
- Die Erledigung des ganzen restlichen Überbaus nimmt mir das Programm "ubinize" ab, das ein Image erzeugen soll, das man einfach so ohne weiteres Rumbasteln in den rohen Flash-Speicher schreiben können soll, um ein von modernen Linux-Kernels bootbares Dateisystem zu bekommen. Nun wäre es natürlich zu einfach, wenn dafür einfach ein "ubinize" auf das Image möglich wäre; man muss auch hier die mehr oder weniger gleichen Parameter zur Speichergeometrie eingeben und außerdem auch noch eine Konfigurationsdatei anlegen, die das ganze UBI-Organisations-Zeugs zwischen Device und Volumes und Dateisystemen usw. beschreibt. Diese Datei "ubi.cfg" sah in meinem Fall so aus:
+ Die Erledigung des ganzen restlichen Überbaus lässt sich mit dem Programm "ubinize" abkürzen. Dieses soll ein Image erzeugen, das man einfach so ohne weiteres Rumbasteln in den rohen Flash-Speicher schreiben kann, um ein von modernen Linux-Kernels bootbares UBI/UBIFS-Dateisystem zu erhalten. Nun wäre es natürlich zu einfach, wenn dafür einfach ein "ubinize" auf das ubifs.img reichen würde; man muss auch hier die mehr oder weniger gleichen Parameter zur Speichergeometrie eingeben und außerdem auch noch eine Konfigurationsdatei anlegen, die das ganze UBI-Organisations-Zeugs zwischen Device und Volumes und Dateisystemen usw. beschreibt. Diese Datei "ubi.cfg" sah in meinem Fall so aus:
213c213
- Wie man vor allem an der etwas merkwürdigen Angabe "vol_size=160MiB" sieht, hab ich auch diese Zeilen irgendwo weggeklaut, ich weiß nur nicht mehr, woher. Wenn ich es richtig verstanden habe, ist die Angabe aufgrund des "vol_flags=autoresize" einigermaßen egal und sollte wohl nur ungefähr groß genug sein, damit das ubifs.img reinpasst; aber ich lasse mich gerne eines Besseren belehren. Das "vol_type=dynamic" besagt, dass das Dateisystem nicht nur lesbar (das wäre "static"), sondern auch beschreibbar sein soll.
+ Es wird also aus dem "image=ubifs.img" ein "[ubifs]"-Volume gebaut mit dem Namen "rootfs". Wie man vor allem an der etwas beliebigen Angabe "vol_size=160MiB" sieht, hab ich auch diese Zeilen irgendwo weggeklaut, ich weiß nur nicht mehr, woher. Wenn ich es richtig verstanden habe, ist diese Größen-Angabe aufgrund des "vol_flags=autoresize" einigermaßen egal und sollte wohl nur ungefähr groß genug sein, damit das ubifs.img reinpasst; aber ich lasse mich gerne eines Besseren belehren. Das "vol_type=dynamic" besagt, dass das Dateisystem nicht nur lesbar (das wäre "static"), sondern auch beschreibbar sein möge. Was genau "mode=ubi" entscheidet und ob es überhaupt notwendig ist, hab ich keine Ahnung :-)
240a241,242
+ 
+ Heraus kommt eine Datei "ubi.img", die ich jetzt theoretisch so 1:1 in den NAND-Speicher schreiben können müsste.
2010-08-27 15:24:54 (rückgängig machen): (plomlompom):
153c153
- !! Ein minimales Debian installieren: das Dateisystem-Image bauen
+ !! Ein minimales Debian installieren, Schritt 1: das Dateisystem-Image bauen
2010-08-27 15:24:29 (rückgängig machen): (plomlompom):
241a242,243
+ !! Ein minimales Debian installieren: Rest
+ 
2010-08-27 15:23:38 (rückgängig machen): (plomlompom):
153c153
- !! Ein minimales Debian installieren
+ !! Ein minimales Debian installieren: das Dateisystem-Image bauen
164c164
- Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines minimalen Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einem zweiten Schritt später/dort vorgenommen werden wird.
+ Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines '''minimalen''' Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Programm-Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einer zweiten Stufe später/dort vorgenommen werden wird.
166c166
- Jetzt habe ich einen Verzeichnisbaum vor mir liegen, aber wie krieg ich den auf den SheevaPlug? So mächtig der U-Boot-Bootloader auch ist, er kann nicht einfach einen solchen Verzeichnisbaum in seinen rohen Flash-Speicher schreiben. Ich muss das ganze Ding in ein Image verpacken, das direkt Byte für Byte in den Speicher geschrieben werden mag.
+ Jetzt habe ich, im Verzeichnis debian-stable/, einen Debian-Verzeichnisbaum vor mir liegen, aber wie krieg ich den auf den SheevaPlug? So mächtig der U-Boot-Bootloader auch ist, er kann nicht einfach einen solchen Verzeichnisbaum in seinen rohen Flash-Speicher schreiben. Ich muss das Ganze verpacken in das Byte für Byte in den Speicher zu schreibende Image eines Dateisystems, das mit den Eigenheiten des NAND-Flash-Speichers im SheevaPlug kompatibel ist.
2010-08-27 15:19:23 (rückgängig machen): (plomlompom):
63c63
- In meinem Versuch, mein eigenes Linux auf den SheevaPlug aufzuspielen, bin ich noch nicht sehr weit gekommen. Was ich aber immerhin schonmal geschafft habe, ist, von U-Boot aus einen beliebigen Kernel zu booten; für sich keine sehr brauchbare Übung, so lange der Kernel kein Dateisystem zum Reinbooten hat. Aber für diesen ersten Schritt hier schonmal ein paar Hinweise:
+ Als Nächstes habe ich ausprobiert, von U-Boot aus einen neuen Kernel zu booten. Wohlgemerkt, nur einen neuen Kernel; was danach an Dateisystem hätte liegen können, hatte ich zu dem Zeitpunkt schon bis ins Unlesbare korrumpiert, so dass der Kernel erstmal ins Nichts würde booten müssen.
65c65
- http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash gibt einige brauchbare Hinweise und Beispiele zum Schreiben eines Kernels in den NAND-Flash des SheevaPlugs, setzt aber die Verwendung des "Trivial File Transfer Protocol" voraus, mit dem mich vertraut zu machen (oder für das gar einen Server auf meinem Debian-Laptop einzurichten) ich zu faul bin. Stattdessen setze ich auf die bereits beim Updaten des U-Boot-Bootloaders bewährte Methode, im Bootloader Dateien über einen FAT-USB-Stick einzulesen (nähere Details siehe "U-Boot-Bootloader updaten").
+ http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash gibt einige brauchbare Hinweise und Beispiele zum Schreiben eines Kernels in den NAND-Flash des SheevaPlugs, setzt aber die Verwendung des "Trivial File Transfer Protocol" voraus, mit dem mich vertraut zu machen (oder für das gar einen Server auf meinem Debian-Laptop einzurichten?) ich zu faul bin. Stattdessen setze ich auf die bereits beim Updaten des U-Boot-Bootloaders bewährte Methode, im Bootloader Dateien über einen FAT-USB-Stick einzulesen (nähere Details siehe oben "U-Boot-Bootloader updaten").
67c67
- Ich ziehe also ein SheevaPlug-geeignetes Kernel-"uImage" auf meinen USB-Stick. Ein "uImage" ist in diesem Fall ein Linux-Kernel-Image, dem noch einige Zusatz-Daten rangepappt sind, die es u-Boot-freundlicher machen; "uboot-mkimage" wäre das Tool der Wahl, wenn man sich selber ein Linux-Kernel-Image solcherart u-Boot-kompatibel einpacken möchte. Ich nehme für den Anfang mal "sheeva-2.6.35.3-uImage", zu finden hier: http://sheeva.with-linux.com/sheeva/ Also rauf auf den USB-Stick damit und den USB-Stick in Sheevas Loch gestoßen! Danach, im U-Boot-Prompt, wird der USB-Stick initialisiert:
+ Ich ziehe also ein SheevaPlug-geeignetes Kernel-"uImage" auf meinen USB-Stick. Ein "uImage" ist in diesem Fall ein Linux-Kernel-Image, dem noch einige Zusatz-Daten rangepappt sind, die es U-Boot-freundlicher machen; "uboot-mkimage" wäre das Tool der Wahl, wenn man sich selber ein Linux-Kernel-Image solcherart u-Boot-kompatibel verpacken möchte. Ich nehme für den Anfang mal "sheeva-2.6.35.3-uImage", zu finden hier: http://sheeva.with-linux.com/sheeva/ Also rauf auf den USB-Stick damit und den USB-Stick in Sheevas Loch gestoßen! Danach, im U-Boot-Prompt, wird der USB-Stick initialisiert:
75c75
- (Warum zwei USB-Devices? Na weil ich gleichzeitig via USB-Kabel mit dem SheevaPlug verbunden bin, um via screen von meinem Debian-Laptop ein Terminal-Fenster hinein zu haben.) Schauen wir uns nun auf dem USB-Stick mal um:
+ (Warum zwei USB-Devices? Na weil ich gleichzeitig via USB-Kabel mit dem SheevaPlug verbunden bin, um via "screen" von meinem Debian-Laptop ein Terminal-Fenster hinein zu haben.) Schauen wir uns nun auf dem USB-Stick mal um:
93c93
- Ich habe das uImage jetzt in den Arbeitsspeicher an Adresse 0x2000000 eingelesen. (Die Adresse habe ich aus http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash übernommen.) Bevor ich jetzt U-Boot anweise, das an dieser Stelle gelegene Image zu booten, überprüfe ich nochmal, ob an der Adresse jetzt tatsächlich das liegt, was da liegen soll, und zwar mittels "iminfo":
+ Ich habe das uImage jetzt in den Arbeitsspeicher an Adresse 0x2000000 eingelesen. (Die Adresse habe ich aus http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash übernommen, k.A., was der Toleranzbereich für eine andere Position wäre.) Bevor ich jetzt U-Boot anweise, das an dieser Stelle gelegene Image zu booten, überprüfe ich nochmal, ob an der Adresse jetzt tatsächlich das liegt, was da liegen soll, und zwar mittels "iminfo":
108c108
- (Nachtrag: Alle Welt sagt, man solle bei Verwendung von etwas Anderem als dem mitgelieferten Kernel auch noch Folgendes setzen (ohne dass ich auch nur halbwegs verstehen würde, warum):
+ ('''Nachtrag''': Alle Welt sagt, man solle bei Verwendung von etwas Anderem als dem mitgelieferten Kernel auch noch Folgendes setzen (ohne dass ich auch nur halbwegs verstehen würde, warum):
113c113
- Das hab ich hier an der Stelle wohl aufzuführen vergessen, weil ich diese Umgebungsvariable bei früheren Versuchen schon gesetzt ''und gespeichert'' hatte, so dass ich sie nicht mehr neu setzen brauchte. Ob der Kernel auch ohne booten würde, bin ich jetzt auszuprobieren zu faul.)
+ Das hab ich hier an der Stelle wohl ursprünglich aufzuführen vergessen, weil ich diese Umgebungsvariable bei früheren Versuchen schon gesetzt ''und gespeichert'' hatte, so dass ich sie nicht mehr neu setzen brauchte. Ob der Kernel auch ohne booten würde, bin ich jetzt auszuprobieren zu faul.)
115c115
- Also booten wir mal! Das geht ganz einfach, indem ich das Programm "bootm" auf besagte Speicheradresse jage. "bootm" scheint nochmal "iminfo" aufzurufen und schiebt danach den Kernel-Code durch den Prozessor:
+ Also booten wir mal! Das geht ganz einfach, indem ich das Programm "bootm" auf besagte Arbeitsspeicheradresse jage. "bootm" scheint nochmal "iminfo" aufzurufen und schiebt danach den Kernel-Code durch den Prozessor:
151c151
- Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich irgendwann im nächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung vielleicht auch noch notwendig sein könnte; alles im nächsten Abschnitt näher erörtert. Um in den einzusteigen, sollte es reichen, obige Zeilen zu setzen, selbst wenn der Kernel dann noch nicht booten sollte.
+ Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich vielleicht im nächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung eventuell auch für vollen Boot-Erfolg noch notwendig sein könnte; alles im nächsten Abschnitt näher erörtert. Um in den einzusteigen, sollte es reichen, obige Zeilen zu setzen, selbst wenn der Kernel dann noch nicht zufriedenstellend booten sollte.
2010-08-27 15:12:56 (rückgängig machen): (plomlompom):
37c37
- Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Geringfügige Abweichungen meinerseits, allein durch Fehleranfälligkeit meinerseits, erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis rekonstruiert, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
+ Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Meine geringfügigen Abweichungen, allein durch Fehleranfälligkeit meinerseits, erfordern aber dennoch nochmal einen Nachvollzug (aus dem Gedächtnis rekonstruiert, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
39c39
- Ich brauchte erstmal ein Binary für den neuen Bootloader. Ich wähnte mich zuerst besonders schlau und dachte mir, ich fände ein aktuelleres als das von Michlmayer verlinkte "U-Boot 3.4.27+pingtoo binary", aber das, was ich nach endlosem Umhersuchen in den PlugComputer-Foren stolz mein eigen nannte, stellte sich im Nachhinein als eben das gleiche heraus. Der nächste Fehler, den ich machte, war, es im versuchten Befolgen von Michlmayers Anweisungen in Unachtsamkeit in "u-boot.bin" statt "uboot.bin" zu benennen, was später einige Verwirrung beim buchstabengetreuen Kopieren von Befehlen stiften würde; also nicht nochmal diesen meinen Fehler machen!
+ Ich brauchte erstmal ein Binary für den neuen Bootloader. Ich wähnte mich zuerst besonders schlau und dachte mir, ich fände ein aktuelleres als das von Michlmayer verlinkte "U-Boot 3.4.27+pingtoo binary"; aber das, was ich nach endlosem Umhersuchen in den PlugComputer-Foren stolz mein eigen nannte, stellte sich im Nachhinein als eben dasselbe heraus. Der nächste Fehler, den ich machte, war, es im versuchten Befolgen von Michlmayers Anweisungen in Unachtsamkeit in "u-boot.bin" statt "uboot.bin" zu benennen, was später einige Verwirrung beim buchstabengetreuen Kopieren von Befehlen stiften würde; das hab ich in diesem Nachvollzug aber bereits auskorrigiert.
41c41
- Ich entschied mich unter den beiden von Michlmayer angebotenen Methoden für Installation via USB-Stick. Ein FAT-formatierter USB-Stick wurde verwandt, und ich glaubte mich in Besitz eines eben solchen, kopierte "uboot.bin" (gehen wir einfach mal davon aus, ich hätte es von Anfang an richtig benannt) drauf, rammte den USB-Stick danach in Sheevas Ritze und gab im U-Boot-Prompt korrekt Folgendes ein:
+ Ich entschied mich unter den beiden von Michlmayer angebotenen Methoden für Installation via USB-Stick. Ein FAT-formatierter USB-Stick wurde verwandt, und ich glaubte mich in Besitz eines eben solchen, kopierte "uboot.bin" drauf, rammte den USB-Stick danach in Sheevas Ritze und gab im U-Boot-Prompt korrekt Folgendes ein:
46c46
- Die erste Zeile zeitigte den gewünschten Erfolg, der USB-Stick wurde erkannt. Die zweite Zeile -- grob lesbar als "fatload (lade von einem FAT-Dateisystem ...) usb 0:1 (... am USB-Interface soundso ...) 0x0800000 (... auf Arbeitsspeicheradresse soundso ...) uboot.bin (... diese Datei)" -- jedoch spuckte irgendeine Fehlermeldung aus. Nach viel Umhergooglen schälte sich der Verdacht heraus, das könnte an der FAT-Partition auf dem USB-Stick liegen. Offenbar hat U-Boot da irgendwelche Probleme mit den Partitionen, wie sie zumindest mein Debian bastelt, wenn ich "cfdisk" und "mkfs.vfat" anwende. 
+ Die erste Zeile zeitigte den gewünschten Erfolg, der USB-Stick wurde erkannt. Die zweite Zeile -- grob lesbar als "fatload (lade von einem FAT-Dateisystem ...) usb 0:1 (... am USB-Interface soundso ...) 0x0800000 (... auf Arbeitsspeicheradresse soundso ...) uboot.bin (... diese Datei)" -- jedoch spuckte beim ersten Durchgang irgendeine Fehlermeldung aus. Nach viel Umhergooglen schälte sich der Verdacht heraus, das könnte an der FAT-Partition auf dem USB-Stick liegen. Offenbar hat U-Boot Probleme mit den Partitionen, wie sie zumindest mein Debian bastelt, wenn ich "cfdisk" und "mkfs.vfat" anwende. 
48c48
- Aus irgendwelchen Gründen lies sich das Problem durch Verkleinerung der Partition und Verwendung von FAT16 lösen; mehr als ein paar MB musste die Partition ja nicht groß sein, um einzelne Dateien wie die uboot.bin zu transportieren. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x0800000 im Arbeitsspiecher geschrieben.
+ Aus irgendwelchen Gründen lies sich das Problem durch erhebliche Verkleinerung der Partition auf dem USB-Stick und Verwendung von FAT16 anstatt einer neueren FAT-Version lösen; für auch alle weiteren Datei-Transfers in den kommenden Abschnitten reicht locker eine Partition von zweihundert Megabyte Größe. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x0800000 im Arbeitsspiecher geschrieben.
50c50
- Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs überschreibt. Hier muss wohl der Bootloader liegen. Insofern kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
+ Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs überschreibt. Hier muss der Bootloader liegen. Insofern kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
55c55
- Nehmen wir das mal auseinander: "nand erase (lösche den Bereich ...) 0x0 (... der hier startet ...) 0xa0000 ( ...mit dieser Länge)"; "nand write (Bereich beschreiben: ...) 0x0800000 (... das, was an dieser Arbeitsspeicheradresse liegt, soll ...) 0x0 (... beginnend dieser Stelle in den NAND-Speicher geschrieben werden, und zwar ...) 0xa0000 (... zu dieser Länge)". Danach dann ...
+ Ich nehme das mal auseinander: "nand erase (lösche den Bereich ...) 0x0 (... der hier startet ...) 0xa0000 ( ...mit dieser Länge)"; "nand write (Bereich beschreiben: ...) 0x0800000 (... das, was an dieser Arbeitsspeicheradresse liegt, soll ...) 0x0 (... beginnend dieser Stelle in den NAND-Speicher geschrieben werden, und zwar ...) 0xa0000 (... zu dieser Länge)". Danach dann ...
2010-08-27 15:05:50 (rückgängig machen): (plomlompom):
5c5
- So ein SheevaPlug ist ja erstmal ein weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Buchstaben-Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen könnte und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
+ So ein SheevaPlug ist ja erstmal ein weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Buchstaben-Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
2010-08-27 15:05:34 (rückgängig machen): (plomlompom):
5c5
- So ein SheevaPlug ist ja erstmal ein weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen könnte und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
+ So ein SheevaPlug ist ja erstmal ein weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Buchstaben-Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen könnte und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
2010-08-27 15:05:13 (rückgängig machen): (plomlompom):
5c5
- So ein SheevaPlug ist ja erstmal ein kleiner weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen könnte und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
+ So ein SheevaPlug ist ja erstmal ein weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen könnte und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
2010-08-27 15:04:57 (rückgängig machen): (plomlompom):
3c3
- !! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
+ !! Serielle Verbindung zu meinem SheevaPlug
5c5
- Mein SheevaPlug hat ja kein eigenes Ausgabegerät außer einem LED. Um mit ihm sinnvoll zu kommunizieren muss ich es mit einem Gerät verbinden, das eine Ausgabe wie zum Beispiel einen Bildschirm und am Besten auch noch eine Eingabe wie eine Tastatur besitzt. Am einfachsten hierfür ist die "serielle" Verbindung.
+ So ein SheevaPlug ist ja erstmal ein kleiner weißer Kasten, der nur über das Blinken zweier kleine Lämpchen sichtbar mit der Außenwelt kommuniziert. Diese Bandbreite würde für manchen Morse-Code-Oldtimer vielleicht reichen, ich hätte aber gerne den Luxus einer Schnittstelle, die es mir erlaubt, direkt im Textformat mit ihm zu kommunizieren. Zum Beispiel wäre es doch nett, wenn ich ihn mit einem Kabel an meinen Laptop anschließen könnte und dann im Laptop ein Terminal-Fenster in ihn hinein öffnen könnte. Der Weg hierzu ist die "serielle" Verbindung.
7c7
- Ich verbinde mein Laptop-Debian-Linux via USB-Kabel mit dem SheevaPlug. Meines Laptop-Debians Kernel erkennt diese neue Verbindung und leitet sie auf ein Device, das er "ttyUSB0" nennt (Hervorhebungen von mir):
+ Ich verbinde meinen Laptop (auf dem ein Debian GNU/Linux läuft) via USB-Kabel mit dem SheevaPlug. Meines Laptop-Debians Kernel erkennt diese neue Verbindung und leitet sie intern auf etwas weiter, das er "ttyUSB0" nennt:
9c9
-  $ dmesg                        # Log der Kernel-Nachrichten ausgeben
+  $ dmesg                        # Log der letzten Kernel-Nachrichten ausgeben
27c27
- Auf dieses Device kann ich im Dateisystem über ''/dev/ttyUSB0'' zugreifen. Ich setze das Programm "screen" darauf an:
+ Auf dieses "ttyUSB0" kann ich im Dateisystem meines Debians zugreifen: es liegt unter /dev/ttyUSB0. Ich setze das Programm "screen" darauf an:
29,30c29
-  $ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit,
-  die per default beim Bootloader U-Boot eingestellt ist
+  $ screen /dev/ttyUSB0 115200   # "115200" ist die erwartbare Baudrate der Verbindung
32c31,33
- Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein-zwei mal Enter drücken. Dann aber sollte ich mittels "screen" einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet. Achtung: das USB-Kabel rutscht sehr leicht aus dem SheevaPlug raus, wenn's nicht funktioniert also besser mal nachgucken, ob's richtig drinne steckt.
+ Aus irgendwelchen Gründen erzeugt "screen" nicht sofort eine zufriedenstellende Anzeige: Ich muss ein-zwei mal Enter drücken. Dann aber sollte sich meine Konsole dank "screen" in einen Terminal zu dem verwandeln, was der SheevaPlug an seiner seriellen Schnittstelle bereithält. Der Bootloader des SheevaPlug etwa, "U-Boot", wird mit der Voreinstellung ausgeliefert, eine serielle Schnittstelle auf sich offenzuhalten und mit einer Baudrate von 115200 zu beliefern (daher kommt die Zahl im obigen Befehl). 
+ 
+ Achtung: das USB-Kabel rutscht sehr leicht aus dem SheevaPlug raus. Wenn's nicht funktioniert also besser mal nachgucken, ob's richtig drinne steckt.
2010-08-27 14:52:25 (rückgängig machen): (plomlompom):
436c436
- Aber halt! Ein zwei kleine Sachen gilt es noch anzupassen, um weiter Freude an der Installation zu haben. Zuerst teile ich dem System mit, dass init beim Initialisieren ein TTY an der seriellen Schnittstelle aufmachen soll, mit der Baudrate 115200. Genau für sowas ist die inittab da:
+ Aber halt! Eine kleine Sachen muss jetzt noch angepasst werden, um weiter Freude an der Installation zu haben. Ich teile dem System mit, dass init beim Initialisieren ein TTY an der seriellen Schnittstelle aufmachen soll, mit der Baudrate 115200. Genau für sowas ist die inittab da:
439a440,474
+ 
+ In der ersten Zeile weiße ich an, dass für die "runlevel" / Boot-Stufen 2,3,4,5 das Programm /sbin/getty ein TTY am Device ttyS0 mit der erwünschten Baudrate eröffnen soll. Das Device ttyS0 allerdings existiert gar nicht ohne Weiteres; ich muss es erst anlegen. Das mache ich in der zweiten Zeile.
+ 
+ Nun wieder von vorne, in den Boot-Loader. Dort nehme ich das "init=/bin/bash" wieder aus der "bootargs"-Umgebungsvariable raus:
+ 
+  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
+  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
+  tfs rootfstype=ubifs
+  Marvell>> saveenv
+ 
+ Dann wird nochmal neu gebootet, und siehe da:
+ 
+  ''INIT: version 2.86 booting''
+ (...)
+  ''INIT: Entering runlevel: 2''
+  
+  ''Debian GNU/Linux 5.0 plom-pad ttyS0''
+  
+  plom-pad login:
+ 
+ Init scheint alles vorzufinden, was es sucht, und ist außerdem so nett, mir einen Login-Prompt an den ttyS0 zu legen.
+ 
+  plom-pad login: root
+ 
+  ''Linux plom-pad 2.6.35.3 #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010 armv5tel''
+  
+  ''The programs included with the Debian GNU/Linux system are free software;''
+  ''the exact distribution terms for each program are described in the''
+  ''individual files in /usr/share/doc/*/copyright.''
+  
+  ''Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent''
+  ''permitted by applicable law.''
+  plom-pad:~# 
+ 
+ Wunderbar! Ich kann mich als "root" einloggen. Da ich noch kein Passwort gesetzt habe, geht das sogar ohne Passwortabfrage. Evtl. nicht der sicherste dauerhafte Zustand.
2010-08-27 14:42:05 (rückgängig machen): (plomlompom):
9c9
-  ''$ dmesg                        # Log der Kernel-Nachrichten ausgeben''
+  $ dmesg                        # Log der Kernel-Nachrichten ausgeben
11,25c11,25
-  [237247.840070] usb 5-1: '''new full speed USB device''' using uhci_hcd and address 40
-  [237248.051109] usb 5-1: New USB device found, idVendor=9e88, idProduct=9e8f
-  [237248.051118] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
-  [237248.051124] usb 5-1: Product: '''SheevaPlug''' JTAGKey FT2232D B
-  [237248.051129] usb 5-1: Manufacturer: FTDI
-  [237248.051134] usb 5-1: SerialNumber: FTSJA9Q3
-  [237248.051332] usb 5-1: configuration #1 chosen from 1 choice
-  [237248.060243] usb 5-1: Ignoring serial port reserved for JTAG
-  [237248.065218] ftdi_sio 5-1:1.1: FTDI USB Serial Device converter detected
-  [237248.065270] usb 5-1: Detected FT2232C
-  [237248.065275] usb 5-1: Number of endpoints 2
-  [237248.065280] usb 5-1: Endpoint 1 MaxPacketSize 64
-  [237248.065285] usb 5-1: Endpoint 2 MaxPacketSize 64
-  [237248.065289] usb 5-1: Setting MaxPacketSize 64
-  [237248.066200] usb 5-1: FTDI USB Serial Device converter '''now attached to ttyUSB0'''
+  ''[237247.840070] usb 5-1: '''new full speed USB device''' using uhci_hcd and address 40''
+  ''[237248.051109] usb 5-1: New USB device found, idVendor=9e88, idProduct=9e8f''
+  ''[237248.051118] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3''
+  ''[237248.051124] usb 5-1: Product: '''SheevaPlug''' JTAGKey FT2232D B''
+  ''[237248.051129] usb 5-1: Manufacturer: FTDI''
+  ''[237248.051134] usb 5-1: SerialNumber: FTSJA9Q3''
+  ''[237248.051332] usb 5-1: configuration #1 chosen from 1 choice''
+  ''[237248.060243] usb 5-1: Ignoring serial port reserved for JTAG''
+  ''[237248.065218] ftdi_sio 5-1:1.1: FTDI USB Serial Device converter detected''
+  ''[237248.065270] usb 5-1: Detected FT2232C''
+  ''[237248.065275] usb 5-1: Number of endpoints 2''
+  ''[237248.065280] usb 5-1: Endpoint 1 MaxPacketSize 64''
+  ''[237248.065285] usb 5-1: Endpoint 2 MaxPacketSize 64''
+  ''[237248.065289] usb 5-1: Setting MaxPacketSize 64''
+  ''[237248.066200] usb 5-1: FTDI USB Serial Device converter '''now attached to ttyUSB0'''''
29,30c29,30
-  ''$ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit,''
-  ''die per default beim Bootloader U-Boot eingestellt ist''
+  $ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit,
+  die per default beim Bootloader U-Boot eingestellt ist
42,43c42,43
-  ''Marvell>> usb start''
-  ''Marvell>> fatload usb 0:1 0x0800000 uboot.bin''
+  Marvell>> usb start
+  Marvell>> fatload usb 0:1 0x0800000 uboot.bin
51,52c51,52
-  ''Marvell>> nand erase 0x0 0xa0000''
-  ''Marvell>> nand write 0x0800000 0x0 0xa0000''
+  Marvell>> nand erase 0x0 0xa0000
+  Marvell>> nand write 0x0800000 0x0 0xa0000
56c56
-  ''Marvell>> reset''
+  Marvell>> reset
68,72c68,72
-  ''Marvell>> usb start''
-  (Re)start USB...
-  USB:   scanning bus for devices... 2 USB Device(s) found
-  Waiting for storage device(s) to settle before scanning...
-  1 Storage Device(s) found
+  Marvell>> usb start
+  ''(Re)start USB...''
+  ''USB:   scanning bus for devices... 2 USB Device(s) found''
+  ''Waiting for storage device(s) to settle before scanning...''
+  ''1 Storage Device(s) found''
76,77c76,77
-  ''Marvell>> fatls usb 0:1 /''
-    2795912   sheeva-2.6.35.3-uimage 
+  Marvell>> fatls usb 0:1 /
+  ''  2795912   sheeva-2.6.35.3-uimage''
79c79
-  1 file(s), 0 dir(s)
+  ''1 file(s), 0 dir(s)''
83,90c83,90
-  ''Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage''
-  reading sheeva-2.6.35.3-uimage
-  .....................................................................
-  .....................................................................
-  .....................................................................
-  ..................................................................
- 
-  2795912 bytes read
+  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
+  ''reading sheeva-2.6.35.3-uimage''
+  ''.....................................................................''
+  ''.....................................................................''
+  ''.....................................................................''
+  ''..................................................................''
+  
+  ''2795912 bytes read''
94c94
-  ''Marvell>> iminfo 0x2000000''
+  Marvell>> iminfo 0x2000000
96,103c96,103
-  ## Checking Image at 02000000 ...
-     Image Name:   Linux-2.6.35.3
-     Created:      2010-08-21   0:22:34 UTC
-     Image Type:   ARM Linux Kernel Image (uncompressed)
-     Data Size:    2795848 Bytes =  2.7 MB
-     Load Address: 00008000
-     Entry Point:  00008000
-     Verifying Checksum ... OK
+  ''## Checking Image at 02000000 ...''
+  ''   Image Name:   Linux-2.6.35.3''
+  ''   Created:      2010-08-21   0:22:34 UTC''
+  ''   Image Type:   ARM Linux Kernel Image (uncompressed)''
+  ''   Data Size:    2795848 Bytes =  2.7 MB''
+  ''   Load Address: 00008000''
+  ''   Entry Point:  00008000''
+  ''   Verifying Checksum ... OK''
109,110c109,110
-  ''Marvell>> setenv mainlineLinux yes''
-  ''Marvell>> setenv arcNumber 2097''
+  Marvell>> setenv mainlineLinux yes
+  Marvell>> setenv arcNumber 2097
116,125c116,125
-  ''Marvell>> bootm 0x2000000''
-  ## Booting image at 02000000 ...
-     Image Name:   Linux-2.6.35.3
-     Created:      2010-08-21   0:22:34 UTC
-     Image Type:   ARM Linux Kernel Image (uncompressed)
-     Data Size:    2795848 Bytes =  2.7 MB
-     Load Address: 00008000
-     Entry Point:  00008000
-     Verifying Checksum ... OK
-  OK
+  Marvell>> bootm 0x2000000
+  ''## Booting image at 02000000 ...''
+  ''   Image Name:   Linux-2.6.35.3''
+  ''   Created:      2010-08-21   0:22:34 UTC''
+  ''   Image Type:   ARM Linux Kernel Image (uncompressed)''
+  ''   Data Size:    2795848 Bytes =  2.7 MB''
+  ''   Load Address: 00008000''
+  ''   Entry Point:  00008000''
+  ''   Verifying Checksum ... OK''
+  ''OK''
127c127
-  Starting kernel ...
+  ''Starting kernel ...''
129,130c129,130
-  Uncompressing Linux... done, booting the kernel.
-  Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010
+  ''Uncompressing Linux... done, booting the kernel.''
+  ''Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010''
135,136c135,136
-  No filesystem could mount root, tried:  ext3 ext2 ext4 cramfs vfat msdos jfs
-  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)
+  ''No filesystem could mount root, tried:  ext3 ext2 ext4 cramfs vfat msdos jfs''
+  ''Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)''
142,148c142,148
-  ''Marvell>> usb start''
-  ''Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage''
-  ''Marvell>> nand erase 0x100000 0x400000''
-  ''Marvell>> nand write 0x2000000 0x100000 0x400000''
-  ''Marvell>> setenv mainlineLinux yes''
-  ''Marvell>> setenv arcNumber 2097''
-  ''Marvell>> saveenv''
+  Marvell>> usb start
+  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
+  Marvell>> nand erase 0x100000 0x400000
+  Marvell>> nand write 0x2000000 0x100000 0x400000
+  Marvell>> setenv mainlineLinux yes
+  Marvell>> setenv arcNumber 2097
+  Marvell>> saveenv
161c161
-  ''# debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/''
+  # debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/
173,196c173,196
-  ''# mkfs.ubifs -v -r debian-stable/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img''
-  mkfs.ubifs
-          root:         debian-stable/
-          min_io_size:  2048
-          leb_size:     129024
-          max_leb_cnt:  4096
-          output:       ubifs.img
-          jrn_size:     8388608
-          reserved:     0
-          compr:        zlib
-          keyhash:      r5
-          fanout:       8
-          orph_lebs:    1
-          super lebs:   1
-          master lebs:  2
-          log_lebs:     5
-          lpt_lebs:     2
-          orph_lebs:    1
-          main_lebs:    532
-          gc lebs:      1
-          index lebs:   9
-          leb_cnt:      543
-          UUID:         DE02F8ED-2032-4F63-AAB5-DE0DC9524908
-  Success!
+  # mkfs.ubifs -v -r debian-stable/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img
+  ''mkfs.ubifs''
+  ''        root:         debian-stable/''
+  ''        min_io_size:  2048''
+  ''        leb_size:     129024''
+  ''        max_leb_cnt:  4096''
+  ''        output:       ubifs.img''
+  ''        jrn_size:     8388608''
+  ''        reserved:     0''
+  ''        compr:        zlib''
+  ''        keyhash:      r5''
+  ''        fanout:       8''
+  ''        orph_lebs:    1''
+  ''        super lebs:   1''
+  ''        master lebs:  2''
+  ''        log_lebs:     5''
+  ''        lpt_lebs:     2''
+  ''        orph_lebs:    1''
+  ''        main_lebs:    532''
+  ''        gc lebs:      1''
+  ''        index lebs:   9''
+  ''        leb_cnt:      543''
+  ''        UUID:         DE02F8ED-2032-4F63-AAB5-DE0DC9524908''
+  ''Success!''
202,210c202,210
-  ''$ cat ubi.cfg''
-  [ubifs]
-  mode=ubi
-  image=ubifs.img
-  vol_id=0
-  vol_size=160MiB
-  vol_type=dynamic
-  vol_name=rootfs
-  vol_flags=autoresize
+  $ cat ubi.cfg
+  ''[ubifs]''
+  ''mode=ubi''
+  ''image=ubifs.img''
+  ''vol_id=0''
+  ''vol_size=160MiB''
+  ''vol_type=dynamic''
+  ''vol_name=rootfs''
+  ''vol_flags=autoresize''
2010-08-27 14:37:52 (rückgängig machen): (plomlompom):
216,224c216,224
-  ''# ubinize -v -m 2048 -p 128KiB -s 512 ubi.cfg -o ubi.img''
-  ubinize: LEB size:      129024
-  ubinize: PEB size:      131072
-  ubinize: min. I/O size: 2048
-  ubinize: sub-page size: 512
-  ubinize: VID offset:    512
-  ubinize: data offset:   2048
-  ubinize: loaded the ini-file "ubi.cfg"
-  ubinize: count of sections: 1
+  # ubinize -v -m 2048 -p 128KiB -s 512 ubi.cfg -o ubi.img
+  ''ubinize: LEB size:      129024''
+  ''ubinize: PEB size:      131072''
+  ''ubinize: min. I/O size: 2048''
+  ''ubinize: sub-page size: 512''
+  ''ubinize: VID offset:    512''
+  ''ubinize: data offset:   2048''
+  ''ubinize: loaded the ini-file "ubi.cfg"''
+  ''ubinize: count of sections: 1''
226,236c226,236
-  ubinize: parsing section "ubifs"
-  ubinize: mode=ubi, keep parsing
-  ubinize: volume type: dynamic
-  ubinize: volume ID: 0
-  ubinize: volume size: 167772160 bytes
-  ubinize: volume name: rootfs
-  ubinize: volume alignment: 1
-  ubinize: autoresize flags found
-  ubinize: adding volume 0
-  ubinize: writing volume 0
-  ubinize: image file: ubifs.img
+  ''ubinize: parsing section "ubifs"''
+  ''ubinize: mode=ubi, keep parsing''
+  ''ubinize: volume type: dynamic''
+  ''ubinize: volume ID: 0''
+  ''ubinize: volume size: 167772160 bytes''
+  ''ubinize: volume name: rootfs''
+  ''ubinize: volume alignment: 1''
+  ''ubinize: autoresize flags found''
+  ''ubinize: adding volume 0''
+  ''ubinize: writing volume 0''
+  ''ubinize: image file: ubifs.img''
238,239c238,239
-  ubinize: writing layout volume
-  ubinize: done
+  ''ubinize: writing layout volume''
+  ''ubinize: done''
243,249c243,249
-  ''Marvell>> usb start''
-  (Re)start USB...
-  USB:   scanning bus for devices... 2 USB Device(s) found
-  Waiting for storage device(s) to settle before scanning...
-  1 Storage Device(s) found
-  Marvell>> fatls usb 0:1 /
-   71434240   ubi.img 
+  Marvell>> usb start''
+  ''(Re)start USB...''
+  ''USB:   scanning bus for devices... 2 USB Device(s) found''
+  ''Waiting for storage device(s) to settle before scanning...''
+  ''1 Storage Device(s) found''
+  ''Marvell>> fatls usb 0:1 /''
+  '' 71434240   ubi.img''
251c251
-  1 file(s), 0 dir(s)
+  ''1 file(s), 0 dir(s)''
255c255
-  ''Marvell>> fatload usb 0:1 0x800000 ubi.img''
+  Marvell>> fatload usb 0:1 0x800000 ubi.img
259c259
-  ''Marvell>> nand erase 0x500000 0x1fb00000''
+  Marvell>> nand erase 0x500000 0x1fb00000
261,274c261,274
-  NAND erase: device 0 offset 0x500000, size 0x1fb00000
-  Skipping bad block at  0x09660000                                            
-  Skipping bad block at  0x09760000                                            
-  Skipping bad block at  0x0fba0000                                            
-  Skipping bad block at  0x110c0000                                            
-  Skipping bad block at  0x12420000                                            
-  Skipping bad block at  0x126e0000                                            
-  Skipping bad block at  0x16920000                                            
-  Skipping bad block at  0x1a1c0000                                            
-  Skipping bad block at  0x1aca0000                                            
-  Skipping bad block at  0x1bdc0000                                            
-  Skipping bad block at  0x1c900000                                            
-  Erasing at 0x1ffe0000 -- 100%25 complete.
-  OK
+  ''NAND erase: device 0 offset 0x500000, size 0x1fb00000''
+  ''Skipping bad block at  0x09660000''                                          
+  ''Skipping bad block at  0x09760000''                                          
+  ''Skipping bad block at  0x0fba0000''                                          
+  ''Skipping bad block at  0x110c0000''                                          
+  ''Skipping bad block at  0x12420000''                                          
+  ''Skipping bad block at  0x126e0000''                                          
+  ''Skipping bad block at  0x16920000''                                          
+  ''Skipping bad block at  0x1a1c0000''                                          
+  ''Skipping bad block at  0x1aca0000''                                          
+  ''Skipping bad block at  0x1bdc0000''                                          
+  ''Skipping bad block at  0x1c900000''                                    
+  ''Erasing at 0x1ffe0000 -- 100%25 complete.''
+  ''OK''
2010-08-27 14:35:43 (rückgängig machen): (plomlompom):
278c278
-  ''Marvell>> nand write.e 0x800000 0x500000 0x1fb00000''
+  Marvell>> nand write.e 0x800000 0x500000 0x1fb00000
280c280
-  NAND write: device 0 offset 0x500000, size 0x1fb00000
+  ''NAND write: device 0 offset 0x500000, size 0x1fb00000''
282,295c282,295
-  Bad block at 0x9660000 in erase block from 0x9660000 will be skipped
-  Bad block at 0x9760000 in erase block from 0x9760000 will be skipped
-  Bad block at 0xfba0000 in erase block from 0xfba0000 will be skipped
-  Bad block at 0x110c0000 in erase block from 0x110c0000 will be skipped
-  Bad block at 0x12420000 in erase block from 0x12420000 will be skipped
-  Bad block at 0x126e0000 in erase block from 0x126e0000 will be skipped
-  Bad block at 0x16920000 in erase block from 0x16920000 will be skipped
-  Bad block at 0x1a1c0000 in erase block from 0x1a1c0000 will be skipped
-  Bad block at 0x1aca0000 in erase block from 0x1aca0000 will be skipped
-  Bad block at 0x1bdc0000 in erase block from 0x1bdc0000 will be skipped
-  Bad block at 0x1c900000 in erase block from 0x1c900000 will be skipped
-  Writing data at 0x1fc4e000 --  99%25 complete.
-  Data did not fit into device, due to bad blocks
-   531628032 bytes written: ERROR
+  ''Bad block at 0x9660000 in erase block from 0x9660000 will be skipped''
+  ''Bad block at 0x9760000 in erase block from 0x9760000 will be skipped''
+  ''Bad block at 0xfba0000 in erase block from 0xfba0000 will be skipped''
+  ''Bad block at 0x110c0000 in erase block from 0x110c0000 will be skipped''
+  ''Bad block at 0x12420000 in erase block from 0x12420000 will be skipped''
+  ''Bad block at 0x126e0000 in erase block from 0x126e0000 will be skipped''
+  ''Bad block at 0x16920000 in erase block from 0x16920000 will be skipped''
+  ''Bad block at 0x1a1c0000 in erase block from 0x1a1c0000 will be skipped''
+  ''Bad block at 0x1aca0000 in erase block from 0x1aca0000 will be skipped''
+  ''Bad block at 0x1bdc0000 in erase block from 0x1bdc0000 will be skipped''
+  ''Bad block at 0x1c900000 in erase block from 0x1c900000 will be skipped''
+  ''Writing data at 0x1fc4e000 --  99%25 complete.''
+  ''Data did not fit into device, due to bad blocks''
+  '' 531628032 bytes written: ERROR''
301,306c301,306
-  ''Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000''
-  ''(u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo''
-  ''tfs rootfstype=ubifs''
-  ''Marvell>> saveenv''
-  Saving Environment to NAND...
-  Erasing Nand...Writing to Nand... done
+  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
+  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
+  tfs rootfstype=ubifs
+  Marvell>> saveenv
+  ''Saving Environment to NAND...''
+  ''Erasing Nand...Writing to Nand... done''
316c316
-  Starting kernel ...
+  ''Starting kernel ...''
318,319c318,319
-  Uncompressing Linux... done, booting the kernel.
-  Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010
+  ''Uncompressing Linux... done, booting the kernel.''
+  ''Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010''
323,335c323,335
-  NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
-  Scanning device for bad blocks
-  Bad eraseblock 1203 at 0x000009660000
-  Bad eraseblock 1211 at 0x000009760000
-  Bad eraseblock 2013 at 0x00000fba0000
-  Bad eraseblock 2182 at 0x0000110c0000
-  Bad eraseblock 2337 at 0x000012420000
-  Bad eraseblock 2359 at 0x0000126e0000
-  Bad eraseblock 2889 at 0x000016920000
-  Bad eraseblock 3342 at 0x00001a1c0000
-  Bad eraseblock 3429 at 0x00001aca0000
-  Bad eraseblock 3566 at 0x00001bdc0000
-  Bad eraseblock 3656 at 0x00001c900000
+  ''NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)''
+  ''Scanning device for bad blocks''
+  ''Bad eraseblock 1203 at 0x000009660000''
+  ''Bad eraseblock 1211 at 0x000009760000''
+  ''Bad eraseblock 2013 at 0x00000fba0000''
+  ''Bad eraseblock 2182 at 0x0000110c0000''
+  ''Bad eraseblock 2337 at 0x000012420000''
+  ''Bad eraseblock 2359 at 0x0000126e0000''
+  ''Bad eraseblock 2889 at 0x000016920000''
+  ''Bad eraseblock 3342 at 0x00001a1c0000''
+  ''Bad eraseblock 3429 at 0x00001aca0000''
+  ''Bad eraseblock 3566 at 0x00001bdc0000''
+  ''Bad eraseblock 3656 at 0x00001c900000''
339,342c339,342
-  Creating 3 MTD partitions on "orion_nand":
-  0x000000000000-0x000000100000 : "u-boot"
-  0x000000100000-0x000000500000 : "uImage"
-  0x000000500000-0x000020000000 : "root"
+  ''Creating 3 MTD partitions on "orion_nand":''
+  ''0x000000000000-0x000000100000 : "u-boot"''
+  ''0x000000100000-0x000000500000 : "uImage"''
+  ''0x000000500000-0x000020000000 : "root"''
355c355
-  '''''UBI warning: ubi_scan: 3500 PEBs are corrupted'''
+  '''''UBI warning: ubi_scan: 3500 PEBs are corrupted'''''
2010-08-27 14:33:44 (rückgängig machen): (plomlompom):
348,359c348,359
-  UBI: attaching mtd2 to ubi0
-  UBI: physical eraseblock size:   131072 bytes (128 KiB)
-  UBI: logical eraseblock size:    129024 bytes
-  UBI: smallest flash I/O unit:    2048
-  UBI: sub-page size:              512
-  UBI: VID header offset:          512 (aligned 512)
-  UBI: data offset:                2048
-  '''UBI warning: ubi_scan: 3500 PEBs are corrupted'''
-  corrupted PEBs are: 545 546 547 548 549 550 551 552 553 554 555 
-  556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571
-  572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587
-  588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603
+  ''UBI: attaching mtd2 to ubi0''
+  ''UBI: physical eraseblock size:   131072 bytes (128 KiB)''
+  ''UBI: logical eraseblock size:    129024 bytes''
+  ''UBI: smallest flash I/O unit:    2048''
+  ''UBI: sub-page size:              512''
+  ''UBI: VID header offset:          512 (aligned 512)''
+  ''UBI: data offset:                2048''
+  '''''UBI warning: ubi_scan: 3500 PEBs are corrupted'''
+  ''corrupted PEBs are: 545 546 547 548 549 550 551 552 553 554 555''
+  ''556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571''
+  ''572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587''
+  ''588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603''
2010-08-27 14:32:05 (rückgängig machen): (plomlompom):
420c420
-  I have no name!@(none):/# ls
+  # ls
434c434,439
- Er entpackt und konfiguriert fleißig bis zur abschließenden Erfolgsmeldung. Und damit ist theoretisch das Debian fertig eingerichtet.
+ Er entpackt und konfiguriert fleißig bis zur abschließenden Erfolgsmeldung. Und damit ist theoretisch das Debian fertig eingerichtet. Sogar eine inittab ist jetzt unter /etc/inittab vorhanden!
+ 
+ Aber halt! Ein zwei kleine Sachen gilt es noch anzupassen, um weiter Freude an der Installation zu haben. Zuerst teile ich dem System mit, dass init beim Initialisieren ein TTY an der seriellen Schnittstelle aufmachen soll, mit der Baudrate 115200. Genau für sowas ist die inittab da:
+ 
+  # echo 'T0:2345:respawn:/sbin/getty -L ttyS0 115200 linux' >> /etc/inittab
+  # mknod -m 660 /dev/ttyS0 c 4 64
2010-08-27 14:26:30 (rückgängig machen): (plomlompom):
431a432
+  ''I: Base system installed successfully.''
433c434
- Er entpackt und konfiguriert jetzt fleißig.
+ Er entpackt und konfiguriert fleißig bis zur abschließenden Erfolgsmeldung. Und damit ist theoretisch das Debian fertig eingerichtet.
2010-08-27 14:25:20 (rückgängig machen): (plomlompom):
364,379c364,379
-  UBI: '''volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs'''
-  UBI: attached mtd2 to ubi0
-  UBI: MTD device name:            "root"
-  UBI: '''MTD device size:            507 MiB'''
-  UBI: number of good PEBs:        4045
-  UBI: '''number of bad PEBs:         11'''
-  UBI: max. allowed volumes:       128
-  UBI: wear-leveling threshold:    4096
-  UBI: number of internal volumes: 1
-  UBI: number of user volumes:     1
-  UBI: available PEBs:             0
-  UBI: total number of reserved PEBs: 4045
-  UBI: number of PEBs reserved for bad PEB handling: 40
-  UBI: '''max/mean erase counter: 1/0'''
-  UBI: image sequence number: 0
-  UBI: background thread "ubi_bgt0d" started, PID 462
+  ''UBI: '''volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs'''''
+  ''UBI: attached mtd2 to ubi0''
+  ''UBI: MTD device name:            "root"''
+  ''UBI: '''MTD device size:            507 MiB'''''
+  ''UBI: number of good PEBs:        4045''
+  ''UBI: '''number of bad PEBs:         11'''''
+  ''UBI: max. allowed volumes:       128''
+  ''UBI: wear-leveling threshold:    4096''
+  ''UBI: number of internal volumes: 1''
+  ''UBI: number of user volumes:     1''
+  ''UBI: available PEBs:             0''
+  ''UBI: total number of reserved PEBs: 4045''
+  ''UBI: number of PEBs reserved for bad PEB handling: 40''
+  ''UBI: '''max/mean erase counter: 1/0'''''
+  ''UBI: image sequence number: 0''
+  ''UBI: background thread "ubi_bgt0d" started, PID 462''
416a417,433
+ 
+ Um zu testen, ob ich wirklich Befehle ausführen kann und das von debootstrap gebaute Dateisystem vor mir habe, gebe ich "ls" ein:
+ 
+  I have no name!@(none):/# ls
+  ''bin   debootstrap  etc   lib  proc  sbin     sys  usr''
+  ''boot  dev          home  mnt  root  selinux  tmp  var''
+ 
+ Prima! Dann machen wir uns mal an die Arbeit. Das debootstrap-Programm liegt intuitiverweise im Verzeichnis /debootstrap/:
+ 
+  I have no name!@(none):/# /debootstrap/debootstrap --second-stage
+  ''I: Installing core packages...''
+  ''I: Unpacking required packages...''
+  ''I: Unpacking libacl1...''
+  ''I: Unpacking libattr1...''
+ (...)
+ 
+ Er entpackt und konfiguriert jetzt fleißig.
2010-08-27 14:20:57 (rückgängig machen): (plomlompom):
385,394c385,394
-  UBIFS: mounted UBI device 0, volume 0, name "rootfs"
-  '''UBIFS: file system size:   514805760 bytes (502740 KiB, 490 MiB, 3990 LEBs)'''
-  '''UBIFS: journal size:       9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)'''
-  UBIFS: media format:       w4/r0 (latest is w4/r0)
-  UBIFS: default compressor: zlib
-  UBIFS: reserved for root:  0 bytes (0 KiB)
-  '''VFS: Mounted root (ubifs filesystem) on device 0:13.'''
-  Freeing init memory: 140K
-  '''INIT: version 2.86 booting'''
-  '''INIT: No inittab file found'''
+  ''UBIFS: mounted UBI device 0, volume 0, name "rootfs"''
+  '''''UBIFS: file system size:   514805760 bytes (502740 KiB, 490 MiB, 3990 LEBs)'''''
+  '''''UBIFS: journal size:       9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)'''''
+  ''UBIFS: media format:       w4/r0 (latest is w4/r0)''
+  ''UBIFS: default compressor: zlib''
+  ''UBIFS: reserved for root:  0 bytes (0 KiB)''
+  '''''VFS: Mounted root (ubifs filesystem) on device 0:13.'''''
+  ''Freeing init memory: 140K''
+  '''''INIT: version 2.86 booting'''''
+  '''''INIT: No inittab file found'''''
396c396
-  '''''Enter runlevel: '''''
+  '''Enter runlevel: '''
400c400,416
- Die dritte hervorgehobene Zeile kündet vom Erfolg meines Vorhabens: Yay, in dem Image, was ich in den Speicher geschrieben habe, findet der Kernel tatsächlich irgendeine Verzeichniswurzel, in die er hineinbooten kann! Die verbleibenden hervorgehobenen Zeilen dämpfen die Freude dann wieder etwas: Der Kernel möchte gerne an den "init"-Prozess abgeben. Der braucht aber eine Datei /etc/inittab, um sich zu orientieren; ohne die weiß er nicht viel zu tun. Im "Enter runlevel: "-Prompt kann ich eintippen, was ich will, nichts wird mich weiterführen, denn es gibt im debootstrap-Dateisystem noch gar keine Anweisungen zu so etwas wie einem "runlevel".
+ Die dritte hervorgehobene Zeile kündet vom Erfolg meines Vorhabens: Yay, in dem Image, was ich in den Speicher geschrieben habe, findet der Kernel tatsächlich irgendeine Verzeichniswurzel, in die er hineinbooten kann! Die verbleibenden hervorgehobenen Zeilen dämpfen die Freude dann wieder etwas: Der Kernel möchte gerne an den "init"-Prozess abgeben. Der braucht aber eine Datei /etc/inittab, um sich zu orientieren; ohne die weiß er nicht viel zu tun. Im "Enter runlevel: "-Prompt könnte ich ein bestimmtes "Runlevel", also einen bestimmten Katalog an weiteren aufzurufenden Schritten spezifieren; aber ohne inittab gibt es keine solchen Kataloge.
+ 
+ Wie, ist da vielleicht doch kein bootbares Unix in dem geflashten Image? Naja, noch kein richtig bootbares. Ich verweise zurück auf den "--foreign"-Parameter, den ich zu Anfang dem "debootstrap"-Befehl übergab: Der weist debootstrap an, den Bau des Systems in zwei Stufen zu unterteilen. Der erste davon kann egal wo stattfinden und baut ein System, das auch schon ans Ziel geflasht werden kann; dort braucht es aber einen Kernel, der reinbootet und an einen Benutzer übergibt, der notwendige Schritte ausführen kann, um das System fertig zu bekommen. Genaugenommen muss vor Ort in dem Dateisystem dann nämlich "debootstrap --second-stage" aufgerufen werden.
+ 
+ Aber ich kann ja nichts weiter eintippen als ein nicht vorhandenes Runlevel! Wie soll ich da irgendwas im System machen, geschweige denn "debootstrap --second-stage" aufrufen? Ganz einfach: Ich weiße den Kernel an, als Init eine Shell zu öffnen. Mit dem Boot-Parameter "init=[Programmpfad]" kann ich den Kernel anweisen, seinen Init-Prozess ein Programm im Verzeichnisbaum aufzurufen. Also erweitere ich im U-Boot-Prompt die "bootargs"-Umgebungsvariable:
+ 
+  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
+  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
+  tfs rootfstype=ubifs init=/bin/bash
+  Marvell>> saveenv
+  Marvell>> reset
+ 
+ Beim nächsten Boot sieht alles schon freundlicher aus: 
+ 
+  ''VFS: Mounted root (ubifs filesystem) on device 0:13.''
+  ''Freeing init memory: 140K''
+  I have no name!@(none):/# 
2010-08-27 07:16:41 (rückgängig machen): (plomlompom):
29,30c29,30
-  ''$ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit,
-  die per default beim Bootloader U-Boot eingestellt ist''
+  ''$ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit,''
+  ''die per default beim Bootloader U-Boot eingestellt ist''
2010-08-27 07:16:24 (rückgängig machen): (plomlompom):
9c9
-  $ dmesg                        # Log der Kernel-Nachrichten ausgeben
+  ''$ dmesg                        # Log der Kernel-Nachrichten ausgeben''
29c29,30
-  $ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
+  ''$ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit,
+  die per default beim Bootloader U-Boot eingestellt ist''
41,42c42,43
-  Marvell>> usb start
-  Marvell>> fatload usb 0:1 0x0800000 uboot.bin
+  ''Marvell>> usb start''
+  ''Marvell>> fatload usb 0:1 0x0800000 uboot.bin''
50,51c51,52
-  Marvell>> nand erase 0x0 0xa0000
-  Marvell>> nand write 0x0800000 0x0 0xa0000
+  ''Marvell>> nand erase 0x0 0xa0000''
+  ''Marvell>> nand write 0x0800000 0x0 0xa0000''
55c56
-  Marvell>> reset
+  ''Marvell>> reset''
67c68
-  Marvell>> usb start
+  ''Marvell>> usb start''
75c76
-  Marvell>> fatls usb 0:1 /
+  ''Marvell>> fatls usb 0:1 /''
82c83
-  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
+  ''Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage''
93c94
-  Marvell>> iminfo 0x2000000
+  ''Marvell>> iminfo 0x2000000''
108,109c109,110
-  Marvell>> setenv mainlineLinux yes
-  Marvell>> setenv arcNumber 2097
+  ''Marvell>> setenv mainlineLinux yes''
+  ''Marvell>> setenv arcNumber 2097''
115c116
-  Marvell>> bootm 0x2000000
+  ''Marvell>> bootm 0x2000000''
141,147c142,148
-  Marvell>> usb start
-  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
-  Marvell>> nand erase 0x100000 0x400000
-  Marvell>> nand write 0x2000000 0x100000 0x400000
-  Marvell>> setenv mainlineLinux yes
-  Marvell>> setenv arcNumber 2097
-  Marvell>> saveenv
+  ''Marvell>> usb start''
+  ''Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage''
+  ''Marvell>> nand erase 0x100000 0x400000''
+  ''Marvell>> nand write 0x2000000 0x100000 0x400000''
+  ''Marvell>> setenv mainlineLinux yes''
+  ''Marvell>> setenv arcNumber 2097''
+  ''Marvell>> saveenv''
160c161
-  # debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/
+  ''# debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/''
172c173
-  # mkfs.ubifs -v -r debian-stable/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img
+  ''# mkfs.ubifs -v -r debian-stable/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img''
201c202
-  $ cat ubi.cfg 
+  ''$ cat ubi.cfg''
215c216
-  # ubinize -v -m 2048 -p 128KiB -s 512 ubi.cfg -o ubi.img
+  ''# ubinize -v -m 2048 -p 128KiB -s 512 ubi.cfg -o ubi.img''
242c243
-  Marvell>> usb start
+  ''Marvell>> usb start''
254c255
-  Marvell>> fatload usb 0:1 0x800000 ubi.img
+  ''Marvell>> fatload usb 0:1 0x800000 ubi.img''
258c259
-  Marvell>> nand erase 0x500000 0x1fb00000
+  ''Marvell>> nand erase 0x500000 0x1fb00000''
277c278
-  Marvell>> nand write.e 0x800000 0x500000 0x1fb00000 
+  ''Marvell>> nand write.e 0x800000 0x500000 0x1fb00000''
300,303c301,304
-  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
-  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
-  tfs rootfstype=ubifs
-  Marvell>> saveenv
+  ''Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000''
+  ''(u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo''
+  ''tfs rootfstype=ubifs''
+  ''Marvell>> saveenv''
395c396
-  '''Enter runlevel: '''
+  '''''Enter runlevel: '''''
2010-08-27 07:10:43 (rückgängig machen): (plomlompom):
298c298
- So, und jetzt? Reicht das, damit der Kernel booten kann? In meinem Fall seltsamerweise schon. Unter Bedingung bestimmter Umgebungsvariablen bei U-Boot, und vielleicht noch Weiterem. Das Mindeste, was ich nicht eliminert kriege, ohne dass der Kernel zu booten sich weigern wird, ist folgende U-Boot-Umgebungsvariable "bootargs":
+ So, und jetzt? Reicht das, damit der Kernel booten kann? Nein, natürlich nicht. Denn woher soll er wissen, dass das Dateisystem für ihn an 0x500000 beginnt? Ich muss ihn aufklären. Das tu ich mit der Umgebungsvariable "bootargs", die dem Kernel Boot-Parameter übergibt:
300c300,302
-  Marvell>> setenv bootargs console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
+  Marvell>> setenv bootargs=console=ttyS0,115200 mtdparts=orion_nand:0x100000@0x000000
+  (u-boot),0x400000@0x100000(uImage),0x1fb00000@0x500000(root) ubi.mtd=2 root=ubi0:roo
+  tfs rootfstype=ubifs
305c307
- Ich muss gestehen, dass ich gemogelt habe; ich habe vorher mir schonmal ein Debian-Dateisystem sehr viel umständlicher auf 0x500000 und Folgende geflasht, und zwar wie in http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash beschrieben. Das hat vermutlich auch diese Umgebungsvariable so gesetzt. Aber auch, als ich den Speicher selbst neu beschrieben hatte, bootete es damit tadellos. Der Versuch einer Entschlüsselung: "console=ttyS0,115200" ist eigentlich nicht Boot-relevant, sagt dem Kernel aber, dass er an die serielle Schnittstelle des SheevaPlug mit 115200 Baud seine Ausgabe lenken soll, was es mir erlaubt, via USB-Kabel und "screen /dev/ttyUSB0 115200" in den Kernel-Bootvorgang reinzugucken, also schonmal extrem praktisch ist. "rootfstype=ubifs" sagt dem Kernel, dass das Dateisystem, in das er hinein booten soll, ein UBIFS ist. "root=ubi0:rootfs" identifiziert das UBI Volume mit dem debootstrap-Dateisystem, wie ich es weiter oben in der ubi.cfg kennzeichnete. "ubi.mtd=2" sagt dem Kernel, dass er das ganze UBI-Dings in der dritten Partition des Flash-NAND-Speichers findet.
+ "console=ttyS0,115200" ist eigentlich nicht Boot-relevant, sagt dem Kernel aber, dass er an die serielle Schnittstelle des SheevaPlug mit 115200 Baud seine Ausgabe lenken soll, was es mir erlaubt, via USB-Kabel und "screen /dev/ttyUSB0 115200" in den Kernel-Bootvorgang reinzugucken, also schonmal extrem praktisch ist. 
307c309,313
- Mooooment mal! Dritte Partition des rauhen, unübersetzten Flash-Speichers? Ja, nun, ich bin da auch etwas ratlos. Aber gucken wir mal in den Kernel, wie er bootet, nachdem ich jetzt den SheevaPlug neu starte:
+ "mtdparts=" (MTD Part[ition]s) kündigt nichts Geringeres an als eine ganze Partitionstabelle: Der interne Flash-Speicher wird vom Kernel an der Bezeichnung "orion_nand" erkannt (bzw. bei Problemen stattdessen mal "nand_mtd" ausprobieren; was hier greift, scheint abhängig vom Kernel in der selben Logik zu stecken wie der Wechsel zu "mainlineLinux yes" und "arcNumber 2097"), es folgen Festlegungen der Positionen und Größen seiner Partitionen (nach dem Muster Größe@Position), wobei jede Partition auch noch in Klammern einen Namen hinterhergeworfen bekommt.
+ 
+ "ubi.mtd=2" kennzeichnet die zweite dieser MTD-Partitionen als UBI. "root=ubi0:rootfs" benennt innerhalb dieser UBI-Partition das erste (nullte) Volume mit dem Namen "rootfs" als die Unter-Partition, die dem Kernel als Root-Partition zu übergeben ist. "rootfstype" sagt dem Kernel, dass er seine Root-Partition als Dateisystem UBIFS booten soll.
+ 
+ Gucken wir mal in den Kernel, wie er bootet, nachdem ich mit "reset" jetzt den SheevaPlug neu starte:
313,318d318
-  CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
-  CPU: VIVT data cache, VIVT instruction cache
-  Machine: Marvell SheevaPlug Reference Board
-  Memory policy: ECC disabled, Data cache writeback
-  Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
-  Kernel command line: '''console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'''
320c320
- Bis hierhin alles ok. Schön zu sehen, dass die im U-Boot eingestellten "bootargs" brav übernommen wurden. Ein bisschen später dann:
+ Bis hierhin alles ok. Ein bisschen später dann:
343c343
- Aha? Woher kommen diese drei Partitionen plötzlich? Sie entsprechen präzise den Bereichen, die ich jeweils mit dem "u-boot"-Bootloader und dem "uImage" des Kernels beschrieben habe bzw. dem Bereich, den ich eben für "root" freigemacht habe. Aber woher weiß der Kernel das so genau? Ich bin da bisher ehrlich gesagt ratlos. Vielleicht ist dieses (fürs Booten mit den genannten Bootargumenten notwendige) Wissen ein von U-Boot irgendwie geheim an den Kernel weitergeleitetes Wissen (es lässt sich aber aus keiner der gesetzten Umgebungs-Variablen herauslesen); vielleicht ist es in den Kernel einkompiliert (er ist schließlich von http://sheeva.with-linux.com/ rübergeholt, die ihn sicher auf erwartbare Defaults beim SheevaPlug angepasst haben); vielleicht ist es ein weiteres Überbleibsel meines vorherigen Versuchs mit http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash -- was doof wäre, weil, dann wäre es nicht so leicht zu rekonstruieren. Ich bin noch am Nachgrübeln / Suchen, woher die Stelle kommen könnte. Es heißt, man könnte mit der "mtdparts"-Umgebungsvariable diese Partitionierungen beeinflussen; sie aber einfach nur so im U-Boot zu setzen, ändert nichts an dieser Anzeige.
+ Hier sehen wir die Partitionstabelle, die wir als Boot-Argument mit übergeben haben.
2010-08-27 06:50:00 (rückgängig machen): (plomlompom):
149c149
- (Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich irgendwann im nächsten Abschnitt.)
+ Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich irgendwann im nächsten Abschnitt. Dasselbe gilt für die Umgebungsvariable "bootargs", deren Anpassung vielleicht auch noch notwendig sein könnte; alles im nächsten Abschnitt näher erörtert. Um in den einzusteigen, sollte es reichen, obige Zeilen zu setzen, selbst wenn der Kernel dann noch nicht booten sollte.
2010-08-27 06:47:08 (rückgängig machen): (plomlompom):
153,154c153
- Gut, ein Kernel ist also drauf auf dem SheevaPlug-internen NAND-Flash-Speicher, aber er hat noch nichts zum Reinbooten. Da helf ich natürlich gerne nach. Wertvolle Hilfen gaben mir dabei folgende Tutorials / Infosammlungen, von denen sich aber keines eins zu eins hier abgebildet findet:
- * http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash
+ Gut, ein Kernel ist also drauf auf dem SheevaPlug-internen NAND-Flash-Speicher, aber er hat noch nichts zum Reinbooten. Da helf ich natürlich gerne nach. Weitere wertvolle Hilfen gaben mir dabei folgende Tutorials / Infosammlungen, von denen sich aber keines eins zu eins hier abgebildet findet:
2010-08-27 06:46:17 (rückgängig machen): (plomlompom):
152,153d151
- 
- (Anmerkung: Huch, nein, ein Kernel ist ja noch gar nicht drauf, nach den bisherigen Beschreibungen. Ich habe den Schritt ausgelassen, den Kernel zu schreiben. Naja, mach ich später.)
2010-08-27 06:46:03 (rückgängig machen): (plomlompom):
149c149
- (0x100000 ist die Default-Position des Kernels, und 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich irgendwann im nächsten Abschnitt.)
+ (Die Adresse 0x100000 ist die Default-Position des Kernels, und die Länge 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich irgendwann im nächsten Abschnitt.)
2010-08-27 06:45:14 (rückgängig machen): (plomlompom):
137a138,149
+ 
+ Lust, den Kernel permanent zu schreiben? Dann mal rasch im Schnelldurchlauf:
+ 
+  Marvell>> usb start
+  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
+  Marvell>> nand erase 0x100000 0x400000
+  Marvell>> nand write 0x2000000 0x100000 0x400000
+  Marvell>> setenv mainlineLinux yes
+  Marvell>> setenv arcNumber 2097
+  Marvell>> saveenv
+ 
+ (0x100000 ist die Default-Position des Kernels, und 0x400000 der Default-Raum für ihn. Wie man diese Defaults evtl. anpassen könnte, erzähle ich irgendwann im nächsten Abschnitt.)
2010-08-27 06:40:38 (rückgängig machen): (plomlompom):
104c104,113
- "iminfo" ist ein U-Boot-Programm, das sich an eben den Zusatz-Kopfdaten abzuarbeiten scheint, die "uboot-mkimage" einem Image aufbürdet, wenn es in ein uImage umwandelt. Sieht ja soweit alles ok aus. Also booten wir mal! Das geht ganz einfach, indem ich das Programm "bootm" auf besagte Speicheradresse jage. "bootm" scheint nochmal "iminfo" aufzurufen und schiebt danach den Kernel-Code durch den Prozessor:
+ "iminfo" ist ein U-Boot-Programm, das sich an eben den Zusatz-Kopfdaten abzuarbeiten scheint, die "uboot-mkimage" einem Image aufbürdet, wenn es in ein uImage umwandelt. Sieht ja soweit alles ok aus. 
+ 
+ (Nachtrag: Alle Welt sagt, man solle bei Verwendung von etwas Anderem als dem mitgelieferten Kernel auch noch Folgendes setzen (ohne dass ich auch nur halbwegs verstehen würde, warum):
+ 
+  Marvell>> setenv mainlineLinux yes
+  Marvell>> setenv arcNumber 2097
+ 
+ Das hab ich hier an der Stelle wohl aufzuführen vergessen, weil ich diese Umgebungsvariable bei früheren Versuchen schon gesetzt ''und gespeichert'' hatte, so dass ich sie nicht mehr neu setzen brauchte. Ob der Kernel auch ohne booten würde, bin ich jetzt auszuprobieren zu faul.)
+ 
+ Also booten wir mal! Das geht ganz einfach, indem ich das Programm "bootm" auf besagte Speicheradresse jage. "bootm" scheint nochmal "iminfo" aufzurufen und schiebt danach den Kernel-Code durch den Prozessor:
2010-08-27 06:35:30 (rückgängig machen): (plomlompom):
130a131,132
+ 
+ (Anmerkung: Huch, nein, ein Kernel ist ja noch gar nicht drauf, nach den bisherigen Beschreibungen. Ich habe den Schritt ausgelassen, den Kernel zu schreiben. Naja, mach ich später.)
2010-08-27 05:57:04 (rückgängig machen): (plomlompom):
377a378,379
+ 
+ Die dritte hervorgehobene Zeile kündet vom Erfolg meines Vorhabens: Yay, in dem Image, was ich in den Speicher geschrieben habe, findet der Kernel tatsächlich irgendeine Verzeichniswurzel, in die er hineinbooten kann! Die verbleibenden hervorgehobenen Zeilen dämpfen die Freude dann wieder etwas: Der Kernel möchte gerne an den "init"-Prozess abgeben. Der braucht aber eine Datei /etc/inittab, um sich zu orientieren; ohne die weiß er nicht viel zu tun. Im "Enter runlevel: "-Prompt kann ich eintippen, was ich will, nichts wird mich weiterführen, denn es gibt im debootstrap-Dateisystem noch gar keine Anweisungen zu so etwas wie einem "runlevel".
2010-08-27 05:53:28 (rückgängig machen): (plomlompom):
377c377
- Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Die 490 MiB sind "3990 LEBs", also "logical erase blocks"; diese sind wegen UBI-Metadaten stets ein bisschen kleiner als die "physical erase blocks" im Speicher. Rundet man die LEBs (je 126 KiB) auf PEBs (je 128 KiB) auf, kommen wir schon auf 498 MiB. Das ebenfalls Metadaten-reiche "Journal" von UBIFS verschlingt, wie die zweite hervorgehobene Zeile zeigt, auch nochmal 8 MiB. Fehlt noch ein MiB; der dürfte locker (wenn auch nicht ganz genau; irgendwer hat hier irgendwo gerundet) in den elf "bad blocks" aufgehen.
+ Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Die 490 MiB sind "3990 LEBs", also "logical erase blocks"; diese sind wegen UBI-Metadaten stets ein bisschen kleiner als die "physical erase blocks" im Speicher. Rundet man die LEBs (je 126 KiB) auf PEBs (je 128 KiB) auf, kommen wir schon auf 498 MiB. Das ebenfalls Metadaten-reiche "Journal" von UBIFS verschlingt, wie die zweite hervorgehobene Zeile zeigt, auch nochmal 8 MiB. Fehlt noch ein MiB; der dürfte locker (wenn auch nicht ganz genau; irgendwer hat hier irgendwo abgerundet) in den elf "bad blocks" aufgehen.
2010-08-27 05:53:18 (rückgängig machen): (plomlompom):
377c377
- Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Die 490 MiB sind "3990 LEBs", also "logical erase blocks"; diese sind wegen UBI-Metadaten stets ein bisschen kleiner als die "physical erase blocks" im Speicher. Rundet man die LEBs (je 126 KiB) auf PEBs (je 128 KiB) auf, kommen wir schon auf 498 MiB. Das ebenfalls Metadaten-reiche "Journal" von UBIFS verschlingt, wie die zweite hervorgehobene Zeile zeigt, auch nochmal 8 MiB. Fehlt noch ein MiB; der dürfte locker in den elf "bad blocks" aufgehen.
+ Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Die 490 MiB sind "3990 LEBs", also "logical erase blocks"; diese sind wegen UBI-Metadaten stets ein bisschen kleiner als die "physical erase blocks" im Speicher. Rundet man die LEBs (je 126 KiB) auf PEBs (je 128 KiB) auf, kommen wir schon auf 498 MiB. Das ebenfalls Metadaten-reiche "Journal" von UBIFS verschlingt, wie die zweite hervorgehobene Zeile zeigt, auch nochmal 8 MiB. Fehlt noch ein MiB; der dürfte locker (wenn auch nicht ganz genau; irgendwer hat hier irgendwo gerundet) in den elf "bad blocks" aufgehen.
2010-08-27 05:52:35 (rückgängig machen): (plomlompom):
377c377
- Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Desweiteren reserviert sich UBIFS davon für sein "Journal" 8 MiB. 
+ Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Die 490 MiB sind "3990 LEBs", also "logical erase blocks"; diese sind wegen UBI-Metadaten stets ein bisschen kleiner als die "physical erase blocks" im Speicher. Rundet man die LEBs (je 126 KiB) auf PEBs (je 128 KiB) auf, kommen wir schon auf 498 MiB. Das ebenfalls Metadaten-reiche "Journal" von UBIFS verschlingt, wie die zweite hervorgehobene Zeile zeigt, auch nochmal 8 MiB. Fehlt noch ein MiB; der dürfte locker in den elf "bad blocks" aufgehen.
2010-08-27 05:44:19 (rückgängig machen): (plomlompom):
377c377
- Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Nun, erstmal reserviert sich UBIFS für sein "Journal" 8 MiB. Fehlen immer noch 9 MiB.
+ Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Desweiteren reserviert sich UBIFS davon für sein "Journal" 8 MiB. 
2010-08-27 05:40:48 (rückgängig machen): (plomlompom):
362c362,377
- Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass der hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen könnte UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen ("wear leveling").  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch vercschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format
+ Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass der hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen könnte UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen ("wear leveling").  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch verschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format Gucken wir jetzt erstmal weiter, zum Ende des Kernel-Monologs:
+ 
+  UBIFS: mounted UBI device 0, volume 0, name "rootfs"
+  '''UBIFS: file system size:   514805760 bytes (502740 KiB, 490 MiB, 3990 LEBs)'''
+  '''UBIFS: journal size:       9033728 bytes (8822 KiB, 8 MiB, 71 LEBs)'''
+  UBIFS: media format:       w4/r0 (latest is w4/r0)
+  UBIFS: default compressor: zlib
+  UBIFS: reserved for root:  0 bytes (0 KiB)
+  '''VFS: Mounted root (ubifs filesystem) on device 0:13.'''
+  Freeing init memory: 140K
+  '''INIT: version 2.86 booting'''
+  '''INIT: No inittab file found'''
+  
+  '''Enter runlevel: '''
+ 
+ Die ersten beiden hervorgehobenen Zeile spucken schon wieder neue interessante Größenangaben aus. Eben hatten wir doch noch 507 MiB, wieso gibt's jetzt nur noch 490 MiB? Nun, erstmal reserviert sich UBIFS für sein "Journal" 8 MiB. Fehlen immer noch 9 MiB.
2010-08-27 05:35:36 (rückgängig machen): (plomlompom):
360c360
- Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. Die dritte hervorgehobene Stelle zählt nochmal die bösen Blöcke auf; hier sollte ich drauf achten, dass das nicht durch irgendeinen Fehler unverhältnismäßig schnell mehr wird.
+ Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. Die dritte hervorgehobene Stelle zählt nochmal die bösen Blöcke auf; hier sollte ich drauf achten, dass diese nicht durch irgendeinen Fehler unverhältnismäßig schnell mehr werden.
362c362
- Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass das hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen kann UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen.  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch vercschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format
+ Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass der hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen könnte UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen ("wear leveling").  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch vercschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format
2010-08-27 05:33:02 (rückgängig machen): (plomlompom):
362c362
- Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "Eraseblock" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. Etwaiges Wissen eines Blocks "wie oft wurde ich schon gelöscht?" habe ich aber mit meinem Brute-Force-Verfahren überschrieben.
+ Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "erase block" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. "max/mean erase counter" gibt Auskunft über den höchsten im Einzelfall auftretenden und den mittleren allgemeinen Schonmal-gelöscht-worden-sein-Wert; dass das hier so niedrig ist, zeigt, dass etwaiges Wissen der Blöcke "wie oft wurde ich schon gelöscht?" durch mein Brute-Force-Verfahren überschrieben wurde. Solches Wissen kann UBI benutzen, um noch nicht so oft gelöschte Blöcke zur Schonung schon oft gelöschter Blöcke bei neuen Löschvorgängen vorzuziehen.  Nun ist der Speicher meines SheevaPlugs aber vorher nur sehr geringfügig strapaziert worden, insofern ist die so verursachte Verfälschung momentan noch vercschmerzbar. Näheres siehe hier: http://www.linux-mtd.infradead.org/doc/ubi.html#L_format
2010-08-27 05:27:13 (rückgängig machen): (plomlompom):
360c360
- Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. 
+ Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. Die dritte hervorgehobene Stelle zählt nochmal die bösen Blöcke auf; hier sollte ich drauf achten, dass das nicht durch irgendeinen Fehler unverhältnismäßig schnell mehr wird.
362c362
- Der dritte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "Eraseblock" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. Etwaiges Wissen eines Blocks "wie oft wurde ich schon gelöscht?" habe ich aber mit meinem Brute-Force-Verfahren überschrieben.
+ Der vierte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "Eraseblock" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. Etwaiges Wissen eines Blocks "wie oft wurde ich schon gelöscht?" habe ich aber mit meinem Brute-Force-Verfahren überschrieben.
2010-08-27 05:26:24 (rückgängig machen): (plomlompom):
341c341,362
- Huch! Das sieht gefährlich aus. Rechnen wir mal nach (PEB = Physical Eraseblock = 128 KiB), sind 3500 PEBs aber ungefähr der ganze Bereich, der vorhin mit leerem Arbeitsspeicher überschrieben wurde. Beim nächsten Boot ist diese Meldung verschwunden; UBI hat dann offenbar diesen Bereich als verloren abgeschrieben und tabula-rasa-erneuert unter sein UBI-Diktat gebracht. (Oder auch nicht; ich bin noch nicht soweit im Experimentieren, um das abschließend beurteilen zu können. Vielleicht ist auch alles als kaputt und nicht benutzbar markiert, das wär natürlich doof ;-) )
+ Huch! Das sieht gefährlich aus. Rechnen wir mal nach (PEB = Physical Eraseblock = 128 KiB), sind 3500 PEBs aber ungefähr der ganze Bereich, der vorhin mit leerem Arbeitsspeicher überschrieben wurde. Beim nächsten Boot ist diese Meldung verschwunden; UBI hat dann offenbar diesen Bereich als verloren abgeschrieben und tabula-rasa-erneuert unter sein UBI-Diktat gebracht. (Oder auch nicht; ich bin noch nicht soweit im Experimentieren, um das abschließend beurteilen zu können. Vielleicht ist auch alles als kaputt und nicht benutzbar markiert, das wär natürlich doof ;-) ) Als Nächstes:
+ 
+  UBI: '''volume 0 ("rootfs") re-sized from 1301 to 4001 LEBs'''
+  UBI: attached mtd2 to ubi0
+  UBI: MTD device name:            "root"
+  UBI: '''MTD device size:            507 MiB'''
+  UBI: number of good PEBs:        4045
+  UBI: '''number of bad PEBs:         11'''
+  UBI: max. allowed volumes:       128
+  UBI: wear-leveling threshold:    4096
+  UBI: number of internal volumes: 1
+  UBI: number of user volumes:     1
+  UBI: available PEBs:             0
+  UBI: total number of reserved PEBs: 4045
+  UBI: number of PEBs reserved for bad PEB handling: 40
+  UBI: '''max/mean erase counter: 1/0'''
+  UBI: image sequence number: 0
+  UBI: background thread "ubi_bgt0d" started, PID 462
+ 
+ Die erste hervorgehobene Stelle, wenn man mal nachrechnet (also jeweils mit der Eraseblock-Größe multipliziert), versichert mir, dass tatsächlich die in der "ubi.cfg" gesetzten "160 MiB" für das Volumen jetzt auf ein mögliches Maximum hochgeschraubt wurden; "auto-resize" at work! Die zweite hervorgehobene Stelle gibt mir einen Wert für die größe des UBI-Devices aus, der gut Sinn ergibt, wenn man von den 512 MiB des Flash-Speichers 1 MiB für den Bootloader und 4 MiB für den Kernel abzieht. 
+ 
+ Der dritte hervorgehobene Bereich macht mich auf ein nicht zu verleugnendes Problem meines Hauruck-Verfahrens "schreibe einfach mal fremderorts generierte Images in den hiesigen Flash-Speicher" aufmerksam. Das UBI-System versucht nämlich bei jedem "Eraseblock" zu zählen, wie oft er gelöscht wurde; die erwartbare Lösch-Zahl, bevor ein solcher Bereich den Geist aufgibt, ist endlich. Etwaiges Wissen eines Blocks "wie oft wurde ich schon gelöscht?" habe ich aber mit meinem Brute-Force-Verfahren überschrieben.
2010-08-27 05:14:12 (rückgängig machen): (plomlompom):
323c323
- Aha? Woher kommen diese drei Partitionen plötzlich? Sie entsprechen präzise den Bereichen, die ich jeweils mit dem "u-boot"-Bootloader und dem "uImage" des Kernels beschrieben habe bzw. dem Bereich, den ich eben für "root" freigemacht habe. Aber woher weiß der Kernel das so genau? Ich bin da bisher ehrlich gesagt ratlos. Vielleicht ist dieses (fürs Booten mit den genannten Bootargumenten notwendige) Wissen ein von U-Boot irgendwie geheim an den Kernel weitergeleitetes Wissen (es lässt sich aber aus keiner der gesetzten Umgebungs-Variablen herauslesen); vielleicht ist es in den Kernel einkompiliert (er ist schließlich von http://sheeva.with-linux.com/ rübergeholt, die ihn sicher auf erwartbare Defaults beim SheevaPlug angepasst haben); vielleicht ist es ein weiteres Überbleibsel meines vorherigen Versuchs mit http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash -- was doof wäre, weil, dann wäre es nicht so leicht zu rekonstruieren. Ich bin noch am Nachgrübeln.
+ Aha? Woher kommen diese drei Partitionen plötzlich? Sie entsprechen präzise den Bereichen, die ich jeweils mit dem "u-boot"-Bootloader und dem "uImage" des Kernels beschrieben habe bzw. dem Bereich, den ich eben für "root" freigemacht habe. Aber woher weiß der Kernel das so genau? Ich bin da bisher ehrlich gesagt ratlos. Vielleicht ist dieses (fürs Booten mit den genannten Bootargumenten notwendige) Wissen ein von U-Boot irgendwie geheim an den Kernel weitergeleitetes Wissen (es lässt sich aber aus keiner der gesetzten Umgebungs-Variablen herauslesen); vielleicht ist es in den Kernel einkompiliert (er ist schließlich von http://sheeva.with-linux.com/ rübergeholt, die ihn sicher auf erwartbare Defaults beim SheevaPlug angepasst haben); vielleicht ist es ein weiteres Überbleibsel meines vorherigen Versuchs mit http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash -- was doof wäre, weil, dann wäre es nicht so leicht zu rekonstruieren. Ich bin noch am Nachgrübeln / Suchen, woher die Stelle kommen könnte. Es heißt, man könnte mit der "mtdparts"-Umgebungsvariable diese Partitionierungen beeinflussen; sie aber einfach nur so im U-Boot zu setzen, ändert nichts an dieser Anzeige.
2010-08-27 05:12:27 (rückgängig machen): (plomlompom):
341c341
- Huch! Das sieht gefährlich aus. Rechnen wir mal nach (PEB = Physical Eraseblock = 128 KiB), sind 3500 PEBs aber ungefähr der ganze Bereich, der vorhin mit leerem Arbeitsspeicher überschrieben wurde. Beim nächsten Boot ist diese Meldung verschwunden; UBI hat dann offenbar diesen Bereich als verloren abgeschrieben und tabula-rasa-neu unter sein UBI-Diktat gebracht. (Oder auch nicht; ich bin noch nicht soweit im Experimentieren, um das Beurteilen zu können.)
+ Huch! Das sieht gefährlich aus. Rechnen wir mal nach (PEB = Physical Eraseblock = 128 KiB), sind 3500 PEBs aber ungefähr der ganze Bereich, der vorhin mit leerem Arbeitsspeicher überschrieben wurde. Beim nächsten Boot ist diese Meldung verschwunden; UBI hat dann offenbar diesen Bereich als verloren abgeschrieben und tabula-rasa-erneuert unter sein UBI-Diktat gebracht. (Oder auch nicht; ich bin noch nicht soweit im Experimentieren, um das abschließend beurteilen zu können. Vielleicht ist auch alles als kaputt und nicht benutzbar markiert, das wär natürlich doof ;-) )
2010-08-27 05:11:34 (rückgängig machen): (plomlompom):
300c300,341
- Bis hierhin alles ok. Schön zu sehen, dass die im U-Boot eingestellten "bootargs" brav übernommen wurden.
+ Bis hierhin alles ok. Schön zu sehen, dass die im U-Boot eingestellten "bootargs" brav übernommen wurden. Ein bisschen später dann:
+ 
+  NAND device: Manufacturer ID: 0xad, Chip ID: 0xdc (Hynix NAND 512MiB 3,3V 8-bit)
+  Scanning device for bad blocks
+  Bad eraseblock 1203 at 0x000009660000
+  Bad eraseblock 1211 at 0x000009760000
+  Bad eraseblock 2013 at 0x00000fba0000
+  Bad eraseblock 2182 at 0x0000110c0000
+  Bad eraseblock 2337 at 0x000012420000
+  Bad eraseblock 2359 at 0x0000126e0000
+  Bad eraseblock 2889 at 0x000016920000
+  Bad eraseblock 3342 at 0x00001a1c0000
+  Bad eraseblock 3429 at 0x00001aca0000
+  Bad eraseblock 3566 at 0x00001bdc0000
+  Bad eraseblock 3656 at 0x00001c900000
+ 
+ Ok, die selben bösen Blöcke wie erwartet. Unmittelbar darauf:
+ 
+  Creating 3 MTD partitions on "orion_nand":
+  0x000000000000-0x000000100000 : "u-boot"
+  0x000000100000-0x000000500000 : "uImage"
+  0x000000500000-0x000020000000 : "root"
+ 
+ Aha? Woher kommen diese drei Partitionen plötzlich? Sie entsprechen präzise den Bereichen, die ich jeweils mit dem "u-boot"-Bootloader und dem "uImage" des Kernels beschrieben habe bzw. dem Bereich, den ich eben für "root" freigemacht habe. Aber woher weiß der Kernel das so genau? Ich bin da bisher ehrlich gesagt ratlos. Vielleicht ist dieses (fürs Booten mit den genannten Bootargumenten notwendige) Wissen ein von U-Boot irgendwie geheim an den Kernel weitergeleitetes Wissen (es lässt sich aber aus keiner der gesetzten Umgebungs-Variablen herauslesen); vielleicht ist es in den Kernel einkompiliert (er ist schließlich von http://sheeva.with-linux.com/ rübergeholt, die ihn sicher auf erwartbare Defaults beim SheevaPlug angepasst haben); vielleicht ist es ein weiteres Überbleibsel meines vorherigen Versuchs mit http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash -- was doof wäre, weil, dann wäre es nicht so leicht zu rekonstruieren. Ich bin noch am Nachgrübeln.
+ 
+ Unmittelbar darauf:
+ 
+  UBI: attaching mtd2 to ubi0
+  UBI: physical eraseblock size:   131072 bytes (128 KiB)
+  UBI: logical eraseblock size:    129024 bytes
+  UBI: smallest flash I/O unit:    2048
+  UBI: sub-page size:              512
+  UBI: VID header offset:          512 (aligned 512)
+  UBI: data offset:                2048
+  '''UBI warning: ubi_scan: 3500 PEBs are corrupted'''
+  corrupted PEBs are: 545 546 547 548 549 550 551 552 553 554 555 
+  556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571
+  572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587
+  588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603
+ (usw. usf. bis zur Nummer 4055)
+ 
+ Huch! Das sieht gefährlich aus. Rechnen wir mal nach (PEB = Physical Eraseblock = 128 KiB), sind 3500 PEBs aber ungefähr der ganze Bereich, der vorhin mit leerem Arbeitsspeicher überschrieben wurde. Beim nächsten Boot ist diese Meldung verschwunden; UBI hat dann offenbar diesen Bereich als verloren abgeschrieben und tabula-rasa-neu unter sein UBI-Diktat gebracht. (Oder auch nicht; ich bin noch nicht soweit im Experimentieren, um das Beurteilen zu können.)
2010-08-27 04:58:28 (rückgängig machen): (plomlompom):
287a288,300
+ 
+  Starting kernel ...
+  
+  Uncompressing Linux... done, booting the kernel.
+  Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010
+  CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977
+  CPU: VIVT data cache, VIVT instruction cache
+  Machine: Marvell SheevaPlug Reference Board
+  Memory policy: ECC disabled, Data cache writeback
+  Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 130048
+  Kernel command line: '''console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs'''
+ 
+ Bis hierhin alles ok. Schön zu sehen, dass die im U-Boot eingestellten "bootargs" brav übernommen wurden.
2010-08-27 04:54:50 (rückgängig machen): (plomlompom):
283a284,287
+ 
+ Ich muss gestehen, dass ich gemogelt habe; ich habe vorher mir schonmal ein Debian-Dateisystem sehr viel umständlicher auf 0x500000 und Folgende geflasht, und zwar wie in http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash beschrieben. Das hat vermutlich auch diese Umgebungsvariable so gesetzt. Aber auch, als ich den Speicher selbst neu beschrieben hatte, bootete es damit tadellos. Der Versuch einer Entschlüsselung: "console=ttyS0,115200" ist eigentlich nicht Boot-relevant, sagt dem Kernel aber, dass er an die serielle Schnittstelle des SheevaPlug mit 115200 Baud seine Ausgabe lenken soll, was es mir erlaubt, via USB-Kabel und "screen /dev/ttyUSB0 115200" in den Kernel-Bootvorgang reinzugucken, also schonmal extrem praktisch ist. "rootfstype=ubifs" sagt dem Kernel, dass das Dateisystem, in das er hinein booten soll, ein UBIFS ist. "root=ubi0:rootfs" identifiziert das UBI Volume mit dem debootstrap-Dateisystem, wie ich es weiter oben in der ubi.cfg kennzeichnete. "ubi.mtd=2" sagt dem Kernel, dass er das ganze UBI-Dings in der dritten Partition des Flash-NAND-Speichers findet.
+ 
+ Mooooment mal! Dritte Partition des rauhen, unübersetzten Flash-Speichers? Ja, nun, ich bin da auch etwas ratlos. Aber gucken wir mal in den Kernel, wie er bootet, nachdem ich jetzt den SheevaPlug neu starte:
2010-08-27 04:48:37 (rückgängig machen): (plomlompom):
276a277,283
+ 
+ So, und jetzt? Reicht das, damit der Kernel booten kann? In meinem Fall seltsamerweise schon. Unter Bedingung bestimmter Umgebungsvariablen bei U-Boot, und vielleicht noch Weiterem. Das Mindeste, was ich nicht eliminert kriege, ohne dass der Kernel zu booten sich weigern wird, ist folgende U-Boot-Umgebungsvariable "bootargs":
+ 
+  Marvell>> setenv bootargs console=ttyS0,115200 ubi.mtd=2 root=ubi0:rootfs rootfstype=ubifs
+  Marvell>> saveenv
+  Saving Environment to NAND...
+  Erasing Nand...Writing to Nand... done
2010-08-27 04:43:07 (rückgängig machen): (plomlompom):
256a257,276
+  Marvell>> nand write.e 0x800000 0x500000 0x1fb00000 
+  
+  NAND write: device 0 offset 0x500000, size 0x1fb00000
+  
+  Bad block at 0x9660000 in erase block from 0x9660000 will be skipped
+  Bad block at 0x9760000 in erase block from 0x9760000 will be skipped
+  Bad block at 0xfba0000 in erase block from 0xfba0000 will be skipped
+  Bad block at 0x110c0000 in erase block from 0x110c0000 will be skipped
+  Bad block at 0x12420000 in erase block from 0x12420000 will be skipped
+  Bad block at 0x126e0000 in erase block from 0x126e0000 will be skipped
+  Bad block at 0x16920000 in erase block from 0x16920000 will be skipped
+  Bad block at 0x1a1c0000 in erase block from 0x1a1c0000 will be skipped
+  Bad block at 0x1aca0000 in erase block from 0x1aca0000 will be skipped
+  Bad block at 0x1bdc0000 in erase block from 0x1bdc0000 will be skipped
+  Bad block at 0x1c900000 in erase block from 0x1c900000 will be skipped
+  Writing data at 0x1fc4e000 --  99%25 complete.
+  Data did not fit into device, due to bad blocks
+   531628032 bytes written: ERROR
+ 
+ Ui, "ERROR", das sieht gefährlich aus! Es ist aber nur halb so schlimm. Erklärung: Ich hätte hier die Wahl zwischen "nand write" und "nand write.e" als Methoden gehabt, um das bei 0x800000 im Arbeitsspeicher lokalisierte UBI-Image an 0x500000 zu schreiben. "nand write" bricht allerdings ab, sobald es einem Bad Block begegnet; "nand write.e" dagegen überspringt die bösen Blöcke einfach. Nun gab ich als zu schreibende Länge ja 0x1fb00000 an; also alles im Arbeitsspeicher ab 0x800000 bis auf die nächsten 0x1fb00000 Stellen. Eigentlich interessiert nur der Anfangsteil dieser Länge, denn hier liegen die Image-Daten; der Rest ist Leere und egal. Da 0x1fb00000 die gesamte verbleibende Länge des Speichers abbildete, hätte es genau reingepasst; wenn nicht die bösen Blöcke übersprungen worden wären. So ist das Schreiben dieser Länge nicht ganz vollständig; am Ende fehlt aber auch nichts Wichtiges. Eleganter wäre es vielleicht gewesen, nachzurechnen, um wieviel kürzer die zu schreibende Länge durch die elf bösen Blöcke werden müsste, aber ich hab Besseres zu tun.
2010-08-27 04:28:25 (rückgängig machen): (plomlompom):
255c255
- Zwei Anmerkungen zu diesem Schritt: Erstens ist die Size von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Alles, was vorher noch im Rest des Speichers lag, ist jetzt weg. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich muss sie allerdings im Hinterkopf behalten, wenn ich als Nächstes das Image schreibe:
+ Zwei Anmerkungen zu diesem Schritt: Erstens ist die "size" von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Alles, was vorher noch im Rest des Speichers lag, ist jetzt weg. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich muss sie allerdings im Hinterkopf behalten, wenn ich als Nächstes das Image schreibe:
2010-08-27 04:28:14 (rückgängig machen): (plomlompom):
255c255,256
- Zwei Anmerkungen zu diesem Schritt: Erstens ist die Size von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich muss sie allerdings im Hinterkopf behalten, wenn ich als Nächstes das Image schreibe:
+ Zwei Anmerkungen zu diesem Schritt: Erstens ist die Size von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Alles, was vorher noch im Rest des Speichers lag, ist jetzt weg. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich muss sie allerdings im Hinterkopf behalten, wenn ich als Nächstes das Image schreibe:
+ 
2010-08-27 04:26:50 (rückgängig machen): (plomlompom):
220c220,255
- Das fertige (und auf unter 70 MiB runterkomprimierte) "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder ins U-Boot vom SheevaPlug ...
+ Das fertige (und auf unter 70 MiB runterkomprimierte) "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder in den U-Boot-Bootloaderprompt vom SheevaPlug ...
+ 
+  Marvell>> usb start
+  (Re)start USB...
+  USB:   scanning bus for devices... 2 USB Device(s) found
+  Waiting for storage device(s) to settle before scanning...
+  1 Storage Device(s) found
+  Marvell>> fatls usb 0:1 /
+   71434240   ubi.img 
+  
+  1 file(s), 0 dir(s)
+ 
+ Alles da, prima. Also rein in den ArbeitsSpeicher damit ...
+ 
+  Marvell>> fatload usb 0:1 0x800000 ubi.img
+ 
+ ... und dann den ganzen internen NAND-Speicher nach dem Kernel leer machen, damit das Image eine schöne Tabula rasa hat, um sich zu entfalten:
+ 
+  Marvell>> nand erase 0x500000 0x1fb00000
+  
+  NAND erase: device 0 offset 0x500000, size 0x1fb00000
+  Skipping bad block at  0x09660000                                            
+  Skipping bad block at  0x09760000                                            
+  Skipping bad block at  0x0fba0000                                            
+  Skipping bad block at  0x110c0000                                            
+  Skipping bad block at  0x12420000                                            
+  Skipping bad block at  0x126e0000                                            
+  Skipping bad block at  0x16920000                                            
+  Skipping bad block at  0x1a1c0000                                            
+  Skipping bad block at  0x1aca0000                                            
+  Skipping bad block at  0x1bdc0000                                            
+  Skipping bad block at  0x1c900000                                            
+  Erasing at 0x1ffe0000 -- 100%25 complete.
+  OK
+ 
+ Zwei Anmerkungen zu diesem Schritt: Erstens ist die Size von 0x1fb00000 genau die Größe, die nach 0x500000 (wo der für den Kernel frei gehaltene Speicher-Bereich endet) noch insgesamt in den 512 MiB des NAND-Speichers verbleibt. Zweitens fallen die "bad blocks" auf, die hier zu sehen sind. Bei meinen vorherigen Lösch- und Schreib-Vorgängen im NAND-Speicher stieß ich nicht auf Bad Blocks; die liegen nämlich weiter hinten. Sie sind keinen großen Alarm wert; einige Bad Blocks kann man ab Werk erwarten. Ich muss sie allerdings im Hinterkopf behalten, wenn ich als Nächstes das Image schreibe:
2010-08-27 04:16:25 (rückgängig machen): (plomlompom):
142c142
- Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines minimalen Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System ungefähr 100 MB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einem zweiten Schritt später/dort vorgenommen werden wird.
+ Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines minimalen Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System ungefähr 100 MiB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einem zweiten Schritt später/dort vorgenommen werden wird.
220c220
- Das fertige "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder ins U-Boot vom SheevaPlug ...
+ Das fertige (und auf unter 70 MiB runterkomprimierte) "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder ins U-Boot vom SheevaPlug ...
2010-08-27 04:11:39 (rückgängig machen): (plomlompom):
132a133
+ * http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash
2010-08-27 04:10:25 (rückgängig machen): (plomlompom):
217a218,219
+ 
+ Das fertige "ubi.img" hab ich mir dann auf meinen FAT16-USB-Stick kopiert, und rein ging's wieder ins U-Boot vom SheevaPlug ...
2010-08-27 04:08:33 (rückgängig machen): (plomlompom):
190a191,217
+ 
+ Mit dieser Datei in der Hand kann ich jetzt "ubinize" anwerfen:
+ 
+  # ubinize -v -m 2048 -p 128KiB -s 512 ubi.cfg -o ubi.img
+  ubinize: LEB size:      129024
+  ubinize: PEB size:      131072
+  ubinize: min. I/O size: 2048
+  ubinize: sub-page size: 512
+  ubinize: VID offset:    512
+  ubinize: data offset:   2048
+  ubinize: loaded the ini-file "ubi.cfg"
+  ubinize: count of sections: 1
+  
+  ubinize: parsing section "ubifs"
+  ubinize: mode=ubi, keep parsing
+  ubinize: volume type: dynamic
+  ubinize: volume ID: 0
+  ubinize: volume size: 167772160 bytes
+  ubinize: volume name: rootfs
+  ubinize: volume alignment: 1
+  ubinize: autoresize flags found
+  ubinize: adding volume 0
+  ubinize: writing volume 0
+  ubinize: image file: ubifs.img
+  
+  ubinize: writing layout volume
+  ubinize: done
2010-08-27 04:06:15 (rückgängig machen): (plomlompom):
139c139
-  # debootstrap --foreign --arch=armel --variant=minbase stable debootstrap/
+  # debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/
145c145
- Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend gibt es auch eigene dafür spezialisierte Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils" (MTD, Memory Technology Devices, ist ein Linux-Projekt, um die Flash-Speicher-Welt zu erschließen), das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien durchratterte, die offenbar aus meinem debootstrap/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
+ Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend gibt es auch eigene dafür spezialisierte Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils" (MTD, Memory Technology Devices, ist ein Linux-Projekt, um die Flash-Speicher-Welt zu erschließen), das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien durchratterte, die offenbar aus meinem debian-stable/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
151c151
-  # mkfs.ubifs -v -r debootstrap/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img
+  # mkfs.ubifs -v -r debian-stable/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img
2010-08-27 04:04:33 (rückgängig machen): (plomlompom):
190c190
- Wie man vor allem an der etwas merkwürdigen Angabe "vol_size" sieht, hab ich auch diese Zeilen irgendwo weggeklaut, ich weiß nur nicht mehr, woher.
+ Wie man vor allem an der etwas merkwürdigen Angabe "vol_size=160MiB" sieht, hab ich auch diese Zeilen irgendwo weggeklaut, ich weiß nur nicht mehr, woher. Wenn ich es richtig verstanden habe, ist die Angabe aufgrund des "vol_flags=autoresize" einigermaßen egal und sollte wohl nur ungefähr groß genug sein, damit das ubifs.img reinpasst; aber ich lasse mich gerne eines Besseren belehren. Das "vol_type=dynamic" besagt, dass das Dateisystem nicht nur lesbar (das wäre "static"), sondern auch beschreibbar sein soll.
2010-08-27 04:02:26 (rückgängig machen): (plomlompom):
189a190
+ Wie man vor allem an der etwas merkwürdigen Angabe "vol_size" sieht, hab ich auch diese Zeilen irgendwo weggeklaut, ich weiß nur nicht mehr, woher.
2010-08-27 04:00:34 (rückgängig machen): (plomlompom):
180c180
-  # cat ubi.cfg 
+  $ cat ubi.cfg 
2010-08-27 04:00:23 (rückgängig machen): (plomlompom):
176a177,189
+ 
+ Die Erledigung des ganzen restlichen Überbaus nimmt mir das Programm "ubinize" ab, das ein Image erzeugen soll, das man einfach so ohne weiteres Rumbasteln in den rohen Flash-Speicher schreiben können soll, um ein von modernen Linux-Kernels bootbares Dateisystem zu bekommen. Nun wäre es natürlich zu einfach, wenn dafür einfach ein "ubinize" auf das Image möglich wäre; man muss auch hier die mehr oder weniger gleichen Parameter zur Speichergeometrie eingeben und außerdem auch noch eine Konfigurationsdatei anlegen, die das ganze UBI-Organisations-Zeugs zwischen Device und Volumes und Dateisystemen usw. beschreibt. Diese Datei "ubi.cfg" sah in meinem Fall so aus:
+ 
+  # cat ubi.cfg 
+  [ubifs]
+  mode=ubi
+  image=ubifs.img
+  vol_id=0
+  vol_size=160MiB
+  vol_type=dynamic
+  vol_name=rootfs
+  vol_flags=autoresize
+ 
2010-08-27 03:55:41 (rückgängig machen): (plomlompom):
174a175,176
+ 
+ Wie man an den ganzen seltsamen Parametern zum Befehl und an der beim Image-Erzeugen ausgepuckten Liste von Werten sieht, kann man nicht mal eben so ein UBIFS-Image erzeugen, sondern man muss diverse speichergeometrische Informationen belegen. Was die Parameter-Angaben im Einzelnen bedeuten, lässt sich durch "mkfs.ubifs --help" rausfinden; ich habe sie 1:1 von http://www.digriz.org.uk/kirkwood übernommen, der für ziemlich genau die gleiche Situation / das gleiche Gerät baute.
2010-08-27 03:53:19 (rückgängig machen): (plomlompom):
145c145
- Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend gibt es auch eigene dafür spezialisierte Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils", das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien durchratterte, die offenbar aus meinem debootstrap/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
+ Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend gibt es auch eigene dafür spezialisierte Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils" (MTD, Memory Technology Devices, ist ein Linux-Projekt, um die Flash-Speicher-Welt zu erschließen), das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien durchratterte, die offenbar aus meinem debootstrap/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
147c147,174
- Mein zweiter Versuch galt UBIFS, das irgendwie das neuere und bessere und hippere JFFS2 sein soll. Gleichzeitig ist es aber auch irgendwie komplizierter; im Gegensatz zu JFFS2 handelt man sich damit nämlich nicht nur einfach ein "mkfs.ubifs" ein, 
+ Mein zweiter Versuch galt UBIFS, das irgendwie das neuere und bessere und hippere JFFS2 sein soll. Gleichzeitig ist es aber auch irgendwie komplizierter; im Gegensatz zu JFFS2 handelt man sich damit nämlich nicht nur einfach ein "mkfs.ubifs" ein, sondern eine ganze Kette von Tools, die übereinandergestülpt werden müssen. Denn eigentlich ist UBIFS nur ein Aufsatz auf UBI (Unsorted Block Devices), einer Schichtung über dem rohen Flash-Speicher, die schonmal ein bisschen was von dem Bodendreck wegabstrahiert, und UBIFS ist dann erst die nächste Abstraktionsstufe. Man muss also irgendwie über den rohen Flash-Speicher ein UBI-Device layern, in diesem UBI-Device dann einzelne Volumes anlegen, und in diesen Volumes kann man dann ein UBIFS-Dateisystem laufen lassen. Puh! Nach viel Rumprobieren und Umwegen hab ich dann aber doch eine grobe Vereinfachung gefunden, die wie folgt aussieht: 
+ 
+ Zuerst lege ich würge ich das debootstrap/-Verzeichnis in das Image eines UBIFS-Dateisystems:
+ 
+  # mkfs.ubifs -v -r debootstrap/ -m 2048 -e 129024 -c 4096 -x zlib -o ubifs.img
+  mkfs.ubifs
+          root:         debian-stable/
+          min_io_size:  2048
+          leb_size:     129024
+          max_leb_cnt:  4096
+          output:       ubifs.img
+          jrn_size:     8388608
+          reserved:     0
+          compr:        zlib
+          keyhash:      r5
+          fanout:       8
+          orph_lebs:    1
+          super lebs:   1
+          master lebs:  2
+          log_lebs:     5
+          lpt_lebs:     2
+          orph_lebs:    1
+          main_lebs:    532
+          gc lebs:      1
+          index lebs:   9
+          leb_cnt:      543
+          UUID:         DE02F8ED-2032-4F63-AAB5-DE0DC9524908
+  Success!
2010-08-27 03:44:42 (rückgängig machen): (plomlompom):
132c132,135
- Gut, ein Kernel ist also drauf, aber er hat noch nichts zum Reinbooten. Da helf ich natürlich gerne nach. 
+ Gut, ein Kernel ist also drauf auf dem SheevaPlug-internen NAND-Flash-Speicher, aber er hat noch nichts zum Reinbooten. Da helf ich natürlich gerne nach. Wertvolle Hilfen gaben mir dabei folgende Tutorials / Infosammlungen, von denen sich aber keines eins zu eins hier abgebildet findet:
+ * http://blog.bofh.it/debian/id_265
+ * http://www.digriz.org.uk/kirkwood
+ * http://www.linux-mtd.infradead.org/index.html
136c139
-  # debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/
+  # debootstrap --foreign --arch=armel --variant=minbase stable debootstrap/
138a142,147
+ 
+ Jetzt habe ich einen Verzeichnisbaum vor mir liegen, aber wie krieg ich den auf den SheevaPlug? So mächtig der U-Boot-Bootloader auch ist, er kann nicht einfach einen solchen Verzeichnisbaum in seinen rohen Flash-Speicher schreiben. Ich muss das ganze Ding in ein Image verpacken, das direkt Byte für Byte in den Speicher geschrieben werden mag.
+ 
+ Nun habe ich sehr lange herumexperimentiert und dabei viel Müll produziert, der, in den Flash-Speicher geschrieben, mal gar nicht und mal nur fehlerproduzierend / Boot-Sequenz-abbrechend vom Kernel erkannt wurde. Der rohe Flash-Speicher ist ja etwas Anderes als die Festplatten, für die die PC-üblichen Dateisysteme-ausgelegt sind; dementsprechend gibt es auch eigene dafür spezialisierte Dateisysteme. Zuerst probierte ich, mittels "mkfs.jffs2" aus dem Debian-Package "mtd-utils", das Erzeugen eines JFFS2-Images und war schon stolz, als der Kernel immerhin beim Booten die Namen einiger Dateien durchratterte, die offenbar aus meinem debootstrap/-Verzeichnis stammten; er ächzte und meckerte aber nur über sie und weigerte sich, irgendwas davon als bootfähiges Root-Verzeichnis anzuerkennen. 
+ 
+ Mein zweiter Versuch galt UBIFS, das irgendwie das neuere und bessere und hippere JFFS2 sein soll. Gleichzeitig ist es aber auch irgendwie komplizierter; im Gegensatz zu JFFS2 handelt man sich damit nämlich nicht nur einfach ein "mkfs.ubifs" ein, 
2010-08-27 03:34:10 (rückgängig machen): (plomlompom):
138c138
- Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines minimalen Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl. Der Paramter "--arch=armel" gibt an, dass dabei die Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einem zweiten Schritt später/dort vorgenommen werden wird.
+ Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines minimalen Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl; wenn debootstrap mit dem obigen Durchgang fertig ist, wird das halbfertige System ungefähr 100 MB groß sein. Der Paramter "--arch=armel" gibt an, dass dabei die Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einem zweiten Schritt später/dort vorgenommen werden wird.
2010-08-27 03:32:40 (rückgängig machen): (plomlompom):
130a131,138
+ 
+ Gut, ein Kernel ist also drauf, aber er hat noch nichts zum Reinbooten. Da helf ich natürlich gerne nach. 
+ 
+ Zuerst baue ich auf meinem Laptop-Debian ein kleines Debian-Dateisystem mit dem Programm "debootstrap":
+ 
+  # debootstrap --foreign --arch=armel --variant=minbase stable debian-stable/
+ 
+ Dieser Befehl schreibt in das Verzeichnis debian-stable/ die vollständige Hierarchie eines minimalen Debian-Systems. Der Parameter "--variant=minbase" trifft diese Minimal-Auswahl. Der Paramter "--arch=armel" gibt an, dass dabei die Varianten für die Armel-Prozessor-Architektur gezogen werden sollen, denn die enthaltenen Binaries sollen ja nicht auf meinem Laptop, sondern auf dem SheevaPlug laufen, der eben dieser Prozessor-Architektur folgt. Der Parameter "--foreign" gibt an, dass ich das System nicht hier vor Ort auf diesem Laptop zum Laufen bringen möchte, sondern auf einem anderen Gerät und deshalb die Finalisierung der System-Einrichtung in einem zweiten Schritt später/dort vorgenommen werden wird.
2010-08-27 03:25:53 (rückgängig machen): (plomlompom):
128a129,130
+ 
+ !! Ein minimales Debian installieren
2010-08-24 21:36:31 (rückgängig machen): (plomlompom):
91c91
- Ich haben das uImage jetzt in den Arbeitsspeicher an Adresse 0x2000000 eingelesen. (Die Adresse habe ich aus http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash übernommen.) Bevor ich jetzt U-Boot anweise, das an dieser Stelle gelegene Image zu booten, überprüfe ich nochmal, ob an der Adresse jetzt tatsächlich das liegt, was da liegen soll, und zwar mittels "iminfo":
+ Ich habe das uImage jetzt in den Arbeitsspeicher an Adresse 0x2000000 eingelesen. (Die Adresse habe ich aus http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash übernommen.) Bevor ich jetzt U-Boot anweise, das an dieser Stelle gelegene Image zu booten, überprüfe ich nochmal, ob an der Adresse jetzt tatsächlich das liegt, was da liegen soll, und zwar mittels "iminfo":
2010-08-24 21:33:35 (rückgängig machen): (plomlompom):
104c104,128
- "iminfo" ist ein U-Boot-Tool, das sich an eben den Zusatz-Kopfdaten abzuarbeiten scheint, die "uboot-mkimage" einem Image aufbürdet, wenn es in ein uImage umwandelt. Sieht ja soweit alles ok aus. Also booten wir mal!
+ "iminfo" ist ein U-Boot-Programm, das sich an eben den Zusatz-Kopfdaten abzuarbeiten scheint, die "uboot-mkimage" einem Image aufbürdet, wenn es in ein uImage umwandelt. Sieht ja soweit alles ok aus. Also booten wir mal! Das geht ganz einfach, indem ich das Programm "bootm" auf besagte Speicheradresse jage. "bootm" scheint nochmal "iminfo" aufzurufen und schiebt danach den Kernel-Code durch den Prozessor:
+ 
+  Marvell>> bootm 0x2000000
+  ## Booting image at 02000000 ...
+     Image Name:   Linux-2.6.35.3
+     Created:      2010-08-21   0:22:34 UTC
+     Image Type:   ARM Linux Kernel Image (uncompressed)
+     Data Size:    2795848 Bytes =  2.7 MB
+     Load Address: 00008000
+     Entry Point:  00008000
+     Verifying Checksum ... OK
+  OK
+  
+  Starting kernel ...
+  
+  Uncompressing Linux... done, booting the kernel.
+  Linux version 2.6.35.3 (kelly@speedy) (gcc version 4.4.3 (Sourcery G++ Lite er) ) #1 PREEMPT Fri Aug 20 18:22:29 MDT 2010
+ (...)
+ 
+ Es folgen jetzt die fünf Milliarden Bildschirme eines Bootvorganges voller kryptischer Meldungen über initialisierte Speicher, Treiber usw. Gegen Ende kommt dann die erwartbare Todesmeldung, weil der Kernel leider nichts Root-Dateisystem-Brauchbares vorfindet:
+ 
+  No filesystem could mount root, tried:  ext3 ext2 ext4 cramfs vfat msdos jfs
+  Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,1)
+ 
+ Aber hey, bis hierher ist ja schonmal ganz schön weit ;-)
2010-08-24 21:26:53 (rückgängig machen): (plomlompom):
80c80
- Vorgelesen: "fatls (liste Segmente in einem FAT-Dateisystem auf ...) usb 0:1 (... das sich an diesem USB-Interface befinden ...) / (... und zwar im Root-Verzeichnis)" Hier sehen wir die Datei, die wir als Nächstes in den Arbeitsspeicher einlesen wollen:
+ Vorgelesen: "fatls (liste Segmente in einem FAT-Dateisystem auf ...) usb 0:1 (... das sich an diesem USB-Interface befinden ...) / (... und zwar im Root-Verzeichnis)" Hier sehe ich die Datei, die ich als Nächstes in den Arbeitsspeicher einlesen will:
89a90,104
+ 
+ Ich haben das uImage jetzt in den Arbeitsspeicher an Adresse 0x2000000 eingelesen. (Die Adresse habe ich aus http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash übernommen.) Bevor ich jetzt U-Boot anweise, das an dieser Stelle gelegene Image zu booten, überprüfe ich nochmal, ob an der Adresse jetzt tatsächlich das liegt, was da liegen soll, und zwar mittels "iminfo":
+ 
+  Marvell>> iminfo 0x2000000
+  
+  ## Checking Image at 02000000 ...
+     Image Name:   Linux-2.6.35.3
+     Created:      2010-08-21   0:22:34 UTC
+     Image Type:   ARM Linux Kernel Image (uncompressed)
+     Data Size:    2795848 Bytes =  2.7 MB
+     Load Address: 00008000
+     Entry Point:  00008000
+     Verifying Checksum ... OK
+ 
+ "iminfo" ist ein U-Boot-Tool, das sich an eben den Zusatz-Kopfdaten abzuarbeiten scheint, die "uboot-mkimage" einem Image aufbürdet, wenn es in ein uImage umwandelt. Sieht ja soweit alles ok aus. Also booten wir mal!
2010-08-24 21:22:05 (rückgängig machen): (plomlompom):
80a81,89
+ 
+  Marvell>> fatload usb 0:1 0x2000000 sheeva-2.6.35.3-uimage
+  reading sheeva-2.6.35.3-uimage
+  .....................................................................
+  .....................................................................
+  .....................................................................
+  ..................................................................
+ 
+  2795912 bytes read
2010-08-24 21:19:04 (rückgängig machen): (plomlompom):
73c73,80
- (Warum zwei USB-Devices? Na weil ich gleichzeitig via USB-Kabel mit dem SheevaPlug verbunden bin, um via screen von meinem Debian-Laptop ein Terminal-Fenster hinein zu haben.)
+ (Warum zwei USB-Devices? Na weil ich gleichzeitig via USB-Kabel mit dem SheevaPlug verbunden bin, um via screen von meinem Debian-Laptop ein Terminal-Fenster hinein zu haben.) Schauen wir uns nun auf dem USB-Stick mal um:
+ 
+  Marvell>> fatls usb 0:1 /
+    2795912   sheeva-2.6.35.3-uimage 
+  
+  1 file(s), 0 dir(s)
+ 
+ Vorgelesen: "fatls (liste Segmente in einem FAT-Dateisystem auf ...) usb 0:1 (... das sich an diesem USB-Interface befinden ...) / (... und zwar im Root-Verzeichnis)" Hier sehen wir die Datei, die wir als Nächstes in den Arbeitsspeicher einlesen wollen:
2010-08-24 21:14:46 (rückgängig machen): (plomlompom):
65c65,73
- Ich ziehe also ein SheevaPlug-geeignetes Kernel-"uImage" auf meinen USB-Stick. Ein "uImage" ist in diesem Fall ein Linux-Kernel-Image, dem noch einige Zusatz-Daten rangepappt sind, die es u-Boot-freundlicher machen; "uboot-mkimage" wäre das Tool der Wahl, wenn man sich selber ein Linux-Kernel-Image solcherart u-Boot-kompatibel einpacken möchte. Ich nehme für den Anfang mal "sheeva-2.6.35.3-uImage", zu finden hier: http://sheeva.with-linux.com/sheeva/ Also rauf auf den USB-Stick damit und den USB-Stick in Sheevas Loch gestoßen!
+ Ich ziehe also ein SheevaPlug-geeignetes Kernel-"uImage" auf meinen USB-Stick. Ein "uImage" ist in diesem Fall ein Linux-Kernel-Image, dem noch einige Zusatz-Daten rangepappt sind, die es u-Boot-freundlicher machen; "uboot-mkimage" wäre das Tool der Wahl, wenn man sich selber ein Linux-Kernel-Image solcherart u-Boot-kompatibel einpacken möchte. Ich nehme für den Anfang mal "sheeva-2.6.35.3-uImage", zu finden hier: http://sheeva.with-linux.com/sheeva/ Also rauf auf den USB-Stick damit und den USB-Stick in Sheevas Loch gestoßen! Danach, im U-Boot-Prompt, wird der USB-Stick initialisiert:
+ 
+  Marvell>> usb start
+  (Re)start USB...
+  USB:   scanning bus for devices... 2 USB Device(s) found
+  Waiting for storage device(s) to settle before scanning...
+  1 Storage Device(s) found
+ 
+ (Warum zwei USB-Devices? Na weil ich gleichzeitig via USB-Kabel mit dem SheevaPlug verbunden bin, um via screen von meinem Debian-Laptop ein Terminal-Fenster hinein zu haben.)
2010-08-24 21:13:04 (rückgängig machen): (plomlompom):
31c31
- Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein paar mal Enter drücken. Dann aber sollte ich mittels "screen" einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet. Achtung: das USB-Kabel rutscht sehr leicht aus dem SheevaPlug raus, wenn's nicht funktioniert also besser mal nachgucken, ob's richtig drinne steckt.
+ Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein-zwei mal Enter drücken. Dann aber sollte ich mittels "screen" einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet. Achtung: das USB-Kabel rutscht sehr leicht aus dem SheevaPlug raus, wenn's nicht funktioniert also besser mal nachgucken, ob's richtig drinne steckt.
2010-08-24 21:12:01 (rückgängig machen): (plomlompom):
63a64,65
+ 
+ Ich ziehe also ein SheevaPlug-geeignetes Kernel-"uImage" auf meinen USB-Stick. Ein "uImage" ist in diesem Fall ein Linux-Kernel-Image, dem noch einige Zusatz-Daten rangepappt sind, die es u-Boot-freundlicher machen; "uboot-mkimage" wäre das Tool der Wahl, wenn man sich selber ein Linux-Kernel-Image solcherart u-Boot-kompatibel einpacken möchte. Ich nehme für den Anfang mal "sheeva-2.6.35.3-uImage", zu finden hier: http://sheeva.with-linux.com/sheeva/ Also rauf auf den USB-Stick damit und den USB-Stick in Sheevas Loch gestoßen!
2010-08-24 21:07:09 (rückgängig machen): (plomlompom):
46c46
- Aus irgendwelchen Gründen lies sich das Problem durch Verkleinerung der Partition lösen; mehr als ein paar MB musste die Partition ja nicht groß sein, um einzelne Dateien wie die uboot.bin zu transportieren. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x0800000 im Arbeitsspiecher geschrieben.
+ Aus irgendwelchen Gründen lies sich das Problem durch Verkleinerung der Partition und Verwendung von FAT16 lösen; mehr als ein paar MB musste die Partition ja nicht groß sein, um einzelne Dateien wie die uboot.bin zu transportieren. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x0800000 im Arbeitsspiecher geschrieben.
61a62,63
+ 
+ http://www.plugcomputer.org/plugwiki/index.php/Installing_Debian_To_Flash gibt einige brauchbare Hinweise und Beispiele zum Schreiben eines Kernels in den NAND-Flash des SheevaPlugs, setzt aber die Verwendung des "Trivial File Transfer Protocol" voraus, mit dem mich vertraut zu machen (oder für das gar einen Server auf meinem Debian-Laptop einzurichten) ich zu faul bin. Stattdessen setze ich auf die bereits beim Updaten des U-Boot-Bootloaders bewährte Methode, im Bootloader Dateien über einen FAT-USB-Stick einzulesen (nähere Details siehe "U-Boot-Bootloader updaten").
2010-08-24 20:50:44 (rückgängig machen): (plomlompom):
25c25
-  [237248.066200] usb 5-1: '''FTDI USB Serial Device converter now attached to ttyUSB0'''
+  [237248.066200] usb 5-1: FTDI USB Serial Device converter '''now attached to ttyUSB0'''
2010-08-24 20:50:21 (rückgängig machen): (plomlompom):
11c11
-  [237247.840070] usb 5-1: new full speed USB device using uhci_hcd and address 40
+  [237247.840070] usb 5-1: '''new full speed USB device''' using uhci_hcd and address 40
2010-08-24 20:50:05 (rückgängig machen): (plomlompom):
14c14
-  [237248.051124] usb 5-1: Product: SheevaPlug JTAGKey FT2232D B
+  [237248.051124] usb 5-1: Product: '''SheevaPlug''' JTAGKey FT2232D B
2010-08-24 20:48:01 (rückgängig machen): (plomlompom):
57a58,61
+ 
+ !! U-Boot einen Kernel zum Booten geben
+ 
+ In meinem Versuch, mein eigenes Linux auf den SheevaPlug aufzuspielen, bin ich noch nicht sehr weit gekommen. Was ich aber immerhin schonmal geschafft habe, ist, von U-Boot aus einen beliebigen Kernel zu booten; für sich keine sehr brauchbare Übung, so lange der Kernel kein Dateisystem zum Reinbooten hat. Aber für diesen ersten Schritt hier schonmal ein paar Hinweise:
2010-08-24 20:45:24 (rückgängig machen): (plomlompom):
31c31
- Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein paar mal Enter drücken. Dann aber sollte ich mittels "screen" einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet.
+ Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein paar mal Enter drücken. Dann aber sollte ich mittels "screen" einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet. Achtung: das USB-Kabel rutscht sehr leicht aus dem SheevaPlug raus, wenn's nicht funktioniert also besser mal nachgucken, ob's richtig drinne steckt.
2010-08-24 20:43:41 (rückgängig machen): (plomlompom):
53c53
- Nehmen wir das mal auseinander: "nand erase (lösche den Bereich ...) 0x0 (... der hier startet ...) 0xa0000 ( ...mit dieser Länge)"; "nand write (Bereich beschreiben:) 0x0800000 (das, was an dieser Arbeitsspeicheradresse liegt, soll ...) 0x0 (... beginnend dieser Stelle in den NAND-Speicher geschrieben werden, und zwar ...) 0xa0000 (... zu dieser Länge)". Danach dann ...
+ Nehmen wir das mal auseinander: "nand erase (lösche den Bereich ...) 0x0 (... der hier startet ...) 0xa0000 ( ...mit dieser Länge)"; "nand write (Bereich beschreiben: ...) 0x0800000 (... das, was an dieser Arbeitsspeicheradresse liegt, soll ...) 0x0 (... beginnend dieser Stelle in den NAND-Speicher geschrieben werden, und zwar ...) 0xa0000 (... zu dieser Länge)". Danach dann ...
2010-08-24 20:40:54 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen, allein durch Fehleranfälligkeit meinerseits, erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis rekonstruiert, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
+ Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Geringfügige Abweichungen meinerseits, allein durch Fehleranfälligkeit meinerseits, erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis rekonstruiert, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
2010-08-24 20:40:06 (rückgängig machen): (plomlompom):
41,42c41,42
-  usb start
-  fatload usb 0:1 0x0800000 uboot.bin
+  Marvell>> usb start
+  Marvell>> fatload usb 0:1 0x0800000 uboot.bin
50,51c50,51
-  nand erase 0x0 0xa0000
-  nand write 0x0800000 0x0 0xa0000
+  Marvell>> nand erase 0x0 0xa0000
+  Marvell>> nand write 0x0800000 0x0 0xa0000
55c55
-  reset
+  Marvell>> reset
2010-08-24 20:38:24 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen, primär durch Fehleranfälligkeit auf meiner Seite, erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
+ Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen, allein durch Fehleranfälligkeit meinerseits, erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis rekonstruiert, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
2010-08-24 20:36:32 (rückgängig machen): (plomlompom):
44c44
- Die erste Zeile zeitigte den gewünschten Erfolg, der USB-Stick wurde erkannt. Die zweite Zeile -- grob lesbar als "fatload (lade von einem FAT-Dateisystem) usb 0:1 (am USB-Interface soundso) 0x0800000 (auf Arbeitsspeicheradresse soundso) uboot.bin (diese Datei)" -- jedoch spuckte irgendeine Fehlermeldung aus. Nach viel Umhergooglen schälte sich der Verdacht heraus, das könnte an der FAT-Partition auf dem USB-Stick liegen. Offenbar hat U-Boot da irgendwelche Probleme mit den Partitionen, wie sie zumindest mein Debian bastelt, wenn ich "cfdisk" und "mkfs.vfat" anwende. 
+ Die erste Zeile zeitigte den gewünschten Erfolg, der USB-Stick wurde erkannt. Die zweite Zeile -- grob lesbar als "fatload (lade von einem FAT-Dateisystem ...) usb 0:1 (... am USB-Interface soundso ...) 0x0800000 (... auf Arbeitsspeicheradresse soundso ...) uboot.bin (... diese Datei)" -- jedoch spuckte irgendeine Fehlermeldung aus. Nach viel Umhergooglen schälte sich der Verdacht heraus, das könnte an der FAT-Partition auf dem USB-Stick liegen. Offenbar hat U-Boot da irgendwelche Probleme mit den Partitionen, wie sie zumindest mein Debian bastelt, wenn ich "cfdisk" und "mkfs.vfat" anwende. 
48c48
- Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs mit dem überschreibt, was im Arbeitsspeicher an Adresse 0x0800000 liegt. Hier scheint der Bootloader liegen zu müssen. Insofern kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
+ Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs überschreibt. Hier muss wohl der Bootloader liegen. Insofern kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
53c53
- Danach dann ...
+ Nehmen wir das mal auseinander: "nand erase (lösche den Bereich ...) 0x0 (... der hier startet ...) 0xa0000 ( ...mit dieser Länge)"; "nand write (Bereich beschreiben:) 0x0800000 (das, was an dieser Arbeitsspeicheradresse liegt, soll ...) 0x0 (... beginnend dieser Stelle in den NAND-Speicher geschrieben werden, und zwar ...) 0xa0000 (... zu dieser Länge)". Danach dann ...
2010-08-24 20:32:53 (rückgängig machen): (plomlompom):
46c46
- Aus irgendwelchen Gründen lies sich das Problem durch Verkleinerung der Partition lösen; mehr als ein paar MB musste die Partition ja nicht groß sein, um einzelne Dateien wie die uboot.bin zu transportieren. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x08000000 im Arbeitsspiecher geschrieben.
+ Aus irgendwelchen Gründen lies sich das Problem durch Verkleinerung der Partition lösen; mehr als ein paar MB musste die Partition ja nicht groß sein, um einzelne Dateien wie die uboot.bin zu transportieren. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x0800000 im Arbeitsspiecher geschrieben.
48c48
- Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs überschreibt. Da genau hier der Bootloader zu liegen scheint, kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
+ Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs mit dem überschreibt, was im Arbeitsspeicher an Adresse 0x0800000 liegt. Hier scheint der Bootloader liegen zu müssen. Insofern kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
2010-08-24 20:31:06 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
+ Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen, primär durch Fehleranfälligkeit auf meiner Seite, erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
2010-08-24 20:29:26 (rückgängig machen): (plomlompom):
37a38,57
+ 
+ Ich entschied mich unter den beiden von Michlmayer angebotenen Methoden für Installation via USB-Stick. Ein FAT-formatierter USB-Stick wurde verwandt, und ich glaubte mich in Besitz eines eben solchen, kopierte "uboot.bin" (gehen wir einfach mal davon aus, ich hätte es von Anfang an richtig benannt) drauf, rammte den USB-Stick danach in Sheevas Ritze und gab im U-Boot-Prompt korrekt Folgendes ein:
+ 
+  usb start
+  fatload usb 0:1 0x0800000 uboot.bin
+ 
+ Die erste Zeile zeitigte den gewünschten Erfolg, der USB-Stick wurde erkannt. Die zweite Zeile -- grob lesbar als "fatload (lade von einem FAT-Dateisystem) usb 0:1 (am USB-Interface soundso) 0x0800000 (auf Arbeitsspeicheradresse soundso) uboot.bin (diese Datei)" -- jedoch spuckte irgendeine Fehlermeldung aus. Nach viel Umhergooglen schälte sich der Verdacht heraus, das könnte an der FAT-Partition auf dem USB-Stick liegen. Offenbar hat U-Boot da irgendwelche Probleme mit den Partitionen, wie sie zumindest mein Debian bastelt, wenn ich "cfdisk" und "mkfs.vfat" anwende. 
+ 
+ Aus irgendwelchen Gründen lies sich das Problem durch Verkleinerung der Partition lösen; mehr als ein paar MB musste die Partition ja nicht groß sein, um einzelne Dateien wie die uboot.bin zu transportieren. Nach ein bisschen Rumprobieren und Rebooten des Bootloaders (der sich weigerte, einen einmal entfernten (und via "usb stop" hoffentlich sauber unmounteten?) USB-Stick im selben Boot nochmal neu zu erkennen) klappte es: uboot.bin wurde sichtlich auf Adresse 0x08000000 im Arbeitsspiecher geschrieben.
+ 
+ Der nächste Schritt scheint kritisch, insoweit er den Anfangsbereich des internen NAND-Flash-Speichers des SheevaPlugs überschreibt. Da genau hier der Bootloader zu liegen scheint, kann man sich vermutlich leicht in Teufels Küche bringen, wenn man hier etwas falsch macht, z.B. kein brauchbares Bootloader-Image reinschreibt:
+ 
+  nand erase 0x0 0xa0000
+  nand write 0x0800000 0x0 0xa0000
+ 
+ Danach dann ...
+ 
+  reset
+ 
+ ... und der U-Boot-Bootloader sollte in einer geupdateten Version neustarten.
2010-08-24 20:14:41 (rückgängig machen): (plomlompom):
29c29
-  $ screen /dev/ttyUSB0 115200   # 115200 ist die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
+  $ screen /dev/ttyUSB0 115200   # "115200" ist die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
2010-08-24 20:13:33 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich beinahe genau den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
+ Hierfür konnte ich beinahe genau den Anweisungen in Martin Michlmayers Gebrauchsanweisung unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
37c37
- Ich brauchte erstmal ein Binary für den neuen Bootloader. Ich wähnte mich zuerst besonders schnell und dachte mir, ich fände ein aktuelleres als das unter genannter URL verlinkte "U-Boot 3.4.27+pingtoo binary", aber das, was ich nach endlosem Umhersuchen in den PlugComputer-Foren stolz mein eigen nannte, stellte sich im Nachhinein als eben das gleiche heraus.
+ Ich brauchte erstmal ein Binary für den neuen Bootloader. Ich wähnte mich zuerst besonders schlau und dachte mir, ich fände ein aktuelleres als das von Michlmayer verlinkte "U-Boot 3.4.27+pingtoo binary", aber das, was ich nach endlosem Umhersuchen in den PlugComputer-Foren stolz mein eigen nannte, stellte sich im Nachhinein als eben das gleiche heraus. Der nächste Fehler, den ich machte, war, es im versuchten Befolgen von Michlmayers Anweisungen in Unachtsamkeit in "u-boot.bin" statt "uboot.bin" zu benennen, was später einige Verwirrung beim buchstabengetreuen Kopieren von Befehlen stiften würde; also nicht nochmal diesen meinen Fehler machen!
2010-08-24 20:09:23 (rückgängig machen): (plomlompom):
35a36,37
+ 
+ Ich brauchte erstmal ein Binary für den neuen Bootloader. Ich wähnte mich zuerst besonders schnell und dachte mir, ich fände ein aktuelleres als das unter genannter URL verlinkte "U-Boot 3.4.27+pingtoo binary", aber das, was ich nach endlosem Umhersuchen in den PlugComputer-Foren stolz mein eigen nannte, stellte sich im Nachhinein als eben das gleiche heraus.
2010-08-24 20:07:25 (rückgängig machen): (plomlompom):
3c3
- ! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
+ !! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
33c33
- ! U-Boot-Bootloader updaten
+ !! U-Boot-Bootloader updaten
2010-08-24 20:07:16 (rückgängig machen): (plomlompom):
3c3
- !! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
+ ! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
2010-08-24 20:07:05 (rückgängig machen): (plomlompom):
3c3
- !!! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
+ !! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
33c33
- !!! U-Boot-Bootloader updaten
+ ! U-Boot-Bootloader updaten
2010-08-24 20:06:56 (rückgängig machen): (plomlompom):
3c3
- '''Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):'''
+ !!! Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):
33c33
- '''U-Boot-Bootloader updaten'''
+ !!! U-Boot-Bootloader updaten
2010-08-24 20:06:33 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich beinahe genau den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen, die Abweichungen erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
+ Hierfür konnte ich beinahe genau den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen. Die geringfügigen Abweichungen erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
2010-08-24 20:06:21 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich beinahe genau den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen.
+ Hierfür konnte ich beinahe genau den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen, die Abweichungen erfordern aber doch nochmal einen Nachvollzug (aus dem Gedächtnis, ohne nochmaliges Durchprobieren, also nicht absolut verlässlich):
2010-08-24 20:05:36 (rückgängig machen): (plomlompom):
35c35
- Hierfür konnte ich präzise den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen.
+ Hierfür konnte ich beinahe genau den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen.
2010-08-24 20:04:33 (rückgängig machen): (plomlompom):
3c3
- '''Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot Bootloader hinein):'''
+ '''Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot-Bootloader hinein):'''
2010-08-24 20:03:42 (rückgängig machen): (plomlompom):
31a32,35
+ 
+ '''U-Boot-Bootloader updaten'''
+ 
+ Hierfür konnte ich präzise den Anweisungen unter http://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade.html folgen.
2010-08-24 20:01:59 (rückgängig machen): (plomlompom):
10d9
- 
12d10
- 
2010-08-24 20:01:31 (rückgängig machen): (plomlompom):
33c33
- Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein paar mal Enter drücken. Dann aber sollte ich einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet.
+ Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein paar mal Enter drücken. Dann aber sollte ich mittels "screen" einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet.
2010-08-24 20:01:04 (rückgängig machen): (plomlompom):
7c7
- Ich verbinde mein Laptop-Debian-Linux via USB-Kabel mit dem SheevaPlug. Mein Kernel erkennt diese neue Verbindung und leitet sie auf ein Device, das er "ttyUSB0" nennt (Hervorhebungen von mir):
+ Ich verbinde mein Laptop-Debian-Linux via USB-Kabel mit dem SheevaPlug. Meines Laptop-Debians Kernel erkennt diese neue Verbindung und leitet sie auf ein Device, das er "ttyUSB0" nennt (Hervorhebungen von mir):
2010-08-24 20:00:40 (rückgängig machen): (plomlompom):
5c5
- Mein SheevaPlug hat ja kein eigenes Ausgabegerät außer einem LED. Um mit ihm sinnvoll zu kommunizieren muss ich es mit einem Gerät verbinden, das eine Ausgabe wie zum Beispiel einen Bildschirm besitzt. Am einfachsten hierfür ist die "serielle" Verbindung.
+ Mein SheevaPlug hat ja kein eigenes Ausgabegerät außer einem LED. Um mit ihm sinnvoll zu kommunizieren muss ich es mit einem Gerät verbinden, das eine Ausgabe wie zum Beispiel einen Bildschirm und am Besten auch noch eine Eingabe wie eine Tastatur besitzt. Am einfachsten hierfür ist die "serielle" Verbindung.
2010-08-24 20:00:10 (rückgängig machen): (plomlompom):
5c5
- Mein SheevaPlug hat ja kein eigenes Ausgabegerät außer einem LED. Um ihm Informationen zu entlocken, muss ich mit einem anderen Gerät darauf zugreifen, das eine Ausgabe wie zum Beispiel einen Bildschirm besitzt. Am einfachsten hierfür ist die "serielle" Verbindung.
+ Mein SheevaPlug hat ja kein eigenes Ausgabegerät außer einem LED. Um mit ihm sinnvoll zu kommunizieren muss ich es mit einem Gerät verbinden, das eine Ausgabe wie zum Beispiel einen Bildschirm besitzt. Am einfachsten hierfür ist die "serielle" Verbindung.
2010-08-24 19:59:26 (rückgängig machen): (plomlompom):
9c9
-  $ dmesg              # Log der Kernel-Nachrichten ausgeben
+  $ dmesg                        # Log der Kernel-Nachrichten ausgeben
31c31
-  $ screen /dev/ttyUSB0 115200      # 115200 ist die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
+  $ screen /dev/ttyUSB0 115200   # 115200 ist die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
2010-08-24 19:58:59 (rückgängig machen): (plomlompom):
31c31
-  $ screen /dev/ttyUSB0 115200      # 115200 ist hierbei die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
+  $ screen /dev/ttyUSB0 115200      # 115200 ist die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
2010-08-24 19:58:48 (rückgängig machen): (plomlompom):
29c29
- Auf dieses Device kann ich im Dateisystem über ''/dev/ttyUSB0'' zugreifen. Ich setze das Programm "screen" darauf an. 115200 ist hierbei die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist:
+ Auf dieses Device kann ich im Dateisystem über ''/dev/ttyUSB0'' zugreifen. Ich setze das Programm "screen" darauf an:
31c31
-  $ screen /dev/ttyUSB0 115200
+  $ screen /dev/ttyUSB0 115200      # 115200 ist hierbei die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist
2010-08-24 19:57:52 (rückgängig machen): (plomlompom):
0a1,33
+ Notizen zu meinem Sheeva-Plug.
+ 
+ '''Serielle Verbindung zu meinem SheevaPlug (mindestens in den U-Boot Bootloader hinein):'''
+ 
+ Mein SheevaPlug hat ja kein eigenes Ausgabegerät außer einem LED. Um ihm Informationen zu entlocken, muss ich mit einem anderen Gerät darauf zugreifen, das eine Ausgabe wie zum Beispiel einen Bildschirm besitzt. Am einfachsten hierfür ist die "serielle" Verbindung.
+ 
+ Ich verbinde mein Laptop-Debian-Linux via USB-Kabel mit dem SheevaPlug. Mein Kernel erkennt diese neue Verbindung und leitet sie auf ein Device, das er "ttyUSB0" nennt (Hervorhebungen von mir):
+ 
+  $ dmesg              # Log der Kernel-Nachrichten ausgeben
+ 
+ (...)
+ 
+  [237247.840070] usb 5-1: new full speed USB device using uhci_hcd and address 40
+  [237248.051109] usb 5-1: New USB device found, idVendor=9e88, idProduct=9e8f
+  [237248.051118] usb 5-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
+  [237248.051124] usb 5-1: Product: SheevaPlug JTAGKey FT2232D B
+  [237248.051129] usb 5-1: Manufacturer: FTDI
+  [237248.051134] usb 5-1: SerialNumber: FTSJA9Q3
+  [237248.051332] usb 5-1: configuration #1 chosen from 1 choice
+  [237248.060243] usb 5-1: Ignoring serial port reserved for JTAG
+  [237248.065218] ftdi_sio 5-1:1.1: FTDI USB Serial Device converter detected
+  [237248.065270] usb 5-1: Detected FT2232C
+  [237248.065275] usb 5-1: Number of endpoints 2
+  [237248.065280] usb 5-1: Endpoint 1 MaxPacketSize 64
+  [237248.065285] usb 5-1: Endpoint 2 MaxPacketSize 64
+  [237248.065289] usb 5-1: Setting MaxPacketSize 64
+  [237248.066200] usb 5-1: '''FTDI USB Serial Device converter now attached to ttyUSB0'''
+ 
+ Auf dieses Device kann ich im Dateisystem über ''/dev/ttyUSB0'' zugreifen. Ich setze das Programm "screen" darauf an. 115200 ist hierbei die Baudrate / Zeichenschreibgeschwindigkeit, die per default beim Bootloader U-Boot eingestellt ist:
+ 
+  $ screen /dev/ttyUSB0 115200
+ 
+ Aus irgendwelchen Gründen gibt "screen" nicht sofort eine zufriedenstellende Ausgabe: Ich muss ein paar mal Enter drücken. Dann aber sollte ich einen Terminal zum SheevaPlug-Bootloader auf meinem Debian-Laptop stehen haben, und vermutlich auch zu dem, was danach unter diesem bootet.
PlomWiki-Engine lizensiert unter der AGPLv3. Quellcode verfügbar auf GitHub.