Cool, you'd probably enjoy it. We have a few active devs at the moment, we're okay on the reversing side and general HW understanding, but not skilled at ARM internals. A1ex has good ARM knowledge but, currently not enough time.
Let me give you a quick summary of some random points:
- Can run arbitrary code, from C, on real cams (this should include 800D). This can be triggered interactively when Canon code (DryOS) is running.
- Can emulate cams to varying degrees in a custom version of Qemu. Old cams have full GUI menus and can even simulate taking pictures, etc. New cams (including 800D) don't emulate that far but can do early init before getting stuck. Not crashed: they go to an idle state, waiting for tasks from a queue that is empty. Somewhat earlier I see Canon code checking a struct in mem that is not initialised. On real hardware it is, so whatever inits that is a missing piece, though perhaps not the direct cause.
- With a little work for the physical connection, you should be able to get UART access to the cam, includes an interactive shell. There are different shells for different processors.
- ROMs are quite friendly to work with, no obfuscation and they contain many debug strings, including an assert function
- Overall structure of Canon OS, DryOS, is fairly well understood. RTOS, task based via a queue, interrupts. Some of the messaging protocols between peripherals are understood.
- ML abstracts camera internals to some degree. There is good support for a range of Digic 4 and 5 cameras. 800D is Digic 7, getting ML working on Digic 7 is mostly working out how 7 has diverged from 4&5 and updating ML to support this. Structures used by Canon APIs may have new fields, HW abstraction in ML may need updating for new co-processors, etc.
