First of all, 5D4 has mostly Thumb code, and ARM-console won't help with that (it's ancient stuff I wrote before getting an IDA license, ARM only). Look on CHDK forum for suggestions (from there, I've tried capdis, but only for double-checking small snippets of code where I didn't trust the output from IDA).
Many stubs are easily identified from strings; chris_overseas found some (look up his repo). Running the firmware in QEMU will save an IDC with what functions got called during that session. Currently the emulation works for the bootloader (which is ARM code) and it also runs a tiny part of the main firmware.
Memory layout is similar to other D6 models (look up my notes on e.g. 7D2 or 80D threads). Or just read it from QEMU logs.
First puzzle to solve: how to jump to main firmware from autoexec.bin? Note the 5D4 has two cores, and I believe we have to do something about it somehow.
Next step (which is easy, will probably work in QEMU, but not on the real hardware) would be to adapt the 7D2/80D startup code (which... works in QEMU, but not on the real hardware).
Third step would be making the startup code work on the real hardware (likely as easy as copying a routine from CHDK, discussed on 80D thread). Since I don't have a D6 model yet, I didn't feel any rush to try it.
After that, porting ML should be more or less straightforward (I don't expect major issues, other than some special handling for Thumb stubs).
For the first puzzle (which was solved for single-digic D6 models, and was a non-issue on earlier single-digic models), I've made some limited progress understanding the IPC protocol (communication between the two cores); if you (or anyone else) is interested in continuing this investigation, I can publish them in the current state.
