[EV3] Sort out caches, cache coherency with DMA, memory barriers, atomicity, and other memory model gremlins

[ArcaneNibble]

Memory caches are very important for getting good performance from modern CPUs, but they also introduce additional complexity because caches introduce opportunities for different agents to have a different view of what memory contains. Additionally, when there are multiple agents all accessing memory, complexity can arise if they try to access the same memory locations at the same time. Although the ARM926EJ-S is a relatively simple CPU in a single-core configuration, the AM1808 SoC contains multiple DMA controllers and other bus mastering peripherals. These concerns will be of increasing relevance as we make additional use of them.

In order to prevent extremely-difficult-to-debug bugs in this area, we need to have a clear plan for how this will be approached, such as by doing the following:

• Figure out what state the caches are currently being left in, and enable them if they are not enabled.
• Check if DMA controllers are cache-coherent with the CPU, or if CPU caches need to be flushed before performing DMA
• Write an internal API for managing memory issues around DMA transfers. When writing data to be accessed by peripherals, this requires at minimum a compiler memory barrier and possibly also a cache flush. When reading memory written by peripherals, this may require a cache invalidate or an uncached mapping.
• Figure out what happens if two agents (e.g. the CPU and a DMA controller) access the same memory at the same time (which is currently used by the WIP new ADC implementation). Are word accesses atomic, or can torn values be observed?
• Decide what memory model will be followed, in order to make sure the compiler does not miscompile code (for example: adopting the C/C++ memory model which requires atomic types, adopting the Linux kernel memory model, adopting a simplified memory model tailored to GCC/clang behavior)

[ArcaneNibble]

Version 0.60 of the EEPROM bootstrap contains the following code

8000401c  100f11ee   mrc     p15, #0, r0, c1, c0
80004020  230cc0e3   bic     r0, r0, #0x2300
80004024  8700c0e3   bic     r0, r0, #0x87
80004028  020080e3   orr     r0, r0, #0x2
8000402c  010a80e3   orr     r0, r0, #0x1000
80004030  100f01ee   mcr     p15, #0, r0, c1, c0

This corresponds to:

• exception vectors at 0x00000000 (which Pybricks sets back to 0xffff0000)
• R/S protection bits cleared
• I-cache enabled
• D-cache disabled
• little-endian operation
• alignment fault enabled
• MMU disabled

The Linux kernel boot requirements for ARM also include "D-cache disabled, MMU disabled" so going through U-boot should not change those two features

Because the D-cache is currently disabled, all of the current code works, but this will need to be revisited in order to turn the D-cache on.

[dlech]

So I made pybricks/pybricks-micropython@1d10654 to fix a regression caused by switching from using the Linux loader in U-Boot to using a generic ELF loader. I'm not sure if all of it was necessary, but clearly we have some work to do before we can enable caches. But at least now, we know for sure where we are starting from.

[laurensvalk]

See also this post, quoted below for convenience. This was needed to get the TIAM1808 example to work, but we haven't applied the same thing to pybricks-micropython yet. Relevant parts could go into start.s as David did, or in platform.c:SystemInit() which is called from start.S before main.

Also, it is worth noting that start.S and the linker script deviates a bit from the StarterWare examples. As acknowledged at the top of our versions of those files, they are based on their counterparts in EV3OSek. But I don't know why it is done differently. So I would say this is up for review and revision as needed.

Quoted post:

---

Additionally, to get examples/evmAM1808/cache_mmu/uartEdma_Cache.c to work without freezing, we have to protect the following code from optimization.

#pragma GCC push_options
#pragma GCC optimize("O0")

static void config_mmu(void) {

    unsigned int index;
    /* Sets up 'Level 1" page table entries. 
     * The page table entry consists of the base address of the page
     * and the attributes for the page. The following operation is to
     * setup one-to-one mapping page table for DDR memeory range and set
     * the atributes for the same. The DDR memory range is from 0xC0000000
     * to 0xDFFFFFFF. Thus the base of the page table ranges from 0xC00 to 
     * 0xDFF. Cache(C bit) and Write Buffer(B bit) are enabled  only for
     * those page table entries which maps to DDR RAM and internal RAM.
     * All the pages in the DDR range are provided with R/W permissions
     */
    for(index = 0; index < (4*1024); index++)
    {
         if((index >= 0xC00 && index < 0xE00)|| (index == 0x800))
         {             
              pageTable[index] = (index << 20) | 0x00000C1E;
         }
         else
         {
              pageTable[index] = (index << 20) | 0x00000C12;
         }
    }
     
 
    /* Configures translation table base register
     * with pagetable base address.
     */
    CP15TtbSet((unsigned int )pageTable);

    /* Enables MMU */
    CP15MMUEnable();
 
    /* Enable Instruction Cache */
    CP15ICacheEnable();
    
    /* Enable Data Cache */
    CP15DCacheEnable();
}
#pragma GCC pop_options

So I think we now have the necessary ingredients to apply this to the SPI driver.

[laurensvalk]

See also this inspiration for our DMA display driver which handles the cache each time prior to writing to the display. I think I recall that their code would not work when the cache clean code was commented out.

For context @ArcaneNibble: EV3RT (see paper) is an early attempt to make a fast booting EV3. I initially pursued this as a "HAL" to run Pybricks on top of. It worked, but the code base was very hard to untangle or build on. Since it also uses the StarterWare APIs for the low level stuff, it is still a useful resource for some peripheral settings. (Crucially, it uses the mmc only, so there was no reference for the SPI flash).

[ArcaneNibble]

Since we now have https://github.com/pybricks/pybricks-micropython/blob/master/lib/pbio/include/pbdrv/cache.h, I would consider this issue "done" for now. We do not have a "formal verification" quality memory model, but the usage of compiler barriers and explicit cache management appear to be sufficient for now.

[dlech]

Does it make sense to revert pybricks/pybricks-micropython@1d10654 now?

[ArcaneNibble]

We still need to turn the MMU off before we turn it back on, so I figured we should leave it?

[dlech]

Fine with me to leave it if there isn't a better place for it. We should probably update the comment though to reflect that.