I have been trying to get an SMP RTOS HAL working using the SDK. I looked at the primes example for how to enable cache and mmu, but for some reason lookups only work on CPU 0, and return 0 on CPU 1-3. I verified this by calling mmu_virtual_to_physical. I am testing it address 0x0021bc430 which is where my startup code for secondary CPUs gets the CPU number and then gets into trouble. Other addresses in DDR have the same behavior. Without caches and MMU the HAL works fine. So there are no general memory problems.
I have read all the ARM docs and just don't see what could be wrong. The primes example works fine.
Can you explain the order of initialization of the L1 cache and MMU so I can understand the dependencies?
The ARM docs clearly say the caches must be invalidated before "used." They don't say invalidated before enabled, but I assumed they mean that. The primes example enable first, then invalidate. That seems dangerous if an instruction fetch happens in the process.
It is also not clear if the caches work when the MMU is disabled. Can you also explain any dependencies when using L1, L2, MMU in different combinations or by themselves?
Can you think of what might be missing that causes the secondary cores to translate to address 0?
One thing that makes me nervous is that the tables are in OCRAM which are configured to be under MMU control. Seems like the MMU has to use itself to translate. I am guessing the MMU is designed to tolerate that.
One more curiosity, when I put the tables at the bottom of OCRAM, all kinds of weird stuff happened on CORE 0. Are there any rules on where to place the tables? There are registers in the init that tell the MMU where they are, but I saw in the docs that the standard layout reserves some memory at the bottom of OCRAM. So I wonder if the MMU has some limitations on where the tables are located.