• Locked Locked
  • Replies 2 replies
  • Subscribers 119 subscribers
  • Views 2588 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Testing Data Cache of ARM926EJ-S

mel mel
Note: This was originally posted on 26th November 2009 at http://forums.arm.com

Hi,
I have an issue testing data cache for ARM926EJ-S used by AT91SAM9XE and AT91SAM9G20.
As you know, AT91SAM9XE has the flash memory and in this case I'm trying to test data cache of the architecture, in these conditions:
1. MMU and Page Table enabled
2. Round Robin replacement  enabled
3. The code of the main program is loaded in the flash memory
4. The data pattern for the test are read and written in SDRAM
Under these conditions the result of the test for data cache is good.

When I use the AT91SAM9G20, that no have flash memory on board, I'm constrained to load the code of the main program in another memory.
In the first case I choose to load the main program, in the SDRAM, and I try to test data cache of the architecture, in these conditions:
1. MMU and Page Table enabled
2. Round Robin replacement  enabled
3. The code of the main program is loaded in SDRAM
4. The data pattern for the test are read and written in SDRAM
The result in this case is a cache fault.

In the second mode of AT91SAM9G20, I choose to load the code of main program in one of the two SRAM region, while the data pattern are read and written always in SDRAM.
Well, in this case, the same test works properly.

I want to know if someone have this problem and why if I load in the same memory (SDRAM) instructions and data, the test fails.
Is there a particular reason?

Thanks in advance for your help
  • Arm Employee Badge
    Note: This was originally posted on 27th November 2009 at http://forums.arm.com

    The cache doesn't care what memory type it is talking to - that's outside of the core, so it shouldn't make any difference.

    Are your new pagetables correctly configured for the different memory regions?
  • Note: This was originally posted on 10th June 2010 at http://forums.arm.com

    Hi,
    I have an issue testing data cache for ARM926EJ-S used by AT91SAM9XE and AT91SAM9G20.
    As you know, AT91SAM9XE has the flash memory and in this case I'm trying to test data cache of the architecture, in these conditions:
    1. MMU and Page Table enabled
    2. Round Robin replacement  enabled
    3. The code of the main program is loaded in the flash memory
    4. The data pattern for the test are read and written in SDRAM
    Under these conditions the result of the test for data cache is good.

    When I use the AT91SAM9G20, that no have flash memory on board, I'm constrained to load the code of the main program in another memory.
    In the first case I choose to load the main program, in the SDRAM, and I try to test data cache of the architecture, in these conditions:
    1. MMU and Page Table enabled
    2. Round Robin replacement  enabled
    3. The code of the main program is loaded in SDRAM
    4. The data pattern for the test are read and written in SDRAM
    The result in this case is a cache fault.

    In the second mode of AT91SAM9G20, I choose to load the code of main program in one of the two SRAM region, while the data pattern are read and written always in SDRAM.
    Well, in this case, the same test works properly.

    I want to know if someone have this problem and why if I load in the same memory (SDRAM) instructions and data, the test fails.
    Is there a particular reason?

    Thanks in advance for your help



    Hi MEL

    Could you share your code for TLB setup to AT91SAM9XE?

    I am a newbie in MMU stuffs and I am trying to activate dCache ( that needs MMU) in my AT91SAM9XE-EK, but unsuccessfully.

    Thanks

    Sergio