Canon EOS R / RP

[a1ex]

- There's a single (unused in grip) pin that shows some digital communication on camera start, photo shots and sometimes random "messages" on idle. Signal is active-low 3.3v, around 50kHz, but no luck trying to treat is as 57600 serial communication.

Here's my attempt at manually identifying the message format and timings. It appears to be UART, bit time about 18.5-19 microseconds, so about 52000-54000 baud. Couldn't identify any plain text in these short fragments, though.

[TiagoSilva1987]

Hello, Where can i download the Magic lantern firmware update for EOS R?

[Walter Schulz]

You have to find the tree ...

[TiagoSilva1987]

It´s under development?

[Walter Schulz]

What difference does it make? ML development follows no schedule.
2 years ago a generous offer was made: A 750D (free of charge) for anyone willing and able to port it. Nobody claimed it ...

My advice:
If there is no ML for your cam act like there will be no ML for your cam ever.

[TiagoSilva1987]

Where can i download RLEDID14.FIR  ?

[jga]

Firmware 1.1 has been released: https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-r.aspx?type=firmware

[civita]

A new firmware regarding EOS R was released!

https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-r.aspx?type=firmware

Canon EOS R Firmware v.1.1.0 changes:

• Support for "continuous shooting" is available when "silent shutter" has been enabled.
• Corrects a phenomenon in which an error may occur if there is a large number of files in a specific format on the memory card.
• Corrects a phenomenon in which an error may occur when silent shutter has been enabled.
• Corrects a phenomenon in which horizontal linear noise may occur when using specific lenses together with certain recording image quality settings.
• Corrects a phenomenon in which the information displayed in the viewfinder may become abnormal.

[Sapporo]

Firmware 1.1.0 is release from Canon now https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-r.aspx?type=firmware&firmwaredetailid=tcm:13-1776855

[kitor]

Grip communication was my mistake, this pin is used by grip itself unfortunately.
Anyway,

Code: [Select]

Battery close!
RSTFLG : 0010
E1ON
openBattery
/USB_DET undetected
setCCSnkRst

MON>>>All task Initialize
================SD send recode 0 0
WakeupReason from ICU: 0x67,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x02,Hello from MPU 

[a1ex]

... the "behind the scenes" picture:



The firmware update... unfortunately wasn't helpful. None of my previous tricks worked with it. I'm still wondering why some of my previous test FIRs resulted in green screen, but I'm now 100% sure we did not execute any code on the camera. The green screen was likely a bug in Canon's FIR loading routine, or something like that.

The good news - kitor identified two UART ports: one at 3.3V, used by the MPU (outputs the log from above) and another at 1.8V, likely used by the main CPU (same voltage level on DIGIC 6). The latter needs some level shifting, but - at least on previous models - it has everything we need to enable the boot flag and explore around.

Worst case - ML on EOS R may require some hardware hacking in order to install it (like in the above picture). No big deal, right? I mean, you need a lot more knowledge to be able to use it

Also forgot to mention - I've got high-res PCB pictures from the Lensrentals teardown. If any of you can identify anything from here, please write it down.

[kitor]

Oh hello!

Code: [Select]

Dry[WarpPUX]> sysvers
SystemIF 1.01
DRYOS version 2.3, release #0060+p4
 MACH 0.51

[kitor]

If you missed the news:
https://twitter.com/_kitor/status/1095807058358796290

However executed via bootloader CLI, and took a lot of pain to debug this for Alex and me. Would be much easier if I had proper FPC for this debug connector; had to hold needle to TX pad all the time by hand.

[Danne]

Geniuses.

[a1ex]

Initial notes:

- Encryption changed. Wasn't able to look inside the firmware update. Unable to create FIR files for this camera.
- Other than that, bootloader and overall code structure look familiar.
- Portable ROM dumper worked after some minor tweaking.
- Display buffer in bootloader context: 1024x682, otherwise like M50 (UYVY).
- LED address: 0xD01300D4 (0xD01300D8/DC maybe also valid).
- CPU info: identical to M50/SX70.
- Early startup: identical to M50 (yes, this entire block is identical, same stub addresses).
- Can jump to main firmware (with this trick). Autoexec.bin is loaded on both CPU cores (maybe there are more?)
- Can save log files and dump ROM from main firmware.
- Overall, very similar to M50, but closer to "classic" EOS firmware (i.e. less of a PowerShot). Also has a MPU.
- Most of the code runs from ROM, very much like M50.
- Source code committed to digic6-dumper branch (initial platform directory) and recovery branch (portable ROM dumper, CPU info).

... and took a lot of pain to debug this for Alex and me.

It's true, it took us many hours of debugging, but compared to other models, this was quite easy. It definitely wasn't a matter of staring at the code for hours or days with no idea what to do next (cough 7D, EOSM shutter bug, 80D io_trace and many others). Yes, the camera was stubborn, but there was visible progress every few dozens of minutes (except during our breaks).

That was partly because most of the hard work was already done for M50 and all other earlier models, so it was mostly a matter of identifying what to tweak. And because Canon didn't change *that* much (except for the FIR encryption). And I didn't have to hold any needle on the UART connector

[Walter Schulz]

- Encryption changed.

Boy, really hate to read that!

[Indy]

Boy, really hate to read that!

Working on it with Alex :-)

[kitor]

Initial notes:

I'll add here
- LV is taking so many resources, that it's loosing input on UART. Going into menu makes it reliable + camera output is a few times faster.

For adventurous (as it need's 1v8 UART or 3v3 with voltage divider on TX), simple bootloader dumper:

Code: [Select]

import serial
import sys

start = int('0xE0000000',16)
end = int('0xE0040000',16)
step = int('0x1000',16)
current = start

with serial.Serial('/dev/ttyS6', 115200, timeout=1) as ser, open("dump2.log", 'w', encoding='utf-8') as logfile:
  while True:
    line = ser.readline()
    if line is not b'':     #skip timeouts
      decoded = line.replace(b'\r\n',b'').decode("UTF-8") #bytes to string
      print(decoded)
      logfile.write(decoded + '\n')

    if b"Mode ON" in line:       #enter interactive shell
      ser.write(b'akashimorino\r\n')
    elif b"K424[1]>" in line:    #prompt, start data dump
      if current > end:
        sys.exit(0)
      ser.write(str.encode("d " + hex(current) + " " + hex(step) + "\r\n"))
      current += step
Of course you need to reassemble this data into binary form yourself.

UART location/pinout is here.

And I didn't have to hold any needle on the UART connector

Yup. Fortunately with bootflag enabled, now RX is sufficient.

[a1ex]

This camera has 2 GiB of RAM

Canon already struggled to pack this amount of RAM into the 32-bit address space: only the first GiB is visible as regular ("cacheable") memory. The second GiB is only visible as "uncacheable", and - just a guess - probably used exclusively by DMAs (image processing etc). Then, there are 512 MiB reserved from peripherals (addresses starting with C and D), 256 for the main ROM (starting with E), 256 for the slow (serial?) flash (starting with F, but apparently unused on R), and a couple of small regions overlapped here and there (DF - probably some sort of TCM; BFE - something with special meaning, etc).

MMU configuration is very similar to DIGIC 7:

Code: [Select]

00001000-00001FFF -> 00000000-00000FFF (-1000) O:NCACH I:WB,WA  P:RW       [ CPU0 only ]
00001000-00001FFF -> 00001000-00001FFF (   +0) O:NCACH I:WB,WA  P:RW       [ CPU1 only ]
00002000-3FFFFFFF -> 00002000-3FFFFFFF (   +0) O:NCACH I:WB,WA  P:RW       [ cacheable RAM - only the first GiB ]
40000000-BFFFFFFF -> 40000000-BFFFFFFF (   +0) O:NCACH I:NCACH  P:RW       [ uncacheable RAM - 2 GiB ]
C0000000-C2FFFFFF -> C0000000-C2FFFFFF (   +0) Device           P:RW XN    [ MMIO area ]
C4000000-C4FFFFFF -> C4000000-C4FFFFFF (   +0) Device           P:RW XN
C8000000-CAFFFFFF -> C8000000-CAFFFFFF (   +0) Device           P:RW XN
CC000000-CDFFFFFF -> CC000000-CDFFFFFF (   +0) Device           P:RW XN
D0000000-D0FFFFFF -> D0000000-D0FFFFFF (   +0) Device           P:RW XN
D2000000-D2FFFFFF -> D2000000-D2FFFFFF (   +0) Device           P:RW XN
D4000000-D5FFFFFF -> D4000000-D5FFFFFF (   +0) Device           P:RW XN
D7000000-D9FFFFFF -> D7000000-D9FFFFFF (   +0) Device           P:RW XN
DE000000-DEFFFFFF -> DE000000-DEFFFFFF (   +0) Device           P:RW XN
DF000000-DFFFFFFF -> DF000000-DFFFFFFF (   +0) O:NCACH I:WB,WA  P:RW       [ TCM? ]
E0000000-E7FFFFFF -> E0000000-E7FFFFFF (   +0) O:WB,WA I:WB,WA  P:R        [ main ROM ]
E8000000-EFFFFFFF -> E8000000-EFFFFFFF (   +0) Strongly-ordered P:R  XN    [ ? ]
F0000000-F7FFFFFF -> F0000000-F7FFFFFF (   +0) O:WB,WA I:WB,WA  P:R        [ only used on M50; at least on DIGIC 7, it's much slower than main ROM ]
F8000000-FFFFFFFF -> F8000000-FFFFFFFF (   +0) Strongly-ordered P:R  XN    [ ? ]

i.e.
- 00000000-00000FFF virtual: unavailable (likely used to catch null pointer errors)
- 00001000-00001FFF virtual: private page for each of the two cores (mapped to either 00000000-00000FFF or 00001000-00001FFF physical)
- other than that, flat mapping everywhere (with different permissions and attributes)
- some regions in the MMIO (Device) areas are unavailable; minor differences from DIGIC 7 in the C0000000 - DEFFFFFF range.
- anything above 0x40000000 (until BFDFFFFF) is uncacheable; this is the main RAM
- the first GiB of RAM is also visible as cacheable: 00002000-3FFFFFFF

[Mike Tornado]

I'll add here
- LV is taking so many resources, that it's loosing input on UART. Going into menu makes it reliable + camera output is a few times faster.

For adventurous (as it need's 1v8 UART or 3v3 with voltage divider on TX), simple bootloader dumper:

Code: [Select]

import serial
import sys

start = int('0xE0000000',16)
end = int('0xE0040000',16)
step = int('0x1000',16)
current = start

with serial.Serial('/dev/ttyS6', 115200, timeout=1) as ser, open("dump2.log", 'w', encoding='utf-8') as logfile:
  while True:
    line = ser.readline()
    if line is not b'':     #skip timeouts
      decoded = line.replace(b'\r\n',b'').decode("UTF-8") #bytes to string
      print(decoded)
      logfile.write(decoded + '\n')

    if b"Mode ON" in line:       #enter interactive shell
      ser.write(b'akashimorino\r\n')
    elif b"K424[1]>" in line:    #prompt, start data dump
      if current > end:
        sys.exit(0)
      ser.write(str.encode("d " + hex(current) + " " + hex(step) + "\r\n"))
      current += step
Of course you need to reassemble this data into binary form yourself.

UART location/pinout is here.

Yup. Fortunately with bootflag enabled, now RX is sufficient.

Did you try sht_memoryread2 B:/K424_00.bin 0xE0000000 0x00040000 ?

[kitor]

No, was working with what Alex provided to me. While I have *some* background in hw hacking (was working on jlime linux port to bsquare power handheld... 10 years ago), that's my first entry into Canon's world (only messed with ML 5d2 audio code before).
Printing things over serial seems to be safer too (considering still have 4/5 of loan to pay and disassembled camera already  )

[e]
sht_memoryread2 is missing

[civita]

A new firmware regarding EOS R was released!

https://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos-r.aspx?type=firmware

Canon EOS R Firmware v.1.1.0 changes:

• Support for "continuous shooting" is available when "silent shutter" has been enabled.
• Corrects a phenomenon in which an error may occur if there is a large number of files in a specific format on the memory card.
• Corrects a phenomenon in which an error may occur when silent shutter has been enabled.
• Corrects a phenomenon in which horizontal linear noise may occur when using specific lenses together with certain recording image quality settings.
• Corrects a phenomenon in which the information displayed in the viewfinder may become abnormal.

Not sure is it helpful or not: Canon has already updated the firmware for the RP. Ver. 1.1.0  for windows and MAC
 
1. Support for Camera Control API (CCAPI)* function, for software developers, has been added.


https://www.usa.canon.com/internet/portal/us/home/support/details/cameras/eos-dslr-and-mirrorless-cameras/mirrorless/eos-rp?subtab=downloads-firmware

[kitor]

If anyone already had his hands on RP and have USB UART that's able to work with 1v8 levels, you may try to dump the bootloader using my previous code.
https://twitter.com/_kitor/status/1095956664287555584
UART will be probably hidden under thumb rubber, as it has same style connector and very similar location to R.

So far I had no time to play more with R unfortunately.
BTW - if anyone knows where I can get my hands on 0.4mm pitch FFC cable (8 pin is needed for R and probably RP UART), please send me PM. Other devices that may use this internally are also a valid option (to harvest from dead / get spare parts).

[Walter Schulz]

Are you sure about 0.4mm?

[kitor]

Almost. Standard 0.5mm is too wide, I wasn't able to connect both TX and RX without shorting one of them to next pin (GND). I measured piece of FPC cut to fit into connector and divided into 8 pins, got roughly this 0.4mm pitch.