In trunk
changeset 2202 I've changed module loading to make it play safely (but not optimally) with the CPU data and instruction caches. The previous unsafe behavior appears to be the cause of the grid crash discussed here:
http://chdk.setepontos.com/index.php?topic=6318.msg91537#msg91537Since this affects all module usage, I'd like to have some testing before merging it over to the stable branch. The basic test is to start the camera in play mode and load a grid. With the old code, some (but not all) cameras will crash repeatably. With the new code, the should not. Aside from that test, exercising stuff in modules (dng, md, games, text view, file browser etc) would be good.
The previous code was unsafe because it would
1) read the module code into cached memory (via an uncached buffer for read(), but this isn't relevant because it isn't at the final address)
2) perform reloactions etc in cached memory
3) Execute the the code.
At this point, there is no guarantee all the data has been written from the data cache out to main memory. The instruction cache is separate, and there is no snooping, so if there was a miss, it would read main memory. If by chance the address was already in instruction cache (for example, a previous module was loaded there) that would also be a problem.
The updated code does the following after loading and relocating a module:
1) Flush the entire instruction cache, forcing any instructions to be fetched from RAM.
2) Clean the data cache, forcing any dirty values to be written out to RAM
3) Drains the write buffer, forcing the CPU to wait until any writes are complete
This is sub-optimal because it isn't necessary to flush and clean the entire caches. It is possible to clean and flush individual addresses, but it's not clear to me that this is necessarily better, depending on the size of the module it could take more iterations than operating on the entire cache. It's also not clear that the write buffer drain is required, but some similar code in the Canon firmware does this, so it seems like a good idea.
Assuming this diagnosis was correct, this probably also caused some other intermittent instability. The fact that it worked as well as it did makes me question whether the diagnosis is in fact correct
Note that the current code assumes the data cache size is 8kb. This is true of every camera I've seen CPU info for (see here
http://chdk.setepontos.com/index.php?topic=2139.msg20148#msg20148 )
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)
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.
On an unrelated note, I noticed assembla stopped sending me commit alerts for chdk. If this happened to you, and you want them back, you can go to the "stream" tab
https://www.assembla.com/spaces/chdk/stream and click email notifications.
Also, I'm through the crunch mentioned in the previous post.
