To get control of the machine, you replace our kernel with yours. The kernel must be on a Be-formatted volume on a hard disk, floppy disk, or CD-ROM. The boot ROM looks for the PEF executable file "system/kernel", loads it at location 0x3100, and jumps to the __start entry point. (In the future we expect to support a more flexible bootstrap, with volume partitioning, alternate file system types, and perhaps boot blocks. For now we're Be-centric.)

The kernel file loaded by the boot ROM should be statically linked, i.e., it shouldn't depend on any shared libraries. With the proper settings, you can use the Metrowerks IDE on either the BeBox or the Macintosh to generate such a beast.

The kernel should be prepared to accept both processors at the same time. As a model, the Be kernel parks one processor in a polling loop until the other one has initialized the kernel.

Most of the hardware devices in the system are in an unpredictable state when the kernel gets control. The only given is that RAM has been set up contiguously starting at address zero (0x0). The processors are running in "real mode" (MMU off), with interrupts disabled (EE bit cleared in the MSR). R2 is set up with the kernel's TOC pointer, so kernel globals may be accessed immediately. The kernel is responsible for initializing the rest of the hardware in an orderly fashion.

Some useful information is placed in low memory by the boot ROM for the kernel:

In the "list of stuff" you'll find bootitem structures:

typedef struct bootitem {
   struct bootitem  *next;   /* -> next item, or null */
   char             *name;   /* -> item name */
   int              size;    /* item size */
   void             *data;   /* -> item data */
} bootitem;

You can scan this list to look for a particular named data item. Items defined to date are:

The pci_table_v5 is quite important. The boot ROM must relocate all PCI devices to make each one accessible. This item is a table of structures, one per device, that give the final device location and other useful information.

The MPC105 defines the physical memory map of the system as follows:

The standard ISA hardware device registers are at the standard offsets within the ISA I/O space. The keyboard is at 0x80000060 and 0x80000064, SERIAL 1 is at 0x800003F8-0x800003FF, etc. The Be-specific ISA hardware (sound, GeekPort™, infrared, extra serial ports) are also in ISA space. Describing their hardware interface is a future newsletter topic.

The boot ROM maps all the PCI devices into the PCI I/O and memory spaces. See the "PCI Local Bus Specification" and the "Device Kit" chapter of "The Be Book" for details.

Five 32-bit registers are implemented in glue logic on the BeBox. These registers handle interrupt identification, masking and routing, as well as interprocessor interrupts, processor resets, and processor identification.

All five registers use an unusual mechanism where individual bits can be changed in a single write (a nice feature for a multiprocessor system). On a write, bit zero (Power PC style numbering, i.e., the most significant bit) controls whether other bits are set to one or zero. Other bits control whether the register bit is written or left unchanged. For instance, writing 0x90008000 sets bits 3 and 16, leaving others unchanged. Writing 0x08040200 clears bits 4, 13, and 22, leaving others unchanged.

The register locations are:

The interrupt source register has a bit for every interrupt source. If the bit is one, the device is asserting its interrupt line. The two interrupt mask registers control which CPU gets each interrupt. If the CPU 0 mask bit is set, CPU 0 gets it. If the CPU 1 mask bit is set, CPU 1 gets it. Setting both bits is not covered under your warranty.

The two mask registers and the source register have the same layout:

The cross-processor interrupt register (0x7ffff3f0) has the following layout:

The processor resets register (0x7ffff4f0) has the following layout:

The FLUSHREQ workaround fixes a problem we encountered using the Intel PCI-ISA bridge (the 82378) together with the Motorola host-PCI bridge (the MPC105). If connected as specified in the data books, DMA cycles from the floppy controller could hang when other ISA interrupts are pending (until another read or write to ISA I/O space is done).

The FLUSHREQ/MEMACK functionality is not needed in our system, so we simply looped the FLUSHREQ output to the MEMACK input on the 82378. However, this caused ISA interrupt acknowledge cycles to hang! Therefore we temporarily reconnect FLUSHREQ and MEMACK between the two parts when running an ISA interrupt acknowledge cycle, then change it back afterwards.

The FLUSHREQ workaround bit should normally be zero, except when running an ISA interrupt acknowledge cycle.

There are two interrupt controllers in the BeBox. The Be interrupt controller is described above. One of the inputs to the Be controller is the output of the 8259-compatible standard ISA interrupt controller that's embedded in the Intel 2378 SIO chip.

Interrupt lines from the ISA slots and standard ISA devices are connected to both interrupt controllers. Edge-triggered interrupts should be handled in the ISA controller, and level-triggered interrupts should be handled in the Be controller. Setting up both interrupt controllers to handle the same interrupt is not advised.

When possible, interrupts should be handled with the Be controller where they can be directly identified and dispatched. Interrupts in the ISA controller require many (slow) ISA I/O accesses to identify and acknowledge the interrupt, and a second level of dispatching to get to an interrupt handler.

Hopefully this article has swamped you with enough detail to discourage you from writing anything better than what we can come up with. Seriously though, we would like the BeBox to be open to all comers, even other operating systems—a Linux port is already up and running! For the lunatic fringe, getting control of the entire machine is the ideal environment. Happy OS hacking!

• PowerPC Microprocessor Family: The Programming Environments, Motorola, Inc., 1994, Motorola Document MPCFPE/AD, or IBM Document MPRPPCFPE-01.

• PowerPC 603e RISC Microprocessor User's Manual with Supplement for PowerPC 603 Microprocessor Motorola, Inc., 1995, Motorola Document MPC603EUM/AD, or IBM Document MPR603EUM-01.

• MPC105 PCI Bridge/Memory Controller User's Manual Motorola, Inc., 1995, Motorola Document MPC105UM/AD.

• 82378 System I/O (SIO), Intel Corp., August 1994, Intel Document 290473-004.

• 82091AA Advanced Integrated Peripheral (AIP), Intel Corp., January 1994, Intel Document 290486-002.

• NCR 53C810 PCI-SCSI I/O Processor Data Manual, NCR Corp., 1993.

• TL16C554 Asynchronous Communications Element, Texas Instruments Inc., 1994.

• Crystal Semiconductor Audio Databook, Crystal Semiconductor Corp., January 1994 (for CS4231 Audio Codec info).

• Benchmarq Data Book, Benchmarq Microelectronics, 1994 (for bq3285 Real-Time Clock).

• PCI Local Bus Specification, Revision 2.1, PCI Special Interest Group, 1995.

• Maxim 1994 New Releases Data Book Volume III, Maxim Integrated Products, 1993, (for MAX186 ADC and MAX505 DAC).