[U-Boot] ppc: using d-cache for C stack and as cache at the same time?

[U-Boot] ppc: using d-cache for C stack and as cache at the same time?

[Jens Gehrlein]

Hi,

AFAIK, while running from flash, u-boot uses (part of) d-cache on some
platforms for the C stack. I think, it's on MPC83xx and MPC85xx?

Does anybody know, if I can use the remaining part of the d-cache
as normal d-cache, e.g. to generate bursts on the SDRAM interface
while testing the RAM?

Kind regards,
Jens

[U-Boot] ppc: using d-cache for C stack and as cache at the same time?

[Wolfgang Denk]

Dear Jens Gehrlein,

In message <49D323E5.9080100@tqs.de> you wrote:
> 
> AFAIK, while running from flash, u-boot uses (part of) d-cache on some
> platforms for the C stack. I think, it's on MPC83xx and MPC85xx?
> 
> Does anybody know, if I can use the remaining part of the d-cache
> as normal d-cache, e.g. to generate bursts on the SDRAM interface
> while testing the RAM?

On which platform?

Note that implementing a memory test  that  actually  triggers  burst
mode  accesses  is really, really tricky. You probably do NOT want to
do this while running from flash  (i.  e.  from  a  very  restrictive
envrionment).  You  might want to have a look at examples/test_burst*
but note that this code was written for a MPC8xx system,  so  changes
will be required for 83xx or 85xx.

Also note that a much more reliable test for burst mode errors is to
boot Linux with root file system over NFS and then compile the Linux
kernel on the target.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Bus error -- driver executed.

[U-Boot] ppc: using d-cache for C stack and as cache at thesame time?

[Liu Dave-R63238]

> > AFAIK, while running from flash, u-boot uses (part of) 
> d-cache on some
> > platforms for the C stack. I think, it's on MPC83xx and MPC85xx?
> > 
> > Does anybody know, if I can use the remaining part of the d-cache
> > as normal d-cache, e.g. to generate bursts on the SDRAM interface
> > while testing the RAM?
> 
> On which platform?
> 
> Note that implementing a memory test  that  actually  triggers  burst
> mode  accesses  is really, really tricky. You probably do NOT want to
> do this while running from flash  (i.  e.  from  a  very  restrictive
> envrionment).  You  might want to have a look at examples/test_burst*
> but note that this code was written for a MPC8xx system,  so  changes
> will be required for 83xx or 85xx.
> 
> Also note that a much more reliable test for burst mode errors is to
> boot Linux with root file system over NFS and then compile the Linux
> kernel on the target.

It needs case by case.

* 83xx, the whole d-cache is locked
If you need generate bursts on DRAM interface, you have to change to
way locked. Otherwise, you can use the DMA to generate burst.

* 85xx, half of d-cache is locked.
it is possible to generate the burst at 85xx.
Try to use dcbf....

Thanks, Dave

[U-Boot] ppc: using d-cache for C stack and as cache at thesame time?

[Jens Gehrlein]

Liu Dave-R63238 schrieb:
>>> AFAIK, while running from flash, u-boot uses (part of) 
>> d-cache on some
>>> platforms for the C stack. I think, it's on MPC83xx and MPC85xx?
>>>
>>> Does anybody know, if I can use the remaining part of the d-cache
>>> as normal d-cache, e.g. to generate bursts on the SDRAM interface
>>> while testing the RAM?
>> On which platform?
>>
>> Note that implementing a memory test  that  actually  triggers  burst
>> mode  accesses  is really, really tricky. You probably do NOT want to
>> do this while running from flash  (i.  e.  from  a  very  restrictive
>> envrionment).  You  might want to have a look at examples/test_burst*
>> but note that this code was written for a MPC8xx system,  so  changes
>> will be required for 83xx or 85xx.
>>
>> Also note that a much more reliable test for burst mode errors is to
>> boot Linux with root file system over NFS and then compile the Linux
>> kernel on the target.
> 
> It needs case by case.
> 
> * 83xx, the whole d-cache is locked
> If you need generate bursts on DRAM interface, you have to change to
> way locked. Otherwise, you can use the DMA to generate burst.

Good idea.

> * 85xx, half of d-cache is locked.
> it is possible to generate the burst at 85xx.
> Try to use dcbf....

Thank you for the hints.

Kind regards,
Jens

[U-Boot] ppc: using d-cache for C stack and as cache at thesame time?

[Peter Tyser]

On Wed, 2009-04-01 at 17:29 +0800, Liu Dave-R63238 wrote:
> > > AFAIK, while running from flash, u-boot uses (part of) 
> > d-cache on some
> > > platforms for the C stack. I think, it's on MPC83xx and MPC85xx?
> > > 
> > > Does anybody know, if I can use the remaining part of the d-cache
> > > as normal d-cache, e.g. to generate bursts on the SDRAM interface
> > > while testing the RAM?
> > 
> > On which platform?
> > 
> > Note that implementing a memory test  that  actually  triggers  burst
> > mode  accesses  is really, really tricky. You probably do NOT want to
> > do this while running from flash  (i.  e.  from  a  very  restrictive
> > envrionment).  You  might want to have a look at examples/test_burst*
> > but note that this code was written for a MPC8xx system,  so  changes
> > will be required for 83xx or 85xx.
> > 
> > Also note that a much more reliable test for burst mode errors is to
> > boot Linux with root file system over NFS and then compile the Linux
> > kernel on the target.
> 
> It needs case by case.
> 
> * 83xx, the whole d-cache is locked
> If you need generate bursts on DRAM interface, you have to change to
> way locked. Otherwise, you can use the DMA to generate burst.
> 
> * 85xx, half of d-cache is locked.
> it is possible to generate the burst at 85xx.
> Try to use dcbf....

You should be able to use the 85xx DMA engine to generate the bursts too
(I'd assume the same for 83xx, but never tried it).  See
cpu/mpc85xx/cpu.c dma_*().  The default values of the satr0 and datr0
don't allow the processor to snoop transactions, so you'd have to use
cache operations or change datr0/satr0 to something like 0x50000 for
your tests.

We've added a very basic DMA test to the mtest command which is used for
board testing here.  Let me know if you'd like me to send it - its not
cleaned up but could give you a starting point.

Best,
Peter

[U-Boot] ppc: using d-cache for C stack and as cache at thesame time?

[Jens Gehrlein]

Peter Tyser schrieb:

> You should be able to use the 85xx DMA engine to generate the bursts too
> (I'd assume the same for 83xx, but never tried it).  See
> cpu/mpc85xx/cpu.c dma_*().  The default values of the satr0 and datr0
> don't allow the processor to snoop transactions, so you'd have to use
> cache operations or change datr0/satr0 to something like 0x50000 for
> your tests.
> 
> We've added a very basic DMA test to the mtest command which is used for
> board testing here.  Let me know if you'd like me to send it - its not
> cleaned up but could give you a starting point.

Although, I will not start before next month with burst testing, it
would be very nice, if could send it. Thank you very much.

Kind regards,
Jens

[U-Boot] ppc: using d-cache for C stack and as cache at the same time?

[Jens Gehrlein]

Dear Wolfgang Denk,

Wolfgang Denk schrieb:
> Dear Jens Gehrlein,
> 
> In message <49D323E5.9080100@tqs.de> you wrote:
>> AFAIK, while running from flash, u-boot uses (part of) d-cache on some
>> platforms for the C stack. I think, it's on MPC83xx and MPC85xx?
>>
>> Does anybody know, if I can use the remaining part of the d-cache
>> as normal d-cache, e.g. to generate bursts on the SDRAM interface
>> while testing the RAM?
> 
> On which platform?
> 
> Note that implementing a memory test  that  actually  triggers  burst
> mode  accesses  is really, really tricky. You probably do NOT want to
> do this while running from flash  (i.  e.  from  a  very  restrictive
> envrionment). 

Why not? Of course, it's only possible if I can use a part of the
D-Cache as C stack (or another internal RAM if available). This must
be separately checked for each processor.

> You  might want to have a look at examples/test_burst*
> but note that this code was written for a MPC8xx system,  so  changes
> will be required for 83xx or 85xx.

Thank you for the hint. I'll have a look.

> Also note that a much more reliable test for burst mode errors is to
> boot Linux with root file system over NFS and then compile the Linux
> kernel on the target.

I agree.

Kind regards,
Jens