Author Topic: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)  (Read 220030 times)

fgervais

  • New to the forum
  • *
  • Posts: 3
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #375 on: March 08, 2021, 01:53:19 PM »
Nice I'll have a look, thank you

names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #376 on: March 15, 2021, 09:07:41 AM »
Good progess over the weekend.  The horrible task bugs were defeated.  Stable ML code up to GUI.  Button handling works.  Menus don't, but drawing does.  Getting there.


names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #377 on: March 29, 2021, 02:13:37 AM »
Don't get excited, it's just the menus, nothing works...  but:



Teamwork with Kitor, thanks!

Raging Ocelot

  • Just arrived
  • *
  • Posts: 1
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #378 on: April 01, 2021, 01:08:32 PM »
This makes me happy. I have a T7i upgraded from a T3i and I can't wait for a magic lantern upload for my T7i.. Thank you so much for your work.

Ondre

  • Just arrived
  • *
  • Posts: 1
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #379 on: April 02, 2021, 08:47:43 PM »
Maybe I can make a donation to support the developer?

Walter Schulz

  • Contributor
  • Hero Member
  • *****
  • Posts: 7987
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #380 on: April 06, 2021, 12:38:32 PM »
Bitcoin only, ATM. And you can only donate to the project but not to a particular port or dev.

Straight_Shooter

  • New to the forum
  • *
  • Posts: 12
  • Canon 80D, Canon 1100D
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #381 on: May 19, 2021, 02:56:12 PM »
It would be great if one could donate to this project via PayPal. I know I would give a couple bucks to it for sure.

names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #382 on: May 21, 2021, 02:00:23 PM »
Have an HDMI capture progress report from 200D.  Minor edits to skip boring pauses:


names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #383 on: May 22, 2021, 05:33:09 PM »
Quite hard bug diagnosed and provisionally fixed in module relocation.  Took me a few weeks to understand.  This is very significant, it removes a large number of very hard to understand crashes from modules, and exposes other, easier to debug problems.

Module loading in ML works by building ELF objects, which are copied to card, and then ML uses libtcc to load these into mem.  The loading process has a relocation step.  There were (probably) two problems here.  The more important, libtcc has I think a bug when it checks to see if the relocation is too far.  Since modules are built as ARM, not Thumb, the default approach means the target of calls / jumps can only be +-32MB from the call site; ARM encodes the address in 24 bits.

For at least Digic 7 cams, offsets can be outside this range, they're typically in 0xe000.0000 or 0xdf00.0000 areas.  Older cams are in 0xff80.0000 or thereabouts, so you can underflow and be within 32MB.  Libtcc tries to check if the target is outside this range but the error condition doesn't trigger.  This was causing tccelf.c, relocate_sections() to fixup the modules with inappropriate relocations.  And that meant calls from within module code would go to *completely unrelated* offsets, with unpredictable and very hard to diagnose crashes.

As far as I can see, the fact that older cams happen to allow modules to successfully relocate was always luck.  If heap allocs had occured from a different region, or if stub addresses hadn't happened to be "near" to heap addresses via wraparound, it would never have worked.

My provisional fix is to build modules with -mlong-calls.  This changes the asm output so the form is "blx r3" style, which allows full 32-bit offsets.  This incurs a minor space and perf cost, and is currently untested on old cams.

kitor

  • Developer
  • Member
  • *****
  • Posts: 249
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #384 on: May 22, 2021, 09:44:01 PM »
Quote
and is currently untested on old cams.

Not true anymore, verified on 50D to work as intended ;)
EOS R, 200D, 50D...

heder

  • Developer
  • Member
  • *****
  • Posts: 152
  • No time for caution
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #385 on: May 23, 2021, 10:16:32 AM »
"+/-32 MB near jump issue" : This is (I guess) the problem that all new cameras will face. It's also on the 1300D. On 1300D you can not hijack any calls as the addresses (csanon firmware) are further away than +/-32MB from the magic lantern firmware. I recreated a patch function that instead of using a single near jump, uses a near jump that jumps into a long call jump. Maybe this problem is also present on DIGIC7? ... if so a *temporary* solution is present in the 1300D thread.
Embedded SW engineer. Canon 20d, 40d, 350d

names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #386 on: May 23, 2021, 03:03:51 PM »
For the module context, since we control the source and are compiling it, I think using -mlong-calls is an appropriate fix.  For patching at runtime, that won't work and you might need to do what you're describing.  I guess that's the context you need to work in, so you can't use -mlong-calls?  Do modules work on 1300D?  If DryOS code is far from heap alloc region, I think they won't, and I also think that my fix will work for you.

I'd like someone with better experience with ARM to confirm -mlong-calls makes sense for where I'm using it - any volunteers?

I'm not doing any runtime patches yet on 200D, they haven't been needed.  I'm assuming I'll use MMU remapping when it gets to that (or, if I'm lucky, overwriting a thunked function, the 200D has *some* code in RWX pages).

heder

  • Developer
  • Member
  • *****
  • Posts: 152
  • No time for caution
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #387 on: May 23, 2021, 09:13:09 PM »
For the module context, since we control the source and are compiling it, I think using -mlong-calls is an appropriate fix.  For patching at runtime, that won't work and you might need to do what you're describing.  I guess that's the context you need to work in, so you can't use -mlong-calls?  Do modules work on 1300D?  If DryOS code is far from heap alloc region, I think they won't, and I also think that my fix will work for you.

I'd like someone with better experience with ARM to confirm -mlong-calls makes sense for where I'm using it - any volunteers?

I'm not doing any runtime patches yet on 200D, they haven't been needed.  I'm assuming I'll use MMU remapping when it gets to that (or, if I'm lucky, overwriting a thunked function, the 200D has *some* code in RWX pages).

I think the -mlong-calls trick is the way to go, the optimization gained by using relative jumps is ussless.

I dont know if modules are running on the 1300D, I just worked out a solution for hijacking firmware functions, where you patch a single instruction, and you're right about that the heap alloc region need to be close, aka within +/-32MB from canon firmware (99%). 

I'll ask citrix to read this thread
Embedded SW engineer. Canon 20d, 40d, 350d

names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #388 on: May 23, 2021, 11:15:19 PM »
I'm not sure.  Relative calls are 1 instruction, 4 bytes and no memory access. Long calls are 2 instructions, 8 + 4 bytes including an addition d-cache read.  It's easy to imagine situations where it would be significant, but I don't know if we hit them.  Not enough runs on 200D for me to try profiling it, and I can't use relative calls for modules so I can't do a comparison easily.

kadushkin90

  • New to the forum
  • *
  • Posts: 5
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #389 on: May 25, 2021, 03:31:24 PM »
Hello, I don't understand anything about programming, but I do have a 6D mark II camera available. Is there anything I can do to help you?

Walter Schulz

  • Contributor
  • Hero Member
  • *****
  • Posts: 7987
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #390 on: May 25, 2021, 03:58:29 PM »
I don't think so. ATM programmers need physical access to a camera.
One thing you are able to do now but it won't accelerate porting ML to 6D2: Looking for UART connectors.

EDIT: Not needed anymore. Watched a disassembly video. I'm sure UART is located right from rear dial and there is a rectangular hole to access it.

names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #391 on: May 25, 2021, 05:32:46 PM »
Beep boop.  200D has a game.


One day, font addr will be good.

names_are_hard

  • Developer
  • Senior
  • *****
  • Posts: 383
  • 200D idiot
Re: DIGIC 7 development (200D/SL2, 800D/T7i, 77D, 6D2)
« Reply #392 on: June 14, 2021, 06:08:44 AM »
Made some improvements to memory management routines, and fixed some ML assumptions that were not true for newer Digic:
https://github.com/reticulatedpines/magiclantern_simplified/tree/feature_show_free_mem

This means there's now a useful display of memory info for 200D.  Should be not hard to extend to other semi-supported Digic 6, 7, 8 cams: