Exophase is working on a MMU hack for Wiz devices and there are already the first mesureable speed improvements.
Here is the initial posting:
I wrote an mmuhack that follows the old fashioned technique that Squidge first introduced. In other words, something that modifies sys_newuname rather than a kernel module (since I can’t write those w/o source). However, it is different from Squidge’s in a couple ways. First, it scans /proc/kallsyms (or /proc/ksyms if it can’t load that) to get the address of sys_newuname, so it shouldn’t be as prone to breaking between kernel versions. Second, it flushes icache/dcache between uname patches – this is vital or it won’t work for coherency issues (it is self modifying code afterall). Third, it does some sanity checks to make sure the process is working as expected along the way.
I tried to flush icache/dcache in the usual GP2X way (with syscall 0x9F0002) but it didn’t work. Maybe you have to do icache/dcache separately now instead of it merging the two, I don’t know, I didn’t investigate. Instead I just wrote some functions to flush all of icache/dcache in software by loading in new things. If anyone can point out an alternative that’d be good. I tried making the dcache flush load the icache flush routine instead of from a BSS section area but that failed to work – it might be that text section things are not data cacheable.
Anyway, here are the files:
http://exophase.devzero.co.uk/wiz_mmuhack.c
http://exophase.devzero.co.uk/asm_util.S
I’m getting as much as 2ms per frame improvement or more (hard to tell exactly, timing is really inconsistent for some reason) so it’s definitely worth it, even if your program just writes to the whole framebuffer once per frame (Temper potentially does multiple, for BG and sprites).
Edit: Still doesn’t work all the time, not at all sure why. Just keep trying it until it does, I guess :/ (tell me if anyone has any ideas)
.jpg)
.png)