Actions
Forum Thread Details
  • State Not Answered
  • Replies 11 replies
  • Subscribers 329 subscribers
  • Views 3837 views
  • Users 0 members are here
Related

Invalidating the data cache

Former Member

I have a problem that I am trying to fix in a program I have written.

I receive internet packets, the Rx interrupt affects a bool so that in a loop I can to to then request the RxBD from the hardware. I then copy out the packets into some linked list containers that I have before returning the BDs to the hardware.


My problem is that when I go to read the data that the BD points to, the cached data is wrong, so I invalidate it. Except that using

void Xil_DCacheInvalidateRange(unsigned int adr, unsigned len)

invalidates a cache line but not necessarily where the packet information starts. It looks at the address I pass to it, then it moves from there to the start of the first cache line and only then begins invalidating the cache.


This leads to varying parts of my packet information being "chopped off". Anywhere from 0 to 28 bytes worth of data.


A solution to this, as stated in the Xilinxs documentation seems to be to cache align the... sections of memory that the BD point to. The problem is, I have no idea how to do this.


I have tried simply disabling the entire cache at the start of the program, however this doesn't seem to work. I don't know if it is my attempt that doesn't work, or if it simply doesn't fix the problem.

(Code used to try to disable the entire cache)
Xil_L2CacheDisable();
Xil_L1DCacheDisable();
Xil_L1ICacheDisable();
dsb();
isb();

Parents
  • 0

    Hum...
    using:
    u8 RxBuf[32][1540]__attribute__((aligned(32)));
    with
    Xil_DCacheInvalidateRange(((u32)BufAddr),((unsigned)BufLen));
    And leaving the RxBD alignment alone (Why was I even messing with that? Nothing was wrong with it...) does not cause any fatal errors (Direction # ErrorWord #), but it still doesn't fix the problem where the packet in the RxBuffer appears to be "hidden" by the cache. And that the cache invalidating command doesn't always reveal the "front" of the packet. Yet still, as the program runs, the number of packets that are unidentifiable based on ethertype (meaning too much of the packet has been hidden with zeros for it to be identifiable) slowly decreases.

    Removing the cache invalidation command, and at the beginning of the program (First thing the ZedBoard ever does) disabling the entire cache still doesn't fix the problem. If I debug and break on the first unknown packet's arrival, I can see that the RxBD points to an empty place in memory, where the next packet should have been located.
    It is here that attempting to do
    Xil_DCacheInvalidateRange(((u32)BufAddr), ((unsigned)BufLen));
    causes Direction 0 ErrorWord 2. Which is understandable. How could it invalidate the cache, if it is disabled?

    While running with the entire cache disabled, the program more rapidly moves towards being able to identify all packets. Where it would take 40 minutes before it reached zero unknown packets per 1 million loops through the program, with cache disabled it gets there in about 4 minutes.

    I have absolutely no idea why, as it runs, it would be able to identify more and more packets. It always stays in the same 32 sections of memory, where RxBuffer is allocated.

    I'm so confused by this.

Reply
  • 0

    Hum...
    using:
    u8 RxBuf[32][1540]__attribute__((aligned(32)));
    with
    Xil_DCacheInvalidateRange(((u32)BufAddr),((unsigned)BufLen));
    And leaving the RxBD alignment alone (Why was I even messing with that? Nothing was wrong with it...) does not cause any fatal errors (Direction # ErrorWord #), but it still doesn't fix the problem where the packet in the RxBuffer appears to be "hidden" by the cache. And that the cache invalidating command doesn't always reveal the "front" of the packet. Yet still, as the program runs, the number of packets that are unidentifiable based on ethertype (meaning too much of the packet has been hidden with zeros for it to be identifiable) slowly decreases.

    Removing the cache invalidation command, and at the beginning of the program (First thing the ZedBoard ever does) disabling the entire cache still doesn't fix the problem. If I debug and break on the first unknown packet's arrival, I can see that the RxBD points to an empty place in memory, where the next packet should have been located.
    It is here that attempting to do
    Xil_DCacheInvalidateRange(((u32)BufAddr), ((unsigned)BufLen));
    causes Direction 0 ErrorWord 2. Which is understandable. How could it invalidate the cache, if it is disabled?

    While running with the entire cache disabled, the program more rapidly moves towards being able to identify all packets. Where it would take 40 minutes before it reached zero unknown packets per 1 million loops through the program, with cache disabled it gets there in about 4 minutes.

    I have absolutely no idea why, as it runs, it would be able to identify more and more packets. It always stays in the same 32 sections of memory, where RxBuffer is allocated.

    I'm so confused by this.

Children
No Data