/[gentoo]/xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml
Gentoo

Contents of /xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.14 - (show annotations) (download) (as text)
Tue Mar 14 19:29:29 2006 UTC (8 years, 7 months ago) by neysx
Branch: MAIN
Changes since 1.13: +2 -2 lines
File MIME type: application/xml
#126195 bump license version in comment, **no content change**

1 <?xml version='1.0' encoding='UTF-8'?>
2 <!DOCTYPE sections SYSTEM "/dtd/book.dtd">
3
4 <!-- The content of this document is licensed under the CC-BY-SA license -->
5 <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
6
7 <!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-install-mips-bootloader.xml,v 1.13 2006/02/27 00:55:34 fox2mike Exp $ -->
8
9 <sections>
10
11 <version>1.10</version>
12 <date>2006-02-27</date>
13
14 <section id="sgi">
15 <title>Silicon Graphics Machines -- Setting Up arcboot/arcload</title>
16 <subsection>
17 <title>Which one?</title>
18 <body>
19
20 <p>
21 On SGI machines, you have two options for bootloaders. <c>arcboot</c> and
22 <c>arcload</c>. The table below lists the pros and cons for each bootloader.
23 </p>
24
25 <table>
26 <tr>
27 <th> </th>
28 <th>arcboot</th>
29 </tr>
30 <tr>
31 <th>+</th>
32 <ti>
33 It can load off EXT2 and EXT3 partitions, so no need to store them in the
34 volume header
35 </ti>
36 </tr>
37 <tr>
38 <th>-</th>
39 <ti>
40 It doesn't work on Octane/Octane2, Origin 200/2000 or
41 Indigo2 Impact (R10000)
42 </ti>
43 </tr>
44 </table>
45
46 <table>
47 <tr>
48 <th> </th>
49 <th>arcload</th>
50 </tr>
51 <tr>
52 <th>+</th>
53 <ti>
54 It boots ALL Linux-compatable SGI systems
55 </ti>
56 </tr>
57 <tr>
58 <th>-</th>
59 <ti>
60 Currently, It cannot read EXT2/EXT3 partitions, and so needs the kernels
61 and config file to be placed in the volume header
62 </ti>
63 </tr>
64 </table>
65
66 <note>
67 The SGI volume header filenames are limited to 8 characters, and there may be no
68 more than 16 files contained in a single volume header.
69 </note>
70
71 </body>
72 </subsection>
73
74 <subsection>
75 <title>Installing arcboot</title>
76 <body>
77
78 <p>
79 Previously in this guide, we showed you how to make a kernel, then copy it to
80 the volume header using <c>dvhtool</c>. There were two main flaws with this
81 system:
82 </p>
83
84 <ul>
85 <li>This is not supported on all SGI systems</li>
86 <li>It requires a significantly larger volume header</li>
87 </ul>
88
89 <p>
90 In order to boot the machine, a bootloader, <c>arcboot</c> was developed for
91 this purpose. Instead of putting the kernel directly into the volume header, we
92 leave it in <path>/boot</path> (which resides on a EXT2/3 partition), and tell
93 <c>arcboot</c> (which sits in the volume header in place of the kernel) where to
94 find it. So our first step, is to emerge some tools that we'll use later...
95 </p>
96
97 <pre caption="Installing the required tools">
98 # <i>emerge dvhtool arcboot</i>
99 </pre>
100
101 <p>
102 That should have installed two tools, <c>arcboot</c> which sits in the volume
103 header and loads kernels for us, and <c>dvhtool</c> which helps us put
104 <c>arcboot</c> into the volume header.
105 </p>
106
107 <p>
108 The <c>arcboot</c> binary lurks in <path>/usr/lib/arcboot</path>. The name of
109 the binary depends on the machine it's compiled for.
110 </p>
111
112 <ul>
113 <li>
114 <c>arcboot.ip22</c>: The binary for Indy, Indigo2 (R4k) and Challenge S
115 systems
116 </li>
117 <li>
118 <c>arcboot.ip32</c>: The binary for O2 systems
119 </li>
120 </ul>
121
122 <pre caption="Installing arcboot into the volume header">
123 # <i>dvhtool --unix-to-vh /usr/lib/arcboot/arcboot.ip?? arcboot</i>
124 </pre>
125
126 <p>
127 We then verify the presence of the file in the volume header.
128 </p>
129
130 <pre caption="Checking if arcboot made it okay">
131 # <i>dvhtool --print-volume-directory</i>
132 ----- directory entries -----
133 Entry #0, name "linux", start 4, bytes 3262570
134 Entry #1, name "newlinux", start 6377, bytes 7619627
135 Entry #3, name "arcboot", start 21260, bytes 51448
136 #
137 </pre>
138
139 <note>
140 You'll notice that in the example above, there are two old kernels sitting
141 around, <path>linux</path> and <path>newlinux</path>. This is a hangover from
142 before we started using <c>arcboot</c>. Their presence doesn't matter -- just
143 so long as <c>arcboot</c> is present, everything is fine.
144 </note>
145
146 <p>
147 If you've ever set up the Linux Loader (<c>lilo</c>) before, you'll find that
148 <c>arcboot</c> employs a similar syntax in its configuration file. Bear in mind
149 though; <c>arcboot</c> expects to find its configuration file existing on an
150 EXT2/3 partition as <path>/etc/arcboot.conf</path>. The easiest way around this
151 is to make sure <path>/boot</path> is an EXT2/3 partition and that there's a
152 file called <path>arcboot.conf</path> inside the <path>/boot/etc</path>
153 directory. An example config can be found in
154 <path>/etc/arcboot.conf.sample</path>.
155 </p>
156
157 <note>
158 Adjust the paths accordingly if you
159 don't have a separate <path>/boot</path> partition.
160 </note>
161
162 <pre caption="Putting arcboot.conf in its place">
163 <comment>(Create the /boot/etc directory)</comment>
164 # <i>mkdir /boot/etc</i>
165
166 <comment>(Put our configuration into the target directory)</comment>
167 # <i>cp /etc/arcboot.conf.sample /boot/etc/arcboot.conf</i>
168
169 <comment>(Create a symlink back to /etc)</comment>
170 # <i>ln -s /boot/etc/arcboot.conf /etc/arcboot.conf</i>
171
172 <comment>(... and a symlink in /boot pointing to itself)</comment>
173 # <i>(cd /boot; ln -s . boot)</i>
174 </pre>
175
176 <p>
177 You can then edit <path>/etc/arcboot.conf</path> to your own preference.
178 One possible layout, is to set up two kernel images: <path>new</path>, a
179 freshly built image that may or may not work; and <path>working</path>, a
180 proven trustworthy kernel image. The <path>arcboot.conf</path> for that
181 setup looks a bit like this.
182 </p>
183
184 <pre caption="Example arcboot.conf">
185 <comment># arcboot.conf</comment>
186 <comment>#</comment>
187 <comment># copyright 2002 Guido Guenther &lt;agx@sigxcpu.org&gt;</comment>
188 <comment>#</comment>
189 <comment># known working version</comment>
190 label=working
191 image=/vmlinux
192 append="root=/dev/sda3"
193
194 <comment># fresh "untested" version</comment>
195 label=new
196 image=/vmlinux-new
197 append="root=/dev/sda3"
198 </pre>
199
200 <p>
201 Once that is set up, there's then just some little tweaks that you need to do
202 within the SGI PROM to make this magic work. This is covered in, not the next
203 section (that's for Cobalt servers) but the following section
204 <uri link="#reboot">Rebooting the System</uri>.
205 </p>
206
207 </body>
208 </subsection>
209
210 <subsection>
211 <title>Installing arcload</title>
212 <body>
213
214 <p>
215 <c>arcload</c> was written for machines that require 64-bit kernels, and
216 therefore can't use <c>arcboot</c> (which can't easily be compiled as a 64-bit
217 binary). It also works around peculiarities that arise when loading kernels
218 directly from the volume header. So, now you know what this is about, we
219 can proceed with the installation:
220 </p>
221
222 <pre caption="Merging arcload and dvhtool">
223 # <i>emerge arcload dvhtool</i>
224 </pre>
225
226 <p>
227 Once this has finished, you should find the <c>arcload</c> binary in
228 <path>/usr/lib/arcload</path>. Now, two files exist:
229 </p>
230
231 <ul>
232 <li>
233 <c>sashARCS</c>: The 32-bit binary for Indy, Indigo2 (R4k), Challenge S
234 and O2 systems
235 </li>
236 <li>
237 <c>sash64</c>: The 64-bit binary for Octane/Octane2, Origin 200/2000 and
238 Indigo2 Impact systems
239 </li>
240 </ul>
241
242 <p>
243 Use <c>dvhtool</c> to install the appropriate binary for your system into the
244 volume header:
245 </p>
246
247 <pre caption="Placing arcload in the volume header">
248 <comment>(Indy/Indigo2/Challenge S/O2 users)</comment>
249 # <i>dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS</i>
250
251 <comment>(Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000 users)</comment>
252 # <i>dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64</i>
253 </pre>
254
255 <note>
256 You don't have to use the name <c>sashARCS</c> or <c>sash64</c>, unless you are
257 installing to the volume header of a bootable CD. For normal boot from
258 hard-disk, you may name them something else if you wish.
259 </note>
260
261 <p>
262 Now just use <c>dvhtool</c> to verify they are in the volume header.
263 </p>
264
265 <pre caption="Checking arcload is present in the volume header">
266 # <i>dvhtool --print-volume-directory</i>
267 ----- directory entries -----
268 Entry #0, name "sash64", start 4, bytes 55859
269 #
270 </pre>
271
272 <p>
273 Now, the <c>arc.cf</c> file has a C-like syntax. For the full detail on how
274 one configures it, see the <uri
275 link="http://www.linux-mips.org/wiki/Arcload">arcload page on the
276 Linux/MIPS wiki</uri>. In short, you define a number of options, which you
277 enable and disable at boot time using the <c>OSLoadFilename</c> variable.
278 </p>
279
280 <pre caption="An example arc.cf">
281 <comment># ARCLoad Configuration</comment>
282
283 <comment># Some default settings...</comment>
284 append "root=/dev/sda3";
285 append "ro";
286 append "console=ttyS0,9600";
287
288 <comment># Our main definition. ip28 may be changed if you wish.</comment>
289 ip28 {
290 <comment># Definition for a "working" kernel</comment>
291 <comment># Select this by setting OSLoadFilename="ip28(working)"</comment>
292 working {
293 description "SGI Indigo2 Impact R10000\n\r";
294 image system "/working";
295 }
296
297 <comment># Definition for a "new" kernel</comment>
298 <comment># Select this by setting OSLoadFilename="ip28(new)"</comment>
299 new {
300 description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
301 image system "/new";
302 }
303
304 <comment># For debugging a kernel</comment>
305 <comment># Select this by setting OSLoadFilename="ip28(working,debug)"</comment>
306 <comment># or OSLoadFilename="ip28(new,debug)"</comment>
307 debug {
308 description "Debug console";
309 append "init=/bin/bash";
310 }
311 }
312 </pre>
313
314 <p>
315 This is then placed in the volume header with <c>sash64</c> (or
316 <c>sashARCS</c>) as shown below. Kernels also get placed in the volume header.
317 </p>
318
319 <pre caption="Placing arc.cf and kernel in the volume header">
320 # <i>dvhtool --unix-to-vh arc.cf arc.cf</i>
321 # <i>dvhtool --unix-to-vh /usr/src/linux/vmlinux new</i>
322 </pre>
323
324 <p>
325 With this done, now all that's left is to set some options in the PROM. See the
326 section on <uri link="#reboot">Rebooting the System</uri>.
327 </p>
328
329 </body>
330 </subsection>
331
332 </section>
333
334 <section id="cobalt">
335 <title>Cobalt MicroServers -- Setting Up CoLo</title>
336 <subsection>
337 <title>Installing CoLo</title>
338 <body>
339
340 <p>
341 On Cobalt servers, these machines have a much less capable firmware installed on
342 chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and has a
343 number of serious limitations.
344 </p>
345
346 <ul>
347 <li>
348 There's a 675kB (approximate) limit on kernels. The current size of Linux
349 2.4 makes it damn near impossible to make a kernel this size. Linux 2.6 is
350 totally out of the question.
351 </li>
352 <li>
353 64-bit kernels are not supported by the stock firmware (although these are
354 highly experimental on Cobalt machines at this time)
355 </li>
356 <li>
357 The shell is basic at best
358 </li>
359 </ul>
360
361 <p>
362 To overcome these limitations, an alternative firmware, called
363 <uri link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> (Cobalt
364 Loader) was developed. This is a BOOTROM image that can either be flashed into
365 the chip inside the Cobalt server, or loaded from the existing firmware.
366 </p>
367
368 <note>
369 This guide will take you through setting up CoLo so that it is loaded by the
370 stock firmware. This is the only truly safe, and recommended way to set up CoLo.
371 </note>
372
373 <warn>
374 You may, if you wish, flash it into the server, and totally
375 replace the original firmware -- however, you are entirely on your own in that
376 endeavour. Should anything go wrong, you will need to physically remove the
377 BOOTROM and reprogram it yourself with the stock firmware. If you are not
378 sure how to do this -- then <e>DO NOT</e> flash your machine. We take no
379 responsibility for whatever happens if you ignore this advice.
380 </warn>
381
382 <p>
383 Okay, with the warnings over now, we'll get on with installing CoLo. First,
384 start by emerging the package.
385 </p>
386
387 <pre caption="Emerging colo">
388 # <i>emerge colo</i>
389 </pre>
390
391 <p>
392 With that installed (I hope you read those messages ;-) you should be able to
393 look inside the <path>/usr/lib/colo</path> directory to find two files,
394 <path>colo-chain.elf</path>: the "kernel" for the stock firmware to load, and
395 <path>colo-rom-image.bin</path>: a ROM image for flashing into the BOOTROM. We
396 start by mounting /boot and dumping a compressed copy of
397 <path>colo-chain.elf</path> in <path>/boot</path> where the system expects it.
398 </p>
399
400 <pre caption="Putting CoLo in its place">
401 # <i>gzip -9vc /usr/lib/colo/colo-chain.elf &gt; /boot/vmlinux.gz</i>
402 </pre>
403
404 </body>
405 </subsection>
406
407 <subsection>
408 <title>Configuring CoLo</title>
409
410 <body>
411
412 <p>
413 Now, when the system first boots up, it'll load CoLo which will spit up a menu
414 on the back LCD. The first option (and default that is assumed after roughly 5
415 seconds) is to boot to the hard disk. The system would then attempt to mount
416 the first Linux partition it finds, and run the script
417 <path>default.colo</path>. The syntax is fully documented in the CoLo
418 documentation (have a peek at
419 <path>/usr/share/doc/colo-X.YY/README.shell.gz</path> -- where X.YY is the
420 version installed), and is very simple.
421 </p>
422
423 <note>
424 Just a tip: when installing kernels, I usually create two kernel images,
425 <path>kernel.gz.working</path> -- a known working kernel, and
426 <path>kernel.gz.new</path> -- a kernel that's just been compiled. You can either
427 use symlinks to point to the curent "new" and "working" kernels, or just rename
428 the kernel images.
429 </note>
430
431 <pre caption="A basic default.colo">
432 <comment>#:CoLo:#</comment>
433 mount hda1
434 load /kernel.gz.working
435 execute root=/dev/hda3 ro console=ttyS0,115200
436 </pre>
437
438 <note>
439 CoLo will refuse to load a script that does not begin with the <c>#:CoLo:#</c>
440 line. Think of it as the equivalent of saying <c>#!/bin/sh</c> in shell
441 scripts.
442 </note>
443
444 <p>
445 It is also possible to ask a question, such as which kernel &amp; configuration
446 you'd like to boot, with a default timeout. This configuration does exactly
447 this, asks the user which kernel they wish to use, and executes the chosen
448 image. <path>vmlinux.gz.new</path> and <path>vmlinux.gz.working</path> may be
449 actual kernel images, or just symlinks pointing to the kernel images on that
450 disk. The <c>50</c> argument to <c>select</c> specifies that it should proceed
451 with the first option ("Working") after 50/10 seconds.
452 </p>
453
454 <pre caption="Menu-based configuration">
455 <comment>#:CoLo:#</comment>
456
457 lcd "Mounting hda1"
458 mount hda1
459 select "Which Kernel?" 50 Working New
460
461 goto {menu-option}
462 var image-name vmlinux.gz.working
463 goto 3f
464 @var image-name vmlinux.gz.working
465 goto 2f
466 @var image-name vmlinux.gz.new
467
468 @lcd "Loading Linux" {image-name}
469 load /{image-name}
470 lcd "Booting..."
471 execute root=/dev/hda5 ro console=ttyS0,115200
472 boot
473 </pre>
474
475 <p>
476 See the documentation in <path>/usr/share/doc/colo-VERSION</path> for more
477 details.
478 </p>
479
480 </body>
481
482 </subsection>
483 </section>
484
485 <section>
486 <title>Setting up for Serial Console</title>
487
488 <subsection>
489 <body>
490
491 <p>
492 Okay, the Linux installation as it stands now, would boot fine, but assumes
493 you're going to be logged in at a physical terminal. On Cobalt machines, this
494 is particularly bad -- there's no such thing as a physical terminal.
495 </p>
496
497 <note>
498 Those who do have the luxury of a supported video chipset may skip this section if
499 they wish.
500 </note>
501
502 <p>
503 First, pull up an editor and hack away at <path>/etc/inittab</path>. Further
504 down in the file, you'll see something like this:
505 </p>
506
507 <pre caption="inittab Configuration">
508 <comment># SERIAL CONSOLE</comment>
509 <comment>#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102</comment>
510
511 <comment># TERMINALS</comment>
512 c1:12345:respawn:/sbin/agetty 38400 tty1 linux
513 c2:12345:respawn:/sbin/agetty 38400 tty2 linux
514 c3:12345:respawn:/sbin/agetty 38400 tty3 linux
515 c4:12345:respawn:/sbin/agetty 38400 tty4 linux
516 c5:12345:respawn:/sbin/agetty 38400 tty5 linux
517 c6:12345:respawn:/sbin/agetty 38400 tty6 linux
518
519 <comment># What to do at the "Three Finger Salute".</comment>
520 ca:12345:ctrlaltdel:/sbin/shutdown -r now
521 </pre>
522
523 <p>
524 First, uncomment the <c>c0</c> line. By default, it's set to use a terminal
525 baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200
526 to match the baud rate decided by the BOOT ROM. This is how that section looks
527 on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend
528 commenting out the local terminal lines (<c>c1</c> through to <c>c6</c>)
529 as these have a habit of misbehaving when they can't open
530 <path>/dev/ttyX</path>.
531 </p>
532
533 <pre caption="Example snippet from inittab">
534 <comment># SERIAL CONSOLE</comment>
535 c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102
536
537 <comment># TERMINALS -- These are useless on a headless qube</comment>
538 <comment>#c1:12345:respawn:/sbin/agetty 38400 tty1 linux</comment>
539 <comment>#c2:12345:respawn:/sbin/agetty 38400 tty2 linux</comment>
540 <comment>#c3:12345:respawn:/sbin/agetty 38400 tty3 linux</comment>
541 <comment>#c4:12345:respawn:/sbin/agetty 38400 tty4 linux</comment>
542 <comment>#c5:12345:respawn:/sbin/agetty 38400 tty5 linux</comment>
543 <comment>#c6:12345:respawn:/sbin/agetty 38400 tty6 linux</comment>
544 </pre>
545
546 <p>
547 Now, lastly... we have to tell the system, that the local serial port can be
548 trusted as a secure terminal. The file we need to poke at is
549 <path>/etc/securetty</path>. It contains a list of terminals that the system
550 trusts. We simply stick in two more lines, permitting the serial line to be
551 used for <c>root</c> logins.
552 </p>
553
554 <pre caption="Enabling root logins on serial console">
555 <comment>(/dev/ttyS0 -- the traditional name for the first serial port)</comment>
556 # <i>echo 'ttyS0' >> /etc/securetty</i>
557
558 <comment>(Lately, Linux also calls this /dev/tts/0 -- so we add this
559 too)</comment>
560 # <i>echo 'tts/0' >> /etc/securetty</i>
561 </pre>
562
563 </body>
564 </subsection>
565 </section>
566
567 <section id="reboot">
568 <title>Rebooting the System</title>
569 <subsection>
570 <body>
571
572 <p>
573 Exit the chrooted environment and unmount all mounted partitions. Then type in
574 that one magical command you have been waiting for: <c>reboot</c>.
575 </p>
576
577 <pre caption="Exiting the chroot, unmounting all partitions and rebooting">
578 # <i>exit</i>
579 cdimage ~# <i>cd</i>
580 cdimage ~# <i>umount /mnt/gentoo/boot /mnt/gentoo/dev /mnt/gentoo/proc /mnt/gentoo</i>
581 cdimage ~# <i>reboot</i>
582 </pre>
583
584 <note>
585 <e>Cobalt Users:</e> The rest of this section covers the setting up of the SGI
586 PROM so that it boots <c>arcboot</c>/<c>arcload</c> off disk and loads Linux.
587 This is not applicable to the setup of Cobalt servers. In fact, all your work
588 is done -- there is no configuration needed for the first boot up, you can skip
589 to the next section: <uri link="?part=1&amp;chap=11">Finalising your Gentoo
590 Installation</uri>
591 </note>
592
593 </body>
594 </subsection>
595 </section>
596 <section>
597 <title>Tweaking the SGI PROM</title>
598 <subsection>
599 <title>Setting generic PROM settings</title>
600 <body>
601
602 <p>
603 Now that you've installed the bootloader, you're ready to reboot the machine.
604 </p>
605
606 <pre caption="Rebooting">
607 <comment>(Exit the chroot environment)</comment>
608 # <i>exit</i>
609
610 <comment>(Unmount the drives)</comment>
611 # <i>umount /gentoo/boot</i>
612 # <i>umount /gentoo</i>
613
614 <comment>(Reboot)</comment>
615 # <i>reboot</i>
616 </pre>
617
618 <p>
619 When you are rebooted, go to the <e>System Maintenance Menu</e> and select
620 <e>Enter Command Monitor</e> (<c>5</c>) like you did when you netbooted the
621 machine.
622 </p>
623
624 <pre caption="Configuring the PROM to Boot Gentoo">
625 1) Start System
626 2) Install System Software
627 3) Run Diagnostics
628 4) Recover System
629 5) Enter Command Monitor
630
631 Option? <i>5</i>
632 Command Monitor. Type "exit" to return to the menu.
633
634 <comment>(Set some options which are common for both arcload and arcboot)</comment>
635
636 <comment>(Provide the location of the Volume Header)</comment>
637 &gt;&gt; <i>setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)</i>
638
639 <comment>(Automatically boot Gentoo)</comment>
640 &gt;&gt; <i>setenv AutoLoad Yes</i>
641
642 <comment>(Set the timezone)</comment>
643 &gt;&gt; <i>setenv TimeZone EST5EDT</i>
644
645 <comment>(Use the serial console - graphic adapter users should have "g" instead of "d1" (one))</comment>
646 &gt;&gt; <i>setenv console d1</i>
647
648 <comment>(Setting the serial console baud rate. This is optional, 9600 is the )
649 (default setting, although one may use rates up to 38400 if that is desired. )</comment>
650 &gt;&gt; <i>setenv dbaud 9600</i>
651 </pre>
652
653 <p>
654 Now, the next settings depend on how you are booting the system.
655 </p>
656
657 </body>
658 </subsection>
659
660 <subsection>
661 <title>Settings for direct volume-header booting</title>
662 <body>
663
664 <p>
665 This is covered here for completeness. It's recommended that users look into
666 installing <c>arcboot</c> or <c>arcload</c> instead.
667 </p>
668
669 <note>
670 This only works on the Indy, Indigo2 (R4k) and Challenge S.
671 </note>
672
673 <pre caption="PROM settings for booting off the volume header">
674 <comment>(&lt;root device&gt; = Gentoo's root partition, e.g. /dev/sda3)</comment>
675 &gt;&gt; <i>setenv OSLoadPartition &lt;root device&gt;</i>
676
677 <comment>(To list the available kernels, type "ls")</comment>
678 &gt;&gt; <i>setenv OSLoader &lt;kernel name&gt;</i>
679 &gt;&gt; <i>setenv OSLoadFilename &lt;kernel name&gt;</i>
680
681 <comment>(Declare the kernel parameters you want to pass)</comment>
682 &gt;&gt; <i>setenv OSLoadOptions &lt;kernel parameters&gt;</i>
683 </pre>
684
685 <p>
686 If you wish to try a kernel without messing with kernel parameters, you may do
687 so using the <c>boot -f</c> PROM command:
688 </p>
689
690 <pre caption="Booting without changing environment variables">
691 <comment>(Booting a kernel, "new", with additional options)</comment>
692 # <i>boot -f new root=/dev/sda3 ro</i>
693 </pre>
694
695 </body>
696 </subsection>
697
698 <subsection>
699 <title>Settings for arcload</title>
700 <body>
701
702 <p>
703 <c>arcload</c> uses the <c>OSLoadFilename</c> option to specify which options to
704 set from <path>arc.cf</path>. The configuration file is essentially a script,
705 with the top-level blocks defining boot images for different systems, and inside
706 that, optional settings. Thus, setting <c>OSLoadFilename=mysys(serial)</c>
707 pulls in the settings for the <c>mysys</c> block, then sets further options
708 overridden in <c>serial</c>.
709 </p>
710
711 <p>
712 In the example file above, we have one system block defined, <c>ip28</c> with
713 <c>working</c>, <c>new</c> and <c>debug</c> options available. We define our
714 PROM variables as so:
715 </p>
716
717 <pre caption="PROM settings for using arcload">
718 <comment>(Select arcload as the bootloader:- sash64 or sashARCS)</comment>
719 &gt;&gt; setenv OSLoader sash64
720
721 <comment>(Use the "working" kernel image, defined in "ip28" section of arc.cf)</comment>
722 &gt;&gt; setenv OSLoadFilename ip28(working)
723 </pre>
724
725 </body>
726 </subsection>
727
728 <subsection>
729 <title>Settings for arcboot</title>
730 <body>
731
732 <p>
733 <c>arcboot</c> loads its configuration file and kernels from your
734 <path>/boot</path> partition, which needs to be formatted either EXT2 or EXT3.
735 Thus <c>OSLoadPartition</c> needs to point to that partition. <c>OSLoader</c>
736 should point to the <c>arcboot</c> binary in the volume header, and
737 <c>OSLoadFilename</c> is the image name being used.
738 </p>
739
740 <pre caption="PROM settings for using arcboot">
741 <comment>(Read configuration and kernels from SCSI ID# 1, partition 0 -- sda1)</comment>
742 &gt;&gt; <i>setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)</i>
743
744 <comment>(Use arcboot as the bootloader)</comment>
745 &gt;&gt; <i>setenv OSLoader arcload</i>
746
747 <comment>(Which boot image in arcboot.conf to load)</comment>
748 &gt;&gt; <i>setenv OSLoadFilename working</i>
749 </pre>
750
751 <p>
752 When testing kernels via <c>arcboot</c> you can specify an alternate image like
753 so (where <c>new</c> is the alternate image):
754 </p>
755
756 <pre caption="Specifying an alternate image">
757 # <i>boot new</i>
758 </pre>
759
760 </body>
761 </subsection>
762
763 <subsection>
764 <title>All Done</title>
765 <body>
766
767 <p>
768 Now you're ready to enjoy Gentoo! Boot in your Gentoo installation and finish
769 up with <uri link="?part=1&amp;chap=11">Finalizing your Gentoo
770 Installation</uri>.
771 </p>
772
773 </body>
774 </subsection>
775 </section>
776 </sections>

  ViewVC Help
Powered by ViewVC 1.1.20