Messages

1

Camera-specific Development / Re: Canon EOS R5 / R6

« on: May 18, 2022, 07:21:40 AM »

I don't want to shatter your dreams, but forget about it.

I can agree that it is mostly complete out of the box. From the list you provided, maybe 30 minutes limit can be removed the same way as on previous generations.
Other things - unlikely to happen.

Please bear in mind that Digic X is another generation of unknown hardware - but this time capable of doing raw natively. And as I stated before, a fundamental part of OS (Resource Manager) got completely replaced, which will break a lot of things. Not to mention that RAW is R5/R3 domain only - we don't touch R3 and as of R5 goes I am the only dev here with R5. And with a lot less time to invest lately due to "away from keyboard" stuff

- Canon Raw recording through USB port for USB SSDs (Jus a routing from CFexpress to USb or even a dual recording).

Impossible. CFExpress is just DMA over PCI Express, USB - even if camera had USB host functionality (and to my knowledge it doesn't) handling overhead and lack of implementation would be most likely too much to achieve it without a significant effort - if possible at all.

From the glimpses of new File I/O I saw - it seems that file I/O is hardware accelerated now (probably DMA using what is called IBus - Image Bus?).

Yes, I know Magic Lantern is famous for crossing items out of "troll questions" list, but if comparing against "well supported" generations, Digic 6 and newer models are in "early 2011" state of things or worse.

2

General Help Q&A / Re: Question about installation step "Launch the Firmware Update proces"

« on: May 14, 2022, 07:49:27 PM »

Not sure what your point is, but OP (and others) have problems with ML documentation.  OP came to the forum to find an answer to a problem caused by incomplete ML documentation, and instead of getting straightforward help, it was suggested that the problem was his fault.

Magic Lantern is lacking everything:
 * user friendliness
 * user documentation
 * support
 * code review
 * developer documentation (!)
 * manpower to continue this project

As far as I'm concerned, due to its hackish nature it was always designed for "technology nerds", not for "general public".

What open source developers do is what they consider fun. If project assumes user had to have at least a bit of skill, then technically it is user fault if he doesn't.
https://mikemcquaid.com/2018/03/19/open-source-maintainers-owe-you-nothing/

There's a reason it is almost a year since Alex last logged in. User expectations are different than authors intentions, and it is devs who give you something to play with zero promises.

On the other hand - wiki is publicly editable. Feel free to improve it.

Yes, it should -- because of the problem with the instructions that is the cause of this thread.

And this is a different view from experienced dev vs user. No, it shouldn't.
Reason is simple - even now people think that Magic Lantern is installed into a camera. And whenever camera fails (99% of the time cause being not related to ML), we are accused of failure.

I see no way to explain to a technology noob why "firmware update" is not a firmware update, and what bootflag setting means + why it just can't brick / damage a camera.
If you can - please add a section to wiki. Everyone will benefit from that.

This is a difference between developer and user. The thing you see is "user friendly" may be actually damaging for project reputation. Yes, I'm probably exaggerating in that particular case, but when you know how it works from the other side, you tend to choose the words more carefully.

because most folks go to YouTube videos by @Zeek and others that show them how to do so -- they don't use the vague/incomplete ML instructions.

You see - those people do a great work. But they do it on their own, in their own medium.

You highlighted a very important issue here - there are people with knowledge, but there's not enough people who contribute that knowledge back to the project.

3

General Help Q&A / Re: Question about installation step "Launch the Firmware Update proces"

« on: May 14, 2022, 06:21:33 PM »

Those instructions should probably add:
"Go to the 'firmware' selection in the menus (usually in the gold 'tools' section of the menus), and update the firmware."

No, they shouldn't - because there's no actual firmware update performed. This is just a way to execute a program on stock camera.

It's not the "opposite" -- it just doesn't give any clue on how to "Launch the Firmware Update process..."

Because that may depend on model. It, in fact, didn't - however ML (unfortunately) is not a beginners tool, so finding how to execute firmware update is quite an easy task.

4

Camera-specific Development / Re: Eos 2000D

« on: April 30, 2022, 10:03:58 AM »

You can try yourself. As said earlier, it looks it might be a pretty straightforward port from 1300D

5

Camera-specific Development / Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)

« on: April 30, 2022, 10:03:19 AM »

Unfortunately your beliefs have no backup in any measurable data. We are not even close to any raw capabilities on Digic6+ models, do not expect anything in literally years from now unless a miracle happens.

6

Reverse Engineering / Re: Battery grip pins / UART

« on: April 28, 2022, 08:56:46 AM »

Not found yet working UART pinout for Canon 5D mark II (I need it for repair purpose) and here is one:

As the image URL is broken, here are the images:
https://photo-parts.com.ua/parts/imgbrowse.php?folder=IMG_STORE/Canon%205D%20mark%20II%20PCB/

7

Duplicate Questions / Re: Shot Review looks like hessian, for dark shots

« on: April 23, 2022, 06:50:42 PM »

This is fine. You see Spotmeter and zebras overlays.

8

General Help Q&A / Re: C100 question

« on: April 22, 2022, 08:47:45 PM »

Cinema EOS are running different firmware base anyway. It will be impossible to just port it.

9

General Development / Re: Canon Basic scripting (DIGIC 8, DIGIC X models)

« on: April 18, 2022, 10:22:43 AM »

"this" -> BASIC ROM dumper works, in both variants (bootable only and both ROMs).

10

General Development / Re: placing ML into shoot memory

« on: April 17, 2022, 01:58:01 PM »

2GB, nice.

EOS R5, DIGIC X in general

Resource Manager is gone. Now we have Resource Manager 2...

Some "old" functions exists, but they contain only assert:

Code: [Select]

debug_assert(0,"Resource::RscMgrOldApiStub.c",0x2b);
smemShowFix DNE. Replacement is res_memshow that requires numerical argument. Output is not yet understood.
R5 has 1GB(2x512) + 4GB(2x2GB) DDR4 memory. ICU bootloader / FROMUTIL says it has 1GB. How it works it is unknown.

11

Camera-specific Development / Re: Canon 90D

« on: April 17, 2022, 10:06:40 AM »

Hello.

There have been some experiments on DIGIC 8 'PowerShot' development (M50, SX70, SX740). This device has same processor & similar hardware. Is there any experiments we can do?

You can basically try to port M50/R/RP/850D progress from magiclantern_simplified.

Portable rom dumper isn't portable anymore (it needs specific per model builds, no new builds will be made as we have Basic now).

Memory map shows 2GB RAM.

I highly suggest joining our dev Discord, as most of Digic6+ discussion/research is done there.

12

Camera-specific Development / Re: Canon EOS R5 / R6

« on: April 14, 2022, 04:53:47 PM »

@Kitor, how did you learn how to get ‘hello world’ on various cameras?
Has the knowledge you need for that overlap with your work ?

It just happened that I was at the right time in the right place (Discord) just when the digic6+ task context struct got finally cracked.

No, my actual work background is devops-ish, I work as continuous integration/delivery engineer (and now architect). In fact, before I joined the efforts I had about 8 years gap since the last time I touched C/C++.
One of my hobbies is old computers (I have quite a big collection) and I watched a lot of videos about 8 bit computer internals or how each generation of consoles was hacked. I guess I had the general idea of what is going on, so it was easier to jump in.

Digic 6 - 8 bootloaders (except latest iterations on 850D, R5/R6) are very similar. This is mostly just stubs hunting, and for hello world you don't need that much of them.

R5/R6 was a little harder. 850D already had "the new/improved" stage 1 bootloader, but due to a different memory layout @Names had no issues there.
Even with that, the Digic 6 - X boot code implementation is common with just some minor differences in stubs/constants required on per generation basis.

When @Lorenzo got his R6, I took that as an opportunity to dig a bit more into QEMU (well, that took a few days of work), so we had "working" builds there. But those were not booting on real hardware. Thus it was known that there has be a catch. That is what ended up into around 60 hours of debugging on real hardware - my R5 so far crashed more times that it made photos

13

Camera-specific Development / Re: Canon EOS R5 / R6

« on: April 14, 2022, 03:19:36 PM »

Angry Walter, that's an achievement!

Is it possible to transfer firmware from upper models or hack/activate at least only raw-video in R6?

Yes? No? Maybe? Even if, it will be illegal and bring whole project into a legal trouble, so feel free to experiment on your own. You won't get any definitive answer or help here.

14

Camera-specific Development / Re: Canon EOS R5 / R6

« on: April 14, 2022, 08:59:19 AM »

Great, can’t wait to have raw video on this camera 

To be honest I was sad I got it after April 1, as it would make a great headline for April Fools.

As for CMOS registers I'm not sure if we even still have those on D78.
We are still in "too early" stages , trying to solve instability issues on much basic level (eg. Digic 8 random crashes related to LiveView, probably due to how we draw ML interface).

For sure script to detect timings can't get anything from EOS R. A ton of things is getting offloaded into secondary cores.
If will be nice to have anyone of the "old guild" with deeper hardware understanding to have a look at D6/7/8 models (even if this means poking around ROMs and not real hardware). Unfortunately Alex is gone for almost a year now.

15

Camera-specific Development / Re: Canon EOS R5 / R6

« on: April 12, 2022, 10:22:29 PM »

That took countless hours spent in qemu.

And then 60 hours extra debugging on physical camera why it crashes.

Turns out that new bootloader (introduced around I think 850D) erases whole destination buffer if autoexec.bin is loaded.
It just happens that before that, the same RAM regions are initialized for coprocessors like EF comm (SHIRAHAMA) and EIS (KUSATSU).
And DryOS was very unhappy if booted in that state, crashing immediately in different places.

So far - R5 has total 5GB of DDR4 RAM - 2x 512MB and 2x 2GB.
How this is mapped - it is unknown. smemShowFix is gone. Looks like whole old Resource Manager is gone and replaced with RscMgr2.
Drawing routines also had to be adjusted, as while interface still seems to be 720x480, buffer is 2048x1080 (it was 960x540 in the past).
I saw some differences in FIO routines.

Bootloader says it has 1 gig of RAM. My theory so far is that 2x512MB are used by main ARM core and 2x2GB by peripherals - and those are memory mapped into ICU where needed (as there's about 1GB of address space left).

Very rough and unpolished code is on my branch: https://github.com/kitor/magiclantern_simplified/tree/R5

16

Camera-specific Development / Re: Canon EOS 1300D / Rebel T6

« on: April 05, 2022, 07:56:22 PM »

Format card on PC and try again.

17

Tutorials and Creative Uses / Re: Let's restore camera help (Help needed)

« on: March 28, 2022, 09:05:08 AM »

来了来了

Ale wiecie że to publiczne, angielskie forum i nie każdy ma ochotę czytać wasze posty przez tłumacza Google?

/s

[e]
I just realized that they may not even have access to any translation service that will unveil the message above. Oh well.

18

Camera-specific Development / Re: DIGIC 8 'PowerShot' development (M50, SX70, SX740)

« on: March 26, 2022, 09:52:02 PM »

CR3 raw from SX740 



Caveats:
 - RAW only works, RAW+JPG L crashes
 - Canon code is confused as it has no settings for RAW modes at all, and screams on UART when it is enabled.
 - File opens fine in Windows preview (including actual RAW render), RawTherapee (missing EXIF data) and http://exif.regex.info/exif.cgi (EXIF data only)
 - File does not open in Lightroom/Photoshop.

To work properly it will most likely require us to understand MMU and patch a ROM in a few places (to make it "understand" RAW).

Right now this can be achieved by

Code: [Select]

GUI_SetImgComposition(1,0,6,3,4); // set RAW only for card1
GUI_SetImgComposition(2,0,6,3,4); // set RAW only for card2

This is C code, I won't share stub (it is easy to find) since we have no idea what are the consequences of leaving camera in that state (other than a ton of debug messages logged).
Thus don't ask how to run that on camera. If you don't know how to do it, you most probably shoudn't try in this state.

If anyone want to dig into cr3 file, here it is: https://kitor.pl/eos/sx740/sx740_raw.cr3

One can reset settings to JPG by just opening menu and setting back to JPG.

===

On the other notes I have a lot of Digic 8 ML code working on SX740, but also have a nasty crash that I can't trace yet. Thus for now it lives on branch in my fork.

19

Camera-specific Development / Re: DIGIC 8 'PowerShot' development (M50, SX70, SX740)

« on: March 24, 2022, 11:27:22 PM »

So far firmware is very similar to EOS R. SX740 runs DryOS +p3, while R/RP does use +p4.

In fact I was able to use compositor code that so far I thought was R specific (RP and later have more sane implementation by Canon).
Code is "so much EOS" that it has all the regular lens info structures even though this is point and shoot with fixed lens.

I even found (and successfully poked) some GUI dialogs from R that should not exists here, but this requires a bit more research.

20

General Help Q&A / Re: Firmware question EOS 500D

« on: March 14, 2022, 07:30:26 AM »

https://wiki.magiclantern.fm/install

21

Camera-specific Development / Re: DIGIC 8 'PowerShot' development (M50, SX70, SX740)

« on: March 11, 2022, 06:48:48 PM »

I guess this is the final confirmation?

SX740 HS indeed runs what appears (at least on surface) very similar to regular EOS ROM.
Looks like it have 1GB RAM. No MPU (everything handled on ICU)
Interface is stretched vertically from 3:2 (720x480) into 4:3 (640x480), thus it looks a bit odd (vertical scaling ratio 8/9).
Interesting is that it doesn't have raw photo capabilities at all (in the firmware).
Also, it seems to have ROM0 only (32MB)

Unfortunately that photo marks my first case in a long time where semi-broken device ended up worse in my hands than it arrived.
It was slightly water damaged - lens was making high pitched noises. Both aperture and IS ribbons just snapped in half when I attempted to disassemble it
Thus right now it just gets ERR60 if booted in regular mode...

If you have a broken SX740 (SX730 might work as it seems they might just updated the pcb) that lens is still intact, please contact me on priv - we may make a deal.

22

Camera-specific Development / Re: Canon 40D

« on: March 10, 2022, 01:14:25 PM »

No idea, but the "SRM_" name originates from the firmware itself.

System (Static?) Resource Manager, on newer models you find a lot of RscMgr.c references. It manages most of memory space, "regular" malloc / AllocateMemory are a very limited pool.

SRM_AllocateMemoryResourceFor1stJob is just a nasty hack that uses SRM Factory mode to allocate a lot of memory. There's a ton of other allocators, they behave differently per camera mode.

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

23

Camera-specific Development / Re: Canon EOS R / RP

« on: March 10, 2022, 08:59:59 AM »

You probably want to join our development Discord then. We are looking for an opportunity to make some wiki pages on that, since all documentation on forum is very outdated.

24

Camera-specific Development / Re: Canon EOS R / RP

« on: March 07, 2022, 09:11:28 AM »

However, I have a distinct lack of understanding of reverse engineering the firmware for EOS/ML.

Hi,
looks that I missed that post - since newcomers are moderated and may show up with delay.

1)How do I get the firmware from my camera? Can I take the file from the website, modify it and flash it as usual, or are there mechanisms out there that don't allow me to flash the modified file?

Easiest way to grab the firmware is via Canon Basic script - see General Development section, pinned topic.
We don't modify / flash original firmware - so I can't answer that question. Magic Lantern is altering DryOS bootloader in RAM, and then just runs as regular task(s) in DryOS.

2)If I can't do that, do I have to download the firmware from the camera itself?
I've seen it done by people in this thread, but it was sketchy and I never figured out exactly how to do it.
Can it be done by downloading the code to the card or does it require access to the insides of the camera?

Yes, because we do not redistribute firmware dumps. Those contain copyrighted Canon code.
You can access UART (Reverse engineering section, pinned topic) and do some things directly from bootloader, but that is not needed.

3)What are the risks in reading and writing firmware? Can I brick the camera in a way that requires something non-trivial steps to repair?

Reading - no risks. Writing - again, can't answer. Main firmware runs from 25xx flash on board so it is theoretically possible to desolder those and program externally.
If you break MPU firmware (hardware "hypervisor", controls buttons, some peripherlials comm and most important - power to main CPU (ICU)) it will get tricky, as this one stores firmware in internal flash - and @coon probably found Jtag there just last week. We don't touch MPU code though.

4)Should I fix the firmware code directly or can I write a small program which will run at startup and patch the camera's memory, to reduce the risk of the camera turning into a brick?

See 1a - we do exactly that. Patch in RAM (what we can) and just run our own tasks that alter camera state where possible.
On older models it was possible to use so called Cache hacks to patch ROM code on runtime - but this feature is missing from new generation CPUs.
In theory you can use MMU to remap whole pages of ROM with patched code - however we don't do that (yet). CHDK uses that functionality, just so far we didn't have to patch ROM directly (again - yet), thus it wasn't investigated.

5)What is the best way to disassemble the firmware? Programs, tools?

The best tool is the tool you know to use. Nowadays we mostly use Ghidra,

25

Camera Emergency Department / Re: Canon 5D Mark 2 err70 on entering LV and sometimes after taking a picture

« on: March 07, 2022, 08:47:47 AM »

Simple checks to perform:
- are all pins straight in CF card socket?
- does it crash with other cards?
- does it crash with other lens?
- does it crash without lens attached?
- what is the shutter count?
- have you tried to re-install Canon firmware? (run upgrade to the same version you have)

You can upload crash log, but ERR70 in Canon world is basically a 'catch all' statement which means 'something went very wrong'.

Symptoms for me suggests that shutter (or mirror assembly) is dying.