[U-Boot] [PATCH] POST: Added ECC memory test for mpc83xx.

[Joakim Tjernlund]

Kim Phillips <kim.phillips at freescale.com> wrote on 2010-04-08 10:27:03:
>
> On Thu, 8 Apr 2010 09:49:08 +0300
> Michael Zaidman <michael.zaidman at gmail.com> wrote:
>
> > On Wed, Apr 7, 2010 at 7:01 PM, Joakim Tjernlund
> > <joakim.tjernlund at transmode.se> wrote:
> > >>
> > >> On Wed, Apr 7, 2010 at 6:10 PM, Timur Tabi <timur.tabi at gmail.com> wrote:
> > >> > On Wed, Apr 7, 2010 at 9:47 AM, Michael Zaidman
> > >> > <michael.zaidman at gmail.com> wrote:
> > >> >
> > >> >> The version #2 of the patch is located here
> > >> >> http://lists.denx.de/pipermail/u-boot/2010-April/069579.html
> > >> >
> > >> > What is ppcDWstore(), and why do you use it sometimes instead of
> > >> > __raw_writel()?  I see the code for ppcDWstore:
> > >> >
> > >> >        .globl  ppcDWstore
> > >> > ppcDWstore:
> > >> >        lfd     1, 0(r4)
> > >> >        stfd    1, 0(r3)
> > >> >        blr
> > >> >
> > >> > I just don't understand why it exists.
> > >> >
> > >>
> > >> This is the fastest way to copy 64 bit words.
> > >
> > > hmm, not all boards have a FPU(8xx and 832x). How are lfd and stfd handled
> > > there?
> > >
> > >  Jocke
> > >
> > The ppcDWstore/ ppcDWload code is mpc83xx specific, so the mpc8xx is
> > not relevant here. The e300c1 and e300c3 have FPU while e300c2 has
>
> right (which also suggests it's badly named (at least since the advent
> of the e300c2)).
>
> > not. The lfd/stfd instructions load/store data from/to memory to/from
> > FPRs. It looks like these instructions are performed by Load/Store
> > Unit and rather require FPRs presence than FPU.  The block diagram of
> > the e300c2 core in the e300coreRM (Rev3, 12/2006) specifies FPR File
> > and its connection to the Load/Store Unit. On other hand the
> > "1.3.1.1.2 Floating-Point Registers (FPRs)" chapter says that FPRs are
> > not included in the e300c2 core. Can someone clarify this?
>
> The documentation is confusing: the e300c2 has its FPU chopped off -
> the FP registers are simply not there.
>
> this is a good catch by Jocke - it would be best if generic 83xx code
> didn't depend on the ppcDW* accessors.

That or one could impl. ppcDW* using normal load/store insns for 832x.
Either way the ppcDW* should be inlined as the overhead for doing
function calls isn't something you want when looking for speed.

     Jocke