[Bug 2020] Provide support for the PPC 440

[bugzilla-daemon at rtems.org]

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

--- Comment #19 from Ric Claus <claus at SLAC.Stanford.edu> 2012-02-22 15:54:45 CST ---
(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)
> > > > > > 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.

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.

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