[Bug 2020] Provide support for the PPC 440

[bugzilla-daemon at rtems.org]

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

--- Comment #13 from Joel Sherrill <joel.sherrill at oarcorp.com> 2012-02-22 11:51:58 CST ---
(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)
> > > > This is not acceptable (multi-lib violation):
> > > > 
> > > > diff --git a/cpukit/score/cpu/powerpc/rtems/asm.h
> > > > b/cpukit/score/cpu/powerpc/rtems/asm.h
> > > > index d54c060..e6b90ec 100644
> > > > --- a/cpukit/score/cpu/powerpc/rtems/asm.h
> > > > +++ b/cpukit/score/cpu/powerpc/rtems/asm.h
> > > > @@ -204,6 +204,83 @@
> > > >  #define br5     0x085   /* DCR: memory bank register 5             */
> > > >  #define br6     0x086   /* DCR: memory bank register 6             */
> > > >  #define br7     0x087   /* DCR: memory bank register 7             */
> > > > +
> > > > +#elif defined(ppc440)
> > > 
> > > This file already had special register definitions for other PowerPC CPU
> > > models. Do you have somewhere else to move them to?  
> > 
> > Me?  I just tried to follow the existing pattern...
> 
> Existing patterns in RTEMS are sometimes best to avoid.  In this particular
> case the main issue is that you introduce a new pre-processor dependency in the
> cpukit.  The aim of the cpukit is to only depend on a particular GCC multi-lib
> provided by the tool chain.  The multi-libs provide the libc.a, libm.a, etc. in
> a particular instruction set (e.g. classic PowerPC, Book E PowerPC, with SPE,
> 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?

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.

I can take care of this (not sure when) but need a solution path.

> > > This is only used as an assembly support file. This isn't a problem for this
> > > particular PR. This isn't directly a problem but using these inside cpukit
> > > probably would.
> > > 
> > > > Why introduce ppc_booke_category_table?  I think you can use
> > > > e500_category_table instead.
> > > 
> > > This one I don't know how to solve. Sebastian/Ric ..
> > 
> > Sorry, I don't know either.  If e500_... is to be used then I suggest that it
> > has an inappropriate name.
> 
> Yes, but this has historic reasons.  The e500 is a PowerPC core from Freescale
> implementing the Book E instruction set.

Sebastian.. what do you think the solution should be?

+ Are you saying ppc_booke_category_table is the same as
ppc_e500_category_table and the ppc440 should return the e500 one and we delete
the booke copy?
+ Should ppc_booke_category_table be renamed ppc_ppc440_category_table?

Naming is hard but if ppc440 can use the same table as e500, that's the first
step. Second is finding a better name.

Ric.. the important question to you is.. can you run what is merged? Is it a
complete and correct merge?

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