Handbook:MIPS/Blocks/Bootloader/de

arcload für Silicon Graphics Maschinen
wurde für Maschinen geschrieben die einen 64-Bit Kernel benötigen und deshalb nicht  verwenden können (welches nicht einfach als 64-Bit Binärdatei kompiliert werden kann). Es kommt auch mit Besonderheiten zurecht die entstehen, wenn man einen Kernel direkt aus dem Volume-Header lädt. Fahren wir mit der Installation fort:

Wenn das abgeschlossen ist, finden Sie die  Binärdatei in. Es gibt zwei Dateien:
 * : Die 32-Bit Binärdatei für Indy, Indigo2 (R4k), Challenge S und O2 Systeme
 * : Die 64-Bit Binärdatei für Octane/Octane2, Origin 200/2000 und Indigo2 Impact Systeme

Verwenden Sie  um die für das System geeignete Binärdatei in den Volume-Header zu installieren:

Für Indy/Indigo2/Challenge S/O2 Benutzer:

Für Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 Benutzer:

Verwenden Sie jetzt einfach  um zu prüfen, dass sie sich im Volume-Header befindet:

Die Datei hat eine C-ähnliche Syntax. Für vollständige Details wie man sie konfiguriert, schauen Sie sich bitte die arcload Seite im Linux/MIPS Wiki an. Die Kurzfassung: Definieren Sie mit Hilfe der  Variable eine Reihe von Optionen die beim Booten aktiviert und deaktiviert werden.

Beginnend mit arcload-0.5 können arc.cf und Kernel entweder im Volume-Header oder auf einer Partition gespeichert sein. Um diese neue Eigenschaft zu nutzen, können Sie die Dateien in der Partition ablegen (oder  wenn es keine extra Boot Partition gibt). arcload verwendet den Dateisystemtreiber-Code des beliebten grub Bootloader und unterstützt somit den gleichen Umfang an Dateisystemen.

CoLo installieren
Cobalt Server haben eine viel weniger leistungsfähige Firmware auf dem Chip installiert. Das Cobalt BOOTROM ist im Vergleich zum SGI PROM primitiv und weist eine Reihe erheblicher Limitierungen auf.
 * Es besteht eine (ungefähr) 675 KB Größenlimitierung des Kernels. Die aktuelle Größe von Linux 2.4 macht es nahezu unmöglich einen Kernel dieser Größe zu erzeugen. Linux 2.6 und 3.x stehen vollkommen außer Frage.
 * 64-Bit Kernel werden von der Original-Firmware nicht unterstützt (obwohl diese momentan sehr experimentell auf Cobalt Maschinen sind)
 * Die Shell ist im günstigsten Fall rudimentär

Um diese Limitierungen zu überwinden wurde eine alternative Firmware genannt CoLo (Cobalt Loader) entwickelt. Dies ist ein BOOTROM Abbild das entweder auf den Chip im Cobalt Server geflasht, oder von der existierenden Firmware geladen werden kann.

Lassen Sie uns mit der Installation von CoLo weitermachen. Zuerst n Sie das Paket.

Nach der Installation werfen Sie einen Blick in das Verzeichnis. Hier liegen die folgenden zwei Dateien:
 * (der "Kernel" der von der Original-Firmware geladen wird)
 * (ein ROM Abbild zum Flashen auf das BOOTROM)

Wir beginnen mit dem Mounten von und dem Ablegen einer komprimierten Kopie von  in, wo das System es erwartet.

CoLo konfigurieren
Wenn das System bootet wird es CoLo laden, welches ein Menü auf dem LCD ausspuckt. Die erste Option (und die Voreinstellung, die nach ca. 5 Sekunden übernommen wird) ist das Booten von der Festplatte. Das System versucht dann die erste Linux Partition die es findet zu mounten und anschließend das Script zu starten. Die Syntax ist vollständig in der CoLo Dokumentation beschrieben (werfen Sie einen Blick auf -- wobei X.YY die installierte Versionsnummer ist) und sehr einfach.

Es ist ebenfalls möglich eine Farge nach dem zu bootenden Kernel und der Konfiguration mit einem Standard-Timeout zu stellen. Die nachfolgende Konfiguration tut genau dies: Die fragt den Benutzer welchen Kernel er verwenden möchte und führt das ausgewählte Abbild aus. und können entweder die eigentlichen Kernel-Abbilder, oder lediglich symbolische Links die auf Kernel-Abbilder auf dieser Festplatte verweisen sein. Das Argument  von   gibt an, dass mit der ersten Option ("Working") nach 50/10 Sekunden fortgefahren werden soll.

Für mehr Informationen sehen Sie sich bitte die Dokumentation unter an.

Serielle Konsole einrichten
Die Linux Installation so wie sie jetzt ist würde booten aber voraussetzen, dass der Benutzer an einem physischen Terminal eingeloggt ist. Auf Cobalt Maschinen ist das besonders schlecht -- es gibt so etwas wie ein physisches Terminal nicht.

Öffnen Sie als erstes die Datei mit einem Editor. Etwas weiter unten in der Datei betrachten Sie folgendes:

Entfernen Sie das Kommentarzeichen ("#") der Zeile. Als Standard ist sie darauf eingestellt eine Terminal-Baudrate von 9600 bps zu nutzen. Auf Cobalt Servern kann dies auf 115200 bps eingestellt werden, um der Baudrate die vom BOOT ROM festgesetzt ist zu entsprechen. Das folgende Listing zeigt wie der Abschnitt anschließend aussieht. Auf Bildschirmlosen Systemen (z.B. Cobalt Servern) empfehlen wir ebenfalls die Zeilen der lokalen Terminals ( bis  ) auszukommentieren, da diese die Angewohnheit haben sich schlecht zu verhalten, wenn sie  nicht öffnen können.

Nun müssen wir dem System mitteilen, dass dem lokalen seriellen Anschluss als sicherem Terminal vertraut werden kann. Die Datei die wir dazu ändern müssen ist. Sie enthält eine Liste von Terminals denen das System vertraut. Wir fügen einfach zwei weitere Zeilen hinzu, die der seriellen Verbindung Root-Logins gestatten.

Lately, Linux also calls this /dev/tts/0 -- so we add this too:

Setting generic PROM settings
With the bootloader installed, after rebooting (which we will come to in a second), go to the System Maintenance Menu and select Command Monitor (5) like did initially when netbooting the system.

Menu after boot

Provide the location of the Volume Header:

Automatically boot Gentoo:

Set the timezone:

Use the serial console - graphic adapter users should have "g" instead of "d1" (one):

Set the serial console baud rate. This is optional, 9600 is the default setting, although one may use rates up to 38400 if that is desired:

Now, the next settings depend on how the system is booted.

Settings for direct volume-header booting
Set the root device to Gentoo's root partition, such as :

To list the available kernels, type "ls".

Declare the kernel parameters to pass:

To try a kernel without messing with kernel parameters, use the boot -f PROM command:

Settings for arcload
arcload uses the OSLoadFilename option to specify which options to set from. The configuration file is essentially a script, with the top-level blocks defining boot images for different systems, and inside that, optional settings. Thus, setting OSLoadFilename=mysys(serial) pulls in the settings for the mysys block, then sets further options overridden in serial.

In the example file above, we have one system block defined, ip28 with working, new and debug options available. We define our PROM variables as so:

Select arcload as the bootloader:- sash64 or sashARCS:

Use the "working" kernel image, defined in "ip28" section of arc.cf:

Starting with arcload-0.5, files no longer need to be placed in the volume header -- they may be placed in a partition instead. To tell arcload where to look for its configuration file and kernels, one must set the OSLoadPartition PROM variable. The exact value here will depend on where the disk resides on the SCSI bus. Use the SystemPartition PROM variable as a guide -- only the partition number should need to change.

To load from the volume header -- use partition 8:

Otherwise, specify the partition and filesystem type: