Porting Advice for phycore_mpc5554

[John Wood]

Thanks Tom,

That makes sense. I have built an mpc5554 based port with no code
changed from the ss555 just to make sure my build environment is sane.
I am reworking the irq section of the code now.  After looking at the
rtems_irq_connect_data structure there appears to be no simple way to
pass in desired interrupt priority.  On the new INTC controller the
level is not dictated by where the ISR is installed.  

What would be the best approach to passing this data in?  Am I missing a
priority function that already exists.  In the 555 this is all done by
installing a handler into a specific location.  

My preferred method would be to add an additional field to the structure
with an ifdef to build just for BSP and processors which wish to support
it.     

John

 

-----Original Message-----
From: Thomas Doerfler [mailto:Thomas.Doerfler at imd-systems.de] 
Sent: Sunday, August 20, 2006 3:34 PM
To: John Wood
Cc: RTEMS Users Mailing List
Subject: Re: Porting Advice for phycore_mpc5554

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John,

the terms "interrupt" and "exception" are used in different ways in the
powerpc documentation. And RTEMS is using its own way to fit these items
to its own terms. So things are a bit difficult to put into the right
place.

Here are some comments:

1.) In curent PPC implementations, the only choice for a task is to
either allow or to disallow the processing of interrupts during task
execution. This is handled using the "EE" bit in the Machine state
register MSR. I personally see no real benefit to have a more granular
choice, and if you decide to do so anyway, the MPC5554 port would be
quite different to the other PPC ports under RTEMS. Therefore I would
recommend to set CPU_MODES_INTERRUPT_LEVEL and CPU_MODES_INTERRUPT_MASK
to 0x0001 (or leave it at the PPC default).

2.) The interrupt definitions in "score/powerpc.h" are more or less
outdated and only used for PPC model implementations using the "old
exception model". Instead of adding stuff there, you should create a new
subdirectory in "c/src/lib/libcpu/mpc55xx" and implement there:
- - drivers for the MPC55xx peripherals
- - code for the exception handling
- - code to get the interrupt controller to work

Each BSP for a MPC55xx board can then use this shared code. Have a look
at the mpc5xx BSP as a structure template.

In the "interrupt controller driver", you will define and handle the
many interrupt sources, and manage the interrupt priorities. It would be
nice to have an interface to assign/reassing interrupt priorities to the
various interrupt sources, but I have no idea now how this can be done.


John Wood schrieb:
> All,
> 
> Unlike other powerpc families, the mpc5554 has 16 interrupt priority 
> levels.
> Additionally, exceptions like the decrementer and timebase and the new

> fixed interval are enabled outside of the interrupt controller.

Having some peripherals on separate exception(!) vectors is not unique
to the MPC5554: In fact, IBM used this concept on some PPC403 and PPC405
derivates. But when peeking into these BSPs, please be careful: They are
still stuck to the "old exception processing" code, so things must be
managed differently for the MPC5554. On the other hand, the decrementer
is on a separate exception for ALL PowerPC cpus, so this is not new on
the MPC5554.

The 16 interrupt levels should be managed in libcpu/poerpc/mpc55xx/irq/*


> 
> I would like to distinguish between interrupt level 15 and when I have

> external interrupts disabled effectively giving me a 17th interrupt 
> level.  How should I set my mask and level macros.

I assume you mean the "mask" and "level" fields used for task context
etc. But IMHO they should not be extended to keep this information, but
only reflect the EE bit of the MSR.

> 
> As a commentary, I have modifed the powerpc.h file in the score 
> directory to include MPC55XX style exceptions and the 300 possible 
> interrupts on the MPC5554.  This file could get out of hand with the 
> definitions done as such, would it make more sense to include a file 
> based upon the processor type and have that file located in the 
> appropriate libcpu directory.

You are right, put this stuff into libcpu.

wkr,
thomas.

> 
> 
> Thanks for any input,
> John


- --
- --------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at:
     http://www.imd-systems.de/pgpkey_en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE6MdJwHyg4bDtfjQRAoX0AJ91VYdIwPLtNMZx6BaPTwG3jMG1YwCePkW3
flemN0/UtbkCxnj2eyFmT7Q=
=HCFH
-----END PGP SIGNATURE-----