Porting Advice for phycore_mpc5554

Thu Aug 24 09:35:03 UTC 2006

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

John,

John Wood schrieb:
> 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.     

Adding an additional field to the irq_connect structure seems sensible
if you look at your current port, and it would be nice to have it
anyway. But if the irq_connect structure looks differently on different
ports, the common API will be broken and portability of drivers will be
more difficult. Currently there are some drivers in "c/src/libchip",
which are shared between BSPs. One example is the ATA/ driver, which
might also be useful for some MPC5554 targets.

If you extend the irq_connect structure, this driver will no longer work
reliably on a MPC5554 target, because it does not properly fill the "irq
priority" field.

I see two possible solutions:

1.) either the irq_connect structure will be extended with a "irq
priority" field, that is used on some targets and ignored on others.

2.) or you add the irq priority into the upper 8 bits of the interrupt
vector number (or "irq name" it is called, i think). This can be done
specific for the MPC5554 port with some nice macros, and would work
transparently for the irq_connect code. Some macros like:

#define MPC55XX_MAKE_IRQ_NAME (vec,prio)\
(((prio)&0xff)<<24)||((vec)&0x0000ffff)

#define MPC5XX_GET_VEC_FORM_IRQ_NAME(name)  ((name) & 0x0000ffff)
#define MPC5XX_GET_PRIO_FORM_IRQ_NAME(name) (((name)>>24) & 0x0000ff)

should do the job. Please note: the names I have choosen will not be the
best ones, please choose them to your taste.

I am not sure which way is the better one. My (and your) first proposal
would be nicer, but the second one would require no changes to existing
code for other targets. Therefore, I would tend to go the second way.

wkr,
Thomas Doerfler.

> 
> 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
> 
> 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

- --
- --------------------------------------------
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

iD8DBQFE7XLHwHyg4bDtfjQRAnDZAKCNUUHy3nNRfGdqqHBRL2m41pP4iACfSlIS
VU9q94Wo8nBGAUVLquVhdwQ=
=rAfc
-----END PGP SIGNATURE-----