Messages

This is getting interesting. Please send me a copy of your ROM, so I can attempt to reproduce in QEMU.

I can also attempt to bypass the error and reset camera settings that way - feel free to join the IRC or Discord chat room for that.

Would be nice if you can also try the Lua build from https://builds.magiclantern.fm/experiments.html - same tests.

Long answer here.

Indeed, it's a bit of a mystery, and here's why:
- Card formatted from camera. Check.
- Bootloader able to load FIR file from card. Check.
- Our installer FIR able to check for existence of AUTOEXEC.BIN and ML folder. Check.
- Card is made bootable. Check.
- Bootloader unable to load AUTOEXEC.BIN from card?! This is where it normally locks up with no apparent signs of life - see this flowchart.

One way to troubleshoot this would require access to UART. Not sure where the pins are on 5D2, but I can check if needed. Requirements: FT232RL module (USB to serial) + needle + Arduino-like electronics skills.

Another way to troubleshoot this would be by running QEMU on Mac directly from the physical CF card. I can assist with that, e.g. on Discord or IRC or Teamviewer. We might have the surprise to find ML booting in QEMU from the physical card, but having trouble doing so on the physical camera - in that case, the only way to diagnose this might be the UART port.

This could actually work - and it doesn't have to be on a different domain. Replacing "^https://bitbucket.org/" with something like "^https://magiclantern.fm/bitbucket.php?u=" could do the trick. This replacement can be done on the fly in the forum code, without modifying the database, so if you'd like to test things temporarily on a different host, that's also possible.

Regarding the commit IDs, I also prefer asking Heptapod for a copy of their the git-mapfile. Still need to find the mental energy for doing that...

BTW, if you prefer to discuss the details on IRC or Discord, I'm keeping an eye of these channels as well.

It might be the power button, but can't tell for sure yet. I've been trying to compare startup logs with the power button in both positions, but from 5D3, where the UART connector is accessible without disassembling the camera. No interesting difference yet - other than power being cut somewhere in the middle of logging, nondeterministically, shortly after initializing the MPU. On 60D, the boot process seems to go a little further than that, so I may need to disassemble mine in order to complete the analysis.

You could also check these builds:
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log-mpu/

If they manage to save any logs, it's not the power button.

Here's a test binary that would shed some light over the early boot process (60D 1.1.1):

autoexec.bin

I might be able to tell whether it's the power button, or not, if you record the camera screen while booting this binary. Caveat: tiny fonts that are supposed to be readable in the video.

If you have Arduino-level electronics skills, it's easy to see Canon's debug messages via UART. This could also give some clues about the power button state, though I haven't tried to identify it specifically yet. The connector on 60D is hard to access without disassembling the camera, but otherwise, the extra hardware needed is a FT232RL module (USB to serial) and a needle.

Pretty much, yes. However, I'd prefer a "soft" replacement, when displaying the forum posts, rather than permanently altering the forum database. There's plenty of room for making non-obvious mistakes (that could be noticed months after the change).

You can find several examples by typing "bitbucket.org" in the forum search box, though for a complete list, one may need admin access. Or, after fixing the most common classes of links, the search box will reveal the remaining ones. Writing down the search/replace patterns would be a significant time saver. Caveat: it's not as simple as replacing "bitbucket.org" with "heptapod.net".

Though, the problem I've been trying to delegate to the other members of the community, is the one about migrating the commit IDs. Search string: "bitbucket.org/hudson/magic-lantern/commits", but there are also links from other repositories, that should be handled somehow. Heptapod only hosts the main repo, without the forks, but I've saved an archive of all of the forks before they got deleted - link earlier in this thread. Forks were also archived by softwareheritage.org (helped by the team behind Heptapod), as mentioned here, so linking to them could be an option as well. Again, last time I've checked, the commit IDs didn't match.

Thanks - for those who didn't get the joke, it means somebody still has to sit down and perform the work

Which is exactly the problem I'm trying to solve with Open Collective.

Very nice. This reminded me to add the video to our About page

https://magiclantern.fm/about.html

[Any progress on XYZ?]

Thank you, my english is not the best, thats why I didnt make a very polite text!

It's not about the language, but the attitude. Even if you wrote in your native language, your message would have been just as rude. Such behavior is one of the reasons I had to take a long break from contributing, and to stop posting updates. I'm still affected by this bug, and it won't be fixed overnight. Sorry.

From the forum rules:

-Do not bump topics by posting replies that do not further the discussion.

From the FAQ:

Any progress on XYZ?

If you can't find anything about it in the relevant forum thread, it's safe to assume there was none.
[...]
If you don't have the right skills, asking this question will only serve to annoy those who might have them. Doing some research about XYZ and sharing your findings would be much better - this may encourage others to take a look at it.

And you kept doing this after being told to stop multiple times

I don't want to encourage such behavior, but... well... I might soon have news. Not specific to M50, but for the entire ML project in general. We might be able to launch a fundraising campaign soon, without worrying anymore about the legal aspects, and that would allow me to resume the development.

So, I've started to think about providing a way to allow such kind of "bumps" - it would be called a "support contract" edit: nope, bad behaviors won't be allowed, no matter how much you might pay

In the CHDK forum I once heard the statement that as soon as CHDK became more commercial, Canon could protect its cameras better for debugging. Is that to be expected here too?

They could have done so back in 2012, when we were accepting donations, or in 2013, when we've got a massive popularity spike after announcing raw video (see e.g. Petapixel, EOSHD and several others). To date, Canon have not removed the ability to run AUTOEXEC.BIN from the card (feature present in all EOS models from DIGIC 2 to DIGIC X), they have not removed the massive amount of debug messages we are relying on, they have not locked down the UART interface and so on.

What they did: they removed the ability to downgrade from certain firmware versions, but this seems to be in response to vulnerabilities recently identified by Checkpoint Research. In other words, they do react quickly if anything bothers them.

They have also changed the encryption in EOS R/RP and newer models, but we didn't even have to figure it out. That's because, at the same time, they also enabled Canon Basic on those models - the scripting engine documented by CHDK some 10 years ago - making it even easier to execute code on these cameras, without even having to worry about DMCA. This scripting engine is likely present on all DIGIC 8 and X models, already confirmed on R/RP, R5/R6, M50, 250D and others.

On top of that, on DIGIC 7/8/X, you can temporarily patch pretty much anything in Canon firmware, by remapping parts of the ROM into RAM. This was possible to a very limited extent on DIGIC 2..5 ("cache hacks"), and no known possibility to patch ROM contents on DIGIC 6. Longer version here.

In other words, recent models are likely a lot more hackable than previous ones. The main reason why there is no ML on these models yet, is lack of developer time. Proof of concept was already done back in 2018 - all those "Hello World" screenshots actually demonstrate running custom code alongside Canon's own firmware. Though, the initial plan was to delegate the porting efforts for new models entirely to the community... hence all of that work on emulator and development documentation.

Yes, there are some technical difficulties, as the hardware changed significantly (so porting is no longer "just" a matter of tweaking the existing code), and the instruction set also changed to Thumb (so, many of our low-level tricks will no longer out of the box), but all of these can be solved given sufficient development time.

BTW, operating under Open Collective's umbrella is somewhat like a nonprofit - Open Collective themselves call it a "virtual nonprofit". Does this count as "commercial" or otherwise a threat for Canon? I don't know, and I hope they don't see it that way. One of the biggest advantages of this approach is - if you ask me - that two fiscal hosting organizations with no previous connections to our project (Open Collective and Conservancy) have reviewed our reverse engineering activities and - after multiple rounds of legal advice - they have (finally) found our project acceptable. I hope this is going to give some peace of mind to everyone involved in the project - at least compared to previous state, where quite a few ex-contributors asked me to remove their e-mail / username / etc from this website because of the legal uncertainty.

We are not the only ones doing this - there are also other "alternative firmware" projects moving in the same direction, for example, OpenWrt joined Software Freedom Conservancy a few months ago, and Rockbox considered joining as well.

And it wasn't a rushed decision either. I've started to consider Open Collective at the beginning of 2019, but fiscal hosting isn't a recent idea - back in 2013 we've tried to apply to Software Freedom Conservancy. As it didn't work out, back in 2014 I've started to work with Apertus, hoping to "subsidize" ML development that way. That didn't work either. Earlier this year I've tried my luck with freelancing (again, didn't work out), and also started some side projects that don't rely on reverse engineering, but none of them had the potential to cover any costs of living within the next few years without *massive* time involvement from my side. So, the only sensible choice was to... change my mind towards fundraising for ML development.

I've submitted the application to Open Collective a long time after crossing a critical point of no longer being able to dedicate long hours to hobby projects (ML in particular). The alternative - for me - would have been to watch from the sidelines - as I did since mid-2019 - at least for the next few years, and hope for the best. Yes, the project can definitely progress without my involvement - Danne and others already proved this - so I can also step back if there are serious concerns about Canon getting upset by this change. As I said before, things will only move in this direction as long as there will be consensus.

This video - very similar to the previous one - explains the situation very well. It's from one of the founders of Open Collective - meeting with them scheduled for Tuesday

https://www.youtube.com/watch?v=szE_00HC5h4

- I took a step back and got a lot more familiar with the ML codebase

This is actually the step I'm most excited about

Yes, being able to discuss the low-level details to somebody who actually knows what they are talking about, makes a huge difference for me.

- I updated Qemu to 4.2 (still some problems, but easier to build than old Qemu, and better in some ways)

This one is also a significant update, as QEMU will be an essential piece of puzzle in supporting recent models (read: DIGIC 4+/6/7/8/X). There are significant - likely massive - amounts of low-level work ahead, but, without the ability to run automated tests for every single supported camera model (whether in emulator or... somehow on real hardware), I don't see any other reasonable way to support ML on all of these new models.

The development kit from @coon will be another essential piece of puzzle - besides exploring camera internals, it will allow debugging ML in real-time while running on real hardware, i.e. exactly where names_are_hard stumbled at his previous attempt. And I'm sure we'll find plenty other good uses for it in the near future.

Chapeau

Hopefully yes - though, part time would be a much more likely scenario. Some details a few posts earlier. The cool part is - with Open Collective at least - that the funds will be available to anyone in the community who makes significant contributions - not just to me or to a restricted set of core developers. And, of course, anyone will be able to see where the money goes

Highly recommended reading: https://docs.opencollective.com/help

Or watch this video - from one of the Open Collective founders:

https://www.youtube.com/watch?v=lyOmToAyvjk

We aren't able to accept money yet; still need to discuss with them and find out the details. But it's a clear step in this direction.

Update: just received an e-mail from Open Collective, titled: " We can host Magic Lantern! "

Santa arrived early?

Next steps: will find out after a virtual meeting with them.

[Affected models:]

There were some recent reports from Mac users who couldn't install ML on exFAT cards, when using the latest version of macOS. The first report I've received was from a 60D user who just upgraded from Catalina to Big Sur. Some other reports followed shortly, so I've decided to take a closer look. Tests were done on macOS Big Sur 11.0.1.

Affected models:
- 550D, 60D, 600D, 700D, 100D, EOS M, 5D3 (both SD and CF), 200D, M50 (tested in QEMU).
- 500D does not support exFAT, so this problem does not apply here.
- Likely all other DIGIC 4..8 models that support exFAT (SD or CF, doesn't matter).
- DIGIC X models: not tested, but expecting them to behave just like DIGIC 8.
- PowerShot cameras: not tested.
- non-Canon hardware: not tested, but anything is possible

Steps to reproduce on real hardware:
1) Take a 64GB SD card (or larger)
2) Format it in the camera (550D or newer) => it will be formatted as exFAT.
3) Unzip ML files on the card from macOS Big Sur (which will create autoexec.bin, ML-SETUP.FIR and the ML directory)
4a) Attempt to install ML by running Firmware Update with ML-SETUP.FIR:

Result: "ML directory not found! Please copy all ML files."

The second screenshot contains some ad-hoc diagnostic output, showing that a FIO_FindFirst/FindNext from the camera is able to find the ML directory, but it's not able to read its contents.

4b) Make the card bootable manually (e.g. with make_bootable.sh) and attempt to run ML
Result: ML will not be able to read the contents of the ML subdirectory. It won't be able to read its fonts, modules, scripts and so on.


Steps to reproduce in QEMU:
1) Create an empty 64GB image

Code Select Expand


rm -f sd64.img
truncate -s 64G sd64.img

2) Format it in the virtual camera.
Edit run_canon_fw.sh to use the newly created image, launch the emulation for your favorite DIGIC 4/5 camera (it must boot the GUI in the emulator and it must support exFAT) and format the image. Turn off the virtual camera.
3) Mount the card image into macOS Big Sur.
e.g. start here and add these definitions into OpenCore-Boot.sh:

Code Select Expand


  -device ide-hd,bus=sata.3,drive=SDCard
  -drive id=SDCard,if=none,format=raw,file=/path/to/qemu-eos/sd64.img

4) Using macOS Big Sur, download ML for your favorite DIGIC 4/5 camera (that's all we've got for now) and unzip it on the virtual card.
5) Eject the virtual card and run the emulation.

Shortcut: here's a 64GB SD image already prepared for 60D, which you can use to reproduce this bug. Tip: decompress (unxz) it on a BTRFS filesystem - that way, it will only take a few megabytes on the disk

Once confirmed on a fully supported camera, you can also test on newer models, such as 200D or M50, with a minimal test program, found on the digic6-dumper branch in minimal/qemu-fio, using the modified source: minimal.c

Compile with:

Code Select Expand


hg clone https://foss.heptapod.net/magic-lantern/magic-lantern/
cd magic-lantern/
hg up digic6-dumper -C
cd minimal/qemu-fio
wget https://a1ex.magiclantern.fm/bleeding-edge/BigMac/minimal.c -O minimal.c
# note: make install_qemu won't work on exFAT card images
# mount the 64GB SD image as EOS_DIGITAL, so "make install" will autodetect it
make MODEL=200D CONFIG_QEMU=y install
# run the emulation from the qemu-eos directory


Analysis

The minimal test code linked earlier will output something like this:

Code Select Expand


Trying SD card...
    filename     size     mode     timestamp
--> DCIM         00020000 00000010 30/09/2017 12:15
--> MISC         00020000 00000010 30/09/2017 12:15
--> .fseventsd   00020000 0000003a 13/12/2020 22:33
--> .Trashes     00020000 0000003a 13/12/2020 22:33
--> autoexec.bin 00002900 00000020 13/12/2020 18:28
--> ._autoexec.b 00001000 00000022 13/12/2020 22:35
--> ML           00020000 00000038 03/07/2018 16:20
--> ML-SETUP.FIR 00008d5c 00000020 13/12/2020 17:14
--> ._ML-SETUP.F 00001000 00000022 13/12/2020 22:35
--> ._ML         00001000 00000022 13/12/2020 22:35
Trying DCIM dir...
    filename     size     mode     timestamp
--> 100CANON     00020000 00000010 30/09/2017 12:15
--> EOSMISC      00020000 00000010 30/09/2017 12:15
Trying ML dir...
FIO_FindFirstEx error 1, test failed.


Notice the attribute of the ML directory (0x38), created by macOS Big Sur, and compare it with the attribute of directories created by the camera (0x10). Thanks Lorenzo33324 on the Discord channel, for spotting the difference!

According to the official exFAT specification from Microsoft, the FileAttributes field may use the following bits:


Valid bitmasks for exFAT are:

Code Select Expand


- 0 -> 0x01: ReadOnly
- 1 -> 0x02: Hidden
- 2 -> 0x04: System
- 3 -> 0x08: Reserved1
- 4 -> 0x10: Directory
- 5 -> 0x20: Archive


In our case, the ML directory created by macOS Big Sur has the attributes set to 0x38, meaning: Archive, Directory, Reserved1. This is a problem - the directory created by Big Sur does not have valid attributes.

The exFAT driver from DryOS does not know how to interpret the Reserved1 bit, so it does not recognize ML (created by Big Sur) as a valid directory.

To confirm, I've mounted the SD card image under a Win10 virtual machine and ran the following command on the root directory of the card:

Code Select Expand


attrib -a ML


Result: the ML directory became readable for the above test code, which was ran on the virtual camera.

You can get the same outcome by manually patching the attribute of the ML directory. In the attached 64GB card image (sd64.img), patch the byte at offset 0x20402A4 from 0x38 to 0x30, recompute the checksum (e.g. with fsck.exfat) and the ML directory becomes readable for the camera.

Caveat: the above workarounds will not "magically" fix your filesystem in order to use Magic Lantern. For that, you'd also have to modify the attributes of all subdirectories of the ML directory.

Another test you may want to run: delete the DCIM directory from the exFAT card and re-create it from Big Sur.
Expected outcome: camera won't be able to save the images.
On 60D, I've got an error at startup: "Card cannot be accessed". This will force you to format the card, losing any data you might have there. The filesystem was fully readable under Linux (FUSE exfat 1.3.0) and Windows 10.

ML bug? Apple bug? Canon bug?

As the issue can be reproduced with plain Canon firmware, it's clearly not a bug in ML.

Microsoft says this about the "reserved" bits:


What happens is that:
1) Apple used a bit declared as "reserved" in the exFAT specification. Whether it was intentional or by mistake, I have no idea.
2) Canon interpreted that bit as in "this is not a directory".

Therefore... both Apple and Canon seem to have misused the exFAT specification. Thanks g3gg0

Conclusion

The current version of macOS Big Sur - at least 11.0.1 - creates directories with invalid attributes on exFAT. While the filesystem drivers from other operating systems, like Windows or Linux, will tolerate these invalid attributes, the exFAT driver from Canon cameras will not.

In other words, the directories created from Big Sur 11.0.1 will not be recognized as valid directories in Canon EOS cameras.

This will affect users who will try to install Magic Lantern on exFAT cards, regardless of the camera generation, from DIGIC 4 until at least DIGIC 8, likely also DIGIC X (but not tested).

Regular users are unlikely to notice this bug, as triggering it requires the user to *create* a directory from macOS Big Sur, and to use it somehow in the camera.

This is not a ML bug. I can attempt to find a workaround as time permits, but... no guarantees.

Let's take a look. If you were able to run the portable ROM dumper, that's a good sign.

[ml-repos.tar.xz]

Le code source est disponible dans cette archive:

Please find the archive with all ML forks, here: ml-repos.tar.xz

Update: I have submitted the story to EFF earlier this week, right before the website went offline; you may read it here (or the shorter version on Twitter, if you prefer). They got back to me, and we expect to have a virtual meeting with them this Tuesday - together with Trammell and g3gg0.

Both Open Collective and Conservancy reacted positively to our attempt to contact EFF - hopefully something good will come out of this

Will keep you posted.

Edit: here's the outcome of our EFF letter

https://www.youtube.com/watch?v=QCJkZlZQoUQ

https://www.ifixit.com/News/47696/were-hosting-a-press-call-to-discuss-how-copyright-law-hinders-repair

The story for EFF is coming together, thanks to everybody who reviewed it on the Discord channel!

As it will appear in a public mailing list and will end up as a public comment, I've shared a link there, if anyone else would like to take a peek or suggest further edits. I'll submit it once it settles, likely tomorrow or the day after. The timing is short, as EFF would have to review it, to get in touch with us for additional info, and to turn it into a pertinent comment for Copyright Office, all before December 14.

Please note this was written as a response to EFF's request for a story about how DMCA interferes with legitimate tinkering with the software-enabled device you have bought (in our case, the DSLR camera). It's not a request for EFF to help us, so it should probably be kept as readable as possible, for anyone outside our project - that is, it shouldn't get too technical.

https://www.eff.org/deeplinks/2020/11/lets-stand-home-hacking-and-repair

The story for EFF can be considered an extended version of the series of tweets shared earlier. Actually, the tweets were copied and/or adapted from an earlier draft.

Shortly after me going into full Donald Trump mode on Twitter, something magic happened.

We have received a reply from Software Freedom Conservancy - another US-based fiscal sponsoring organization to which we have applied back in 2013. They are also on good terms with Open Collective. Some relevant projects already hosted on Conservancy: OpenWRT (joined September 2020), Wine, Samba, Git, Mercurial, Homebrew, QEMU.

Their reaction was totally unexpected to me - in particular, this paragraph sounds very promising:

We turn projects away these days, but only if they aren't a good fit for our mission, but that's not a case for you all — in fact, Magic Lantern is the kind of project we're really interested in seeing apply!

Background: we have submitted an application letter in January 2013, but we haven't received a reply back then. We didn't follow up, because shortly afterwards, we talked to SFLC - which, at that time, I thought it was a related organization, but it wasn't the case - who advised us sharply against taking donations. Their advice wasn't really in disagreement with the advice from EFF, as they also said that making money out of our software could increase our legal risk - but SFLC was a lot more conservative, possibly because of the 1DX/1DC rumour, which appeared shortly after we spoke to EFF. That's when we stopped accepting monetary donations, from what I remember. Eventually we calmed down to some extent and started accepting BTC as a workaround.

So, the idea of fiscal hosting is not new for us, but - back in 2013 - we gave up after receiving the not-so-favorable advice from SFLC. OK, Conservancy said they weren't prepared to accept us in 2013 either - but the lack of reply was actually a honest mistake from both sides (bad timing + not following up).

Of course, this does not mean Conservancy accepted us, or that is going to accept us, but they seem to have a genuine interest in figuring out a way forward. We'd still have to go through the same steps as with Open Collective, as they need to know what we are doing, to make sure our reverse engineering activities are not risky for them.

TLDR: now we've got two potential fiscal hosts to work with

If you are wondering: "Conservancy does encourage projects to apply to multiple non-profit homes to find the best fit.". Therefore, it is my understanding that discussing our application with both Open Source Collective and Conservancy in parallel shouldn't be an issue.

Status update: as you might have expected, Open Source Collective (US-based) has to be very careful not to put themselves at risk by accepting us, so they had to review our reverse engineering activities. Unfortunately the response wasn't positive.

After a virtual meeting with their lawyer, together with g3gg0 and coutts, where we tried to explain what we do and what are the points we are careful about, things progressed a little. Earlier this week, I've received a small positive sign that there might be a way forward - still waiting for the details.

In any case, one of the biggest roadblocks is the FIR encryption, which might be problematic under DMCA - although we don't distribute any Canon code in our downloads, and we don't publish any encryption tools either. On recent models - since DIGIC 8 - Canon Basic is likely helpful from the DMCA point of view, as there's no encryption to be bypassed. On old models, UART - which we figured out in 2018 - might also be useful, as there's no encryption to be bypassed there, but one would have to attach wires to the camera.

So, there are some alternatives to FIR encryption - but we didn't know about them before ~ 2018. Now, the question is whether our previous approach of creating fake firmware updates (ML-SETUP.FIR, ROM dumpers) is going to haunt us, and for how long.

Anyway - the lawyer who advised Open Collective told us that one of the preferred ways to make our project acceptable for fiscal hosting would have been to apply for a DMCA exemption for allowing software modifications to digital cameras - unfortunately, the application deadline had passed some months ago...

However, I've recently found about an initiative from EFF, where they ask for an exemption to allow repairing *and* modifying any software-enabled device:
https://twitter.com/EFF/status/1331657954412544002
https://www.eff.org/deeplinks/2020/11/lets-stand-home-hacking-and-repair

If you have a story about how:

- someone in the United States;
- attempted or planned to modify, repair, or diagnose a product with a software component; and
- encountered a technological protection measure (including DRM or digital rights management—any form of software security measure that restricts access to the underlying software code, such as encryption, password protection, or authentication requirements) that prevented completing the modification, repair, or diagnosis (or had to be circumvented to do so)
—we want to hear from you! Please email us at [email protected] with the information listed below, and we'll curate the stories we receive so we can present the most relevant ones alongside our arguments to the Copyright Office. The comments we submit to the Copyright Office will become a matter of public record, but we will not include your name if you do not wish to be identified by us.

I'm tempted to ask EFF whether they would be interested in our story. Though, I have several reasons to believe our approach regarding fake FIR files, without publishing the encryption tools, is actually safe from the DMCA - but this part is still being reviewed by Open Collective at the time of writing.

If we decide to contact EFF, they would have to submit our story to Copyright Office no later than December 14: https://www.copyright.gov/1201/2021/. Further details available on Discord - e.g. if you'd like to help me review the draft e-mail for EFF.

BTW, normally our software is free, but today is Black Friday - you can get it for a reduced price

Here you go (howto):

Code Select Expand


0.676.391  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 11 01 00)                               ; GMT_GUICMD_LOCK_ON
0.676.600  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 12 00 00)                               ; GMT_GUICMD_CLOSE_SLOT_COVER
0.676.733  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
0.711.587  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 0a 00 00)                               ; BGMT_UNPRESS_ZOOM_OUT
0.711.746  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 09 00 00)                               ; BGMT_UNPRESS_ZOOM_IN
0.713.322  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1c 00 00)                               ; Unknown GUI event
4.141.943  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
4.142.166  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 00 01 00)                               ; BGMT_MENU
4.184.613  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 0a 00 00)                               ; BGMT_UNPRESS_ZOOM_OUT
4.184.777  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 09 00 00)                               ; BGMT_UNPRESS_ZOOM_IN
4.186.119  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1c 00 00)                               ; Unknown GUI event
7.094.984  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
7.095.216  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 01 00)                               ; BGMT_PRESS_DOWN
7.228.965  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 00 00)                               ; BGMT_UNPRESS_DOWN
7.298.088  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
7.298.252  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 01 00)                               ; BGMT_PRESS_DOWN
7.447.705  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 19 00 00)                               ; BGMT_UNPRESS_DOWN
7.899.904  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
7.900.048  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1b 01 00)                               ; BGMT_PRESS_LEFT
8.065.160  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1b 00 00)                               ; BGMT_UNPRESS_LEFT
8.860.851  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
8.861.006  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1b 01 00)                               ; BGMT_PRESS_LEFT
9.018.022  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 1b 00 00)                               ; BGMT_UNPRESS_LEFT
9.876.111  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
9.876.346  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 01 01 00)                               ; BGMT_INFO
10.072.643  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 01 00 00)                               ; Unknown GUI event
14.048.170  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
14.048.894  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 0a 00 00)                               ; BGMT_UNPRESS_ZOOM_OUT
14.049.030  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 09 00 00)                               ; BGMT_UNPRESS_ZOOM_IN
14.061.437  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
14.074.828  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
14.160.863  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 05 06 26 01 00)                               ; GMT_GUICMD_PRESS_BUTTON_SOMETHING
14.162.888  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
14.163.138  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 04 05 07 00)                                  ; EVENTID_ACCUMULATION_STOP
14.163.356  **INT-36h*:0001dedc:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON


Ignore the zoom events - they are sent internally by the MPU when switching GUI modes. Also, GMT_GUICMD_PRESS_BUTTON_SOMETHING means some button was pressed - it's sent together with some other button events.

14.217.667         Evf:00034e78:91:06: Image Power Failure

That explains why you are not able to enter LiveView. I don't know if replacing the sensor is enough to fix this, or whether it's a bad connector or a faulty driver circuit on the main board. If you find out, please keep me posted, as this is an error I've seen a few times - but no way to diagnose it without opening the camera.

IDA has a different issue - iirc an intermittent one - but it's also on the image capture side. I wasn't able to diagnose it remotely, without physical access to the camera.

The last line appears to indicate a bug in the logging code. The debug string was "[Post]%s %s(%s)(%d) %s", and there was an issue with the (%s) argument. Hopefully the error can be reproduced on a good camera as well

The error from lines 777 etc, is not something to worry about - I've got it in many startup logs saved from good EOS M's.

The DM-000 log looks quite good - but it doesn't cover the ERR70 event. Can you trigger the error within the first 20 seconds, so it will be included in the log?

Indeed, RAW information is only available right after capturing a picture (so-called QuickReview mode).

It can be done in regular image review mode as well, but it's not very easy. It was requested here as well - if anyone is looking for hints.