Sorry, I misread the original post. We had a similar, but not identical
problem.
In our case, CPU writes to control registers in an external FPGA were
not being propagated correctly.
Still, the same solution may work (dummy writes followed by reads?)
Also:
Andy Ngo wrote:
> 1) If I need the writes to be real-time (immediately flushed out to
the shared RAM), do I have to call msync every single time I do a
write? If this is the case, isn't this very inefficient? Does msync
have to check the whole 0x20000 range to check what bytes need to be
flushed?
You can tell msync() to synchronize only the same area modified in the
write. If this is "inefficient" or not, only you can tell. msync() may
not be necessary for memory access, as opposed to access to memory
mapped files.
> 3) I tried using MAP_PRIVATE and it doesn't seem to map to the shared
RAM space at all (mmap doesn't return an error but I can't write or read
from it). Is there anyway to force the mechanism behind mmap (driver
for /dev/mem ?) to force a flush everytime the ARM writes to shared RAM
without having to call msync?
I thought about writing a special driver similar to /dev/mem, but with
that property as well as only using the right word size (16 bits in our
case)
Roberto Waltman wrote:
R. Simning wrote:
Andy Ngo wrote:
..... the FPGA Microblaze write values to the shared RAM, and when
our ARM processor on the Davinci reads them during the interrupt
processing, the data looks staled (as though from previous reads).
...
I thought the declaration of a variable as "volatile" would force
the value to always be read directly from RAM, never cache. I'm not
clear whether declaring a variable "volatile" forces the write to
RAM, but that case doesn't seem to be an issue here.
I would believe that just declaring those data structures as
"volatile" should resolve your cache issues of reading "stale" data.
No, that only tells the compiler not to optimize-out references to a
variable, always fetching a new value from "memory" when necessary.
The compiler has no knowledge if the value is fetched from actual
memory, from an internal or external cache, or if it is out of sync
with a second CPU's view, etc.
We went through the same problem recently, one of my colleagues found
the answer:
(a) Declare all variables in the mapped area as volatile, and
(b) Do a readback immediately after writing to mapped memory, to force
flushing the cache.
See http://www.arm.com/pdfs/DDI0198D_926_TRM.pdf, chapter 4, in
particular section 4.2, for the rationale behind this.
Roberto Waltman
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
