Problem with data cache on MPC823E

Problem with data cache on MPC823E

[Jan Damborsky]

Hello people,

we have developed our board with MPC823E, FLASH memory
DRAM memory for embedded Linux porting, but we have problem
with data cache. From time to time when CPU wants load data from DRAM
to data cache, it makes four burst-reads instead of one for loading one
cache line.
After this, all four words in cache line are loaded with the same first
"critical word".
We don't know, why CPU repeats this burst-read four times. May be it is
because we have floating BI (burst inhibit) CPU singnal.
We have set BIH bit in UPMA to zero.
When setting this BIH bit to one (burst inhibit), all works well.
Does anybody have any help ?
                                                     Jan Damborsky


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem with data cache on MPC823E

[Wolfgang Denk]

In message <3E2D751C.7000001@devcom.cz> you wrote:
>
> we have developed our board with MPC823E, FLASH memory
> DRAM memory for embedded Linux porting, but we have problem
> with data cache. From time to time when CPU wants load data from DRAM
> to data cache, it makes four burst-reads instead of one for loading one
> cache line.
> After this, all four words in cache line are loaded with the same first
> "critical word".
> We don't know, why CPU repeats this burst-read four times. May be it is
> because we have floating BI (burst inhibit) CPU singnal.
> We have set BIH bit in UPMA to zero.
> When setting this BIH bit to one (burst inhibit), all works well.
> Does anybody have any help ?

This pheomenon is typical for bad SDRAM initialization. Read the chip
manufacturer's manual and follow  the  steps  of  the  init  sequence
_to_the_letter_. It is _not_ sufficient to set up the UPM tables.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Committee, n.:  A group of men who individually can do nothing but as
a group decide that nothing can be done.                 - Fred Allen

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Problem with data cache on MPC823E

[Wells, Charles]

Jan,

The following question assumes that your DRAM is physically organized as
32-bits wide and connected to CS1.

Do you have the PS field of BR1 set to 00 (32-bit mode) or is it set to 01
(8-bit mode)? If it's set to 8-bit mode, a burst access becomes 16 bus
cycles, which looks a lot like 4 bursts.

Regards,
Charlie

-----Original Message-----
From: Jan Damborsky [mailto:Jan.Damborsky@devcom.cz]
Sent: Tuesday, January 21, 2003 11:28 AM
To: linuxppc-embedded@lists.linuxppc.org
Subject: Problem with data cache on MPC823E



Hello people,

we have developed our board with MPC823E, FLASH memory
DRAM memory for embedded Linux porting, but we have problem
with data cache. From time to time when CPU wants load data from DRAM
to data cache, it makes four burst-reads instead of one for loading one
cache line.
After this, all four words in cache line are loaded with the same first
"critical word".
We don't know, why CPU repeats this burst-read four times. May be it is
because we have floating BI (burst inhibit) CPU singnal.
We have set BIH bit in UPMA to zero.
When setting this BIH bit to one (burst inhibit), all works well.
Does anybody have any help ?
                                                     Jan Damborsky


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem with data cache on MPC823E

[Jan Damborsky]

Wells, Charles wrote:

>Jan,
>
>The following question assumes that your DRAM is physically organized as
>32-bits wide and connected to CS1.
>
>Do you have the PS field of BR1 set to 00 (32-bit mode) or is it set to 01
>(8-bit mode)? If it's set to 8-bit mode, a burst access becomes 16 bus
>cycles, which looks a lot like 4 bursts.
>
>Regards,
>Charlie
>
>
Yes,
DRAM is organized as 32-bits wide and connected to CS2 (PS field of BR2
is set to 00 - 32 bit mode).
The problem is that burst access becomes 16 bus cycles only from time to
time. And this problem
occurs only when accessing data cache. Instruction cache use always
correct 4 bus cycle bursts.
          Thanks,
          Jan


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem with data cache on MPC823E

[Jan Damborsky]

>
>
>This pheomenon is typical for bad SDRAM initialization. Read the chip
>manufacturer's manual and follow  the  steps  of  the  init  sequence
>_to_the_letter_. It is _not_ sufficient to set up the UPM tables.
>
>Best regards,
>
>Wolfgang Denk
>
>
>
But we dont use SDRAM, but DRAM EDO SIMM module. I think these RAM types
dont require special initialization.

Thanks,
Jan Damborsky


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Problem with data cache on MPC823E

[Jan Damborsky]

Wells, Charles wrote:

>Jan,
>
>While reviewing your original email, I noticed the following statement.
>
>
>
>>May be it is because we have floating BI (burst inhibit) CPU singnal.
>>
>>
>
>My MPC823UM manual (Rev 1, p. 13-36, section 13.4.9.2 BURST INHIBIT SIGNAL)
>states the following:
>
>    "This signal must be pulled up to Vdd with a pullup resistor."
>
>This is shown in figure 13-24.  Have you tried adding a pullup resistor?
>
I think it is the reason, why our board behaves so erraticaly (we have
developed our board with
MPC823UM Revision 0, there is only "should be pulled up", but in
Revision 1 is "must be pulled up",
so we have to base our next development on newest documentation - like
it "must be" always).
Because when I set BIH bit in OR register, there are no problems. I
think because there are no bursts.
But solution of this problem is not so trivial. Because MPC823 is in BGA
package and BI signal
is unconnected, the appropriate pin is unreachable. So I am not sure we
will be successful
in connecting BI to pullup, may be we will be forced to create new PCB,
but it is future.

>Also, where did you get your UPM table for DRAM?

We have derived UPM settings from Motorola MPC823ADS documentation,
and verified them in Motorola graphical software for UPM settings
visualisation, so I think it is OK.

                                                                Thank
you for your help very much,

                Jan Damborsky


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/