Question: cacheFlush/cacheInvalidate

Narendra C. Tulpule

unread,

Dec 21, 1999, 3:00:00 AM12/21/99

to

Hi,
the VxWorks system calls cacheFlush/cacheInvalidate take cache type,
address and # bytes as arguments. My question is:
if the address was obtained through normal malloc() rather than memalign()
call, and it's in the middle of a cache page, and # bytes is arbitrary,
how do these calls work (if at all)? Will they still flush/invalidate the
whole cache page?
In general, I am writing a device driver whose buffers come from normal
cache-enabled memory. Upper layers giving me the buffers got them through
malloc(). Now I want to tell the hardware to DMA them from external memory
to I/O. (I am using MPC860 from Motorola so "I/O" is an SCC). How can I
make sure that the same data is present in the cache as the external
memory - without affecting other data present in the external memory page
that corresponds to the cache page.
Same problem when h/w DMAs data from SCC to memory. For that time I want
to invalidate cache corresponding to that memory address. But for all I
know, the memory area just before the "address" parameter lies in the same
page and is being used by someone.
Please let me know of your insights. Thanks.

Leonid Rosenboim

unread,

Dec 22, 1999, 3:00:00 AM12/22/99

to Narendra C. Tulpule

Your question is rather long, so let me just start with some basics:

The CACHE is comprise of "Cache Lines" which are typically 16-bytes
large,
and are aligned. These have nothing to do with MMU "Pages".

Now, when you Flush or Invalidate a range of addresses, it will do that
for any CAHCE LINE that contains any of the addresses you requested.

It IS a good idea to align DMA buffers to the Cahce Line size, to
avoid sharing of Cache lines with any other resource, and will improve
performance too.

Hope this helps,
Leonid

codeWorks

unread,

Dec 22, 1999, 3:00:00 AM12/22/99

to

The SDMA controller on the CPM is connected to the internal UBUS, on which
data-cache snooping is implemented
( as far as I understand the documentation).
Because of this, cache will be invalidated/commited if needed
when an access on the UBUS to a data-cached location is seen.
You can leave the cache as it is, and the hardware will take care of the
job.

What you call the cache page is normally called a cache-line and is 8 bytes
long. If you invalidate the data-cache for an address outside your bufffer
area, the result will be one extra memory-bus access to retrieve this data
from external memory. As the cache is small, this area is very likely to be
replaced by the LRU algorithm before it is needed anyhow.

Narendra C. Tulpule <na...@trillium.com> wrote in message
news:Pine.SOL.3.96.991221181403.8581I-100000@esmeralda...

code...@mobilpost.com

unread,

Dec 22, 1999, 3:00:00 AM12/22/99

to

Sorry for the mistake on cache-line size.
It is 16 bytes on MPC8xx, not 8.

codeWorks <code...@mobilpost.com> wrote in message
news:83qgfm$14j$1...@news.ost.eltele.no...

> The SDMA controller on the CPM is connected to the internal UBUS, on which
> data-cache snooping is implemented

> ...

> replaced by the LRU algorithm before it is needed anyhow.
>
>
> Narendra C. Tulpule <na...@trillium.com> wrote in message
> news:Pine.SOL.3.96.991221181403.8581I-100000@esmeralda...
> > Hi,
> > the VxWorks system calls cacheFlush/cacheInvalidate take cache type,
> > address and # bytes as arguments. My question is:

>> ...
> >
>
>

Tor Ringstad

unread,

Jan 4, 2000, 3:00:00 AM1/4/00

to

"codeWorks" <code...@mobilpost.com> writes:

> The SDMA controller on the CPM is connected to the internal UBUS, on

> which data-cache snooping is implemented (as far as I understand the
> documentation).

What part of the documentation do you interpret in this way?

> Because of this, cache will be invalidated/commited if needed when
> an access on the UBUS to a data-cached location is seen. You can
> leave the cache as it is, and the hardware will take care of the
> job.

Chapter C.9.2, "Data Coherency", in the old MPC860 manual states the
following:

"If the cache is in write-back mode, changes made in the cache are
not made to memory. This can create data coherency problems if
another bus master (an SDMA, IDMA or external processor) accesses a
memory location which has a more recently updated value in the
cache. [...]"

> If you invalidate the data-cache for an address outside your bufffer
> area, the result will be one extra memory-bus access to retrieve
> this data from external memory.

Assuming the addresses outside the buffer area do not accidentally
include a recently changed variable, in which case invalidating the
cache line will cause the update of the variable to be lost.

--
Tor H. Ringstad | Kongsberg Defence & Aerospace
<tor.h.r...@kongsberg.com> | P.O.Box 1003, 3601 Kongsberg, Norway
| tel: +47 32737468 fax: +47 32739922

sense

unread,

Jan 5, 2000, 3:00:00 AM1/5/00

to

Tor Ringstad <tor.h.r...@kongsberg.com> wrote in message
news:vpzogb2m8...@hps5.faero.kog.no...

> "codeWorks" <code...@mobilpost.com> writes:
>
> > The SDMA controller on the CPM is connected to the internal UBUS, on
> > which data-cache snooping is implemented (as far as I understand the
> > documentation).
>
> What part of the documentation do you interpret in this way?
>

8.1 (Instruction Cache) States
...The instruction cache implements a single state bit for each cache block
that indicates
whether the cache block is valid or invalid. The MPC860 does not support
snooping of the
instruction cache. All memory is considered to have
memory-coherency-not-required
attributes. Therefore, software must maintain instruction cache coherency.
The MPC860...

while

8.2 (Data Cache ) States
...The two state bits implement a three-state
(modiŢed-valid/unmodiŢed-valid/invalid)
protocol. The MPC860 does not provide support for snooping external bus
activity. All
coherency between the internal caches and external agents (memory or I/O
devices) must
be controlled by software....

8.6.6 States
Internal to the MPC860, the data cache has snoop logic to monitor the
internal bus for communication processor module (CPM) accesses of the
address associated with the last lwarx instruction.

I assumed the UBUS is not an external bus, and hence that internal bus
access was snooped.
If the intention was to say that neither external nor internal bus activity
is snooped, why
specificly mention "external bus activity"

If the SDMA/U-BUS access is for external memory the address will still be
observed on the UBUS, which is internal as far as I can see.

> > Because of this, cache will be invalidated/commited if needed when
> > an access on the UBUS to a data-cached location is seen. You can
> > leave the cache as it is, and the hardware will take care of the
> > job.
>
> Chapter C.9.2, "Data Coherency", in the old MPC860 manual states the
> following:
>
> "If the cache is in write-back mode, changes made in the cache are
> not made to memory. This can create data coherency problems if
> another bus master (an SDMA, IDMA or external processor) accesses a
> memory location which has a more recently updated value in the
> cache. [...]"
>
> > If you invalidate the data-cache for an address outside your bufffer
> > area, the result will be one extra memory-bus access to retrieve
> > this data from external memory.
>
> Assuming the addresses outside the buffer area do not accidentally
> include a recently changed variable, in which case invalidating the
> cache line will cause the update of the variable to be lost.
>

OK. This should have been
If you flush/store ( dcbf / dcbs or DC_CST=0b1110 ) the data-cache....

If you invalidate the data-cache before you update it, it will not be valid
in memory for a DMA operation. If you invalidate the cache after you update
it
you just wasted some CPU. If you flush/store the cache after updating it it
will be
committed to memory.

If you flush (dcbf / DC_CST=0b1110) a memory area outside the intentended
buffer area, the cache-entry will be committed and invalidated, and it must
be reloaded on the next access.

If you store (dcbs) the memory area, the cache is committed to memory but is
still valid.
With the relatively small cache of the PPC8xx i would guess a DC_CST=0b1110
(flush all)
is more efficient than performing a dcbs on every cache-line in your buffer.
( Depending on buffer size of course)

Tor Ringstad

unread,

Jan 11, 2000, 3:00:00 AM1/11/00

to

"sense" <code...@mobilpost.com> writes:

> I assumed the UBUS is not an external bus, and hence that internal
> bus access was snooped. If the intention was to say that neither
> external nor internal bus activity is snooped, why specificly
> mention "external bus activity"

The point may be _what_ the internal bus is snooped for, i.e. "the
last lwarx instruction". I didn't interpret that to be the same as
full snooping, e.g. as provided by the MEI protocol on the 740/750.
Thus, I would believe that the reason for the wording in the manual is
that the internal bus isn't totally unsnooped, but it isn't snooped
for the kind of accesses you want (all data accesses).

- Tor Ringstad -