I am working on a port to the Motorola MPC821/823/860 family of chips.  The
initial target platform is the Motorola MBX821 and MBX860 boards.

The MPC821/823/860 chips are derived from the PowerPC, with two major
differences:

  1. The MMU is more of a classical two-level page directory / page table
  system, rather than the segment register / hash table system of the PPC600
  series.

  2. These chips have no floating point unit, thus have no floating point
  instructions.

The MBX821 and MBX860 boards do not conform to PREP or CHRP, nor do they
offer Open Firmware support.  They do provide sophisticated bootstrapping
services (Flash ROM, floppy disk, hard disk, ethernet with BOOTP and TFTP),
but provide very few services to the loaded program -- mostly polled console
input and output.

I'm struggling with how to structure the port to take advantage of the
powerpc base code in the kernel.  Three possibilities come immediately to
mind:

  1.  Create a sys/arch/mpc8xx directory which will be the base for the
  actual port in sys/arch/mbx8xx.  The mpc8xx port will symlink to or
  #include files from sys/arch/powerpc where advantageous.  This method,
  however, has the disadvantage of requiring hand-updating of the mpc8xx
  port when files are added to or removed from the powerpc port.

  2.  Split sys/arch/powerpc into sys/arch/powerpc (code common to all
  PowerPC systems) and sys/arch/ppc6xx (code specific to the traditional
  PPC600 series of chips).  To these I would then add sys/arch/mpc8xx (code
  specific to the MPC800 series of chips).  This method might reduce future
  maintenance effort, but would require more care and testing initially.

  3.  Put the new code into the existing sys/arch/powerpc directory, and use
  Makefile switches and conditional compiliation to choose the required
  code for a particular chip.  Create a sys/arch/mbx8xx directory to house
  the board-specific code.

A similar question also arises in lib/libc/arch due to the lack of hardware
floating-point support in the MPC821/823/860 chips.  

I'd like to set this up right the first time, to avoid creating future
maintenance headaches.  Any suggestions would be welcome.

Regards,

David Querbach
Real-Time Systems Inc.