Messages

Turns out that "Powershot" based models don't have MPU but use small Cortex M0 instead. At least on SX70 and SX740, I don't have a good photo of M50 to confirm.
But there seems to be a visually matching chip, SD slot side, bottom right corner if SD slot is facing down.
M17M6, 36 pin XFBGA -> https://www.nxp.com/docs/en/data-sheet/KL17P64M48SF2.pdf

Today I desoldered DIGIC and that Cortex M0 from my water damaged SX70 HS board.
https://twitter.com/_kitor/status/1656369031383773188

With some measurements I was able to identify about 1/2 of the pins.
It doesn't seem to have any UART output.

Interesting ones: Power, Play and WiFi buttons go to Cortex M0, not ICU. This makes sense as both can wake up the camera.
However INFO button also goes to M0. Reason is unknown.

Code Select Expand


pin  where?         signal    (mode)
A1
A2
A3
A4  to DIGIC        SPI0_MISO (alt2)
A5  to DIGIC        SPI0_SCLK (alt2)
A6  to DIGIC        SPI0_PCS0 (alt2)
B1
B2
B3
B4  to DIGIC        SPI0_MOSI (alt2)
B5
B6
C1
C2  button Play     PTE16     (alt1)
C3                  VDD
C4                  GND
C5
C6  at DNE chip     I2C0_SDA  (alt2)
D1
D2
D3  VDDA
D4  GND
D5  at debug conn   RESET     (default)
D6  at DNE chip     I2C0_SCL  (alt2)
E1
E2
E3
E4  button Power    PTA2      (alt1)
E5  at debug conn   SWD_IO    (default)
E6  at crystal      EXTAL_0   (default)
F1  button INFO     PTE23     (alt1)
F2
F3  at debug conn   SWD_CLK   (default)
F4  button WIFI     PTA1      (alt1)
F5
F6  at crystal      XTAL_0    (default)  @crystal


No, it doesn't. It redirects to https://builds.magiclantern.fm/. Just checked.

After a quick test I have a bad stub or two (tasks view doesn't display names properly[1], in LV our menu closes almost instantly[2]), other than that seems on par with 750D.
That was a quick (< 3 hour) job after i learned how to use Ghidra Version Tracking, thanks to @reyalp.

Ok, it took a week prior to that as I took the opportunity to create a proper loader script for Ghidra that should improve ghidra project quality a lot. More on that later.

E:
[1] Turns out one of task related structs is different.
[2] Fixed, wrong Canon dialog used in background.

Read this and guess for yourself:
https://www.magiclantern.fm/forum/index.php?topic=26852.0

OMG I need to rush buying a 2nd hand 5D4 before the news hits the market

Let me remind you that this is just menus. When we will have RAW video, you'll be able to buy 2 of them for todays price.

Okey, with no instructions on how it was configured it is hard to reproduce anything.
Do you have at least rom backup stored somewhere?

Anyway, since you are from Romania, if you are fine with shipping it to Poland I can take a look at it (for free, just cover the shipping). If so, hit me on PM. I can't promise anything though.

On the other hand I'd be surprised if this is other issue than a firmware itself. I'm yet to see a damaged CPU or RAM in Canon camera.
It was always firmware, one of sensors (check card door switch btw, you can push it with a screwdriver) or once a fuse. Other than those it was always either a wear (shutter stuck, etc) or physical damage.

Do you remember any specific settings that you used / changed?

What firmware version you had, what ML build you used?

If you still have your card contents as it was when it broke, please zip autoexec.bin, ML directory and any files with assert or log in name. Upload them somewhere and send me the link in PM.

I'd like to reproduce this issue if possible.

[Except EOS 200D there are no public builds available.]

I mean, this was stated very clearly:

Except EOS 200D there are no public builds available.

The bug never stopped the work. Just consider there are exactly two of us working on all DIGIC 6, 7, 8 and X models. There's no point spending much effort on DIGIC 8/X when it inherits all the 6/7 issues anyway.

I don't think you will find it this way. This functionality comes from CameraConductor - CC_InterfaceWrapperHack - creates a task called CC_SWHACK, and pointer (pSwifCBR) is registered in structure passed to that task.

But look for strings pSwInitCompCBR != NULL && pSwChangeCBR != NULL and CameraConductor::CC_SWInterface.c. On R the function takes three function pointers - seem related to (low level) button handling.

Just to in ML we hook GUI event queue (higher level), this seems to be lower level data.

nice find!

I confirmed `cc_cmd_keychkmode` working on R. I'm sure those are MPU codes,  not GUI event codes - they doesn't match ours, seems to be (button id, button state) pairs and contain data from buttons we can't pass properly from gui events atm (like mode dial and RF lens ring on R).

I think this is an important discovery to investigate, as GUI events are gui mode dependent. If we can easily hook there instead of GUI queue, it might be easier.

Also, @ponguin codes seems to match R 1:1 (not that surprising: 1 - power button, 2 - sd card lid, 4 - sd card (single slot), 1d menu, 2b-2e direction button, 1c SET... )
35/36 are scrolls, 1 right, -1 left. Touch bar has 59/5a for taps (right, left) and 5b for swipe - again, 1 for right, -1 (0xFF) for left.

2 is battery door switch.

It is funny as it allows to swap card without shutdown.

I think having an 'official' github organization containing the active forks would be useful.

I already created a placeholder some time ago: https://github.com/autoexec-bin

You can add a repo that isn't git, and isn't in github, into a github org?  Unexpected!

Yes, mercurial for official, of which I assume there are some forks.  Danne is using git, but on bitbucket (the commit history seems...  insane, I think he's using hg locally and then using git to push those changes to bitbucket?)

How? I guess this is a miscommunication.

For the existing GH repos you need to transfer it into org so it can be managed -> https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

As for general discussion, I also do prefer to have a single repo with not too many branches. But let's be honest - with the amount of changes (including a ton of code formatting changes) it won't be a trivial task to merge anything into magiclantern_simplified.
We will need each fork maintainer to verify existing status over this repo and then merge their work by hand.

By the way, what does this graph represent? The activity in the forum or in firmware development? It is very enlightening

This is commits graph in the Magic Lantern repository. To be exact, until 2021 it is commits from official Bitbucket (now Heptapod), starting from 2021 it is magiclantern_simplified Github fork where we work on Digic 6/7/8/X support.

There will be another status update in coming days from @names_are_hard - this time technical one.

[Technical update is now available]

Technical update is now available: https://www.magiclantern.fm/forum/index.php?topic=26814.0

[Chapter 7: What can I expect from you? How can I help?]

Chapter 7: What can I expect from you? How can I help?

First, a gentle reminder that ML project is not a company or commercial institution.
This means that while we are happy to listen to your suggestions and feedback, the project doesn't have any timelines, obligations and we are not bound to fulfill any of those.
If there's a build available for your camera - this is all we can offer. It includes all the features and also bugs you may encounter. Everything else should be considered as our best effort to support the community.

What is the status for X? When you will implement Y? Why not Z?
We realise people ask these questions because they're enthusiastic about ML - people want it on their cam and they want it to work well!  This is understandable.
When you have a hundred people asking the same questions, it can come across as nagging, or demanding.
Please try to remember that we will always announce significant progress on the forums, and we will always ask for testers if we need them.

For people who have technical knowledge and want to contribute - there's source code, QEMU emulation, Wiki, development Discord and many more.
We are aware our build system is very outdated and documentation is very lacking. Please consider joining Discord server - we will be more than happy to help you get started.

What about ChatGPT?
Slightly out of context, but since this question is asked very often in every single open source project on the planet.
ChatGPT will not help Magic Lantern. The majority of the work is in reverse engineering (and in general research). AI is trained on already available data - it can help you with problems that were already solved elsewhere.

[Chapter 6: I noticed PowerShots on the list? Do you want to steal CHDK user base?!]

Chapter 6: I noticed PowerShots on the list? Do you want to steal CHDK user base?!

Different firmware variants
Historically there were three "variants" of Camera firmware on Canon devices. We usually named them by their origins:
- "PowerShot" - running on point-and-shoot cameras
- "EOS" - DSLRs and mirrorless
- "Cinema EOS" - video cameras

Those three variants are very different. Think about your smartphone, internet modem and satellite box. There's a high likelihood they are all based on Linux - but each runs a different set of applications on top of it.
In "our" world the concept is very similar - each of those three areas runs operating system known as DryOS. Everything else (how camera operation is handled - majority of the software) is different.

Project targets
This is why CHDK project works only on devices that run "PowerShot" variant and only there.
Magic Lantern works on DSLRs and mirror less devices.
Cinema EOS is uncharted territory for now. (edit: for update on those, see July 2023 update)

It is very hard if not impossible to port CHDK over "EOS" firmware and Magic Lantern over "PowerShot" variant.

But life is confusing
If you own EOS M3, M5, M6, M10 or M100 (DIGIC 6 and 7 models of M series), you may already know they are target of CHDK project.
Canon decided to use "PowerShot" firmware variants on those models. Why? Our guess is as good as yours.

With DIGIC 8 generation - Canon tried to simplify things internally, and they got rid of "PowerShot" variant entirely - or at least this is what we think has happened.
EOS M50, M50 Mk II, M6 Mk II, M200 - they all run "EOS" variant again and thus are target of Magic Lantern.

But this also means that DIGIC 8 based PowerShot SX70 HS, SX740 HS, G5 X Mark II, G7 X Mark III, as well as the weird PowerShot Zoom - they run "EOS" firmare.
And by extension - those can be supported by Magic Lantern, even though this may be counter-intuitive at first glance.

[Chapter 5: So what is the status of newer models? (DIGIC 6, 6+, 7, 8, X)]

Chapter 5: So what is the status of newer models? (DIGIC 6, 6+, 7, 8, X)

In general: it is a very early work.

We were able to bring up multiple Digic 6, 7, 8 and X models into Magic Lantern menus.
There are some features that work, but nothing really exciting. What works depends mostly on camera generation.

Except EOS 200D there are no public builds available. This may change in future!

DIGIC 6: EOS 750D, EOS 7D Mark II
DIGIC 6 is the "big unknown". It lacks some features needed to modify firmware behavior (cache hacks).

On 750D we were able to get into ML menu, LiveView overlays, attached lens info details and disable 30 minute liveview shutdown timer aka "webcam mode".
@names_are_hard was able to get his 7D Mark II into menus last month. For now it has some groundbreaking issues that we are not sure how to fix.

We also know how to activate over and underexposure zebras in LV!
This needs a major rewrite in Magic Lantern as new hardware can do much more (e.g. both under and over exposure at the same time with a custom thresholds and styles)

https://i.imgur.com/apyBOfQ.mp4

Barebones port, no ML features yet.

DIGIC 7: EOS 200D
DIGIC 7 introduces new features that replace those missing in previous generation (MPU).
We have some issues with memory management that will be needed later to use bigger parts of camera RAM.

EOS 200D is probably the best supported model. Like 750D, ML menu, LiveView overlays, attached lens info details and disable 30 minute liveview shutdown timer aka "webcam mode".
With many other "under the hood" things that are not yet important for end users.

Don't get too excited - very few features work.  But, it's ML, and it's on 200D.

(...)

https://i.imgur.com/yvZX1V1.mp4

DIGIC 8: EOS M50, R, RP, 850D, 250D, PowerShot SX70 HS and SX740 HS

What is the general status?

DIGIC 8 is similar-ish to DIGIC 7. Unfortunately on this generation we have a long standing bug.
It leads the camera to a crash in a few minutes of operation. We roughly know where it crashes, we don't understand why.
Additionally the memory management mentioned in DIGIC 7 is completely broken now - we can't use it at all.



With the firmware on DIGIC 8 models Canon changed some internal representations of data like aperture, shutter speed and ISO.
Magic Lantern code needs a major adaptation to fit in those new values into existing functions. This is a major blocker for the future.

With models starting with EOS R, firmware encryption has changed. This mean we can't create "ML install" program anymore.
Fortunately we found another way to enable the boot flag. Less user friendly, but exists.

What models we work on?

Currently all listed models: M50, R, RP, 850D and 250D have similar functionality. ML Menu, LV overlays, attached lens info, and ability to disable 30 minute  liveview shutdown timer aka "webcam mode".

On PowerShot SX740 HS we were able to activate CR3 RAW shooting, even though this camera allows only for JPEGs.

Recently I started working on PowerShot SX70 HS. It already reaches ML menus, but I likely have a stub or two wrong, as it locks the camera if some features are enabled.

CR3 raw from SX740 

Extra points: on EOS R in "clean HDMI mode" we can enable zebras both on internal screen and HDMI - each screen with its own thresholds and styles!

DIGIC X: EOS R5

DIGIC X inherits all problems listed on DIGIC 8 and unfortunately adds an extra one:
This time memory management doesn't work because Canon replaced old solution with a brand new one.
We know nothing about how exactly it works (to simply explain an idea - EOS R5 have more than 4GB of RAM, but can access only ~1.5GB at a time).
A lot (!) of Magic Lantern code is dependent on old solution right now.

Additionally, only EOS R5 and R6 work with the method of enabling Magic Lantern mentioned in DIGIC 8 generation.
Starting from EOS R7/R10 (technically from R3 but it is not ML target anyway) this method got unfortunately locked.

EOS R5: goes into Magic Lantern menus and displays Lens information.

https://twitter.com/_kitor/status/1533767862531268608

[Chapter 4: What is going on with new models? All supported cameras are 10 years old!]

Chapter 4: What is going on with new models? All supported cameras are 10 years old!

Most of the supported cameras run Canon DIGIC 4 or 5 processor. This is because project started with EOS 5D mk2 and then was ported to EOS 550D - both DIGIC 4 based models.
Later it was found DIGIC 5 was a very similar processor internally with much more capabilities. And firmware was quite similar. It was relatively easy to maintain a single project covering both generations.

Problems started with DIGIC 6. This processor internally uses a different architecture than 4 and 5. Not very different, but enough that it didn't have some crucial features required by Magic Lantern to achieve many of its possibilities.
Canon also changed a few details in hardware inner-workings, which added to the difficulty of porting.

The slowdown.

Unfortunately at the same time project slowed down due to lack of... people. It is simply impossible to support more than a few models by a single person, and this is what had happened.
A1ex, the project lead - tried to attract new developers, but this didn't work out. His last effort was EOS M50 "fishy" build as a proof it is possible to achieve.

At some moment @names_are_hard joined the scene with his 200D. After that @coon with EOS RP and me with EOS R.

A light in the tunel.

After a lot of work with great help of other forums and Discord server members, in early 2020 we made an achievement - for the first time since "fishy" build we were able to boot new models into Magic Lantern menus. This included mentioned EOS 200D, R and RP.

Don't get excited, it's just the menus, nothing works...  but:

[gifv]https://i.imgur.com/UP8gqR0.mp4[/gifv]


Teamwork with Kitor, thanks!

I have catched up with R / M50 / 200D progress and finally got Magic Lantern menus running on RP:

We started to learn a lot about reverse engineering and also Canon cameras - remember that we "just joined" the project at that moment, without any knowledge how earlier models work.
We quickly found that while similar on the surface - almost everything had changed in minor or major way -this includes both hardware and firmware. Unfortunately this means double the work - we had to understand both how old models work and how that relates to the ones we work on.

This is (unfortunately) the ongoing theme for last 2 years.

[Chapter 3: DIGIC 5 and 5+: Exciting updates: SD overclocking, Full resolution LV preview]

Chapter 3: DIGIC 5 and 5+: Exciting updates: SD overclocking, Full resolution LV preview

For the past few years the development was focused on RAW video area, beside the custom crop_rec builds which offer various custom RAW video modes, there were two major RAW video improvements:

-The write speed increase:

A. back in 2018 a1ex proved that increasing SD write speed a.k.a SD Overclocking was possible on DIGIC 5 models, but it was limited to 160 MHz frequency, here is example shows Stock write speed (at 96 MHz) vs Overclocked one (at 160 MHz) from 700D:

Stock 700D	160MHz

Then after two years from that, @Bilal took a closer look into SD Overclocking process and was trying to get higher (stable) SD frequencies like 192 MHz and 240 MHz across all DIGIC 5 models (5D3 / 6D / 70D / 650D / 700D / EOS M / EOS M2 / 100D), and that did happen just last year in 2022, benchmarks shows write speed at 192 MHz and 240 MHz:

192MHz	240MHz

B. Unfortunately above benchmarks don't represent actual write speed when recording RAW video, they were done outside LiveView, in order to maximize effective write speed during RAW video recording, we will need to lower CPU usage and save it to RAW recording, and yet again @Bilal take a look into it and was able to disable some unnecessary tasks during RAW video recording which increased write speed performance significantly:

Hi, is this April 1st?
                                                                                                                                                                                                                                                         

By combining these two things, the final write speed was increased:

-Up to 125% in 6D / 70D                             (from  ~40 MB/s  to  ~90 MB/s)
-Up to 100% in entry level models like 700D (from  ~40 MB/s  to  ~80 MB/s)
-Up to   45% on 5D3                                   (from ~100 MB/s to ~145 MB/s)

Which greatly exteneded RAW video recording times in all RAW video modes.

-Full Real-Time preview:

ML offers many custom RAW video modes which can present higher resolutions than native Canon video modes, offering better image quality and more shooting capabilities.
One problem with these custom modes is preview during RAW video recording, it can be either cropped or stretched (part of frame is missing), here are some examples:

2560x1440p 1:1 mode on 700D:

-Here we are comparing frame size among Real-Time Canon Cropped preview (what's being displayed on screen) vs Actual frame size, ML Framing preview (what's being recorded):
[gifv]https://i.imgur.com/KATkDai.mp4[/gifv]


-So why not to just use ML Framing preview? good question, because it has very low refresh rate (around ~2-3 FPS), here is a refresh rate comparison among Real-Time Canon Cropped preview and ML Framing preview:
[gifv]https://i.imgur.com/Ktzidb6.mp4[/gifv]


Framing preview becomes even more laggy when recording, beside it has negative impact on write speed too.
At this stage you may ask us to use that card, unfortunately that magic doesn't work here . . but Magic Lantern is full of Magic, let's explore it then :

Back in 2020 @Bilal started looking into how Preview works, and was able to control preview successfully to some point with some limitations.

It's 2023 now, so what's up? Well, it truned out that our DIGIC 5 models which are ~10 years old are fully capable of previewing RAW data at high resolutions:
Here is an showcase ML Framing preview vs Full Real-Time preview in 2560x1440p 1:1 custom mode:

[gifv]https://i.imgur.com/SzN87Ct.mp4[/gifv]



Another comparison:

1736x2214 1x3 mode, Stretched Canon preview vs ML Framing vs New Full Real-Time preview:

[gifv]https://i.imgur.com/G0uTba0.mp4[/gifv]



Yet another comparison, shows how preview got evolved:
(2.5K 1:1 preset as example)

[gifv]https://i.imgur.com/ti7NDyX.mp4[/gifv]


-It just a perfect match to Framing preview but in real-time
-If DIGIC 5 was that capable, what about DIGIC 6/7/8/X
-A new era for MLV RAW video
-This is applicable to 650D / 700D / EOS M / EOS M2 / 100D family
-Epic video about the new preview, also none epic one

The announcement for the new preview work came out yesterday by Bilal (on April 1st 2023),

For more info, details and availability, follow this topic which will be updated frequently:
Crop mood - WYSIWYG Edition

And for users who are wondering, the contents of the announcement video, also the topic . . were 100% real

[Chapter 2: Developments in already supported generations (DIGIC 3, 4, 4+)]

Chapter 2: Developments in already supported generations (DIGIC 3, 4, 4+)

DIGIC 3: Heder's 40D port

Did you expect RAW video on 16 years old camera? Heder made that possible:

OPen beta updated to 1.0.5

https://www.magiclantern.fm/forum/index.php?topic=1452.msg224594#msg224594

What are the limits of 40D? What works, what doesn't? Check the linked post in the quote above to learn more


DIGIC 4 and 4+: 1300D port

While there's not much going on in DIGIC 4 models, all recent low ends (1300D, 2000D, 4000D) are based on a slightly upgraded version of DIGIC 4 known as "4+"

Critix created a 1300D port. It works on older firmware (1.1.0), petabyte recently created an updated version for firmware 1.2.0.
Not everything is working yet as DIGIC 4+, while very similar to older DIGIC 4, requires some amount of reverse engineering too.

First boot with ML:

... and the first self-test...

[Chapter 1: What is Magic Lantern? Who is responsible for it?]

Chapter 1: What is Magic Lantern? Who is responsible for it?

What is Magic Lantern?



Magic Lantern is a firmware add-on. It runs alongside your original camera firmware. It doesn't replace Canon firmware and it won't install inside camera.
We know this may be very confusing - to use Magic Lantern we ask you to use "Firmware update" menu which runs "Magic Lantern Install" program.

When you use "Magic Lantern Install", it will just enable a hidden option of your camera firmware. This hidden option tells the camera:
Hey! When you turn on, check if memory card is prepared in a special way and there's a file called autoexec.bin on storage card. If it is - please execute it!

This means - if you simply format your card (or use a card without Magic Lantern files), Magic Lantern is gone.
This hidden option (known as bootflag) has a small bug - if you ever delete autoexec.bin from the card, but don't format it - you camera will appear dead.
However fear not! Just take out both the battery and the card. Then insert only the battery to confirm it is fine. If so - just format your card on PC.

Who is responsible for it?

Magic lantern is an open source project, written by enthusiasts. It is not affiliated with Canon in any way.
People contribute a lot of their spare time and, very often, in-depth specialized knowledge in areas like programming, reverse engineering, embedded hardware - all of that for free for you to use.
With over 10 years in the making, since Tramell Hudson started the project we have seen people come and go. Many of us spent literally years contributing in one way or another.

[A very RAW update, February 2024!]

A very RAW update, February 2024!
Current state of Magic Lantern project (updated February 2024)

New update, October 2023!
Another mini-update.
Current state of Magic Lantern project (updated October 2023)

New update, July 2023!
This time just a quarterly mini update, so requires you to read April update for the context.
Current state of Magic Lantern project (updated July 2023)

Hello!

This is a relatively short summary about what is going on with the project in last years. This thread started as an update on development for "new era" models - this includes cameras based on DIGIC 6, 6+, 7, 8 and DIGIC X processors. But with recent exciting news for older models we decided we owe you a full update 

We will try to keep this post written in layman's words - providing just links to more in-depth readings where suitable.

Credits to @theBilalFakhouri, @names_are_hard and @Walter Schulz for their help in preparing this write up.

For your reading convenience, thread is split into chapters, each of which is a separate post:

Chapter 1: What is Magic Lantern? Who is responsible for it?
Chapter 2: Developments in already supported generations (DIGIC 3, 4, 4+)
Chapter 3: DIGIC 5 and 5+: Exciting updates: SD overclocking, Full resolution LV preview
Chapter 4: What is going on with new models? All supported cameras are 10 years old!
Chapter 5: So what is the status of newer models? (DIGIC 6, 6+, 7, 8, X)
Chapter 6: I noticed PowerShots on the list? Do you want to steal CHDK user base?!
Chapter 7: What can I expect from you? How can I help?

Back in the PowerShot land. This time SX70 HS. It runs runs DryOS +p4 like R/RP.
But the code is more RP alike - new "high" gui modes, XCM implementation that is used on RP onwards.

I still have to trace possibly a bad stub - it doesn't recognize it is in LV, FEATURE_SHOW_FREE_MEMORY hard locks when entering free memory menu, FEATURE_GLOBAL_DRAW hard locks after a few seconds from boot.

If you live in EU and want to ship it to Poland, I can try to reprogram missing areas using a service port (UART). Likelyhood of this being succesfull is very low though. More like an interesting experiment for me than a viable option for you.

Unfortunately older models have parallel ROM chip, which is BGA - even if there was a golden copy of the firmware, new chip and all the work needed to replace it would probably exceed the price of a replacement board/cam.

I recently fixed 1300D with rom chip failed even more - it was reading random junk. But this was a newer model with SPI ROM that is easy to unsolder and program in external reader...