From
this EOSM2 quirk:
The ENGINE_MIRROR region from the above logs is used by engio_read / EngDrvOut to store the values written to hardware registers, as these registers cannot be read back. This address must be aligned at 0x40000 bytes, but the block allocated for it might be a bit larger.
Some examples:
60D: ENGINE_MIRROR 0x5C849960 0x00080000
Actual mirror address is 0x5c880000 (rounded up near 0xff1c566c), used until 0x5c8c0000.
0x5c880000 - 0x5C849960 = 217K free before this block.
0x5C849960 + 0x00080000 - 0x5c8c0000 = 38K free after this block.
1100D: ENGINE_MIRROR 0x40FF7000 0x00080000
Actual mirror address is 0x41000000 (rounded up near 0xff1d4890), used until 0x41040000.
0x41000000 - 0x40FF7000 = 36K free before this block.
0x40FF7000 + 0x00080000 - 0x41040000 = 225K free after this block. Not bad!
EOSM2: ENGINE_MIRROR 0x412A0000 0x00044000
Actual mirror address 0x412A0000 (somebody forgot to round it up). Good luck fixing that...
550D: ENGINE_MIRROR 0x4F757200 0x00040000
Actual mirror address: 0x4f780000 (rounded up near 0xff1c1228), used until 0x4f7c0000. Buffer overflow?! (overlaps VSHADING_COMP_WORK)
The above is just theory; I did not verify whether the addresses are really unused or not. Procedure: CONFIG_MARK_UNUSED_MEMORY_AT_STARTUP, then use the camera in any mode you may think of, including taking pictures in burst mode until the buffer gets full, then look for changes in the tested memory region. See also
PR #731.