ti.sysbios.family.arm.a15.Cache Cache_inv and Cache_wb functions in SYS/BIOS 6.45.1.29 don't work when the virtual address extends to the end of address space

Also, which hardware platform are you on?

Can you please attach your map file?

As far as the memory map goes there are two regions:

Memory Configuration

Name             Origin             Length             Attributes
MSM              0x0c000000         0x00600000         xrw
DDR3             0x80000000         0x80000000         xrw

The MSM region is used to allocate the SYS/BIOS program Code Memory, Data Memory and Stack Memory. The DDR3 region, which covers the upper 2Gbytes of virtual address space is used by the application for a memory test, for which the entire 2Gbytes was intended to be passed in calls to Cache_inv() and Cache_wb().

In the attached project in the test_memory_region() function there is currently a work-around applied to make two calls Cache_inv() and Cache_wb() when region=0x80000000 and region_size_bytes=0x80000000 :

static Void test_memory_region (Void *const region, const SizeT region_size_bytes, const post_write_cache_ops cache_op)
{
<snip>
    /*@todo Avoid bug where only one cache line is affected by the cache operation */
    const Bool workaround_final_cache_op_problem = ((UInt32) region + region_size_bytes) == 0;
    Void *const final_cache_line = (Void *) ((UInt32) region + region_size_bytes - Cache_sizeL1dCacheLine);
<snip>

    case POST_WRITE_INV:
        if (workaround_final_cache_op_problem)
        {
            Cache_inv (region, region_size_bytes - Cache_sizeL1dCacheLine, Cache_Type_ALL, TRUE);
            Cache_inv (final_cache_line, Cache_sizeL1dCacheLine, Cache_Type_ALL, TRUE);
        }
        else
        {
            Cache_inv (region, region_size_bytes, Cache_Type_ALL, TRUE);
        }
        break;

    case POST_WRITE_WB:
        if (workaround_final_cache_op_problem)
        {
            Cache_wb (region, region_size_bytes - Cache_sizeL1dCacheLine, Cache_Type_ALL, TRUE);
            Cache_wb (final_cache_line, Cache_sizeL1dCacheLine, Cache_Type_ALL, TRUE);
        }
        else
        {
            Cache_wb (region, region_size_bytes, Cache_Type_ALL, TRUE);
        }
        break;

When the above is run it reports that Cache_inv and Cache_wb perform data cache Write-Back - Cleaning and coherency on 510 out of the total 512 L1D cache lines and on 65534 out of the total 65536 L2 cache lines.

Starting test of memory region 0x80000000 ... 0xffffffff
Tested memory region 0x80000000 ... 0xffffffff using cache op Cache_inv, with 0 readback failures
PMU counter changes during Cache op:
  Level 1 data cache Write-Back - Victim = 0
  Level 1 data cache Write-Back - Cleaning and coherency = 510
  Level 1 data cache invalidate = 510
  Level 2 data cache Write-Back - Victim = 0
  Level 2 data cache Write-Back - Cleaning and coherency = 65534
  Level 2 data cache invalidate = 0
<snip>
Tested memory region 0x80000000 ... 0xffffffff using cache op Cache_wb, with 0 readback failures
PMU counter changes during Cache op:
  Level 1 data cache Write-Back - Victim = 1
  Level 1 data cache Write-Back - Cleaning and coherency = 510
  Level 1 data cache invalidate = 0
  Level 2 data cache Write-Back - Victim = 0
  Level 2 data cache Write-Back - Cleaning and coherency = 65534
  Level 2 data cache invalidate = 0

If the program is changed to remove the work-around, by setting workaround_final_cache_op_problem to FALSE, then when the program is run it reports that Cache_inv and Cache_wb are only operating on one cache line:

Tested memory region 0x80000000 ... 0xffffffff using cache op Cache_inv, with 0 readback failures
PMU counter changes during Cache op:
  Level 1 data cache Write-Back - Victim = 1
  Level 1 data cache Write-Back - Cleaning and coherency = 1
  Level 1 data cache invalidate = 1
  Level 2 data cache Write-Back - Victim = 0
  Level 2 data cache Write-Back - Cleaning and coherency = 1
  Level 2 data cache invalidate = 0
<snip>
Tested memory region 0x80000000 ... 0xffffffff using cache op Cache_wb, with 0 readback failures
PMU counter changes during Cache op:
  Level 1 data cache Write-Back - Victim = 0
  Level 1 data cache Write-Back - Cleaning and coherency = 1
  Level 1 data cache invalidate = 0
  Level 2 data cache Write-Back - Victim = 0
  Level 2 data cache Write-Back - Cleaning and coherency = 1
  Level 2 data cache invalidate = 0

With the program in this state you should be able to step-into the Cache_wb() and Cache_wb() functions called with blockPtr = 0x80000000 and byteCnt = 0x80000000 and see that a cache maintenance operation is only performed on one virtual address.

Steven Connell said:

I'm just wondering if your question was answered by that thread? Does the system reset suggestion resolve this problem?

The purpose of this thread was just to report that when I created a test program which made either of the following calls I expected the requested cache maintenance operations to be performed on all the virtual address space from 0x80000000 ... 0xffffffff, where the cache maintenance operations were performed on virtual addresses which incremented by the cache line size of 64 bytes:

Cache_inv (0x80000000, 0x80000000, Cache_Type_ALL, TRUE);
Cache_wb (0x80000000, 0x80000000, Cache_Type_ALL, TRUE);

However, as of the ti.sysbios.family.arm.a15.Cache module in SYS/BIOS 6.45.1.29 the actual result was that cache maintenance operation was only performed on the initial virtual address of 0x80000000, due to the specific combination of the arguments blockPtr = 0x80000000 and byteCnt = 0x8000000.

This is not currently causing me a problem, but was just wondering if the difference between my expected behaviour and the actual behaviour was considered a bug or not.

Ashish Kapania said:

I filed a bug against SYS/BIOS to fix the logic to determine the cache lines that need to be maintained.

Ashish Kapania said:

Looking at the start address and size you are using, it looks like you want to write-back invalidate the entire cache. I would suggest using Cache_wbInvAll() API for this purpose

- Cache_invL1dAll : Which performs an invalidate by set/way

- Cache_inv : Which performs an invalidate by Modified Virtual Address

- Cache_wbInvAll : Which performs a clean and invalidate by set/way

- Cache_wb : Which performs a write back by Modified Virtual Address

This was to aid my understanding of Why does the Cache_inv() API flush the cache on Cortex-A15 ?