MPC8260 + L2 Cache: ever been done?

MPC8260 + L2 Cache: ever been done?

[Mike Mager]

[-- Attachment #1: Type: text/plain, Size: 3831 bytes --]

Hello,

Has anyone ever seen an MPC8260-based design with L2
cache run Linux (or any OS) with some semblance of stability?
I know there are several designs out there with an 8260 and
L2, but they usually also have a 750 or some other CPU, and
the L2 is hooked up to that CPU, not the 8260. I've checked the
archives and searched online, but have been unable to find
any information on these two devices working together.

We have an 8260 design running in 60X-compatible mode with
1 to 4 MPC2605 L2 cache devices, and cache size is jumper-
selectable. Also on the 60X bus are a DIMM and a 16-bit flash.
When L2 is turned off, Linux runs fine (we're using 2.4.18).
When 256kB of L2 is enabled, Linux boots partially and then
crashes, either freezing or getting infinite machine checks.
When 512kB or 1MB are enabled, I never see any output from
Linux. We're using PPCBoot 1.1.2 for booting, and the L2 is
turned on in Linux (arch/ppc/kernel/head.S).

Our first concern was the fact that two of the cache control pins
(/WT and /CI) are muxed with BADDR pins that are required on
the flash device. These pins are controlled by the L2CPC bits in
the BCR, and there is an errata for the 8260's user manual that
specifies that these bits (any many others in the BCR) cannot
change after reset. At first we thought we were SOL, so we
called Motorola to see if they had a solution other than going to
a 64-bit flash device. It turns out their ADS board also has L2
cache and a 16-bit flash, and they assured us that their system
works. So they sent us the initialization code and test code they
used to verify that "their system works". It included setting up a
chip select, turning on the L2, initializing the MMU, and then
turning on L1 caches. The test code simply did reads to fill up
the L1 and L2 caches, followed by a flush of the L1. It then did a
read from an address that would still be in the L2. We modified
their init and test code to work with our board (since the 2605
control lines were hooked up differently) and it seems like the L2
works OK. However, this is a simple test that only goes to one
location in memory in an infinite loop. It is not doing instruction
fetches and accessing data from all over memory like Linux does.

So the issue now is that our board seems to behave like
Motorola's board when running some very basic code and
enabling L2. But under Linux, our board hangs. (We placed the
init code for the L2 that Motorola provided us in head.S) The
difficult part about debugging this problem is that Linux crashes
in different ways at different times, so I've been unable to trigger
on the condition that causes this problem. It seems to me that
the L2 is simply returning bad data, which sends the OS into
the weeds.For what it's worth, we've also ported OS-9 to this
board, and it eventually crashes as well if the L2 is enabled.

Also, in the 8260's user manual it says (on page 11-7) "For
systems that use copy-back mode, all cachable memory regions
must be marked as global in the CPU's MMU and the CPM's
RBA." Since we are using copy-back mode, I believe this infers
that the M bit in the BATs and PTEs must be set, enforcing
coherency. However, from what I've seen, the only way to get
Linux to do this (without hacking it) is to enable SMP. I did so
but that did not appear to solve the problem. But is that the right
thing to do?

Some other info: We've tried running the system in write-through
mode with the same results. We've done this test with two
versions of the 8260, mask A.1 and the new HiP4 (2k25a). And
the CPM fifos are all either in local bus RAM or DPRAM in order
to keep the CPM off the 60X bus (which causes other problems).

If anyone has any answers, ideas, or insights into this problem,
they'd be greatly appreciated.

Thanks!

Mike Mager
Digital Design Engineer
CARTS, LLC

[-- Attachment #2: Type: text/plain, Size: 1 bytes --]

Re: MPC8260 + L2 Cache: ever been done?

[Wolfgang Denk]

Dear Mike,

in message <5.1.0.14.2.20020422102923.00af7550@carts.com> you wrote:
>
> Has anyone ever seen an MPC8260-based design with L2
> cache run Linux (or any OS) with some semblance of stability?

Ummm.... you should improve your internal  communication:  Kevin  Fry
<kevin@carts.com>  has asked the same question just 2 days ago, and I
replied:

Yes, for example the TQM8260 modules come in some configurations with
L2 cache. It's a shipping product which runs 100% stable.

> I know there are several designs out there with an 8260 and
> L2, but they usually also have a 750 or some other CPU, and
> the L2 is hooked up to that CPU, not the 8260. I've checked the
> archives and searched online, but have been unable to find
> any information on these two devices working together.

It's working here.

> We have an 8260 design running in 60X-compatible mode with
> 1 to 4 MPC2605 L2 cache devices, and cache size is jumper-

There is only 1 x MPC2605 om the TQM8260 modules.

> selectable. Also on the 60X bus are a DIMM and a 16-bit flash.
> When L2 is turned off, Linux runs fine (we're using 2.4.18).
> When 256kB of L2 is enabled, Linux boots partially and then
> crashes, either freezing or getting infinite machine checks.
> When 512kB or 1MB are enabled, I never see any output from
> Linux. We're using PPCBoot 1.1.2 for booting, and the L2 is
> turned on in Linux (arch/ppc/kernel/head.S).

Never tried it with more than 256kB of L2; but you can check out  and
compare with the TQM8260_L2 resp. TQM8260_L2_266MHz configurations in
PPCBoot.

> location in memory in an infinite loop. It is not doing instruction
> fetches and accessing data from all over memory like Linux does.

Are you really sure it's a cache issue? So far I have seen many  more
cases  where  the  real  cause  of  the  problem  was  improper SDRAM
operation (failing in burst mode).

> init code for the L2 that Motorola provided us in head.S) The
> difficult part about debugging this problem is that Linux crashes
> in different ways at different times, so I've been unable to trigger

That just means you have a  memory  problem,  which  _can_  be  cache
related.

> Some other info: We've tried running the system in write-through
> mode with the same results. We've done this test with two
> versions of the 8260, mask A.1 and the new HiP4 (2k25a). And
> the CPM fifos are all either in local bus RAM or DPRAM in order
> to keep the CPM off the 60X bus (which causes other problems).

It works here for C.2 [6K23A] and A.0(A) [2K25A]; on the  TQM8260  we
cannot  enable  L2  on the A.0 [K22A] because the CPM (running at 133
MHz) has DMA problems there, and we  cannot  easily  reduce  the  CPM
speed to <100MHz on this board.

> If anyone has any answers, ideas, or insights into this problem,
> they'd be greatly appreciated.

All I can say is: it works for us on the only board that I have  with
L2 cache on it...

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Lack of skill dictates economy of style.                - Joey Ramone

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