Be Developers:
Put your banner here!

Be Newsletter

Issue 27, June 12, 1996

Table of Contents

BE DEMO TOUR IN MICHIGAN: MacHack and Three Demo Meetings

    WHEN: Monday, June 17, at 7:00 pm
    WHERE: 1311 EECS Building (Electrical Engineering and Computer Science), 1301 Beal Avenue, University of Michigan, North Campus, Ann Arbor

    WHEN: Tuesday, June 18, at 10:00 am.
    Advanced Computer Architecture
    WHERE: 1311 EECS Building (Electrical Engineering and Computer Science), 1301 Beal Avenue, University of Michigan, North Campus, Ann Arbor

    WHEN: Tuesday, June 18, 3:00 pm.
    WHERE: Room 402, Computer Center, Michigan State University, East Lansing

REGISTRATION (for the three meetings): E-mail bedemotour@be.com. Tell us your name, the names of the people coming with you, and the meeting name (UM/Monday, ACAL/UM Meeting, or MSU Meeting). If you don't register, admission will be on a first-come, first-served basis.

    Be will attend the MacHack conference in Dearborn, Michigan, and show off the BeBox from June 19 to 22. See you there!


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.

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:

   0x3010   RAM size, in bytes
   0x301C   Pointer 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:

   Name               Type       Description
   "pci_table_v5"     pci_info   PCI 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"      bool       Flag: mount only kernel vol
   "boot_kvol_only"   bool       Flag: check only kvol
                                 for a bootable system
   "debug_output"     bool       SERIAL4 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.

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

   Start        Size         Description
   0x00000000   0x40000000   Physical RAM
   0x40000000   0x40000000   Other system memory 
                              (motherboard glue regs)
   0x80000000   0x00800000   ISA I/O
   0x81000000   0x3E800000   PCI I/O
   0xBFFFFFF0   0x00000010   PCI/ISA interrupt acknowledge
   0xC0000000   0x3F000000   PCI memory
   0xFF000000   0x01000000   ROM/flash

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(TM), 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:

   0x7ffff0f0   CPU 0 interrupt mask
   0x7ffff1f0   CPU 1 interrupt mask
   0x7ffff2f0   Interrupt sources
   0x7ffff3f0   Cross-processor interrupts, processor ID
   0x7ffff4f0   Processor 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
     3    Not used
     4    IRQ4, a/k/a SERIAL1
     5    IRQ3, a/k/a SERIAL2
     6    SERIAL3
     7    SERIAL4
     8    MIDI1
     9    MIDI2
     10   SCSI
     11   PCI slot 1
     12   PCI slot 2
     13   PCI slot 3
     14   Sound
     15   IRQ1, a/k/a Keyboard
     16   IRQ8, a/k/a Real-Time Clock
     17   IRQ5
     18   IRQ6, a/k/a Floppy Disk
     19   IRQ7, a/k/a Parallel Port
     20   IRQ9
     21   IRQ10
     22   IRQ11
     23   IRQ12, a/k/a Mouse
     24   IRQ14, a/k/a IDE
     25   IRQ15
     26   8259 (ISA-compatible interrupt controller)
     27   Infrared Controller
     28   A2D Converter
     29   GeekPort
     30   Not used
     31   Not used

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

    Bit#  Interrupt Source
     0    (Used for setting/clearing individual bits)
     1    0 - deassert /SMI to CPU 0, 1 - assert it
     2    0 - deassert /SMI to CPU 1, 1 - assert it
     3    Not used
     4    0 - assert /TLBISYNC to CPU 0, 1 - deassert it
     5    0 - 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)
     1    0 - assert /SRESET to CPU 1, 1 - deassert it
     2    0 - assert /HRESET to CPU 1, 1 - deassert it
     3    FLUSHREQ workaround (see below)
     4    not used
     5    not used
     6    not used
     7    disk 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.

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


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 cfleming@alleg.edu.

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.

Copyright ©1997 Be, Inc. Be is a registered trademark, and BeOS, BeBox, BeWare, GeekPort, the Be logo and the BeOS logo are trademarks of Be, Inc. All other trademarks mentioned are the property of their respective owners. Comments about this site? Please write us at webmaster@be.com.