Sorry for delay - was a bit away from ML lately, so anything that required more than a 5-minute break went to the back burner. Nice to see the progress - now the questions:
1) the null pointer warning appears to be false - both my 700D ROMs have that magic value. A sure way to tell would be to compare with a ROM from a 700D that never had ML on it - for example, the ROM backup saved during ML installation. If anyone made a backup copy of those ROMs (easily recognized by their boot flag status), they could be useful.
Detailed analysis: I get the magic value 0xA5A5A5A5 at the following offsets:
- 0xa5403c: that's in the middle of other magic values with similar patterns (e.g. 34 34 34 34 A5 A5 A5 A5 E5 E5 E5 E5 F1 F1 F1 F1). This pattern is also present in the firmware update from Canon.
- 0xc950e4, 0xc950e8, 0xc950ec, 0xc950f0. This is in the data area, not present in Canon's update and not recognized by my property parser either. Not sure what's up with it, but there are similar patterns nearby.
- 0xc95bd0, 0xc95bd4, 0xc95bd8, 0xc95bdc: same as above.
- 0xc9f1b0, 0xc9f1b4: like the first one, except it's not present in Canon's update.
- 0xfdb4b0: same as above.
2) Buffers - this was a bit of guesswork. On 5D3, I've assumed the raw buffer allocated by Canon is at least as big as the maximum resolution - the one from 5x zoom. With dm-spy-experiments I've found out a possible size for that buffer (commit 1ee9679 => 0x1cae000, so about 30 MB). Experimentally I've found out that was wrong - the buffer was overwritten by something else.
Another interesting discovery - as soon as leaving LiveView, a small part of Canon's default raw buffer (0x4d31a000) was overwritten near 0x4d600000 - about 2.9MB after its beginning. If we always stay in LiveView, things should be fine - however, we are using the "paused" LiveView for various things, so I wanted to play safe and pick a buffer that's not going to be overwritten when doing that. So I took whatever was not overwritten - found by trial and error between 0x4d600100 and 0x4ee00000: about 24 MB. Enough for 4K, but not for full-res (in 14-bit). For that (extreme) case, the only way to allocate a contiguous chunk of memory was with the SRM backend from Canon - they use it as raw buffer for still photo capture. It's very tricky to use - the buffers have to be freed in exactly the same order as allocated, there's a BUSY sign printed on the screen while this buffer is allocated, while this sign is on the screen it also locks up the UI as soon as you move a scrollwheel, and so on. For that reason, I went for something very hackish - intentional use after free for this buffer (assuming Canon code won't use or move the SRM buffers while in LiveView). It's not very robust, but it's only used with full-res LiveView (since that's the only case we need more than 25 MB for one frame).
To see the memory map, and find out what areas might be free, there is CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP. Without it, the RAM is not cleared at boot, so you'll get different results (and likely not relevant) every time you boot.
Then, once you have guessed a possibly free memory region, you'll need to test it somehow to make sure nobody overwrites it (at least during LiveView). There is some test code for that in the RscMgr_memory branch, but it's nothing fancy - you could just fill the buffer with something and check whether it's still unchanged, in a loop.
RAW_LV_BUFFER_ALLOC_SIZE is how much we need for a full-res image (max W * max H * 14/8).
3) Regarding 07573f3 - that's a bit difficult to do in C (since the arrays have different lengths for different camera models). See for example mpu.c in the QEMU branch for a similar situation.
Tip: the ResLock entries do not depend on the firmware version (they probably depend only on the DIGIC generation), so you can use is_camera("5D3", "*") to cover all versions.
4) 600D LED blink means "out of memory". You could remove some features in features.h (you can even boot with an empty features.h, also comment out CONFIG_RAW* and related entries, e.g. EDMAC, and - on 600D - also remove audio-lapis.o from Makefile.setup.default). [ todo: allow compiling without features on all models, and include this on jenkins ]
Another todo for me: integrate dfort's 700D crop_rec in the 4K branch [DONE], and merge the non-4K changes (e.g. without memory hacks) into mainline (WIP in the raw_fixes branch).
