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.

It is also possible to ask a question, such as which kernel & configuration to boot, with a default timeout. The following configuration does exactly this, asks the user which kernel they wish to use, and executes the chosen image. vmlinux.gz.new and vmlinux.gz.working may be actual kernel images, or just symlinks pointing to the kernel images on that disk. The 50 argument to select specifies that it should proceed with the first option ("Working") after 50/10 seconds.

See the documentation in for more details.

Setting up for serial console
Okay, the Linux installation as it stands now, would boot fine, but assumes the user will be logged in at a physical terminal. On Cobalt machines, this is particularly bad -- there's no such thing as a physical terminal.

First, pull up an editor and hack away at. Further down in the file, notice the following:

First, uncomment the c0 line. By default, it's set to use a terminal baud rate of 9600 bps. On Cobalt servers, this may be changed to 115200 to match the baud rate decided by the BOOT ROM. The following is how that section looks then. On a headless machine (e.g. Cobalt servers), we also recommend commenting out the local terminal lines (c1 through to c6) as these have a habit of misbehaving when they can't open.

Now, lastly... we have to tell the system, that the local serial port can be trusted as a secure terminal. The file we need to poke at is. It contains a list of terminals that the system trusts. We simply stick in two more lines, permitting the serial line to be used for root logins.

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: