It also will not work on cameras without cp15 (only srsas S1 port as far as we know, which is not in in the trunk anyway)
Do you have any idea/suggestion what could be used on a CPU where the cache control isn't known?
If there's anywhere the Canon code copies code into RAM, that might contain some clues. Otherwise you can do some brute force things. My initial "fix" for this was to do
for(i=0;i<size_flat;i++) {
*(char *)((int)(flat_buf+i) | CAM_UNCACHED_BIT) = *(flat_buf+i);
}
Which should take care of the data cache "cleaning". Not sure how you would flush the instruction cache short of executing a full cache worth of code (can't be a loop either!), but that should be less of an issue.
With a bit more work using cp15 cache control will also allow us to improve the handling of read()/write() and the umalloc/malloc issues.
By any chance is this related to what the ML developers do?
No, thats something very different, although I was wondering last night if we could abuse lockdown like that. Interesting.
Could we use this method directly or are our (compacts <-> DSLRs) CPUs configured differently?
I don't think there should be much difference.
I remember A1ex mentioning that ML is less stable with cache hacks for some reason though.
It seems like there's a few ways the Canon firmware could break it. Those could be different between P&S and DSLR too, I guess.
