Wonderful job especially the procedure! The procedure works like a charm. Just tested the A1100 in less than half an hour! Maybe some tips for adding the support for other cameras. I am interested in SX230HS SX220HS or SX270HS.
I haven't actually added one from scratch, but having taken A1100 from mostly broken to mostly working, I'd say it should generally be a matter of adding an entry in the hw/eos/model_list.c based on a similar cam, confirming / updating the values there, and then repeatedly running, seeing where it crashes, and adding the appropriate camera specific workarounds (mostly in eos.c) to fix it.
One thing to note unless you use the gdb scripts, it may not be obvious the firmware has crashed. I added functions in magiclantern/cam_config/A1100/debugmsg.gdb to report the various DebugAssert, HardwareDefect etc cases.
A lot of the errors also don't happen close to the root cause, for example, a crash might be triggered by a semaphore wait timing out, but the code that code that triggers the semaphore may be somewhere completely different. Tracking that kind of thing down involves a lot of quality time in ghidra and gdb.
If I were adding another pre-digic 6 powershot, I'd skim through all the A1100 cases and either add it or adapt for the new camera. For digic 6,
ant's fork has much more complete M3 support than main qemu-eos repo, so if I were trying to support one of those cameras, I'd probably look to integrate that.
Currently, the way different models are handled in the qemu code is pretty awkward. Essentially, all the handlers for hardware addresses etc are applied to all cameras by default, and then tweaked with camera-specific special cases. This made sense when there were a small number of quite similar cameras, but gets messy as they get more diverse. I believe some of the ML folks are working on improving that situation.
