https://github.com/LdB-ECM/Raspberry-Pi ... tualmemory
Now I am going to have to do this otherwise I will get a snide comment.
Okay that said my bootstub runs each core thru a setup process and then parks them back so I can command them to enter a standard C function. This functionality is a feature of my bootstub if you use your own bootstub you will need to engineer something. I use it for testing like this and kicking Virtual Machine code.I do not suggest this is how you do multicore code it is simply a test setup !!!!.
I would also thank bzt for his initial work and sample which I hacked the hell out of
So on the test code, core 0 enters and creates the MMU table.
Table1 is a 2GB 1:1 Map of the memory from 0x0 to 0x40200000 which is the just over 1GB area of the Pi memory plus the hardware area described in QA7_rev3.4.pdf
Table2 is a virtual table and unused in this sample
The core then loads the tables and turns on it's MMU and all caching giving it the ability to run an aquire semaphore.
If the MMU fails the semaphore_inc code will deadlock as it will not be able to get a clean aquire.
Core0 then using an aquire semaphore, commands each other Core to load the same table they will release the semaphore when they complete so I know they have done it.
Finally then it does some testing to make sure each core can see a semaphore lock.
All I was trying to do was check the MMU code was correct and worked on all 4 cores. You will need to lookup and make more synchronizing primitives (ARM has a whitepaper on them). That however should get you started.
This is probably for lizzard but a BIG WARNING once you have the MMU engaged you will need MEMORY BARRIERS on hardware access. My serial code wouldn't even work properly without placing them on it.
A side question for people, does anyone know if we are allowed to turn the L2 cache on over the VC memory area. I haven't got memory barriers setup on my graphics code so wan't able to test?