/[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.16 - (show annotations) (download) (as text)
Wed Aug 30 22:52:28 2006 UTC (8 years, 2 months ago) by nightmorph
Branch: MAIN
Changes since 1.15: +35 -19 lines
File MIME type: application/xml
2006.1 networked docs are in. portage handbook still untouched per separate bugs. thanks to all the hard work, guys. blame me if something is wrong (and please fix quickly) :)

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

  ViewVC Help
Powered by ViewVC 1.1.20