Issue 1-27, June 12, 1996

Be Engineering Insights: OS Writer's Cookbook

By Bob Herold

The engineers at Be have had the luxury of writing a new operating system from scratch. We've worked hard to make it as good as possible. Still, you might feel that you can write a better one, or that some other ancient OS is more suited to your taste. In the spirit of open, friendly competition, this article will describe how you can get control of a BeBox so you can boot your own operating system.

Before you start hacking away, you may want to get the data books describing the major components of the BeBox hardware. These books are listed at the end of this article.

Getting Loaded

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.

System State

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:

0x3010RAM size, in bytes
0x301CPointer to a null-terminated "list of stuff" passed to 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:

"pci_table_v5"pci_infoPCI device table
"boot_config_dev"char*Configured boot device name
"boot_kernel_dev"char*Where boot ROM found kernel
"boot_kernel_name"char*Name of booted kernel
"boot_ignore"boolFlag: mount only kernel vol
"boot_kvol_only"boolFlag: check only kvol for a bootable system
"debug_output"boolSERIAL4 debug enabled flag

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.

Hardware Memory Map

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

0x000000000x40000000Physical RAM
0x400000000x40000000Other system memory (motherboard glue regs)
0x800000000x00800000ISA I/O
0x810000000x3E800000PCI I/O
0xBFFFFFF00x00000010PCI/ISA interrupt acknowledge
0xC00000000x3F000000PCI memory

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.

Be Motherboard Registers

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:

0x7ffff0f0CPU 0 interrupt mask
0x7ffff1f0CPU 1 interrupt mask
0x7ffff2f0Interrupt sources
0x7ffff3f0Cross-processor interrupts, processor ID
0x7ffff4f0Processor resets, other stuff

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:

Bit#Interrupt Source
0(Used for setting/clearing mask registers)
1(CPU 0 mask reg only) SMI interrupt to CPU 0
2(CPU 1 mask reg only) SMI interrupt to CPU 1
3Not used
4IRQ4, a/k/a SERIAL1
5IRQ3, a/k/a SERIAL2
11PCI slot 1
12PCI slot 2
13PCI slot 3
15IRQ1, a/k/a Keyboard
16IRQ8, a/k/a Real-Time Clock
18IRQ6, a/k/a Floppy Disk
19IRQ7, a/k/a Parallel Port
23IRQ12, a/k/a Mouse
24IRQ14, a/k/a IDE
268259 (ISA-compatible interrupt controller)
27Infrared Controller
28A2D Converter
30Not used
31Not used

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

Bit#Interrupt Source
0(Used for setting/clearing individual bits)
10 - deassert /SMI to CPU 0, 1 - assert it
20 - deassert /SMI to CPU 1, 1 - assert it
3Not used
40 - assert /TLBISYNC to CPU 0, 1 - deassert it
50 - assert /TLBISYNC to CPU 1, 1 - deassert it
6(Read only) 0 if read by CPU 0, 1 if read by CPU 1

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

Bit#Interrupt Source
0(Used for setting/clearing individual bits)
10 - assert /SRESET to CPU 1, 1 - deassert it
20 - assert /HRESET to CPU 1, 1 - deassert it
3FLUSHREQ workaround (see below)
4not used
5not used
6not used
7disk LED (0 - off, 1 - on)

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.

A Word About Interrupt Controllers

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.

In Conclusion

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!

Data Books

  • 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).

Be Developer Profile: Night Owl Software

Charles G. Fleming, director of software development at Night Owl Software in Saegertown, Pennsylvania, isn't afraid of new technology. The small software shop has been in business since 1989 developing for emerging platforms such as NEXTSTEP/OpenStep and Newton.

Night Owl's current products include a NEXTSTEP device driver for Nikon's Coolscan 35mm slide scanner, and a NEXTSTEP Interface Builder palette that provides objects that communicate with Mathematica. Night Owl mostly serves the higher education market, with incremental sales to business and scientific customers.

Now they're looking to the BeBox. Night Owl has had a BeBox in house since late December. “The BeBox has the potential to be a great virtual reality development environment,” says Charles. “With the DR7 release and the full CodeWarrior development tools, we're finding programming it more enjoyable than ever.

Night Owl's plans to build BeBox development tools similar to those produced by NeXT. “For rapid prototyping, we believe the BeBox needs a tool similar to NeXT's Interface Builder,” Charles says. “We already have a prototype for in-house use.

After that, Night Owl plans to focus its BeBox development on the educational market, possibly in art and modern languages. For example, an artist at Allegheny College is currently investigating "Interface Art" -- works of art constructed from common interface widgets. Since the artist is an Amiga programmer, Night Owl is looking at the possibility of steering the artist toward the BeBox. “We see an opportunity to attract former educational Amiga users.

For more information on Night Owl Software, send e-mail to Charles at

Teething Pains

By Jean-Louis Gassée

As we grow and make the transition from a group of engineers developing hardware and software to a real business with shipping products, we experience problems and, unfortunately, we ship some of them. For this, I'd like to extend our apologies to our developers and thank them for their patience and feedback.

Last fall, we were surprised and more than a little overwhelmed by the reaction to the first public showing of the BeBox at the Agenda PC industry conference. Our web site was swamped, we got hundreds of developer applications, and we managed to ship over a hundred development systems. The motherboards came from Altatron, our manufacturing contractor in Milpitas, and each BeBox was assembled by hand in our offices. The front bezel was missing, the loud color scheme got equally loud reviews but, overall, we didn't experience any unusual hardware or software problems. The venture community was watching this and the warm reception, and this external validation played a crucial role in our getting serious financing.

As with many a start-up company, we had several good looks at the whites of the repo man's eyes. One of these "extreme cash conservation" episodes occurred in the two-to-three-month period preceding the close of our financing. As a result, we stopped manufacturing units for a while, thus creating frustrations in the developer community and the unfortunately accurate perception of availability problems. Once our financing closed, we ordered parts, restarted production of motherboards, and signed on a contractor for final assembly, test, pack, and shipment. On paper it looks good: A lighter infrastructure, outsourcing, flexibility. As we all found out, buzzwords don't make good processes. We got a bad batch of sound chips, our shipping container didn't protect our chassis, and miscellaneous other problems resulted in an abnormal number of bad systems shipped to our developers. Some were damaged in shipment, some were insufficiently tested to catch the sound problem before shipment. And we got frustrated developers and a stain on our reputation at a time when we ought to be happily focusing on going through our database of registered developers with the good news that we have systems available. Needless to say, we're mortified—but motivated. The good news is this happened early in our life. We didn't create problems on a grand scale. Better news is we got, shall we say, energetic, highly motivating feedback from the technically proficient recipients of our mistakes. We have a brand new Director of Manufacturing, Don Fotsch, assisted by Kevin Peoples, also a new hire, and we're focused on the product design, procurement, contractor management, and testing processes that led to these problems. At the same time, we're cleaning up the situation in the field—exchanging units or I/O boards as needed.

Now, we need to behave in a way that restores confidence and demonstrates we've learned from these bad experiences. You'll be the judge.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.