[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Intec Automation SS555 Port



Our company is currently porting RTEMS to the MPC555-based Intec Automation
SS555 board.  Our customer would like us to ensure that the port will be
acceptable for integration into the official RTEMS project sources.

To that end, we'd like to present some of the design decisions we've made for
review by the RTEMS community:

  - The existing MPC555 RCPU work (in cpukit/score/cpu/powerpc) seems
    nearly complete.  We'll add the power-down mode and base interrupt
    vectors to complete it.
 
  - We've chosen the c/src/lib/libcpu/powerpc/mpc8xx CPU-dependent code as
    the basis of our MPC555 CPU-dependent code.  The MPC8xx code follows the
    "new exceptions" model of exception and interrupt handling, and appears
    to be the most up-to-date in other minor ways, as well.

  - We've chosen the c/src/lib/libbsp/powerpc/mbx8xx BSP as the basis of our
    Intec SS555 BSP.  The mbx8xx BSP uses the MPC8xx CPU-dependent code,
    which, as noted above, is the most current.

  - Unlike in the mbx8xx BSP, we've decided to push the exception and
    interrupt handling code up to the CPU-dependent level.  This will reduce
    the amount of needlessly duplicated code in MPC5xx BSP's.  This also
    makes sense since with this highly-integrated CPU, it's less likely that
    a user will make the interrupt handling board-dependent by using an
    external interrupt controller.

    We will retain the c/src/lib/libbsp/powerpc/ss555/irq/irq.h file, but it
    will consist largely of a #include of the CPU-dependent definitions, and
    some macros to re-map the function names.

  - All of the existing PowerPC ports appear to assume that the vector table
    is in RAM, and thus copy the interrupt handler prologues into place at
    system initialization time.  This won't work for the MPC555, since the
    vector table is in Flash ROM.  The MPC555 exception prologues will thus
    be hard-coded at build time.

    The existing scheme does, however, have the advantage of being able to
    modify exception handlers at runtime.  Our port will retain this feature
    by adding a table of exception handler pointers through which the
    exception prologue code will vector to get to the proper handler for
    each exception.

  - Since we have to rewrite the exception prologues anyway, we've decided
    to use the MPC555 compressed interrupt vector table feature.  This will
    save the better part of 8k of Flash ROM.

  - The two-level MPC5xx interrupt controller will be handled similarly to
    the way that the interrupt controller in the MPC8xx is handled, as in
    c/src/lib/libbsp/mbx8xx/irq/irq.[ch].

  - Unlike the existing PowerPC ports, we will support execution directly
    from Flash ROM.  In addition to the exception table rework described
    above, this requires relocating the global offset tables to Flash ROM to
    minimize RAM usage, and requires arranging for the reloading of
    initialized C variables at each reset.

  - We've chosen SCI2 as the default console, since SCI1 has extra features
    that may be wanted by the application code.  This choice can be easily
    changed, if desired.  Console configuration (port choice,
    polled/interrupt, termios yes/no) will be done at build time in a
    similar way to the MPC8xx ports.

  - The system clock will be provided by the MPC5xx programmable interval
    timer (PIT) as is the case in the MBX8xx port.

  - Statistics timing will be provided by the PowerPC timebase register, as
    is the case in the MBX8xx port.

We would value your comments and suggestions on the above, as we would like
to maximize code commonality and minimize integration effort when the port
is ready for contribution to the RTEMS project.

Regards,

David Querbach
Real-Time Systems Inc.
www.realtime.bc.ca
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://rtems.rtems.org/pipermail/rtems-users/attachments/20040205/ecfcb123/attachment.bin