October 10, 2023
It seems that the D cache is not properly enabled. I thought this worked once, so this may be a regression bug. We did a lot of work on MMU, cache, and processor initialization when we got multiple cores running and may have broken something then.
I discovered this while working on Kyu and trying to understand why 100 Mbit network performance as not what it should be. I would like to go back to a simpler scenario, essentially adding to my Orange Pi Bare Metal collection:
The very first thing is to figure out how U-Boot hands the processor to us. What speed is it running at? Is the D cache enabled? What about the MMU?Next, I would want to get one core running full speed (that makes it easier to detect if the D cache is enabled or not). Then figure out a test that discriminates between the cache being enabled or not. Just a simple delay loop function might do, but experimenting with memcpy would also be interesting.
Once this is well understood, I would like to get a second core running and understand how to enable and disable the cache as I see fit.
The ARM CCNT timer along with a stopwatch would work to find out what speed the CPU is running at. Knowing the CPU speed would then allow us to use the CCNT timer to calibrate delay loops and that should lead to a way to test if the D cache is enabled.
Tom's bike pages / tom@mmto.org