Messages

Long press is only possible to detect on some buttons - half-shutter, SET on some models (not all), direction keys (likely all models), zoom in/out (most models, but not all). The Play button is not among them.

A double-click should be easier to detect - that is, a single press could return to LiveView after a timeout, and a double press could trigger some special functionality.

A three-state toggle is also doable, e.g. LiveView --(PLAY)--> Image review --(PLAY)--> Image review with ML overlays --(PLAY)--> LiveView.

Though, it probably makes a lot more sense to hook the INFO/DISP key (normally used to toggle Canon review modes), and that would also be consistent with LiveView (press INFO until selecting the ML screen). Disadvantage: this particular key might require hardcoding yet another model-specific address, which I'd prefer to avoid. Reasons: I cannot test the image review mode in QEMU yet, to validate that address, and I'm no longer sure whether I can get tester feedback on all supported models. With fully generic code (without model-specific bits or assumptions), it's much easier to test - if it works on 2 or 3 cams, it will very likely work on all other models.

Exactly that's why cr2hdr needs to use the same settings for the entire clip, rather than evaluating every single frame. That means, it needs two passes. There is a workaround, --same-levels, which still evaluates every single frame, but at the end it runs a second pass to equalize them. It's probably not as good as using the same settings from the beginning, but... the test clip used back then (2014) was a night clip with the subject performing in front of a light bulb.

Now the surprise - I've re-rendered your test clip, with and without --same-levels, and couldn't notice any flicker. Not sure where to look - I must be terrible at pixel peeping

Code Select Expand


mlv_dump --dng --no-stripes --no-fixcp M31-0934.MLV
cr2hdr --same-levels *.dng
ufraw-batch --exposure=10 *.DNG   # that's right, exposure boosted by 10 stops, otherwise it was pitch black :)


This feature is triggered by a model-specific button (5D2: PicStyle, 5D3: Light, 100D: Menu etc - see the Help tab). The 650D/700D don't seem to have this feature enabled at all.

Ideally, there should be one single button for all models to trigger this feature. Possible choices:

- Pressing PLAY a second time once in review mode could be OK, but normally the user would expect it to exit the image review dialog. If we decide to hook this key, I'm pretty sure there will be others who will ask for the previous behavior (or, at least an option to turn this off). Interpreting a double-click could also be an option.
- MENU also looks like a reasonable choice to me, though, in this case, the user may expect a menu. There are some playback-related features that could be moved here, so it might not be a bad idea, after all.
- SET is not good, as it triggers a menu on recent models. It's available (unused) on some old models, but that doesn't help with portability.
- *, AF-ON, DOF preview: hard to use (they normally trigger half-shutter events)
- left, right - better leave those for navigation
- down: used as "delete" on EOS M, maybe others
- up: might be available on most models without joystick, but I wouldn't choose it on models with joystick
- did I miss any other buttons present on all models?

Not going to implement this overnight, but that old model-specific code needs to go, if you ask me.

Other than noticing that old commit hashes cannot be used on Heptapod (i.e. no direct link translations), no significant updates. The FAQ about progress & stuff applies here as well.



Edit: looked further into the Bitbucket - Heptapod link translation issue for commits. Heptapod uses internally a Git repository, as a temporary implementation detail (they intend to get rid of it eventually, but that will probably take some months or years). I've tried to replicate their Git mirroring process using their fork of hg-git, and I can get consistent Git - Hg mappings until commit 2c7a27c / b08b345ea3f3fb5dc11a0f6ffb4603b07063761a. The next commit, b8083a2 / cea71a6a628f66b722725387bb9c5c4794b0df16 on Heptapod, shows up as ae85588aeb12efb0895b9c41efd18e5d3c747de6 in my local Git copy.

I've looked at their sources (Heptapod itself is open source) and found the hash translation code in hg_git_repository.rb. They use a file named "git-mapfile", apparently generated by hg-git, which stores the mapping between git and hg commit hashes.

Currently, they don't seem to be able to look up anything on the web interface using the Mercurial commit hash (grep their sources for "sha_from_hgsha"), so in order to fix our Bitbucket commit links throughout the forum and documentation, we need to pick one of those:

- fix them manually (there are probably hundreds, not going to do that)
- ask Heptapod admins to implement this functionality for us (feature request)
- hack Heptapod source code to implement it ourselves, according to their coding standards, and submit a PR (it has to be accepted by them, a local fork won't be enough)
- ask Heptapod admins for their copy of git-mapfile for our repo
- write a crawler that browses our repo on Heptapod's web interface and rebuild  git-mapfile from there

According to the first joke from here, the problem is solved - you may consider I'm the mathematician

Maybe it's worth mentioning that, in some edge cases, the method presented in the video (first post) may fail to downgrade, which is why I recommend the method from the download page - which doesn't come with a video, but so far I'm not aware of any cases where it failed. Some users may be searching specifically for a video tutorial, as the procedure can be tricky to get right.

In other words, a video tutorial describing the method recommended on the download page, could be useful.

At this stage, it's probably best to look at Canon's debug messages to see why exactly it fails.

Easiest way: UART.

Software-only solution for logging Canon messages during a firmware update is also possible, but may require a few days of work. Unable to allocate this time atm, sorry.

there's also another weird issue when i turn the camera off and turn it back on, it resets SOME of my settings like video format and LCD brightness and the most annoying, it resets my picture settings.

This one could give some clues. Video format is on the MPU side (this list), but LCD brightness is not. Most picture settings (image quality, picture style etc) are also saved on the MPU side. Messages printed on UART during normal operation could be useful, too.

I can capture these messages, with various degrees of verbosity, but only on 2.1.2. Other firmware versions require significant work.

I wrote a1ex in a pm but I didn't get a reply.

I couldn't find any message from you, neither PM, nor e-mail. Anyway.

I'm from Germany and have a 5d4, but I might be willing to lend it to a ml guy, but my main motivation is for raw video, 1080p would be fine first.

In my case, the main issue is not lack of hardware - that's relatively easy to get on the used market, or borrow from a friend etc. The biggest problem, in *my* case, is the allocation of large amounts of time for hobby projects (estimated several hundred hours required for a working port, not including maintenance). I'm no longer able to allocate this amount of time without risking my ability to put food on the table. This wasn't an issue before ~ 2017, but living expenses increased a lot in recent years (they doubled this year, for example). I'm already looking for a second job (tried freelancing, without success, but still considering it), and having an extra 5D4 to take care of, is definitely not going to help, as it only means additional workload for me. Even if I'll be allowed to sell it afterwards, I still won't be tempted, sorry.

In other words:

Need hardware + time.

Hardware is easy.

However, that's my motivation behind Open Collective - if it works out (unlikely, given the reverse engineering nature of our project), and if I'll be able to cover at least a significant part of my living expenses out of that, I'll reconsider. Otherwise, I'm really sorry, but this port will have to be created and maintained by somebody else. Same for all other cameras that are not yet supported.

So, if other developers are willing to look into it and can prove their skills first, preferably on another DIGIC 6 camera, OK from my side. Just be careful with lending - I won't be able to guarantee they will succeed, or that they will actually return the camera afterwards

C log in 5D IV is just an on/off feature in the firmware. Same as language restriction or WiFi/GPS.
Possible to change with Tornado EOS but I also suppose A1ex could do the same.

As for C-Log, if it's a paid upgrade, I wouldn't touch it, no matter how trivial it might be to unlock. It would be software piracy, which could upset Canon and put our project in danger.

Using this approach, I've got the following annotated logs:

T5i startup log-a.log
T5i startup Log MPU-a.log

Looking for SW1 (half-shutter) entries:

Code Select Expand


0.260.933    EventMgr:ff2273dc:8d:03: Already SW1OFF
0.281.407  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
0.281.520    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
0.306.714    Fstorage:ff1d0788:9e:03: fssSW1On
0.381.686     PropMgr:ff2a6e98:33:03: PROP_REMOTE_SW1[0]
9.586.010  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
9.586.215    EventMgr:ff22769c:8d:03: emDeliverMulticastEvent : SW1OFF
9.620.344  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
9.620.442    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
9.693.040     CtrlSrv:ff39e860:83:03: IDLEHandler UNPRESS_SW1_BUTTON
9.698.658     CtrlSrv:ff39e7bc:83:03: IDLEHandler PRESS_SW1_BUTTON
10.091.657  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
10.091.793    EventMgr:ff22769c:8d:03: emDeliverMulticastEvent : SW1OFF
10.092.026  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
10.092.128    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
10.230.766     CtrlSrv:ff39e860:83:03: IDLEHandler UNPRESS_SW1_BUTTON
10.230.923     CtrlSrv:ff39e7bc:83:03: IDLEHandler PRESS_SW1_BUTTON
10.459.433    Fstorage:ff1d0788:9e:03: fssSW1On
10.459.472    Fstorage:ff1d0788:9e:03: fssSW1On
11.895.314  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
11.895.457    EventMgr:ff22769c:8d:03: emDeliverMulticastEvent : SW1OFF
12.011.518     CtrlSrv:ff39e860:83:03: IDLEHandler UNPRESS_SW1_BUTTON
18.676.057  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
18.676.142    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
18.678.878    Fstorage:ff1d0788:9e:03: fssSW1On
18.778.213     CtrlSrv:ff39e7bc:83:03: IDLEHandler PRESS_SW1_BUTTON
0.260.933    EventMgr:ff2273dc:8d:03: Already SW1OFF
0.281.407  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
0.281.520    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
0.306.714    Fstorage:ff1d0788:9e:03: fssSW1On
0.381.686     PropMgr:ff2a6e98:33:03: PROP_REMOTE_SW1[0]
9.586.010  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
9.586.215    EventMgr:ff22769c:8d:03: emDeliverMulticastEvent : SW1OFF
9.620.344  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
9.620.442    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
9.693.040     CtrlSrv:ff39e860:83:03: IDLEHandler UNPRESS_SW1_BUTTON
9.698.658     CtrlSrv:ff39e7bc:83:03: IDLEHandler PRESS_SW1_BUTTON
10.091.657  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
10.091.793    EventMgr:ff22769c:8d:03: emDeliverMulticastEvent : SW1OFF
10.092.026  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
10.092.128    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
10.230.766     CtrlSrv:ff39e860:83:03: IDLEHandler UNPRESS_SW1_BUTTON
10.230.923     CtrlSrv:ff39e7bc:83:03: IDLEHandler PRESS_SW1_BUTTON
10.459.433    Fstorage:ff1d0788:9e:03: fssSW1On
10.459.472    Fstorage:ff1d0788:9e:03: fssSW1On
11.895.314  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 0b 00)                                  ; EVENTID_METERING_TIMER_START_SW1OFF
11.895.457    EventMgr:ff22769c:8d:03: emDeliverMulticastEvent : SW1OFF
12.011.518     CtrlSrv:ff39e860:83:03: IDLEHandler UNPRESS_SW1_BUTTON
18.676.057  **INT-36h*:ff31af1c:00:00: *** mpu_recv(06 04 05 00 00)                                  ; EVENTID_METERING_START_SW1ON
18.676.142    EventMgr:ff227524:8d:03: emDeliverMulticastEvent : SW1ON
18.678.878    Fstorage:ff1d0788:9e:03: fssSW1On
18.778.213     CtrlSrv:ff39e7bc:83:03: IDLEHandler PRESS_SW1_BUTTON


In a normal startup log, these entries won't appear, unless you press half-shutter manually (but the first attempt appeared ~ 0.3 seconds after power on - unlikely to be you pressing this button). Half-shutter events are also triggered by the star (*) button, AF-ON (where present) and DOF preview (with electronic lenses only).

There is a sequence of half-shutter press/unpress events after about 9.5 seconds; that's when you tried to navigate Canon menu, from what I could tell. There are events about shooting mode changing around that time, so it might be the MPU temporarily resetting the half-shutter state:

Code Select Expand


0.143.558     PropMgr:ff0f2e90:81:03: dwNewAeModeDial = 0     ; P
9.571.943     PropMgr:ff0f2e90:81:03: dwNewAeModeDial = 22    ; A+


After 18 seconds, you went back to LiveView using the recording button:

Code Select Expand


18.660.731     CtrlSrv:ff39dd00:83:03: GuiMainEventHandler.c PRESS_LV_MOVIE_START_BUTTON/PRESS_LV_START_BUTTON


and shortly afterwards, the MPU locked half-shutter again.

I could reproduce the defect on 60D with the following procedure:

1) hold the AF-ON button pressed while in LiveView
2) while still holding the AF-ON button, press MENU to make sure it doesn't work (it shouldn't open Canon menu)
3) while still holding the AF-ON button, perform a mode switch that gets the camera out of LiveView
4) while still holding the AF-ON button, press MENU - this time it should open Canon menu
5) while still holding the AF-ON button, go back to LiveView using the recording button
6) while still holding the AF-ON button, press MENU - this time it shouldn't work (it shouldn't open Canon menu)

Also worth noting:
- When using the half-shutter button, mode switches from/to LiveView did not unlock the MENU button
- when using the * button, I could open Canon menu at step 6 (repeatable); from your logs, I wouldn't expect this
- on 5D3, I could not unlock the MENU button at all using the same procedure

Based on this test:
- is there any unusual autofocus activity, e.g. at camera startup, or after leaving Canon menu?
- if you touch the half-shutter button, or the * button, does this unlock the keys, even temporarily?
- if you change the functionality of the * button from CFn (try all available options), does it help?
- can anyone with a 700D perform the above test and document the expected behavior?
- if the faulty button is half-shutter, I can try a workaround, to manually "unpress" it from software, without any guarantees of success. Are you able to compile from source?

In any case, I believe the defect is on the hardware side (half-shutter signal somehow stuck, possibly the * button). These events are not coming from the main CPU, where ML runs, but for the MPU (a small microcontroller handling buttons, shutter mechanism and a few other functions). Updating the firmware or uninstalling ML will probably not change anything.

While this topic didn't get much attention, the Discord channel started by 200D folks gained significant momentum - much more active than the IRC channel.

https://discord.gg/yBurP7a

If so, feel free to join us on our unofficial discord server: https://discord.gg/uaY8akC

Would it be a good idea to make it official, or are there any concerns (such as being a closed platform, privacy or whatever) ?

Refer to issue #1781.

Hardcoding addresses is simply *not* going to work on 650D, 700D and maybe other models. It may fix the problem for some cases (possibly depending on what camera mode is used at startup, or other settings, or simply because of the multitasking startup process used by Canon) and will fail otherwise. The address you are looking for is allocated dynamically, so one has to find a pointer to it somewhere in a RAM dump - that pointer is likely at some fixed address, regardless of the exact startup sequence.

Suggested approach:
- find a few cameras / startup configurations that result in different CMOS[0] addresses (at the very least 2, but I'd recommend 3 or more)
- hardcode the address from adtg_gui and confirm it's actually working reliably (predictably, deterministically) on each of those cameras and/or configurations
- get a RAM dump from each of those cameras and/or configurations
- annotate each RAM dump with the address that was confirmed to work
- blindly scan for a pointer to that address (the CMOS[0] address will be specific to each RAM dump, but the pointer address should be the same in all dumps)

Indeed, this takes time. However, the latest update from Open Collective left me without many hopes - apparently they are not very comfortable with the legal gray areas. They might have a long answer in 3 weeks or so; until then, I can only speculate.

Their initial reaction was very good though - apparently they already knew about our project before initiating the discussion. Maybe there's still some tiny hope.

Still looking into alternatives.

"Only" 1GB

SX740 picture posted over here.

The R5/R6 don't have smemShowFix, but they seem to have some similar strings, like USER_BMPVRAM, USER_IMGVRAM_1, USER_MOVIE_REC_WORK_2, USER_DAF_RAW and many others:

Code Select Expand


strings gang100.bin |grep '^USER_'


The routine referencing these strings is likely the equivalent of smemShowFix.

SX740, based on log from srsa:


1 GB RAM?! Roughly similar to M50.

RP, log from coon:


2 GB RAM, similar to EOS R.

Getting the basic features working (menus, intervalometer etc) shouldn't be harder than on any other DIGIC 6/7/8/10 camera.

80D can output a 1080p-sized DNG without much fuss, so getting raw video is likely straightforward. On 5D4, we need to request a larger size for the Bayer raw data, to cover the entire frame - this is the missing bit from the puzzle (where is that done in Canon firmware, and how to modify it?)

There is a caveat on DIGIC 6 - there's no known way to temporarily patch parts in the ROM. On DIGIC 2..5, we can patch a small number of 32-bit integers directly in the cache (aka "cache hacks") - though, they are only required for advanced features. On DIGIC 7..10 (Cortex A9) we've got a MMU, so we can remap any parts of the ROM into RAM, and patch pretty much anything - without actually modifying the ROM. On DIGIC 6, there's no known way to patch ROM contents, though it might be possible with ARM debug registers. Others tried, without success, to my knowledge (I didn't).

Such a patch might be required for getting full-size raw video, but I don't know yet what exactly to patch. That alone may take several hundred hours of investigation. Even if I'll spend these hours on this particular task, there's no guarantee I'll succeed, even if the community would pay me at the rate suggested by names_are_hard.

Or I might be wrong and you'll figure it out in a few hours. I'm pretty bad at estimating the difficulty of a task in advance

[ml-repos.tar.xz]

It is, indeed, in the archive, under chris_miller/ml-fork:

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

Caveat: unzipping that file took me about an hour of processing time and 17 GiB of space.

However, if you are looking for raw video, you may want to know I wasn't able to save a full-sized DNG yet (experiments start around here). The same experiment worked without much trouble on 80D.

My hypothesis back then was that some important parts from image capture configuration might be offloaded to a secondary CPU (Omar). If that's true, getting raw video out of this camera might be as difficult as porting crop_rec to the 7D (that is, orders of magnitude harder than porting crop_rec to any other DIGIC 4/5 camera).

Topic split from https://www.magiclantern.fm/forum/index.php?topic=24548.0

Please just sign up for a patreon page to pay the bills. Then let's grab you at least a 5mkiv or whatever your heart wishes to do the magic work. Community will support it.

Well, given the recent evolution of the project (in particular, recent contributions), opening an individual Patreon page doesn't make sense to me. If we will do some kind of fundraising, it has to be for the entire team of developers and contributors, not just for one individual developer. And I think I've found a much better tool for this purpose.

I'm looking at Open Collective. They offer something similar to a non-profit organization, but without the requirement to incorporate one - they call it a "virtual non-profit". It's fully transparent (everybody can see how we spend the money), they do all the paperwork for us (for a fee), and it's open to all contributors, not just to one particular person, or to a closed group or core developers. Anyone can submit invoices to be reimbursed for project-related expenses, but the core team has to approve them. It even allows paying contributors for their time, as long as they can submit an invoice as a freelancer (but - depending on their country - they may need to register a local business or a sole proprietorship).

In other words, with Open Collective, even if I won't be available for some months (hopefully not years), the project will be able to continue without my direct involvement - as the money from the supporters won't be in my pockets, but available to the entire team of developers/contributors (whoever will still be active in the community). That would be pretty difficult to achieve with Patreon.

Open Collective already offers fiscal hosting for several open source projects - both US-based (Open Source Collective) and EU-based (Open Collective Europe ASBL). Some projects hosted there:

- Qubes OS (US host)
- Mastodon (US host)
- Vue JS (US host)
- Rada.re (US host)
- Tor (US host)
- Manjaro (EU host)
- many others

Here's our page on Open Collective - but it's not functional yet (you can't donate yet).

Also worth reading:
- What is Open Collective & how it works?
- Open Collective is a New, Transparent Way to Fund Open Source Projects
- Open Collective Docs - all of them
- The Value of Fiscal Sponsorship in FLOSS Communities (also covered on LWN)

I've got in touch with Open Collective in spring 2019, but had to abandon the idea for a while (having several unfinished projects in the pipeline, then pandemic etc). Back then, they were very friendly and open towards our project, so... earlier this week I've decided to resume the application process. They even offered to help with legal advice - will keep you posted once I'll have more details.

We still need to choose between the EU-based host (my personal preference), or the US-based one (which is specifically tailored to open source projects, and - according to OC admins - much better prepared for hosting our project). Last year I would have strongly leaned towards the EU-based host, primarily because of DMCA, but this is no longer a critical issue (in my opinion for now, to be confirmed).

Assuming this will work out, i.e. if the level of support will allow me to return to the project without risking my ability to pay the bills, I'll do just that - my job still allows some degree of flexibility. Otherwise, if the donations will not be enough to partially cover my costs of living, but if they will exceed the hosting costs, I might be able to reimburse contributors for their project-related expenses (such as high-speed cards, or nonfree documentations, or equipment needed for reverse engineering, maybe a camera or two... depending on the budget).

Of course, in the past, there were voices completely against money (very understandable), so if there are any concerns with my proposal, I won't move forward unless consensus is reached. I haven't sorted out the details yet - last year I've got green light from Trammell and g3gg0, which is why they are listed on our Collective page linked earlier.

Memory map for R5/R6 (see also for DIGIC 7 and DIGIC 8):

Code Select Expand


00001000-00001FFF -> 00000000-00000FFF (-1000) O:NCACH I:WB,WA  P:RW       [ CPU0 only ]
00001000-00001FFF -> 00001000-00001FFF (   +0) O:NCACH I:WB,WA  P:RW       [ CPU1 only ]
00002000-3FFFFFFF -> 00001000-3FFFFFFF (   +0) O:NCACH I:WB,WA  P:RW       [ cacheable RAM - only the first GiB ]
40000000-BEFFFFFF -> 40000000-BEFFFFFF (   +0) O:NCACH I:NCACH  P:RW       [ uncacheable RAM - 2 GiB ]
BF000000-DEFFFFFF -> BF000000-DEFFFFFF (   +0) Device           P:RW XN    [ MMIO area ]
DF000000-DFFFFFFF -> DF000000-DFFFFFFF (   +0) O:NCACH I:WB,WA  P:RW       [ TCM? ]
E0000000-E7FFFFFF -> E0000000-E7FFFFFF (   +0) O:WB,WA I:WB,WA  P:R        [ main ROM ]
E8000000-EFFFFFFF -> E8000000-EFFFFFFF (   +0) Strongly-ordered P:RW XN    [ ? ]
F0000000-F7FFFFFF -> F0000000-F7FFFFFF (   +0) O:WB,WA I:WB,WA  P:R        [ secondary ROM ]
F8000000-FFFFFFFF -> F8000000-FFFFFFFF (   +0) Strongly-ordered P:R  XN    [ ? ]


Created with this script and annotated manually.

Try running these builds; one of them should save a log that might hopefully show what's going on.

https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log/
https://builds.magiclantern.fm/jenkins/view/Experiments/job/startup-log-mpu/

Best guess so far: half-shutter stuck.

Cool hack - it's the clearest proof the "overheating" is timer-based, if you ask me.

As I said: IMO this would be *the* opportunity to make transition to pay-for-ML-feature-development work.

Well, this particular hack is easy enough to automate - I wouldn't be surprised if somebody comes up with a one-click version within the next few days or weeks (also mentioned on Twitter). Motivation is high in the R5/R6 user community - much higher than for porting ML on 5D4, EOS R and the like, in my opinion. So, while it's definitely a low-hanging fruit with high rewards, I don't see anyone paying for a slightly more polished version of this hack. A free one will very likely appear sooner or later, without our involvement.

BTW - I feel a lot safer knowing this hack was discovered by third parties - even if it was documented on our forum. There's no single person behind it - all of the previous iterations paved the way to this version of the hack ("standing on the shoulders of giants"), and I'm pretty sure it will be further refined by the community.

On the other hand, this "overheating" thingie caused quite a stir on the internet, which ended up drawing some of the attention towards our project. That's probably "exploitable" in the sense of "pay-for-development", but primarily for the other models - if I'm not mistaken, the R5 already records 8K raw video (but I haven't touched this camera, so I might be wrong), so the motivation for our enhancements on this model is probably low, besides the overheating timer hack.

Now, back to my (covid-related) research

The display issue is just a matter of fixing the resolution (in particular, the horizontal one). It's not auto-detected, but hardcoded, based on model ID.

The red thing is an error message - probably the dumper couldn't find suitable stubs for writing to card.

However, Canon Basic dumper appears to provide a complete ROM dump for now, so the portable ROM dumper is no longer essential. Just nice to have, as a proof of concept (portable code running on all cameras). I should be able to troubleshoot it in QEMU using the Canon Basic dumps - these include the bootloader, from what I've seen.

Thanks - apparently that's the price of a used 1300D on eBay. In other words, you are effectively donating a 1300D to the project

Currently setting up a space to work from home (because... corona). Hoping the change could make it easier for me to consider this topic a bit more seriously - but can't promise anything atm.

Very cool, thanks for sharing the low-level details!

Also confirmed to work on EOS RP.

[Does anyone have advice on a way to probe the pins?]

Does anyone have advice on a way to probe the pins? I have an arduino uno, usb host shield,  FTDI USB UART IC 'FT232RL' adapter that can run at 3.3V or 5V, and all the accessories that come with an arduino (breadboard, wires etc). But I don't know how to make a connector that could probe pins that are that small.

I've got the FT232RL adapter, and can confirm it can listen to 1.8V signals via its RX pin, with the jumper set to 3.3V. That's the easiest way to probe for the UART, in my opinion:
- connect the GND pin between FT232 and camera
- use the FT232 RX pin to probe around, while watching the Arduino serial monitor (a needle could be handy)

Expecting a bunch of messages right after camera startup, but also while in LiveView, for example.

TLDR: initial probing can be done with only the GND and RX pins from the FT232 adapter.

For sending messages to the camera, via the FT232 TX pin, you will need a voltage divider, as suggested by Kitor. When you reach this step, you may want to join the chat room

Yeah, today I woke up earlier than usual for some reason, so I've dusted off the M50 and tested the dumper

Guess what: the EOS R has some Canon Basic scripts in the firmware, pretty much the same ones as on the M50, so it's definitely worth trying.

If it works, it may provide a way to execute code on newer cameras cameras without hardware hacks, and without us having to break the encryption. Which hopefully keeps us safe(r) from the DMCA as well, but IANAL

That is, it might be possible to enable the boot flag directly from a Canon Basic script. At least, the execution context looks relatively safe at first sight (outside LiveView, with GUI locked up).

I'm using a 128gb lexar card. I don't have anything smaller nor do I know how to make my card "look smaller."

You could write our QEMU card image to the card, which will shrink the filesystem to 256MB (FAT16 iirc):

Formatting a larger card at a much lower capacity (e.g. 256MB) does the trick. For example, you can write the SD image that comes with QEMU to your SD or CF card (follow this guide). This image contains the portable display test and is bootable (so, you can test it in the camera straight away).

To verify it, test the card on any other ML-enabled camera. Once that works, make the card scriptable by following CHDK instructions (EosCard or whatever), then start the camera, go to PLAY mode and press SET. At least, that's what I did on M50.

I can also prepare a scriptable card image with Canon Basic dumper, if needed.