/[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.15 - (show annotations) (download) (as text)
Mon Jun 12 10:18:17 2006 UTC (8 years, 6 months ago) by neysx
Branch: MAIN
Changes since 1.14: +102 -102 lines
File MIME type: application/xml
#135295 Improved coding style. **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.14 2006/03/14 19:29:29 neysx 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 Indigo2 Impact
41 (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-compatible 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
68 no 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
94 to 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 don't have a separate <path>/boot</path>
159 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. One
178 possible layout, is to set up two kernel images: <path>new</path>, a freshly
179 built image that may or may not work; and <path>working</path>, a proven
180 trustworthy kernel image. The <path>arcboot.conf</path> for that setup looks a
181 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 <uri
204 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 can
219 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 and
234 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 one
274 configures it, see the <uri
275 link="http://www.linux-mips.org/wiki/Arcload">arcload page on the Linux/MIPS
276 wiki</uri>. In short, you define a number of options, which you enable and
277 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
342 on chip. The Cobalt BOOTROM is primitive, by comparison to the SGI PROM, and
343 has a 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 <uri
363 link="http://www.colonel-panic.org/cobalt-mips/">CoLo</uri> (Cobalt Loader) was
364 developed. This is a BOOTROM image that can either be flashed into the chip
365 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
371 CoLo.
372 </note>
373
374 <warn>
375 You may, if you wish, flash it into the server, and totally replace the
376 original firmware -- however, you are entirely on your own in that endeavour.
377 Should anything go wrong, you will need to physically remove the BOOTROM and
378 reprogram it yourself with the stock firmware. If you are not sure how to do
379 this -- then <e>DO NOT</e> flash your machine. We take no responsibility for
380 whatever happens if you ignore this advice.
381 </warn>
382
383 <p>
384 Okay, with the warnings over now, we'll get on with installing CoLo. First,
385 start by emerging the package.
386 </p>
387
388 <pre caption="Emerging colo">
389 # <i>emerge colo</i>
390 </pre>
391
392 <p>
393 With that installed (I hope you read those messages ;-) you should be able to
394 look inside the <path>/usr/lib/colo</path> directory to find two files,
395 <path>colo-chain.elf</path>: the "kernel" for the stock firmware to load, and
396 <path>colo-rom-image.bin</path>: a ROM image for flashing into the BOOTROM. We
397 start by mounting /boot and dumping a compressed copy of
398 <path>colo-chain.elf</path> in <path>/boot</path> where the system expects it.
399 </p>
400
401 <pre caption="Putting CoLo in its place">
402 # <i>gzip -9vc /usr/lib/colo/colo-chain.elf &gt; /boot/vmlinux.gz</i>
403 </pre>
404
405 </body>
406 </subsection>
407
408 <subsection>
409 <title>Configuring CoLo</title>
410
411 <body>
412
413 <p>
414 Now, when the system first boots up, it'll load CoLo which will spit up a menu
415 on the back LCD. The first option (and default that is assumed after roughly 5
416 seconds) is to boot to the hard disk. The system would then attempt to mount
417 the first Linux partition it finds, and run the script
418 <path>default.colo</path>. The syntax is fully documented in the CoLo
419 documentation (have a peek at
420 <path>/usr/share/doc/colo-X.YY/README.shell.gz</path> -- where X.YY is the
421 version installed), and is very simple.
422 </p>
423
424 <note>
425 Just a tip: when installing kernels, I usually create two kernel images,
426 <path>kernel.gz.working</path> -- a known working kernel, and
427 <path>kernel.gz.new</path> -- a kernel that's just been compiled. You can
428 either use symlinks to point to the curent "new" and "working" kernels, or just
429 rename the kernel images.
430 </note>
431
432 <pre caption="A basic default.colo">
433 <comment>#:CoLo:#</comment>
434 mount hda1
435 load /kernel.gz.working
436 execute root=/dev/hda3 ro console=ttyS0,115200
437 </pre>
438
439 <note>
440 CoLo will refuse to load a script that does not begin with the <c>#:CoLo:#</c>
441 line. Think of it as the equivalent of saying <c>#!/bin/sh</c> in shell
442 scripts.
443 </note>
444
445 <p>
446 It is also possible to ask a question, such as which kernel &amp; configuration
447 you'd like to boot, with a default timeout. This configuration does exactly
448 this, asks the user which kernel they wish to use, and executes the chosen
449 image. <path>vmlinux.gz.new</path> and <path>vmlinux.gz.working</path> may be
450 actual kernel images, or just symlinks pointing to the kernel images on that
451 disk. The <c>50</c> argument to <c>select</c> specifies that it should proceed
452 with the first option ("Working") after 50/10 seconds.
453 </p>
454
455 <pre caption="Menu-based configuration">
456 <comment>#:CoLo:#</comment>
457
458 lcd "Mounting hda1"
459 mount hda1
460 select "Which Kernel?" 50 Working New
461
462 goto {menu-option}
463 var image-name vmlinux.gz.working
464 goto 3f
465 @var image-name vmlinux.gz.working
466 goto 2f
467 @var image-name vmlinux.gz.new
468
469 @lcd "Loading Linux" {image-name}
470 load /{image-name}
471 lcd "Booting..."
472 execute root=/dev/hda5 ro console=ttyS0,115200
473 boot
474 </pre>
475
476 <p>
477 See the documentation in <path>/usr/share/doc/colo-VERSION</path> for more
478 details.
479 </p>
480
481 </body>
482
483 </subsection>
484 </section>
485
486 <section>
487 <title>Setting up for Serial Console</title>
488
489 <subsection>
490 <body>
491
492 <p>
493 Okay, the Linux installation as it stands now, would boot fine, but assumes
494 you're going to be logged in at a physical terminal. On Cobalt machines, this
495 is particularly bad -- there's no such thing as a physical terminal.
496 </p>
497
498 <note>
499 Those who do have the luxury of a supported video chipset may skip this section
500 if they wish.
501 </note>
502
503 <p>
504 First, pull up an editor and hack away at <path>/etc/inittab</path>. Further
505 down in the file, you'll see something like this:
506 </p>
507
508 <pre caption="inittab Configuration">
509 <comment># SERIAL CONSOLE</comment>
510 <comment>#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102</comment>
511
512 <comment># TERMINALS</comment>
513 c1:12345:respawn:/sbin/agetty 38400 tty1 linux
514 c2:12345:respawn:/sbin/agetty 38400 tty2 linux
515 c3:12345:respawn:/sbin/agetty 38400 tty3 linux
516 c4:12345:respawn:/sbin/agetty 38400 tty4 linux
517 c5:12345:respawn:/sbin/agetty 38400 tty5 linux
518 c6:12345:respawn:/sbin/agetty 38400 tty6 linux
519
520 <comment># What to do at the "Three Finger Salute".</comment>
521 ca:12345:ctrlaltdel:/sbin/shutdown -r now
522 </pre>
523
524 <p>
525 First, uncomment the <c>c0</c> line. By default, it's set to use a terminal
526 baud rate of 9600 bps. On Cobalt servers, you may want to change this to 115200
527 to match the baud rate decided by the BOOT ROM. This is how that section looks
528 on my machine. On a headless machine (e.g. Cobalt servers), I'll also recommend
529 commenting out the local terminal lines (<c>c1</c> through to <c>c6</c>) as
530 these have a habit of misbehaving when they can't open <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
704 to set from <path>arc.cf</path>. The configuration file is essentially a
705 script, with the top-level blocks defining boot images for different systems,
706 and inside that, optional settings. Thus, setting
707 <c>OSLoadFilename=mysys(serial)</c> pulls in the settings for the <c>mysys</c>
708 block, then sets further options 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