Messages

Thia is really convenient and will make the port more easy, but still it's a strange beast, "dual core + single core"

Huh? D6 is one R4 core (Marius, what we call ICU) and one secondary R4 (Omar), also one secondary Xtensa (Zico, GPU accel) and two tiny cores (Arima, Shirahama; IIRC Xtensa, in single CPU models related to lens comm. They run tiny dryos variant like MPU)
7D2 has two physical D6 chips, thus twice that. So four R4 cores in total across two physical CPUs.

R4, source via reyalp at CHDK -> https://chdk.setepontos.com/index.php?topic=11316.msg142241#msg142241

Fun fact we found: On Digic 8 (EOS R) edmac info struct has three extra params: Off1s, Xs, Ys. No idea what they mean right now. Names did a quick patent search without luck.

Yes, that was the crash trigger for me - if AF was enabled and didn't lock. We use factory mode functions underneath so it is not surprising they have edge cases.
I spent a few days looking for a better way to make a photo from code but was unsuccessful.

We found intervalometer broken at least on D8 - Canon evproc used for that crashes the camera (null pointer) if previous shot was unsuccessful. Otherwise it worked - wonder if that's an issue on D6.

[someone created FB page with the same user name which was used previously by ZEEK]

Have you ever read the quote?

> ZEEK deleted his FB account around ~10 months ago.
> someone created FB page with the same user name which was used previously by ZEEK
> FB link is still there in ZEEK's YT channel

And then your argument:
> The link to his FB page is right on the about section of his YouTube channel.

[October 2023 (delayed) update]

October 2023 (delayed) update

There was not much going on in D6+ areas, as we got busy IRL. However we have a three notable mentions coming from @a.sintes:

Ultrafast framed preview (5D3)

A new, ultra-fast preview mode for 5D3 and possibly other models not supported by "crop mood" builds right now. This is a mid-step between old preview and hardware accelerated one.

Learn more here

After some time spent tweaking Danne's crop_rec codebase for the 5D3, I finally got some interesting results around the framed preview, with visible performance increases, leading to an ultrafast framed preview feature.


Latest feature overview video:

SD/CF dual slots free space display (5D3)

Pretty self explanatory Details: LINK

Hello,

Following a request on our Discord channel, I've implemented a very small feature to replace the legacy "free space" display in the ML top bar (top-right corner) with a new one including:
- a regular refresh (every 2 seconds min.) of the top bar (no need to do some specific operation in the menus to potentially trig a random update)
- an indication of the card councerned by the display (CF or SD prefix)
- a potential display of the two card slots in case of SD+CF usage (e.g.: 5D3)

It look like this:

A new focus sequencing module

Description, downloads: Focus sequencing (5D3)

Hello,

Just released a new focus sequencing feature allowing us to create and manage a list of focus point created via autofocus with specific transition durations, then easily replay the sequence step-by-step while recording a video, using a single button push.

Demonstration video:

Technical updates

@names_are_hard prepared a technical update covering last months. You can read it here.

And the (obligatory) reminder
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.

Thing is: if that was a checksum problem, camera wouldn't work (either black screen or a crash) as it would still load the (broken) binary.

With that problematic card (after preparation, and with ML files on it) - do you see any activity from card access LED immediately after turning the camera on?

When trying to boot the workaround's autoexec.bin in qemu, it seems as if the SD-card emulation needs to be improved for actually making the first-stage bootloader find and load autoexec.bin.

I remember doing some patches for SD code to work with R6 ROM. But it failed anyway very early in Canons init task.

I think I sent you already my diff for QEMU2.5 and Digic X. If not, ping me on Monday.

If it doesn't help, send me your ROM backups via PM.

https://www.magiclantern.fm/forum/index.php?topic=5470.0

There's a long thread about what can and can't be done.

Theoretically SATA to IDE (UDMA) and IDE -> CF could work, as CF in IDE mode is subset of IDE and UDMA is also part of ATA.

And CFast is jut SATA with different connector.
How to combine those? Will you find proper adapters? (note that every adapter in this chain is one way only so you need SATA to ATA and ATA to CF - do those even exist?). Will it even work? (SATA->ATA is quirky, there are a ton of problems with different adapter ICs). Will it cost less than buying a better camera?
I don't think any of those were answered in the past.

This is likely due to Cortex M0 that takes role of MPU on PowerShots new PS based models. Would need a research for our MPU equivalent.
https://www.magiclantern.fm/forum/index.php?topic=23296.msg243752#msg243752

EOS RP also have two different versions of 1.6.0 firmware in the wild - 3.9.5 and 3.9.6. (like case of R.180)

The one we work on is 3.9.5, build date is 2020-08-20 15:54:54 and is available at https://gdlp01.c-wss.com/gds/2/0400006292/01/eosrp-v160-win.zip
I was unable to track update file for 3.9.6 anywhere. It has build date of 2021.02.01 11:46:45.

Good news is that (just like R) it is enough to grab 1.6.0 3.9.5 file from the URL above and install it - no card swap tricks needed.

[Please note that this update contains things that happen since April 2023, when we posted a huge "status" update summarizing last 5 years of development.If you are not familiar with the previous update, or want to refresh your memory a bit, here it is (just scroll this thread to the first post ):Current state of Magic Lantern project (updated April 2023)]

Please note that this update contains things that happen since April 2023, when we posted a huge "status" update summarizing last 5 years of development.

If you are not familiar with the previous update, or want to refresh your memory a bit, here it is (just scroll this thread to the first post ):
Current state of Magic Lantern project (updated April 2023)


Chapter 1: Updates on Digic 6 / 7 / 8 / X support

Except existing "not yet dead edition" build for EOS 200D, there are no new builds available.
Everything listed here is available as source code only, and that's for a good reason.

Since April, we have initial support for a few extra models:
DIGIC 6: EOS 80D (on par with 750D), 5D Mark IV (goes to menus, very unstable)
DIGIC 7: EOS 77D (on par with 200D)
DIGIC 8: SX70 is finally merged, but still unstable.

BTW: @names_are_hard also merged 70D support to magiclantern_simplified (D6+ repo) as we both have one as our test subject.

I now have a 5D4.

I also have this:

77D.

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.

Side note: Canon XF605 / Cinema EOS discoveries

Recently we've been contacted by a group of people trying to reverse engineer XF605 camera.
This is Cinema EOS line, which is a different firmware "base" than our models. For details refer to Chapter 6: I noticed PowerShots on the list? Do you want to steal CHDK user base?! of previous status update.

What they found is very interesting (and promising!). Digic DV7 seems very similar to DIGIC X as we know it. But not only that - firmware seems to be very related to our "EOS" variant, there's in fact a ton of similarities. Not tested yet, but we think ML "hello world" should be portable over this platform, maybe even our GUI system.

Some details are available in @ponguinforum threads:
Canon XF605: Teardown and Datasheets
Canon XF605: Digic DV 7 == Digic X rebranded for camcorders?
D214 / Diva / drysh UART on XF605

How this relate to Magic Lantern? Is support of C100/C300/etc. possible? We don't know.


Chapter 2: Code level improvements

I won't go into much details here, for more info check out Names's recent technical status update.
Let me just take some highlights:

Some time ago we started documenting relation between DryOS versions and data structures. This was started by @names_are_hard find that some structures in ML code doesn't seem to match any known model.
This resulted in a big cleanup of task-related structures that in the long run should reduce complexity and avoid some hard to debug bugs.

I cleaned up Digic 6+ boot code to match older models. Now it is much easier to start a port of new model / rom version for those cameras.

Names is working on crop_rec_4k_mlv_snd branch merge into magiclantern_simplified repo. This is a challenging task due to how branches were previously handled.

Chapter 3: Experiments

I experimented a bit around Zico (GPU) core on Digic 6 and up. Turns out we have some OpenVG and possibly OpenGL capabilities via EGL. Unfortunately a lot of code is missing, so utilizing them may be a huge task.
However, what I was able to achieve is GPU-accelerated ML GUI. For now it exists only as an experiment as we still didn't solve some caveats (refresh rate on D6/D7, instability on D8).
More on that in Compositors, layers, contexts in RGB and YUV - How Digic 7(6?)+ draw GUI.

A few days ago I was able to achieve this. Full double-buffered ML menu with hardware indexed rgb -> RGBA rendering on Zico.

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

While old method felt "laggy" and was prone to rendering glitches, this is so damn fast. Feels exactly like using 5D3.

This is all thanks to a single Zico function - GrypDsCoreDrawImageToVramForEqualPhase.

Chapter 4: 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.

RTFM. Only "FRTP" and "crop" presets have any kind of real time preview.

We have to remember that these are volunteers.

You forgot that you quoted actual mod and very experienced community member.
In fact we discussed that internally some time ago and we will try to do that. Just because it actually reduces noise, since we can redirect any of those recurring questions to the status thread.

Next update will be posted somewhere early June. Depends when I'll have time to write it and others to review.
Since quarterly updates are not 5-years-of-stuff-to-describe, it will be likely much shorter one, but a bit more detailed. We want to keep the form of writing "in layman's words", providing links to additional (more detailed) resources where possible.

Well, there's a surprise. M50 mkII is not cbasic/uart locked, even though it runs latest DryOS version. I guess PowerShot team didn't get the memo.

Also there's 1.0.4 firmware in the wild, by google results it seems to be shipped since December last year. However there's no firmware update available (latest on the site is 1.0.3).
Even though firmware downgrade is locked (and we have no 1.0.4 file to use card swap method), Names found a way to downgrade any downgrade-locked camera without a real "same version as installed" file.

Yes and no. ICUs have secondary cores, delegated to some specific tasks.
D6 has ARM core called OMAR. Likely used for tasks like EEKO on D5
>= D6 have Zico core - Xtensa arch, delegated for GPU offload)
>= D7 have Lime / CCLime - Xtensa arch, offloading of network stuff
>= D8 have (forgot the name) - again Xtensa arch, seems to be used for offloading cr2/cr3/etc encoding/decoding.

We can control firmware loaded there, but it will be a non-trivial task. We are more likely to use available functionality to accelerate/offload GUI rendering than anything else.
Zico is interesting as it has direct access mapped 1:1 at least to lower 1GB of ICU address space. There's some private memory at 0x80000000 and then again shared one at 0xBFF...... (used for RPC)

Recently I did some tests with EGL capabilities of ZICO (GPU) core. Quote from R/RP thread:

Code Select Expand


  mzrm eglGetDisplay 0
  mzrm eglInitialize 1 2720200 2720204
  mzrm eglGetError
cmd status      EGL_SUCCESS
EGL Version     1.3 // via eglInitialize()
EGL_VENDOR      TAKUMI Corporation
EGL_VERSION     1.3 TAKUMI Corporation
EGL_EXTENSIONS  NONE
EGL_CLIENT_APIS OpenGL_ES OpenVG

Fun fact: Zico core can do OpenGL ES and EGL 1.3. There's no implementation ICU side, but at least EGL is implemented on Zico. After some digging I was able to initialize EGL and query capability strings.
Not sure if that will go anywhere (OpenGL seems missing in Zico firmware even though hardware is capable of that), I never worked with OpenGL before so I don't know if EGL is enough to do anything interesting.
There's OpenVG support too.

This was a good excuse to dig into ICU-Zico communication.

Fun fact, EGL/OpenVG while exposed via mzrm (ICU - Zico comm) it is cleary not tested (?) by Canon. Some OpenVG functions returs Zico code pointers (Xtensa code in Zico private memory region) to ARM side...
There is at least part of OpenGL implementation in Zico firmware, but wrappers are completely missing from Zico RPC table.

Anyway, EGL tests ended in a discovery!

Up to now we rendered GUI in indexed RGB (like old models do) and then converted it using a naive code (well, a loop over a buffer + LUT table) to RGBA that new generations use.
We theoreticized since the very beginning that ZICO (gpu core) could be probably used to accelerate that, since Canon also still keeps whole gui resources in indexed RGB.

A few days ago I was able to achieve this. Full double-buffered ML menu with hardware indexed rgb -> RGBA rendering on Zico.

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

While old method felt "laggy" and was prone to rendering glitches, this is so damn fast. Feels exactly like using 5D3.

This is all thanks to a single Zico function - GrypDsCoreDrawImageToVramForEqualPhase.

Caveats? Of course they are caveats Camera likes to randomly lock up (literally lock, UART output hangs mid-print) on Canon main menu enter.
This happens on R, I wasn't able to trigger it on 80D (D6) and 77D (D7). No other models were tested yet.

Also it is unable to render full buffer at once. Buffer is 960x540px (out of which 720x480 is the visible area on LCD). I was able to get at max 960x480px renedred at once, so I just split rendering into a two calls - for upper and lower half of indexed buffer.

Also on 80D and 77D menu is still laggy, we get like 5FPS refresh rate while R seems to do at least 20FPS. I switched LV frame rate to power saving mode and it was still as fast.

Dirty code (EGL tests, ZICO rendering + double buffering, etc) is on my dirty branch: https://github.com/kitor/magiclantern_simplified/tree/EOSR_zico_EGL

Code Select Expand


  mzrm eglGetDisplay 0
  mzrm eglInitialize 1 2720200 2720204
  mzrm eglGetError
cmd status      EGL_SUCCESS
EGL Version     1.3 // via eglInitialize()
EGL_VENDOR      TAKUMI Corporation
EGL_VERSION     1.3 TAKUMI Corporation
EGL_EXTENSIONS  NONE
EGL_CLIENT_APIS OpenGL_ES OpenVG

Fun fact: Zico core can do OpenGL ES and EGL 1.3. There's no implementation ICU side, but at least EGL is implemented on Zico. After some digging I was able to initialize EGL and query capability strings.
Not sure if that will go anywhere (OpenGL seems missing in Zico firmware even though hardware is capable of that), I never worked with OpenGL before so I don't know if EGL is enough to do anything interesting.
There's OpenVG support too.

This was a good excuse to dig into ICU-Zico communication.

Sensor seems to be recycled again from 1300D/2000D - 24MPx, 4k only cropped and with contrast detection.

Camera looks like 1300D/2000D with Digic 8 and RF mount.

It looks like it is one of the most affordable newer cams so it might get popular.

That's your opinion. I heard a variant of that about every single model.

Do you think that R100 has a chance to become "the new EOS M"?

EOS M is overhyped. R100 seems to be crap sensor with relatively good CPU.
If we ever get to the state where R100 will make any sense, M50 will probably be much better and cheaper 2nd hand.

we can all donate a small amount to buy one for you devs to try it.

Also you are clearly not familiar with our latest status update if you think ML will pop out of nowhere for just released Digic 8 model.
https://www.magiclantern.fm/forum/index.php?topic=26852.0

Get me an R100 and I'll tell you.
But I'm fairly sure it uses newer DryOS that first appear on R3 and locks out our entry methods.

Images are dead. @g3gg0 do you still have them?

77D.