Canon EOS R / RP

Started by SpenceM, September 05, 2018, 03:09:27 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

a1ex

Quote from: kitor on January 10, 2019, 08:13:25 AM
- 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?


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  ?


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.


kitor

Grip communication was my mistake, this pin is used by grip itself unfortunately.
Anyway,
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  8)
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

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!

Dry[WarpPUX]> sysvers
SystemIF 1.01
DRYOS version 2.3, release #0060+p4
MACH 0.51
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

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.
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

Danne


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).

Quote from: kitor on February 14, 2019, 08:03:51 AM... 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 :D

Walter Schulz


Indy


kitor

Quote from: a1ex on February 14, 2019, 06:21:17 PMInitial 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:
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.


QuoteAnd I didn't have to hold any needle on the UART connector
Yup. Fortunately with bootflag enabled, now RX is sufficient.
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

a1ex

This camera has 2 GiB of RAM 8)

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:

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

Quote from: kitor on February 15, 2019, 07:31:14 AM
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:
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 ?
There is no knowledge that is not power

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 :(
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

civita

Quote from: civita on February 12, 2019, 08:43:03 AM
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).
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.

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.
Too many Canon cameras.
If you have a dead R or RP mainboard (e.g. after camera repair) and want to donate for experiments, I'll cover shipping costs.