MPC7455 and lwarx

MPC7455 and lwarx

[Dave Wilhardt]

Hello,

Is anyone using the MPC745x series and performing lwarx/stwcx. in non
cached
space?  The 7410 didn't seem to care but the MPC7455 take a DSI
exception
on non cached regions.  Is there a work-around?

- Dave
--
Dave Wilhardt
Synergy Microsystems
9605 Scranton Road, Suite 700
San Diego, CA 92121
858 452-0020 x164


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

Re: MPC7455 and lwarx

[Gabriel Paubert]

Dave Wilhardt wrote:
> Hello,
>
> Is anyone using the MPC745x series and performing lwarx/stwcx. in non
> cached
> space?  The 7410 didn't seem to care but the MPC7455 take a DSI
> exception
> on non cached regions.  Is there a work-around?

No, it is documented somewhere in Motorola docs that lwarx/stwcx. only
work on writeback cacheable space. Earlier processors allow non-cacheable
space, I believe that this restriction was introduced with the 7440/7450.

	Regards,
	Gabriel


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

Re: MPC7455 and lwarx

[Dan Malek]

Gabriel Paubert wrote:

> No, it is documented somewhere in Motorola docs that lwarx/stwcx. only
> work on writeback cacheable space. Earlier processors allow non-cacheable
> space, I believe that this restriction was introduced with the 7440/7450.

There are implementation options in the PowerPC specification that will
produce different "working" behavior when these instructions are not
used properly.  As Gabriel mentioned, the programmer interface specifies
these instrucitons work properly only on cached, writeback data spaces.
This is because the finest granularity implementation is a cache line and
the synchronization information is stored in the cache tag.  Processors
that aren't MP capable, like the 4xx, appear to operate as if they have
a single global flag to support lwarx/stwcx so the cache mode of the
desitination address (and the address itself) is irrelevant.  This
"restriction" has been around forever, MP systems won't work properly
without it (and all 6xx and "bigger" cores are MP capable).

Why do you want to use these instructions on a data space that isn't
cached?  Further, why are you running this class of processor with
uncached memory?

Thanks.


	-- Dan


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

Re: MPC7455 and lwarx

[Dave Wilhardt]

>
>
> Why do you want to use these instructions on a data space that isn't
> cached?  Further, why are you running this class of processor with
> uncached memory?
>

I have a "shared memory" region that is used between VME boards in
a chassis.  The "master pool" is located on the system controller in DRAM.
In order to maintain coherency between the boards, I have marked the region
as non cached.  This was fine for non-MPC745x boards.  Time for a redesign...

- Dave


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

Re: MPC7455 and lwarx

[Gabriel Paubert]

Dave Wilhardt wrote:
>>
>>Why do you want to use these instructions on a data space that isn't
>>cached?  Further, why are you running this class of processor with
>>uncached memory?
>>
>
>
> I have a "shared memory" region that is used between VME boards in
> a chassis.  The "master pool" is located on the system controller in DRAM.
> In order to maintain coherency between the boards, I have marked the region
> as non cached.  This was fine for non-MPC745x boards.  Time for a redesign...


Are you sure that it even worked to start with ? Consider a system with 3
processor boards (processor 1 is the system controller):
- processor 2 does lwarx on the shared memory
- processor 3 does another lwarx before 2 has time to perform the stwcx.
- processor 2 does the stwcx.
- processor 3 does not notice it since the address is taken by processor 1
VME<->PCI bridge and it does not snoop it
- processor 3 does the stwcx. but modifies a stale value, for example a
counter will be incremented once instead of twice, or both processors will
have taken a lock and who knows what the consequences are.

I believe that the scheme could work with 2 master boards accessing shared
memory on one of the boards, never with 3 or more.

As the author of one of the Tundra Universe drivers, I'd suggest using
semaphores to do this. Disclaimer, Ie never used them since several of my
boards have a Universe I (with an impressive list of bugs) and all are
single master systems. So I never defined an API to access the semaphores
in my drivers.

	Regards,
	Gabriel.


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