Messages

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

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.

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/

This is fine. You see Spotmeter and zebras overlays.

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

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

[EOS R5, DIGIC X in general]

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 Expand

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.

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.

@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

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.

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.

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

[on PC]

Format card on PC and try again.

来了来了

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.

[not]

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 Expand


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.

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.

https://wiki.magiclantern.fm/install

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.

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

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.

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,

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.

Two first are dummy. `lensdrivefocus` seems to have implementation.

[there will be no RAW recording support, unless announced otherwise]

There's no such thing as "only lua scripting" anyway.
Lua can only expose what is already supported by the build. If you strip something from build, you strip the lua ability to use that.

Not to mention that Lua is probably completely broken on Digic 6+, and will be not trivial to fix.

Existing code crashes camera with seemingly random reasons. We don't release anything for your own safety. Do not request any builds as those requests will be ignored.

Not at all likely to come true this year.

I see post was deleted? (or not approved by mod). Anyway,  there will be no RAW recording support, unless announced otherwise. Hardware is different.

What about overexposure warning in LV?

Yes, ML has this feature on older cameras. But DIGIC registers doesn't work the same way as before.
I was able to alter threshold and highlight style by poking registers, but I'm not able to activate the function (yet?). For now it works like warning you can enable in Play mode.

Not valid anymore. I spent some time and found out that now this is a set of three registers, not a single one.

And both overexposure and underexposure warning can be enabled independently at the same time with different visual settings.

And while running in Clean HDMI mode, one can configure HDMI and LCD to display different things, with independent thresholds and styles

Complete registers documentation is on wiki.
This should apply to all Digic 8 models (+/- clean hdmi limitations), I need to explore code on Digic 6 and 7.

[e] Digic 6 and 7 use different register addresses and a bit different values, but capabilities are generally the same. I added those in Digic 6 section of Wiki.

PoC will follow soon.