2.4 Where is the BIOS

It is likely that our Linux readers are more accustomed to Intel PCs than to pSeries systems. There are obviously significant differences between them, and we describe them here. Apart from performance or scalability, the differences show at various levels:

• Processor - PowerPC versus Intel

• System architecture - CHRP versus PC

• Firmware - Open Firmware versus BIOS

• Booting, yaboot versus grub/lilo - a consequence of the difference in firmware

2.4.1 PowerPC

All pSeries systems use processors that implement the PowerPC architecture. Chips based on this architecture can also be found in the Apple Macintosh (G3, G4, G5) and in many embedded systems from various manufacturers. You can even find PowerPC chips in game consoles. More information on the family of PowerPC chips can be found at:

http://www.ibm.com/chips/products/powerpc/

IBM manufactures processors based on the PowerPC architecture for its own systems (POWER4 is the current declination), but it also manufactures PowerPC chips for other equipment manufacturers.

2.4.2 CHRP

All pSeries systems are built around PowerPC processors, and all obey the Common Hardware Reference Platform (CHRP) specification.

In the lifetime of the Power architecture, the first systems in 1990 were based on the Micro Channel Architecture (MCA) bus and were named RS6K systems. These systems were built on the Power technology but not on the PowerPC architecture; that was instantiated for the first time with the desktop model 250 in 1993.

Later on, a first attempt was made to define a specification for building systems around the PowerPC processor. Called PReP (PowerPC Reference Platform ), it first came to life with the desktop model 43P in 1995, architected around the 604 PowerPC chip.

Since the introduction of the model S70, based on the PowerPC RS64 chip, in 1997 and the desktop model 43P-260, based on the POWER3 chip, all the systems obey the CHRP specification. The older PReP systems which were still supported with AIX 5.1 are no longer supported with AIX 5.2.

The CHRP specification is available from:

http://www.ibm.com/servers/eserver/pseries/library/wp_powerpc.html

This specification comes with two parts : one describing the base architecture (NVRAM, RTAS, power management), and the other describing the I/O devices. The specification describes how the firmware needs to abstract the hardware and present a consistent interface to the operating systems that may run on a CHRP system.

2.4.3 Open Firmware basics

pSeries CHRP systems use a firmware that conforms to the open firmware IEEE Std. 1275-1994. Open Firmware is primarily a boot firmware that does not specify a particular system or processor. It also provides a machine independent devices tree interface that lists the properties of each IO device which can be displayed and altered using a command line interface.

There are Open Firmware bindings for a variety of systems architectures. The one that pertains to pSeries is described in:

http://playground.sun.com/1275/bindings/chrp/chrp1_8a.ps

The home of the Open Firmware working group is located at:

http://playground.sun.com/1275.

The Open Firmware standard derives from the Sun Microsystems OpenBoot and is currently being developed mainly by Sun, Apple and IBM. It complies with the ANSI Forth language as described at:

http://www.forth.org/

Open Firmware prompt

pSeries systems can be booted to SMS or to the open firmware prompt, sometimes referred to as the ok prompt. You can reach the open firmware prompt by hitting the 8 key while booting. If under AIX, system administrators rarely have to use this.

For installing Linux, however, we sometimes had to boot to the OK prompt to pass arguments to the kernel, as described in Example 2-29 on page 75.

The Open Firmware prompt is also used extensively by the netboot command in CSM to boot/install from the network. SMS itself is an Open Firmware application.

Next, we give a very brief introduction to the Open Firmware prompt command line interface. A quick reference guide is available from:

http://www.firmworks.com/QuickRef.html

A thorough description can be found at these sites:

http://developer.apple.com/technotes/tn/tn1061.html

http://developer.apple.com/technotes/tn/tn1062.html

Open Firmware commands

Booting the system in Open Firmware gives you the screen shown in Example 2-32.

Example 2-32. Open Firmware prompt

 1 = SMS Menu                           5 = Default Boot List        6 = Stored Boot List                   8 = Open Firmware Prompt     memory     keyboard     network      scsi    speaker   ok 0 > 

You can navigate inside the device tree. Upon startup, you are at the top of the device tree. Use the ls command to display the device tree, a walk along all the buses and adapters that constitute the system under examination. It is shown in Example 2-33 on page 82.

Example 2-33. ls lists the device tree

 0 >  ls  000000c8fee0: /ibm,serial 000000c9c6c0: /chosen 000000ca0290: /cpus 000000ca39b8:   /PowerPC,POWER4@2 000000ca60e0:   /L2-cache@2001 000000ca65a8:   /L3-cache@3001 000000ca6c28: /memory@0 000000ca9100: /memory@10000000 000000ca93f0: /memory@20000000 000000ca96e0: /memory@30000000 000000ca9ac8: /memory-controller@7000000000000 000000caa698:   /IBM,memory-module@0 000000caaa48:   /IBM,memory-module@1 000000caadf8:   /IBM,memory-module@2 000000cab1a8:   /IBM,memory-module@3 000000cabd88: /memory-controller@7000000000010 000000cac958:   /IBM,memory-module@0 ........ 000000d1c690: /rtas 000000d31358: /vdevice 000000d317b0:   /vty@0 000000d321e0:   /IBM,sp@4000 000000d3a420:   /rtc@4001 000000d3bd70: /pci@400000000110 000000d43168: /pci@400000000111 000000d49b80:   /pci@2,4 000000d5ff60:     /ethernet@1 000000d511d8: /pci@400000000112 000000d57bd8:   /pci@2,2 000000d6b4c8:     /scsi@1 000000d722f8:       /sd 000000d737c0:       /st 000000d74f10:     /scsi@1,1 000000d7bd40:       /sd 000000d7d208:       /st  ok 0 > 

You can navigate back and forth in the device tree by using the dev command, and you can check where you are in the device tree by using the pwd command. This is shown in Example 2-34 on page 83, where we first point to the Ethernet adapter, then move backward, and finally return to the root of the device tree.

Do not type ok, as this is echoed by the Open Firmware.

Example 2-34. dev and pwd to navigate the device tree

 0 >  dev /pci@400000000111/pci@2,4/ethernet@1  ok 0 >  pwd  /pci@400000000111/pci@2,4/ethernet@1 ok 0 >  dev  .. ok 0 >  pwd  /pci@400000000111/pci@2,4 ok 0 >  dev  / ok 0 >  pwd  / ok 0 > 

It can be interesting to show the properties attached to the devices. Example 2-35 displays the properties of our Ethernet adapter. Displaying the properties at the root of the device tree gives general information about the system.

Example 2-35. properties lists the adapter properties

 0 >  dev /pci@400000000111/pci@2,4/ethernet@1  0 >  .properties  ibm,loc-code            U0.1-P2-I5/E1 vendor-id               00008086 device-id               00001229 revision-id             0000000d class-code              00020000 .... device_type             network supported-network-types ethernet,auto,rj45,auto                         ethernet,10,rj45,half                         ethernet,10,rj45,full                         ethernet,100,rj45,half                         ethernet,100,rj45,full max-frame-size          00000a28 address-bits            00000030 local-mac-address       0002556f 1fef mac-address             0002556f 1fef ibm,fw-adapter-name     10/100 Mbps Ethernet PCI Adapter II ibm,fw-driver-version   00000150 chosen-network-type     ethernet,100,rj45,full ibm,fw-revision-level   00000150 ok 0 > dev / 0 > .properties ibm,model-class         G5 ibm,pci-full-cfg        00000001 clock-frequency         17d78400 device_type             chrp #address-cells          00000002 #size-cells             00000002 ibm,max-boot-devices    00000005 ibm,aix-diagnostics ibm,extended-address ibm,lpar-capable ibm,partition-no        00000002 ibm,partition-name      6c706172 3800 ibm,fw-sp-per-current   3000 ibm,fw-sp-per-default   3000 ibm,fw-sp-l3-current    3000 ibm,fw-sp-l3-default    3000 ibm,fw-sp-l3prefetch-current                         3000 ibm,fw-sp-l3prefetch-default                         3000 .... name                    IBM,7038-6M2 model                   IBM,7038-6M2 compatible              IBM,7038-6M2 system-id               IBM,0110197AA  ok 0 > 

Some devices have aliases which you can use to avoid typing long device names , especially when using the boot command. You can list these devices with the devalias command, as shown in Example 2-36.

In our example, net is an alias for the Ethernet adapter, and disk is an alias for the first SCSI disk.

Example 2-36. devalias command

 0 >  devalias  ibm,sp           /vdevice/IBM,sp@4000 disk             /pci@400000000112/pci@2,2/scsi@1/sd@0,0 scsi             /pci@400000000112/pci@2,2/scsi@1 screen           /vdevice/vty@0 net              /pci@400000000111/pci@2,4/ethernet@1 network          /pci@400000000111/pci@2,4/ethernet@1 rtc              /vdevice/rtc@4001 nvram            /nvram@3fdbd800000  ok 0 > 

Persistent configuration variables can be displayed with the printenv command, as shown in Example 2-37 on page 85.

Example 2-37. printenv command

 0 >  printenv  .... screen-#rows             28                  28 selftest-#megs           0                   0 boot-device              /pci@400000000112/pci@2,2/scsi@1/sd@0,0 boot-file diag-device              /pci@400000000112/pci@2,2/scsi@1/sd@0,0 diag-file                diag                diag output-device            /vdevice/vty        com1 input-device             /vdevice/vty        com1 oem-banner oem-logo nvramrc                  Defined : use NVEDIT related words to view boot-command             boot                boot reboot-command security-#badlogins      0                   0 ... 

The command that we will most likely use is the boot command. This is the only way we found to give command line arguments to the Linux kernel when booting from the network.

We use the alias for the network to do that, passing along the arguments to the kernel. This is shown in Example 2-38, where we boot off the network (BOOTP) and pass along the two modules to load when booting.

Example 2-38. boot command

 0 >  boot net insmod=e100 insmod=lvm-mod  

To leave the Open Firmware prompt and jump into SMS, use the command shown in Example 2-39, and press <1>.

Example 2-39. Back to SMS

 0 >  dev /packages/gui obe  

See the device tree from Linux

The device tree shows under Linux in the /proc/device-tree directory.

2.4.4 Yaboot

Yaboot is a disk boot loader for PowerPC-based systems. The way to boot CHRP systems was carried over from the old PReP systems, so that it uses a disk partition that is defined as a PReP boot partition.

The yaboot home page is located at:

http://penguinppc.org/projects/yaboot/doc/yaboot-howto.shtml/

SLES 8 provides a script called lilo that is more "natural" for Intel Linux users to use. Only the name of the script is the same; it has nothing to do with the Linux loader on PCs.

The lilo script stores the yaboot.chrp file raw inside the PReP boot partition and updates the /etc/yaboot.conf file based on the contents of the /etc/lilo.conf file. The simplest /etc/lilo.conf file specifies the location of the kernel to boot, as well as the root partition to mount. Example 2-40 gives a basic example.

Example 2-40. Sample /etc/lilo.conf file

 # Generated by YaST2 default=test timeout=100 boot=/dev/sda1 activate image = /boot/vmlinuz         label = linux         root = /dev/sda2         append = "" 

To understand how yaboot operates, start it in debug mode. This can be done by copying the /boot/yaboot.chrp.debug file raw in the PReP boot partition with the command shown in Example 2-41.

Note : This is not needed in regular operation and is shown here only to demonstrate the process.

Example 2-41. Run yaboot in debug mode

 #  dd if=/boot/yaboot.chrp.debug of=/dev/sda1 bs=512  

Then reboot the node and watch the output at the system console; see Example 2-42 on page 87.

Example 2-42. Watching yaboot

 Adding OF methods...     prom_init - OF interface initialized.     yaboot_start - Malloc buffer allocated at 00300000 (1048576 bytes)     yaboot_start - reloc_offset :  0         (should be 0)     yaboot_start - test_bss     :  0         (should be 0)     yaboot_start - test_data    :  0         (should be 0)     yaboot_start - &test_data   :  00227780     yaboot_start - &test_bss    :  00227f60     yaboot_start - linked at    :  0x00200000     yaboot_start - Running on _machine = 4     yaboot_main -  /chosen/bootpath = /pci@400000000111/pci@2/scsi@1/sd@8,0  ... file_name = /etc/yaboot.conf partition = -1     open_file - device is a block device     partitions_lookup - block size of device is 512 partitions:     file_block_open - number: 02, start: 0x00003ec1, length: 0x0080344b  --> ext2_open  .... ext2_open -  ext2fs_open returned bad magic  loading file 0291fca8  <-- ext2_open - -8  ...  --> xfs_open  xfs_open - dev=/pci@400000000111/pci@2/scsi@1/sd@8,0, part=0x00308068 (2), file_name=/etc/yaboot.conf ... xfs_mount - xfs_mount: Bad magic: 0  xfs_open - Couldn't open XFS  @ /pci@400000000111/pci@2/scsi@1/sd@8,0:0/8225280  <-- xfs_open - FILE_ERR_BAD_FSYS   --> reiserfs_open  reiserfs_open - dev=/pci@400000000111/pci@2/scsi@1/sd@8,0, part=0x00308068 (2), file_name=/etc/yaboot.conf ...  Config file read, 160 bytes  reiserfs_close - reiserfs_close called     load_config_file - Config file successfully parsed, 160 bytes Welcome to yaboot version 1.3.6.SuSE Enter "help" to get some basic usage information boot: 

At startup time, yaboot will determine, from the firmware, which disk it was started from. Then, yaboot has to locate its /etc/yaboot.conf configuration file. But how can it locate a file in /etc when there is no root device mounted?

The answer is that yaboot has a built-in knowledge of three types of file systems: ext2/3, xfs, and reiserfs. It tries to open the partitions, looking for a valid /etc/yaboot.conf file.

In our example, yaboot tries ext2 first and fails, then tries xfs and fails, and finally succeeds opening a reiserfs file system with the /etc/yaboot.conf file. Once the configuration file is read, yaboot can then record the location of the kernel(s) referenced in the file and prompt the user to choose which kernel to use.