The log from M looks good.
CONFIG_LVAPP_HACK_DEBUGMSG is no longer a valid option on the above PR (it has no effect, same as commenting out the old option). Without any bottom bar hack enabled, Canon's bottom bar will probably conflict with ML one (it does on all other cameras I tried).
To debug, first advice would be to start without LiveView, but I assume you already tried that.
Next, I'd comment out our logging stuff from the data abort handler, and leave just the bare minimum for tracing the MMIO reads/writes (without actually logging anything):
static void __attribute__ ((naked)) trap()
{
/* data abort exception occurred. switch stacks, log the access,
* enable permissions and re-execute trapping instruction */
asm(
/* save context */
"STMFD SP!, {R0-R12, LR}\n"
/* prepare to re-execute the old instruction */
"SUB R0, LR, #8\n"
"LDR R0, [R0]\n"
/* copy it to uncacheable memory - will this work? */
"LDR R1, =trapped_instruction\n"
"ORR R1, #0x40000000\n"
"STR R0, [R1]\n"
/* sync caches - unsure */
"mov r0, #0\n"
"mcr p15, 0, r0, c7, c10, 4\n" // drain write buffer
"mcr p15, 0, r0, c7, c5, 0\n" // flush I cache
/* enable full access to memory */
"MOV R0, #0x00\n"
"MCR p15, 0, r0, c6, c7, 0\n"
/* restore context */
"LDMFD SP!, {R0-R12, LR}\n"
/* placeholder for executing the old instruction */
"trapped_instruction:\n"
".word 0x00000000\n"
/* save context once again */
"STMFD SP!, {R0-R12, LR}\n"
/* sync caches - unsure, try commenting out, see b771f5a0ed3f */
"mov r0, #0\n"
"mcr p15, 0, r0, c7, c10, 4\n" // drain write buffer
"mcr p15, 0, r0, c7, c5, 0\n" // flush I cache
/* re-enable memory protection */
"LDR R0, protected_region\n"
"MCR p15, 0, R0, c6, c7, 0\n"
/* restore context */
"LDMFD SP!, {R0-R12, LR}\n"
/* continue the execution after the trapped instruction */
"SUBS PC, LR, #4\n"
/* ------------------------------------------ */
);
}
The above runs "step by step" the trapped instruction (the one that does the MMIO read/write), and allows one to log what happens before and after its execution (but doesn't actually log anything - this is just the framework for logging the MMIO accesses). This code should run without crashing, but I'm not sure what to do with the caching registers - if it doesn't work, that could benefit from some fiddling. I don't really know whether the cache is handled correctly - if it's not, it's likely to result in subtle side effects that may be hard to track down. If you know how to handle this stuff properly, please chime in.
On 5D3, with REGION(0xC0000000, 0x10000000), the above code sequence may have some side effects when capturing photos (distorted colors, non-deterministic, doesn't happen all the time) and LiveView doesn't start (black screen, camera locked up). Looking into it.
If that won't work, changeset b771f5a0ed3f was the first one that worked on the camera; it did not save any kind of logs, but it did not trap all the MMIO accesses either; only the first one from a DryOS time slice (a very small percentage of them). Still, useful for debugging. You don't have the REGION macro on that changeset - REGION(0xC0090000, 0x001000) evaluates to 0xC0090017.
Edit: narrowed down a LiveView crash to REGION(0xC0F19000, 0x001000). No idea what device uses this range, and emulation doesn't go far enough to access these registers.
The crash happens on the first exception from this range (which makes it easier to debug). Failed instruction:
0001C370 LDMIA R1!, {R3,R4,R12,LR}
and it appears to be in some sort of memcpy, which gets called like this:
7DD90> Evf:000afaa8:00:00: *** sub_1C364(0xfe4bd00, 0xc0f19000, 0x140, 0x0), from ff48f25c
7DDDF> Evf:000afaa8:00:00: *** sub_1C364(0xfe4be40, 0xc0f19200, 0x140, 0x0), from ff48f270
7DE2C> Evf:000afaa8:00:00: *** sub_1C364(0xfe4bf80, 0xc0f19400, 0x140, 0x0), from ff48f284
7DE78> Evf:000afaa8:00:00: *** sub_1C364(0xfe4c0c0, 0xc0f19600, 0x140, 0x0), from ff48f298
...
If I re-enable the permissions and return from the data abort handler so it re-executes this instruction execute from its original location (SUBS PC, LR, #8), I get no crash.
If I execute this instruction from our handler (self-modifying code), and return from data abort to the next instruction (SUBS PC, LR, #4), it crashes.
This scenario should be reproducible in QEMU, outside LiveView.
Edit: indeed, it is. Somehow it attempts to execute an undefined instruction.
0x0001c370: e8b15018 ldm r1!, {r3, r4, ip, lr}
Taking exception 4 [Data Abort]
...with DFSR 0x1 DFAR 0xc0f19000
0x00000010: e59ff014 ldr pc, [pc, #20] ; 0x2c
0x000b0710: e92d5fff push {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr}
0x000b0714: e59f05b4 ldr r0, [pc, #1460] ; 0xb0cd0
0x000b0718: e2800001 add r0, r0, #1 ; 0x1
0x000b071c: e58f05ac str r0, [pc, #1452] ; 0xb0cd0
0x000b0720: e24e0008 sub r0, lr, #8 ; 0x8
0x000b0724: e5900000 ldr r0, [r0]
0x000b0728: e59f15a8 ldr r1, [pc, #1448] ; 0xb0cd8
0x000b072c: e3811101 orr r1, r1, #1073741824 ; 0x40000000
0x000b0730: e5810000 str r0, [r1]
0x000b0734: e3a00000 mov r0, #0 ; 0x0
0x000b0738: ee070f9a mcr 15, 0, r0, cr7, cr10, {4}
0x000b073c: ee070f15 mcr 15, 0, r0, cr7, cr5, {0}
0x000b0740: e3a00000 mov r0, #0 ; 0x0
0x000b0744: ee060f17 mcr 15, 0, r0, cr6, cr7, {0}
000B073C: MCR p15, ... : CACHEMAINT x261 (omitted)
000B0744: MCR p15,0,Rd,cr6,cr7,0: 946_PRBS7 <- 0x0
0x000b0748: e8bd5fff pop {r0, r1, r2, r3, r4, r5, r6, r7, r8, r9, sl, fp, ip, lr}
0x000b074c: e8b15018 ldm r1!, {r3, r4, ip, lr}
[ENGIO] at run_test:000B074C:0001C378 [0xC0F19000] -> 0x0 : ???
[ENGIO] at run_test:000B074C:0001C378 [0xC0F19004] -> 0x0 : ???
[ENGIO] at run_test:000B074C:0001C378 [0xC0F19008] -> 0x0 : ???
[ENGIO] at run_test:000B074C:0001C378 [0xC0F1900C] -> 0x0 : ???
0x000b0750: e25ef004 subs pc, lr, #4 ; 0x4
0xfffffffc: ffffffff undefined instruction 0xffffffff
Taking exception 1 [Undefined Instruction]
The trapped instruction modifies LR...
