[Bug 2020] Provide support for the PPC 440

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Thu Feb 23 02:39:16 CST 2012


https://www.rtems.org/bugzilla/show_bug.cgi?id=2020

--- Comment #27 from Sebastian Huber <sebastian.huber at embedded-brains.de> 2012-02-23 02:39:16 CST ---
(In reply to comment #19)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > (In reply to comment #12)
> > > > The problem is that in the BSP area so much is without documentation.  No need
> > > > to say sorry if you cause some trouble.
> > > > 
> > > > (In reply to comment #10)
> > > > > (In reply to comment #8)
> > > > > > (In reply to comment #5)
[...]
> > > > etc.).  Please have a look at
> > > > "cpukit/score/cpu/powerpc/rtems/powerpc/registers.h".  This file can be used in
> > > > assembler and C files.
> > > 
> > > Would you be happy if the code from here until right before the "endif ASM"
> > > were moved to registers.h?
> > > 
> > > -#if defined(ppc403) || defined(ppc405)
> > > -/* the following SPR/DCR registers exist only in IBM 400 series */
> > > 
> > > If I moved that, where do you want it in registers.h?

We already have a lot of defines for the special purpose registers defined in
your "cpukit/score/cpu/powerpc/rtems/asm.h" additions.  You should use the
existing defines in "cpukit/score/cpu/powerpc/rtems/powerpc/registers.h" and
add only the missing ones with a proper name space prefix, e.g. "#define
BOOKE_DBCR0 308".  If you need your defines added to
"cpukit/score/cpu/powerpc/rtems/asm.h", then please move the definitions in a
BSP specific header file (out of cpukit).

> > > 
> > > FWIW the style of register name constants is not the same and it could easily
> > > be argued that one should unify the style of names while merging.

No, this may break applications.  I would do this only if absolutely necessary.
 There is some history here and things were much worse as they are today.

[...]
> When I started, the e500_category_table looked rather different from what it
> does now.  However, there are still these entries that are in addition to the
> ones that are appropriate to the 440:
> 
>   [ASM_E500_SPE_UNAVAILABLE_VECTOR] = PPC_EXC_CLASSIC,
>   [ASM_E500_EMB_FP_DATA_VECTOR] = PPC_EXC_CLASSIC,
>   [ASM_E500_EMB_FP_ROUND_VECTOR] = PPC_EXC_CLASSIC,
>   [ASM_E500_PERFMON_VECTOR] = PPC_EXC_CLASSIC
> 
> It's not clear to me what the effect of those would be.

The category table provides you with the properties of a exception number.  It
gives an answer to:  What exception properties has exception number X?  In case
of the PPC440 this will add support for four unsupported exceptions and waste
some bytes of RAM.  You only have to make sure, that you don't access invalid
IVORs in ppc_exc_initialize_booke().

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.


More information about the rtems-bugs mailing list