|
Be Newsletter
Issue 27, June 12, 1996
Table of Contents
BE DEMO TOUR IN MICHIGAN:
MacHack and Three Demo Meetings
- UNIVERSITY OF MICHIGAN: 2 DEMOS
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
MEETING NAME: UM/Monday
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
MEETING NAME: ACAL/UM Meeting
- MICHIGAN STATE UNIVERSITY: DEMO
WHEN: Tuesday, June 18, 3:00 pm.
WHERE: Room 402, Computer Center, Michigan State
University, East Lansing
MEETING NAME: MSU Meeting
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.
- MACHACK CONFERENCE
Be will attend the MacHack conference in Dearborn,
Michigan, and show off the BeBox from June 19 to 22. See
you there!
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:
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.
HARDWARE MEMORY MAP
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.
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:
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.
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
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.
|
