Bitbucket cannot automatically merge this request.
The commits that make up this pull request have been removed.
Bitbucket cannot automatically merge this request due to conflicts.
Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:
hg update 7a3b5fa3f4c6hg pull -r update-to-EOSM.203 https://bitbucket.org/Eosm_Dev/magic-lantern# Note: This will create a new head!hg merge update-to-EOSM.203hg commit -m 'Merged in Eosm_Dev/magic-lantern/update-to-EOSM.203 (pull request #792)'
It might be a good idea to keep track of the real SoundDevShutDownIn address in your stubs.S. The reason we're temporarily using address for StopASIFDMAADC is to resolve Issue #2255 while not breaking other platforms that seem to have the addresses for StopASIFDMAADC and SoundDevShutDownIn transposed.
For EOSM.203 it would be:
///NSTUB(0xFF10D450, SoundDevShutDownIn) // This is the real address
They haven't changed, they are all there. It is just that he removed all the unused stubs, which is fine because the addresses most like changed anyway. I was only suggesting keeping track of that one stub because it has the wrong address. Changing it would break other platforms--that are probably also using the wrong address.
Ok--a couple of stubs are changing, the pre_isr_hook and post_isr_hook. Check out commit b1bd219 This hasn't made it into unified yet but the latest changes in unified are causing conflicts with stubs.S in this pull request.
As far as I can tell the stubs haven't changed. Things got rearranged a bit with the 202 stubs which caused this merge conflict. The stubs in the @Eosm Developer repository haven't changed either. By the way, who is @Eosm Developer ? I distributed test builds and have been getting very good results, certainly no worse than EOSM.202.
I'm not the original developer, but I have been trying to get EOS M 2.0.3 working in QEMU (for something else I'm working on) and along the way, I needed to do an sf_dump and noticed that the stubs are wrong. I disassembled the 2.0.3 firmware and found the stubs for SF_Create and SF_readSerialFlash, but wasn't able to find SF_Destroy. From modules/sf_dump/sf_dump.c
It should be at the same offset (it doesn't have a string, but was named based on its usage patterns).
Currently EOS M doesn't boot the GUI in QEMU, but it goes pretty far. It's most likely because it boots to LiveView by default, which is not emulated. It's probably fixable with a startup log in playback mode.
Hmm. I found a .FIR file for 2.0.2 and downgraded. I get a LOT further with 2.0.2 in QEMU than I did with 2.0.3. With 2.0.2, I get past loading AUTOEXEC.BIN and eventually hang with repeated messages about changing user_mem_start. With 2.0.3, my last message is about Serial Flash: "70: 34.048 [PROPAD] SerialFlash Packages!! 0x7". That had me wondering if I'd really successfully dumped the flash, but based on what I'm assuming is a magic number at offset 0x200000, I think I did. In any event, I don't mean to hijack this pull request into a way for me to get my QEMU session to work, but I thought I'd post the offsets.
As for SF_Destroy, I had apparently screwed up the math when I looked for it last night. I looked again and, as you suggest, it is likely at the same offset, which puts it at 0xff13b00c. That location looks like a function entry and has 18 references to it in my disassembly.
While I don't know enough about Magic Lantern to claim that I can maintain this pull request (this is my first development effort with it), if you'd like, I can submit a change to sf_dump that updates it with these offsets.
The SerialFlash Packages!! 0x7 is actually a successful one. The error message you are looking to avoid is something like [PROPAD] ERROR Not Exist Valid ComboPackages!!. It tricked to me as well - see my latest post on EOS M2.
Feel free to continue the emulation discussion on the forum (the main QEMU thread would probably be a better place). If you get a startup log that boots the camera directly into some sort of menu, without opening LiveView, I'd like to give it a try as well. I'm pretty sure @Daniel Fort already got such logs in some other thread, probably related to the shutter bug.
I recall a while back doing startup logs while booting the camera with the playback button which isn't LiveView, is it? It didn't resolve the Shutter-bug (Issue #1893) but we did find three different StartupCondition states, one of which doesn't show the bug.