[Bug 2020] Provide support for the PPC 440

[bugzilla-daemon at rtems.org]

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

--- Comment #14 from Ric Claus <claus at SLAC.Stanford.edu> 2012-02-22 12:32:02 CST ---
(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)
> > > > > 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?

I understand, Joel, but at the moment (especially today) I have a lot on my
plate, so please give me some time.  I'll get to it as soon as I can, and I
don't right now when that will be.

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