GPMC Bursting/Caching Behaviour

Hey all,
           We're trying to use the GPMC peripheral as a method to
communicate with an external high-speed processing element, and would
like to use it in a address/data muxed, synchronous mode with support
for bursting transactions.

Before diving into an implementation, I've been spending time trying
to characterize the behaviour of this peripheral, especially with
regards to bursting writes/reads. Based on my conversations with Soren
(another poster here), bursting transactions are determined by the
cache properties of the memory mapped chip select space (by setting
the appropriate Cacheable, Bufferable bits in the page table entry).
I've currently tested in both un-cached and writeback modes using the
L_PTE_MT_UNCACHED, and L_PTE_MT_WRITEBACK protection bits during my
mmap setup. I've also setup the gpmc for synchronous, with
config1.writemultiple and config1.readmultiple set to 1.

However, my experimentation leads me to believe that during writeback
mode, the transactions i've observing on the scope do not entirely
behave as true writeback cache would. Here's an example.

Test #1:
MMAP: Writeback mode (Correct behavior)

In code:
1) Read DWORD at location 0 (within GPMC CSx space):
2) Read DWORD immediately after at location 8

In HW:
I notice a single 32-byte read burst - this confirms a cache line is
being filled

Test #2:
MMAP: Writeback mode (Fishy behaviour)

In code:
1) Read DWORD at location 0 (within GPMC CSx space)
2) Write DWORD at location 8
3) Read DWORD at location 16

In HW:
I notice a single 32-byte read burst, then a little while later, a
burst DWORD write transaction and then another 32-byte read burst.
This does not really coincide with my understanding of writeback
cache, which should not persist the three transactions out until i
have invalidated the line, or it has been hit by another memory
location.
Now since i'm working in Linux, and this is set-associative cache, it
could be that that line is being trampled by another location (very
likely) - but i've repeated the tests enough times and get the same
behaviour.

Soooo....what exactly is the relationship between bursting and caching
with respect to the GPMC? Sorry for the long post, but any help here
would be appreciated.

Thank you,

Jerry Johns
Nuvation Research Corporation (Canada)

Hi Jerry and all,

Hey all,
We’re trying to use the GPMC peripheral as a method to
communicate with an external high-speed processing element, and would
like to use it in a address/data muxed, synchronous mode with support
for bursting transactions.

Before diving into an implementation, I’ve been spending time trying
to characterize the behaviour of this peripheral, especially with
regards to bursting writes/reads. Based on my conversations with Soren
(another poster here), bursting transactions are determined by the
cache properties of the memory mapped chip select space (by setting
the appropriate Cacheable, Bufferable bits in the page table entry).
I’ve currently tested in both un-cached and writeback modes using the
L_PTE_MT_UNCACHED, and L_PTE_MT_WRITEBACK protection bits during my
mmap setup. I’ve also setup the gpmc for synchronous, with
config1.writemultiple and config1.readmultiple set to 1.

However, my experimentation leads me to believe that during writeback
mode, the transactions i’ve observing on the scope do not entirely
behave as true writeback cache would. Here’s an example.

Test #1:
MMAP: Writeback mode (Correct behavior)

In code:

  1. Read DWORD at location 0 (within GPMC CSx space):
  2. Read DWORD immediately after at location 8

In HW:
I notice a single 32-byte read burst - this confirms a cache line is
being filled

Test #2:
MMAP: Writeback mode (Fishy behaviour)

In code:

  1. Read DWORD at location 0 (within GPMC CSx space)
  2. Write DWORD at location 8
  3. Read DWORD at location 16

In HW:
I notice a single 32-byte read burst, then a little while later, a
burst DWORD write transaction and then another 32-byte read burst.
This does not really coincide with my understanding of writeback
cache, which should not persist the three transactions out until i
have invalidated the line, or it has been hit by another memory
location.
Now since i’m working in Linux, and this is set-associative cache, it
could be that that line is being trampled by another location (very
likely) - but i’ve repeated the tests enough times and get the same
behaviour.

Soooo…what exactly is the relationship between bursting and caching
with respect to the GPMC? Sorry for the long post, but any help here
would be appreciated.

Thank you,

Jerry Johns
Nuvation Research Corporation (Canada)

Sorry for digging up such an old thread but I’m looking for help with using GPMC bus.

  1. I’ve managed to setup the GPMC register sets to do single read/write transaction using IOCTL and simple driver which uses “readw()” and “writew()” to start the transaction on the GPMC bus. I’m running Linux v3.0 on the board.

Now I wish to do burst transfer of 4 words, 8 words and 16 words and I don’t know what is the proper C-functions/mechanism to initiate the transaction for each burst length.

I hope you/someone here can share some lights to using the burst transaction of the GPMC.

  1. Can you advise me/share with me how to do mmap as per your testing?

Many thanks in adv.

James Ang.