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)'
Nice! Got it running.
ML-SETUP.FIR is working fine too.
Sounds good. Can you attach a stubs test log from the selftest module?
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
So the stubs have changed? I though those where more or less set in stone.
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.
Oh, you mean this commit from a few days ago? Looks like all the changes were on commented out stubs and this pull request removed them:
There's a script that auto-formats all the stubs files (comments out unused ones, makes sure all of them are grouped in a consistent way etc).
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.
These are all different, unless I misunderstand things (possible):
+NSTUB(0xFF1350F0, PowerAudioOutput) // Look for actrlCpowerControl Case 1 Sub
+NSTUB(0xFF10B190, SetNextASIFADCBuffer) // Int16
+NSTUB(0xFF10B378, SetNextASIFDACBuffer) // Int16 Regular
+NSTUB(0xFF10A920, SoundDevShutDownIn) // Temporarily using address for StopASIFDMAADC to resolve MLV_SND issue
+NSTUB(0xFF10A674, StartASIFDMAADC) // To Regular
+NSTUB(0xFF10AA48, StartASIFDMADAC) // Needs Patches Or
+NSTUB(0xFF10A920, StopASIFDMAADC) // Regular -- Stop ASIF ADC - needed for future changes to mlv_snd.c
+NSTUB(0xFF10ACC8, StopASIFDMADAC) // NormalStopAsif
+NSTUB(0xFF1351A0, PowerAudioOutput) // Look for actrlCpowerControl Case 1 Sub
+NSTUB(0xFF10A724, StartASIFDMAADC) // To Regular
+NSTUB(0xFF10A9D0, SoundDevShutDownIn) // Temporarily using address for StopASIFDMAADC to resolve MLV_SND issue
+NSTUB(0xFF10A9D0, StopASIFDMAADC) // Regular -- Stop ASIF ADC - needed for future changes to mlv_snd.c
+NSTUB(0xFF10AAF8, StartASIFDMADAC) // Needs Patches Or
+NSTUB(0xFF10AD78, StopASIFDMADAC) // NormalStopAsif
+NSTUB(0xFF10B240, SetNextASIFADCBuffer) // Int16
+NSTUB(0xFF10B428, SetNextASIFDACBuffer) // Int16 Regular
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_Dev repository haven't changed either. By the way, who is @Eosm_Dev ? I distributed test builds and have been getting very good results, certainly no worse than EOSM.202.
As far as I can tell the stubs haven't changed
Ok I'll believe you, although the actual addresses are different (eg. 0xFF134CE4 vs 0xFF134D94 for PowerMicAmp) my lack of knowledge here might be at fault.
Right, what's confusing is that one address is for 2.0.2 and the other address is for 2.0.3. Check the stub-checker log posted by a1ex and you'll see both addresses are correct.
Any sign of @Eosm_Dev ? The code is changing and there are conflicts to resolve in stubs.S. How do we keep this pull request up to date?
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.
Looks like @Eosm_Dev abandoned this pull request. That is the protocol for reviving it? Would it be inappropriate to submit a new pull request using this one as a starting point?