Sorry for the brief pause in development...
So I was reading some of the forum posts here and I saw one about a guy who got more speed out of the Raspberry Pi 2 on single core:
http://www.raspberrypi.org/forums/viewt ... 2&t=102806
dom wrote:Your bare metal environment doesn't wake the other cores up, which means they keep polling a register, and so compete on the bus with the useful work you want the first core to do.
using config.txt option arm_control=0x1000, changes the "cmp r0, #0xff" to be a cmp r0, #0x1", which causes the secondary cores to not poll for the signal, but just to sleep.
This was obviously just a debug switch when trying to get mulitcore linux working, which fortunately hasn't been removed yet.
The real solution is for your bare metal world to wake up the other cores and make them sleep, or change the bootcode to sleep directly.
So this reminded me of my bare metal video codec test, which seemed to run much slower on the Raspberry Pi 2 compared to the Raspberry Pi 1!
I tested my video using the config.txt option arm_control=0x1000
, and it suddenly ran much faster as the extra cores were not fighting for BUS space.
I then took away the config.txt option, and woke up the 3 extra cores, putting them all into a simple loop, and the huge speed gain for the video decoding worked =D
Here is the updated Video test which now runs much faster on the Raspberry Pi 2:
https://github.com/PeterLemon/Raspberry ... GRBLZVideo
So that was a big problem fixed, and the moral is if you want the most speed out of your bare metal single core coding, you really should wake up the other cores and put them in a loop.
Now I only have 2 problems left in my Raspberry Pi 2 understanding:
1. DMA demos are still not working (the 1st DMA always works, my hello world demo only prints "h")
2. My V3D animation demo is static (the 1st V3D Contol List always works, could this be linked to the dma problem above?)
I will try to get to the bottom of this, would be great if anyone knows what the problem might be...