Intec Automation SS555 Port

[Joel Sherrill]

 From your description, I see no technical reason why this wouldn't
be an acceptable submission.  I see no mention of modifications
to anything that should impact other CPUs or BSPs.

The biggest issues facing this submission will be dealing with
merging it.  There are two issues there.

(1) The development trunk where this would be merged has had a
LOT of work done on the configure and make infrastructure and
this will have to be addressed.  The best approach here is to
merge it against the next snapshot which will be coming as soon
as some test sweeps are completed.  All testing was focused on
4.6.0 so the snapshot side needs some sanity checking.

(2) There is some other mpc5xx work from Wilfried Busalski which
has not been merged.  Any conflicts or overlaps between that and
yours will have to be addressed.  I can send that to you directly
and you can merge it with your work.  Hopefully you will be submitting
soon and I will only have to merge one submission will deal with both.

When is this expected to be submitted?

How is the performance?

--joel


David Querbach wrote:

> 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