Daemon News '200604' : '"Installing BSD on IBM Netvista S40

DæmonNews: News and views for the BSD community

Installing BSD on IBM Netvista S40 - Part 1: FreeBSD Installation

By Micho Durdevich <micho@matem.unam.mx>

Abstract

We present several ways of installing BSD on the IBM Netvista S40, a so-called legacy free computer. Difficulties arise because the machine has no standard AT keyboard controller, and the subroutines controlling gate A20 and the keyboard create inappropriate results. We discuss replacement bootstrap code, which more carefully deals with the A20 issue. Some simple modifications to the FreeBSD kernel code are considered too. A manual method for preparing a bootable installation CD, suitable for both Netvista and all standard configurations, is examined. Installations of DragonFly, NetBSD, OpenBSD and OS/2 are also discussed.

1. Introduction

1.1. The Machine

In this article we shall talk about installing FreeBSD on a very interesting and elegant machine: IBM Netvista S40. In its creators own terminology, it is "legacy-free". The computer has no parallel, serial, AT keyboard, nor PS/2 mouse ports. No floppy controller either. Instead, it has 5 USB ports (2 frontal and 3 rear) connected to a single USB controller. Besides these USB ports, the system only comes with standard video and audio connectors. The video controller is Intel 82810E SVGA and audio chip is Intel ICH 82801AA, both integrated on board. The CPU is 866MHz Intel PIII. The machine is further equipped with a fast Intel Pro PCI network adapter containing a PXE/RIPL boot PROM. A quiet 20G Quantum Fireball HDD and a Liteon ATAPI CD-ROM, both connected as masters, constitute the storage subsystem. The case is Flex ATX, a small form factor.

1.2. Problem Description

If we try to install FreeBSD 4.11 on this machine in a standard way, by using the bootable installation CD, the computer simply hangs after the initial attempt to read the CD. Nothing is displayed on the screen. Essentially the same symptom appears with NetBSD, DragonFly and FreeBSD 5.3 as well. A natural assumption is that the problem has to do with some BIOS settings. However, no twidlings in "BIOS Setup" would remedy this. Another natural path of action is to physically remove the HDD from the Netvista, and connect it to a different "auxiliary" system. This would allow us to install FreeBSD in a standard way. Then put back the HDD in Netvista, and hopefully the machine would boot fine into FreeBSD. Unfortunately, this idea does not work either: the machine just hangs as it does during the boot attempt.

From this we can conclude that, most probably, the bootstrap code is somehow incompatible with the Netvista. In order to verify this, we use a third approach: install a boot manager, such as GRUB; accomplished by using an auxiliary machine and then attempt to start the system. At the beginning of the boot process, everything looks encouraging with GRUB. It starts fine and it initializes the FreeBSD loader correctly. Unfortunately, the system freezes as soon as control is transferred to the kernel. So it follows that the problem lies in both kernel and bootstrap code.

In order to deal with this puzzle, we need a mechanism to efficiently change the kernel and the bootstrap files. Drive swapping and re-installing each time we made a change would be a pain. This is one situation where we can take the full, natural advantage of remote booting. First, we set up a DHCP/PXE remote-boot server, equipped with full sources, and then try to boot the Netvista remotely.

It comes as no surprise that PXEboot fails in a similar way--after some rudimentary initial processing the system appears brain dead. However, on the remote-boot server, we can easily change the code and quickly deploy all necessary files for the Netvista, in the hope to find some solution for the initialization problem.

1.3. Solution

Further experiments and a more detailed examination of the FreeBSD PXEboot source code, show that the subroutine responsible for enabling A20 gate is "guilty". It contains two possibly infinite loops, and indeed the Netvista falls into the first of them. The reason is that A20 gate is normally enabled by software, through the keyboard controller. Since this machine has no standard keyboard controller, it falls in a loop of indefinite waiting for the non-existing controller to become ready.

The same A20 subroutine is present in the CD-ROM bootstrap code and also in the hard disk bootstrap code. However, in FreeBSD 5.3 the hard disk bootstrap code has been slightly changed to allow it to get out of the deadly loop for systems without a standard keyboard controller.

The Netvista does not need any A20 instructions, so removing the subroutine from the code solves the problem of the initialization, allowing the loader to start properly. In order to boot the kernel, we need to proceed in a similar spirit. Remove all references to keyboard and mouse drivers (atkbd and psm), and recompile the kernel. This was the solution for FreeBSD 4.11 and also DragonFly.

In the case of FreeBSD 5.3, we are equipped with the flexibility of using device hints. So in order to boot the kernel, we can simply disable atkbd and psm at the loader prompt.

1.4. Organization of the paper

In the next section we shall explain the A20 gate in more detail, and present an alternative A20 subroutine appropriate for both Netvista and standard keyboard controller-equipped systems. In Section 3 we discuss a "quick and dirty" way to get FreeBSD running on the Netvista, by moving the hard drive on another computer. A more careful approach is to build a bootable FreeBSD installation CD, compatible with the Netvista and also the standard systems. This is the subject of Part Two of this article. In Section 5 some concluding remarks are made. The paper continues with three more installments. In Part Three, we play with DragonFly on the Netvista. The procedure is very similar to installing FreeBSD 4.11. In Part Four, we discuss installing NetBSD, with the help of a live installation CD and GRUB. Finally, in Part Five we shall leave the framework of BSD, and briefly talk about installing OS/2 and eComStation on the Netvista, by taking advantage of the remote-booting capability of OS/2.

2. Understanding the A20 Gate

The problematics of A20 gate is related to the days of "prehistory" of PC hardware. It addresses an inherent incompatibility between 80286 and 8086 architectures. The original IBM 8086 had 20 binary lines for addressing memory (A0-A19). This corresponds to 2²⁰=1M bytes of addressable memory. The processor 80286 was capable to access physical memory via 24 lines (A0-A23). This corresponds to 16M bytes of addressable memory. In real mode we would only get 1M + (64K-16) bytes, still above 8086's addressable range. This value comes from the expression FFFF:FFFF as the maximum address in segmented form, which translates into a linear value of FFFF0+FFFF = 10FFEF = 100000+(10000-11) in hexadecimal form (add one to this number to get the amount of addressable bytes, as we start counting at zero).

By the way, there existed a possibility to run 80286 in protected mode, different from the well known protected mode of 80386. It also is interesting to note that the first versions of OS/2 were running in the protected mode of 286. Processors 80386, 80486 and Pentiums feature a 32-bit address bus, corresponding to the maximum of 2³²=4G bytes of addressable memory.

Returning to our main subject, let us see what would happen if a program designed for 8086 running on 80286 tries to access a memory location requiring more than 20 bits. The 8086 would just ignore the bit 21, corresponding to the line A20 of the address bus. And some old programs required memory space to wrap up at coordinate 2²⁰. A way for 80286 to effectively simulate this behavior, is to switch off its address line A20. And indeed, IBM introduced such a compatibility function by allowing software to explicitly decide if the address line A20 should be active.

To be precise, they implemented a logical AND gate on line A20, where the address line is coupled with an output line of the standard keyboard controller. By setting the keyboard controller line output to 1 (or 0), we effectively enable (or disable) the gate. By default, the PC would initialize with A20 disabled. However, in order for the CPU to access the full memory space, the A20 gate must be enabled by the operating system.

Otherwise, weird things would happen: all the theoretical memory space would be factorized over the equivalence relation, obtained by flipping bits at position 20. Any reasonably designed operating system would most probably crash under such conditions.

On the other hand, the Netvista S40 is a "legacy free" system, and it has no such a special gate for A20. It actually lacks any standard keyboard controller (both keyboard and mice are USB). Execution of a straightforward A20 enablement subroutine on such systems could easily result in weird things. Indeed, this is exactly what happens with the existing FreeBSD and DragonFly code.

Here comes the listing of an alternative A20 enablement subroutine, that should work both for standard systems and the Netvista S40. This code should be put in place of the existing A20 subroutine in files

              /sys/boot/i386/cdboot/cdboot.s    /sys/boot/i386/pxeldr/pxeldr.s


set_a20:                cli
                         movw $qfbsd, %si       # Say something.
                         callw putstr

                         movw $0x10, %cx        # Initial wait, to allow
                         callw delay            # a keypress.

                         movb $0x1, %ah         # If a key has been pressed
                         int $0x16              # then skip.
                         jnz skip_a20

                         movw $qstar, %di       # Entering the first wait cycle,
                         callw wait_kbdc        # check for the controller
                         jcxz  skip_a20         # to report its readiness.

                         movb $0xD1, %al        # We are ready to ask for the
                         outb %al, $0x64        # write command...

                         movw $qnumb, %di       # Wait for the controller
                         callw wait_kbdc        # to get ready again.
                         jcxz  skip_a20

                         movb $0xDF, %al        # Everything looks ok, so let us
                         outb %al, $0x60        # turn on the kbd line of the gate.


skip_a20:                movw $monkey, %si
                         callw putstr

                         sti
                         retw

wait_kbdc:               movw $0x10, %cx

wait_kbdc.2:             inb  $0x64, %al
                         testb $0x2, %al
                         jz wait_kbdc.3

                         movw %di, %si
                         callw putstr

                         pushw %cx
                         movw $0x2, %cx
                         callw delay
                         popw  %cx

                         loop wait_kbdc.2
wait_kbdc.3:             retw

delay:                   movb $0x86, %ah        # BIOS wait call. The combination
                         int $0x15              # cx:dx holds the number of
                         retw                   # microseconds to wait.

...

qfbsd:                  .asciz "\r\nA20 Gate [Keypress to Skip]\r\n"
qstar:                  .asciz "*" 
qnumb:                  .asciz "#" 
monkey:                 .asciz "@\r\n\n"

The lines in green are optional. They introduce some rudimentary verbose output, so we know whenever the controller is not ready to take commands. It also allows us to skip the A20 related code altogether, by pressing a key when an initialization message appears. This might be useful to avoid the mess, for example if we plan to expand the A20 code, by introducing different methods of enabling the A20 gate, or in highly non-standard configurations where the in/out ports are different.

In Part Two of this article we conclude the installation of FreeBSD on the Netvista, including creating a bootable installation CD.