Canon EOS R / RP

[paulleavitt]

Hey all! I have a GH5 now so I've been out of the ML world for a while, but I'm glad you guys are still at it!

My business partner has an EOS R that he's said he's willing to run some tests on if that's helpful for y'all (and if the likelihood of bricking is reasonably low). If that would be helpful, just let me know!

Paul

[kitor]

At the moment it's impossible to run anything without enabling bootflag via UART first. Something like this:
https://twitter.com/_kitor/status/1095729715284008960

[aprofiti]

Canon released a new 1.2.0 firmware update for Eos R.

[kitor]

Can someone with working toolchain checkout this repo/branch: https://bitbucket.org/kitorPL/magic-lantern/branch/kitor/eosr_120
and compile for me minimal hello world?

Code: [Select]

cd minimal/hello-world
make MODEL=R
On 1.1.0 hello_world gave me LV crashes instead of text printed, but at least it worked.
Between updating, dumping 1.2.0 and updating stubs I updated my WSL distro (Ubuntu 16.04 to 19.04) and linker stopped working:

Code: [Select]

Using /usr/bin/arm-none-eabi-gcc (from PATH).
[ VERSION  ]   ../../platform/R.120/version.bin
[ CPP      ]   magiclantern.lds
(...)
[ LD       ]   magiclantern
arm-none-eabi-ld:magiclantern.lds:1: syntax error
make: *** [../../src/Makefile.src:224: magiclantern] Error 1indeed magiclantern.lds is generated broken https://i.imgur.com/iLLqR2B.png

So i setup toolchain on another machine (this time Debian testing), built it and camera lockups completely, even before any print from ICU on UART:

Code: [Select]

BootLoadNow jump to AUTOEXEC.BIN(0x00800000)!!
//and dead...
ML Rescue as autoexec.bin still works from the same card...

Not sure if that's my toolchain problem or what. For new stubs I even compared them against M50 ROM and I'm sure they are right.

[dfort]

Compiled fine here in Costa Rica -- no errors but no testing either.

On my downloads page.

[kitor]

Thanks. Same behavior unfortunately 
Time to dig into ML code then.

[aprofiti]

It probably locked due to firmware signature not corresponding.
I saw you didn't updated it yet in your repo.

You can also replace qprintf messages to print using uart if you prefer to not use qemu

[kitor]

Hmm, I was sure that digic6 branch had no signature testing. At least it was the case at some moment just when 1.1.0 update arrived

Then I'll remove signature check as I don't have qemu working for R yet (got path from Alex for m50, however this needs mods for R), and on-camera computation won't work at the moment (guess why )

[dfort]

Just saw this article about Canon's CCAPI (Camera Control Application Program Interface) software developer's kit. Don't know anything about it or if the R is one of the supported cameras but the RP is.

[EDIT] Looks like the cameras supported at this time are the RP, Canon 200D II / SL3 and Powershot SX70 HS.

[kitor]

It probably locked due to firmware signature not corresponding.

And bingo! After skipping check it runs like before (crashes LV). Added some blinking, LV crashes on bmp_vram_raw() as I have 4 blinks and then crash

Code: [Select]

static void hello_world()
{
    blink_led(1000);
    blink_led(1000);
    blink_led(1000);
    blink_led(1000);

    while (!bmp_vram_raw())
    {
        blink_led(200);
    }

    while(1)
    {
        blink_led(500);
        font_draw(100, 75, COLOR_WHITE, 3, "Hello, World!");
    }
}

Unfortunately when tracing bmp_vram_raw() i saw dark magic

[kitor]

At least I was able to get firmware signature updated and collect stack dump for Alex when he's back.

Would create MR, however I don't have rights for official repo...

Is there any built-in way to send some prints to log on card? Without qemu and still no display, UART using needle (literally as I still don't have proper cable) is quite annoying...

[histor]

Simple registering here - https://developers.canon-europe.com/developers/s/login/SelfRegister
gives you enough information.
Latest CCAPI supports EOS 250D, EOS RP (firmware 1.1.0 is required), PowerShot SX70 HS (firmware 1.1.0). Usual SDK support Eos R from version EDSDK v3.9.0, EOS RP – from EDSDK v13.10.0, EOS 250D – from EDSDK v13.10.20. These are consequent releases.
There were rumors that you can complete registration, fill the profile and get access to it after awhile.
If somebody needs version 2.14 (models up to EOS Kiss X70 / EOS 1200D / EOS REBEL T5 / EOS Hi / EOS M2) – it’s available in the net.

[srsa]

Simple registering here (...)
gives you enough information.

Those who wish to work on ML in the future may want to read the terms & conditions, especially the section "Confidentiality". Their stuff is not open source.

[dfort]

Would create MR, however I don't have rights for official repo...

Anyone can create a pull request on the main repo. I'm good with merging it as long as it doesn't disturb the other platforms.

[kitor]

Nevermind, tried to create PR from master repo instead of mine  But I'll wait a bit, since...

In the meantime I traced the problem to bmp_vram_info. I was able to hand-draw some lines on display using code from here:

https://www.magiclantern.fm/forum/index.php?topic=17360.510
and display buffers from RAM dump: 1100100 12ffc00

No related picture as I was too lazy to make one, however now I understand mostly that this structure holds addresses of both buffers

Code: [Select]

struct bmp_vram_info
{   
    struct MARV * vram1;        /* one of the two bitmap buffers - statically allocated? */
    struct MARV * vram2;        /* the other bitmap buffer */
    struct MARV * back_vram;    /* we need to write to the other one */
};
but I still don't know how to find this pointer from stubs.C / how Alex got one:

Code: [Select]

/** Bitmap **/
DATA_PTR(    0xFB1C,  bmp_vram_info) Funny enough, when set to exactly the same value as on M50 LV won't crash, but drawing won't work either.
DATA_PTR is relative to RAM?

[aprofiti]

Don't know if it's a valid way to find bump buffer without a ram dump or MMIO logs, but found the "SetDrawWait" reference while looking for 6d2 and 800d stubs.

Pointer inside the function's body appears to match the 200D and 77D dumps. Maybe you can try with EOS R?

[kitor]

Got another RAM dump and this makes sense, those are buffers I drawn into myself (dump starts from 0x40000000):

Code: [Select]

kitor@kitor-pc:Desktop$ xxd -e -s 0x0000FB1C -l 0x0C RAM.BIN     #bmp_vram_info
0000fb1c: 412ff900 414ff400 414ff400           ../A..OA..OA      #vram1, vram2, back_vram

kitor@kitor-pc:Desktop$ xxd -e -s 0x002ff900 -l 0x2C RAM.BIN    #MARV for 2ff900
002ff900: 5652414d 41100100 00000000 11060200  MARV...A........
002ff910: 00000400 000002aa 412ff91c 4d454d50  ........../APMEM
002ff920: 00000010 00000000 41100000           ...........A

kitor@kitor-pc:Desktop$ xxd -e -s 0x004ff400 -l 0x2C RAM.BIN    #MARV for 4ff400
004ff400: 5652414d 412ffc00 00000000 11060200  MARV../A........
004ff410: 00000400 000002aa 414ff41c 4d454d50  ..........OAPMEM
004ff420: 00000010 00000000 412ffadc           ........../A
So the problem seems to be somewhere deeper, as LV hangs (and ML throws exception) directly on bmp_vram_raw() call

[e] I don't understand something:

Code: [Select]

  uart_printf("bmp_vram_info %p \n", bmp_vram_info);
    uart_printf("bmp_vram_info[0] %p \n", bmp_vram_info[0]);
    uart_printf("vram1 %p \n", bmp_vram_info[0].vram1);
    uart_printf("vram2 %p \n", bmp_vram_info[0].vram2);
    uart_printf("back_vram %p \n", bmp_vram_info[0].back_vram);
    uart_printf("bmp_marv, should match above %p \n", bmp_marv());

Code: [Select]

bmp_vram_info 0xfb1c
bmp_vram_info[0] 0x1
vram1 0x1
vram2 0x4fc0278
back_vram 0x41100000
bmp_marv, should match above 0x1


[kitor]

Oh, Hai!


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

I don't understand this at all. Seems that dump_file shifts down ram offsets by 0X10?! explanation below
bmp_vram_info sits at 0xFB2C, not 0xFB1C. How I found this?

Code: [Select]

for(uint32_t * i = 0x40000000; i < 0x80000000; i+=1){
        if(*i == 0x412ff900) uart_printf("vram1 %p \n", i);
        if(*i == 0x414ff400 ) uart_printf("vram2 %p \n", i);
    }
and a few moments later

Code: [Select]

vram1 0x4000fb2c
vram2 0x4000fb30
vram2 0x4000fb34
But what's werid MARV structures sits exactly where I found them in a dump:

Code: [Select]

bmp_vram_info 0xfb2c
bmp_vram_info[0] 0x412ff900
vram1 0x412ff900
vram2 0x414ff400
back_vram 0x414ff400
yup, that's shows my desperation 

@dfort - new MR coming in a moment

[edit]
OK, now I know what happened. Our initial dump on 1.1.0 has been shifted. I got MARVs from new dump, bmp_vram_info I was checking on old one all the time... working on pointers at 2AM is a bad idea.

[dfort]

Great work @kitor -- PR merged.

[Indy]

Hi,

FYI, Canon has changed the way signature and encryption is done for EOS R and EOS RP (FIR version 5).

Previous versions were:
https://magiclantern.fandom.com/wiki/Firmware_file
https://magiclantern.fandom.com/wiki/Fir_Security

As soon as debugging EOS R or RP will be possible within QEmu, I'll continue my investigations started with Alex. He owns holidays after giving years of time to ML.

Kind regards
Indy

[kitor]

A bit of ML offtopic:

1.2.0 seems to remove banding issues:
https://www.canonrumors.com/firmware-v1-2-0-seems-to-have-solved-a-banding-issue-that-was-present-in-the-canon-eos-r/

Ladies and Gentlemen! WE HAVE DONE IT!! Thank you so much to the many of you who gave feedback, shared my videos, posted in forums and relayed the information you received from Canon, I can confirm that Firmware update 1.2.0 resolves the banding issue I reported back in November on the Canon EOS R!

Tamron 70-200 G2 works great with R
Tired of waiting for RF 70-200 (and in need for one soon) I wanted to pick used 2.8L IS II USM. But found that Tamron presented not so long ago 2nd gen of their lineup (and new SP 70-200mm F/2.8 Di VC USD G2 is roughly the same price as used 2.8L IS II). As I have good contact with one camera store, I played a little with this lens via basic EF-RF adapter and it worked flawlessly, AF was fast and accurate, no problems with VR (shots like 1/30 on 200mm).
Interesting (and not found in manual) feature is that tripod mount will mount directly to Arca Swiss compatibile Quick Releases, what I found by accident.

Sample full-res jpeg (from raw, without LR lens corrections; 200mm/2.8 ISO 100): https://kitor.pl/eos_r/img/r_tamron_example.jpg
This is how this combo looks:


As for missing control ring on EF lenses, I'm using back-button focus, thus I have exposure lock on half-shutter. So i set exp-lock button + upper dial as ISO change. Works much better than fighting with touch bar and saves a lot of money on adapter with control ring.

[kitor]

As soon as debugging EOS R or RP will be possible within QEmu, I'll continue my investigations started with Alex. He owns holidays after giving years of time to ML.

https://www.magiclantern.fm/forum/index.php?topic=2864.msg215604#msg215604

There is a patch for M50 here; IIRC it worked on R with minimal changes. Will clean them up for committing, but I think it will happen after bringing the current state into mainline.

I'm not competent enough to do those 'minimal changes' myself unfortunately, at least not without any hints where to look.

[oc_masta]

Can someone with far more intelligence than me, explain the high level concept of what needs doing and how it works.

Is it a hunt for the memory addresses than respond to the things we need. LED at address xxxxxxx, memory for sensor data at xxxxxx ??

I'm genuinely very curious and would love to learn more if someone can break it down just a little.
Cool Stuff!

[kitor]

Up to now, mostly like you described.

Is it a hunt for the memory addresses than respond to the things we need. LED at address xxxxxxx, memory for sensor data at xxxxxx ??

But not only for hardware memory addresses, but also for location of needed DryOS functions that we need to call. In 'normal' programming you just include headers for some library and use it. Here you need to find that stuff in disassembled ROM first, understand how it works, what parameters it can take (and thus how to call it). This is already mostly done with previous cameras, so you just need to find proper memory location that holds your needed function. Later also find how to 'hook' into Canon tasks to get data from them, etc.

And DryOS (and low level stuff - new Digic processors) changes with time. That's why Alex did 'fishy' M50 port that allows ML menu access, but it breaks things for older devices so he decided not to push code until he sorts this out.

[sast]

Hello,
is there somebody, who is still working on ML for Canon EOS R? 

Before I was using ML on the Canon 5D III. ML gave me an perfectin handling of the camera.
I don't now how to do all the things on the EOS R without ML (f. e. Intervalometer, Motion detection, the modules). 

Best regards from Germany