Author Topic: Canon EOS R / RP (Read 193757 times)

coon · « **Reply #150 on:** September 18, 2020, 07:21:02 PM »

Interesting. Shutter count also broken here or has some encoding scheme.
Thanks for providing this!

Could you edit your post and wrap the XML output into code blocks like this?

[code]
<xml code here>
[/code]

It's easier to read like this.

It meight be interesting getting a dump of a fresh RP with 0 shots taken to find out the origin value. But it will be very hard to find such I guess...

c_joerg · « **Reply #151 on:** September 18, 2020, 07:41:48 PM »

Quote from: coon on September 18, 2020, 07:21:02 PM

Interesting. Shutter count also broken here or has some encoding scheme.

Looks like this...
But only on RP.

Quote from: coon on September 18, 2020, 07:21:02 PM

It meight be interesting getting a dump of a fresh RP with 0 shots taken to find out the origin value.

Yes, would be intresting...
All my M's and 6D had 0 on the biginning.

coon · « **Reply #152 on:** September 19, 2020, 07:57:31 PM »

Executed the following Canon Basic script from srsa on EOS RP (https://www.magiclantern.fm/forum/index.php?topic=25305.msg231075#msg231075):

Code: [Select]

private sub Initialize()
  ExecuteEventProcedure("smemShowFix")
  dumpf()
end sub

Got the following memory map:

Code: [Select]

[RSC] --- Common Lower ----
[RSC] LIME_HEAP                0x00000000 0x00000000         0 [Cacheable!
[RSC] MOVIE_CFILTER_SEED       0x00000000 0x00000000         0 [Cacheable!
[RSC] OMAR COM                 0x00000000 0x00000000         0 [Cacheable!
[RSC] ENGINE_MIRROR            0x00000000 0x00000000         0 [Cacheable!
[RSC] SITTERVCODEC WORK        0x4048C000 0x00207000   2125824
[RSC] DCFNO                    0x40693000 0x00004000     16384
[RSC] FILE HEADER              0x40698400 0x00100000   1048576
[RSC] DAF_WORK                 0x40798400 0x00051000    331776
[RSC] FACTORY/TVAFDEBUG        0x41585000 0x00080000    524288
[RSC] VSHADING_COMP_WORK       0x41682000 0x0002CC00    183296
[RSC] DARKCUR_COMP_WORK        0x416AEC00 0x00025400    152576
[RSC] LIME                     0x41800000 0x00500000   5242880
[RSC] NETWORK_HEAP             0x41D00000 0x00300000   3145728
[RSC] ZICO                     0x42000000 0x00180000   1572864
[RSC] APROC                    0x42180000 0x00021000    135168
[RSC] ARIMA                    0x421A1000 0x0006C000    442368
[RSC] SHIRAHAMA                0x4220D000 0x0002E000    188416
[RSC] RENDERING WORK           0x4233B000 0x00D00000  13631488
[RSC] JOB OBJECT               0x430D1000 0x00320000   3276800
[RSC] FIX                      0x43D18400 0x00200000   2097152
[RSC] TUNE                     0x43F18400 0x00200000   2097152
[RSC] TUNE2                    0x44118400 0x00600000   6291456
[RSC] FANCING_WORK             0x44718400 0x001C2000   1843200
[RSC] CAPTURE_WORK             0x449DA400 0x056E0000  91095040
[RSC] DAF_RAW                  0x7F4BB000 0x0083B800   8632320
[RSC] DANCING                  0x7FCF6800 0x00309800   3184640

[RSC] --- Normal ----
[RSC] LV_SERVO_WORK            0x00000000 0x00000000         0 [Cacheable!
[RSC] LV_AE_WORK               0x41605000 0x0007D000    512000
[RSC] EXMEM3_AREA              0x4A0BA400 0x04455C00  71654400
[RSC] TWAIN_AREA_L             0x5B710000 0x00300000   3145728
[RSC] YUV 2nd_L                0x5BA10000 0x04520000  72482816
[RSC] SS_U                     0x60000000 0x077B0000 125501440
[RSC] YUV 1st_U                0x677B0000 0x03D40000  64225280
[RSC] YUV 2nd_U                0x6B4F0000 0x04520000  72482816
[RSC] SUSANYUV                 0x6FA10000 0x048C0000  76283904
[RSC] YUV Thumb                0x742D0000 0x02B93000  45690880
[RSC] DECMEM1_AREA_U           0x76E63000 0x03480000  55050240
[RSC] EXMEM3_AREA_2            0x7A2E3000 0x051D8000  85819392
[RSC] TWAIN_AREA_U             0x80000000 0x00300000   3145728
[RSC] CAPMEM1_AREA_U           0x80300000 0x03480000  55050240
[RSC] ALGS_AREA_1U             0x83780000 0x03480000  55050240
[RSC] ALGS_AREA_2U             0x86C00000 0x03480000  55050240
[RSC] EXALGS_AREA_U            0x9A700000 0x032A0000  53084160
[RSC] SS_L                     0xA0000000 0x077B0000 125501440
[RSC] YUV 1st_L                0xA77B0000 0x03D40000  64225280
[RSC] CAPMEM1_AREA_L           0xAB4F0000 0x03480000  55050240
[RSC] DECMEM1_AREA_L           0xAE970000 0x03480000  55050240
[RSC] EXALGS_AREA_L            0xB5270000 0x032A0000  53084160
[RSC] ALGS_AREA_2L             0xB8510000 0x03480000  55050240
[RSC] ALGS_AREA_1L             0xBB990000 0x03480000  55050240

[RSC] --- Movie ----
[RSC] CINEMA_FILTER_WORK       0x00000000 0x00000000         0 [Cacheable!
[RSC] MOVIE_RECYUV             0x00000000 0x00000000         0 [Cacheable!
[RSC] AUDIO WORK               0x435C0400 0x00258000   2457600
[RSC] MOVIE_STREAM             0x4E510000 0x0FC00000 264241152
[RSC] LV_WORK_L                0x5E150000 0x01EB0000  32178176
[RSC] LV_WORK_U                0x60000000 0x04F00000  82837504
[RSC] MOVIE_RECWORK_U          0x64F00000 0x01A00000  27262976
[RSC] MOVIE_RECWORK_L          0xAB4F0000 0x0FC40000 264503296

[RSC] --- Play ----
[RSC] SLIDE_SHOW_WORK          0x5DEDA800 0x01FA4000  33177600
[RSC] IMGPLAY_WORK             0x60000000 0x05400000  88080384
[RSC] MOVIE_PLAYWORK           0xA0000000 0x176D0000 393019392

[RSC] --- Multishot ----
[RSC] HDR/GIS_MOVIE_RECWORK    0x00000000 0x00000000         0 [Cacheable!
[RSC] HDR/GIS_MOVIE_RECYUV     0x00000000 0x00000000         0 [Cacheable!
[RSC] HDR/GIS_KAITO_YUV        0x00000000 0x00000000         0 [Cacheable!
[RSC] HDR/GIS_LV_SERVO_WORK    0x00000000 0x00000000         0 [Cacheable!
[RSC] HDR/GIS_FLEXIBLE_MEM3_1  0x00000000 0x00000000         0 [Cacheable!
[RSC] HDR/GIS_FLEXIBLE_MEM3_2  0x00000000 0x00000000         0 [Cacheable!
[RSC] HDR/GIS_AUDIO WORK       0x435C0400 0x00258000   2457600
[RSC] HDR/GIS_EXMEM3_AREA      0x4A0BA400 0x04455C00  71654400
[RSC] HDR/GIS_MOVIE_STREAM     0x4E510000 0x0FC00000 264241152
[RSC] HDR/GIS_COMP_WORK        0x505F0000 0x28A00000 681574400
[RSC] HDR/GIS_YUV 2nd-1        0x5BAE0000 0x04520000  72482816
[RSC] HDR/GIS_SLIDE_SHOW_WORK  0x5DEDA800 0x01FA4000  33177600
[RSC] HDR/GIS_LV_WORK_L        0x5E150000 0x01EB0000  32178176
[RSC] HDR/GIS_LV_WORK_U        0x60000000 0x04F00000  82837504
[RSC] HDR/GIS_SS-2             0x60000000 0x077B0000 125501440
[RSC] HDR/GIS_IMGPLAY_WORK     0x60000000 0x05400000  88080384
[RSC] HDR/GIS_YUV 1st-2        0x677B0000 0x03D40000  64225280
[RSC] HDR/GIS_YUV 2nd-2        0x6B4F0000 0x04520000  72482816
[RSC] HDR/GIS_SUSAN_YUV        0x6FA10000 0x048C0000  76283904
[RSC] HDR/GIS_YUV Thumb        0x742D0000 0x02B93000  45690880
[RSC] HDR/GIS_EXMEM3_2         0x7A2E3000 0x051D8000  85819392
[RSC] HDR/GIS_WORK4            0x80300000 0x03480000  55050240
[RSC] HDR/GIS_WORK2            0x80300000 0x03480000  55050240
[RSC] HDR/GIS_MOVIE_PLAYWORK   0xA0000000 0x176D0000 393019392
[RSC] HDR/GIS_SS-1             0xA0000000 0x077B0000 125501440
[RSC] HDR/GIS_YUV 1st-1        0xA77B0000 0x03D40000  64225280
[RSC] HDR/GIS_WORK3            0xAB4F0000 0x03480000  55050240
[RSC] HDR/GIS_WORK1            0xAB4F0000 0x03480000  55050240

[RSC] --- Indev ----
[RSC] INDEV_SS-1               0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_YUV 1st-1          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_YUV 2nd-1          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_BASIC              0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_SS-2               0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_YUV 1st-2          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_YUV 2nd-2          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_YUV Thumb          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_SUSAN_YUV          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_KAITO_YUV          0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_MOVIE_REC_YUV      0x00000000 0x00000000         0 [Cacheable!
[RSC] INDEV_EXMEM3_AREA        0x4A0BA400 0x04455C00  71654400
[RSC] INDEV_YUV_OUT            0x51486000 0x047C7000  75264000
[RSC] INDEV_TRIMING_VIEW_WORK  0x56550000 0x02200000  35651584
[RSC] INDEV_YUV_IN             0x58750000 0x05780000  91750400
[RSC] INDEV_SLIDE_SHOW_WORK    0x5DEDA800 0x01FA4000  33177600
[RSC] INDEV_IMGPLAYWORK        0x60000000 0x05400000  88080384
[RSC] INDEV_WORK               0x65400000 0x10B00000 279969792
[RSC] INDEV_EXMEM3_AREA        0x7A2E3000 0x051D8000  85819392

[RSC] --- DP ----
[RSC] DP_SS-1                  0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV 1st-1             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV 2nd-1             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV_IN                0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV_OUT               0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_MULTI_CHUNK           0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_WORK                  0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_SINGLE_CHUNK          0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_SS-2                  0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV 1st-2             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV 2nd-2             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_YUV Thumb             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_SLIDE_SHOW_WORK       0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_SUSAN_YUV             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_KAITO_YUV             0x00000000 0x00000000         0 [Cacheable!
[RSC] DP_MOVIE_REC_YUV         0x00000000 0x00000000         0 [Cacheable!

RP has 2GB of RAM.

coon · « **Reply #153 on:** September 22, 2020, 12:48:48 AM »

Got portable dumper working on RP by finding the card init stub (thx to names_are_hard for some help!):

Interestingly the firmware file sizes compared to Canon Basic dumper are different.

Portable Dumper:
ROM0.bin: 32MB
ROM1.bin: 16MB

Canon Basic Dumper:
gang100.bin: 32MB
gang200.bin: 32MB

However, both firmware dumps are binary equal. (ROM0.bin == gang100.bin, ROM1.bin == gang200.bin), while ROM0.bin / gang100.bin have some usual noise in the last section of the files.

File content of gang200.bin from 16MB on does only consist of 0xFF values so the real size of it seems to be 16MB.

coon · « **Reply #154 on:** October 01, 2020, 10:06:07 PM »

I am now able to blink the SD card LED of RP v1.5.0 via Canon Basic:

Code: [Select]

private sub Initialize()
    System.Create()

    ExportToEventProcedure("LedOn",0xE0587BC5)
    ExportToEventProcedure("LedOff",0xE0587BE5)

    For i = 1 To 3
      LedOn(1)
      SleepTask(500)
      LedOff(1)
      SleepTask(500)
    Next
end sub

However, if I try to use LedOn and LedOff stubs on the portable dumper like this:

Code: [Select]

void (*LedOn)(int unknown)  = 0xE0587BC5;
void (*LedOff)(int unknown) = 0xE0587BE5;

while (true) {
  LedOn(1);
  busy_wait(500);
  LedOff(1);
  busy_wait(500);
}

It will crash on LedOn() call. It seems these functions do need some initialization before they can be used.

Walter Schulz · « **Reply #155 on:** October 01, 2020, 10:24:59 PM »

IANAP but are you able to run Canon Basic scripts in QEMU?

coon · « **Reply #156 on:** October 01, 2020, 10:29:40 PM »

I don't know how. Canon basic may be initialized as well before. We are not very far with qemu yet. We are only able to run the portable dumper and we can run the dump_task of digic6 dumper. d6 dumper does not run on real hw yet.

coon · « **Reply #157 on:** October 01, 2020, 11:43:10 PM »

We just had a breakthrough. Digic 6 dumper does work on RP! We can now start tasks and run our own code side by side to canon gui:

The code I am executing:

Code: [Select]

static void DUMP_ASM dump_task()
{
  void (*LedOn)(int unknown)  = 0xE0587BC5;
  void (*LedOff)(int unknown) = 0xE0587BE5;

  while (true) {
    LedOn(1);
    msleep(500);
    LedOff(1);
    msleep(500);
  }
}

IDA_ML · « **Reply #158 on:** October 02, 2020, 07:42:16 AM »

This is very exciting news. Congratulations!

kitor · « **Reply #159 on:** October 02, 2020, 09:53:17 AM »

We have a blink. I repeat, we have a blink!

Hello world coming soon confirmed?

coon · « **Reply #160 on:** October 02, 2020, 08:34:57 PM »

Of course.

Next task is getting control over the display. Shouldn't be too hard, since portable dumper already guesses the required addresses correctly.

Nigel95 · « **Reply #161 on:** October 02, 2020, 08:54:42 PM »

Amazing keep up the good work!!

reddeercity · « **Reply #162 on:** October 03, 2020, 01:44:23 AM »

I haven't bought a camera yet but the EOS R with this break though is looking tempting to bought one , great job !

kitor · « **Reply #163 on:** October 03, 2020, 10:43:55 AM »

Quote from: reddeercity on October 03, 2020, 01:44:23 AM

I haven't bought a camera yet but the EOS R with this break though is looking tempting to bought one , great job !

Not that I had Hello World running on R a year ago

https://www.magiclantern.fm/forum/index.php?topic=22770.msg215750#msg215750

Just porting it further is 'above my paygrade'.

However, if there's a progress made on RP (and I have high hopes in @coon work, considering his experience as listed on twitter), I will attempt to port his work to R.

coon · « **Reply #164 on:** October 04, 2020, 01:28:11 PM »

I have also some issues on finding the vram_info struct location at the moment. I have found the location where it *should* be, based on the code of 200D but I cannot see valid pointers to MARV structs there so I am still investigating...

Quote from: kitor on April 28, 2019, 12:55:12 PM

[...] 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); }

Wow, now that's an aggressive method

. Dereferencing thousands of invalid pointers didn't crash your cam?
If nothing helps and if I should lose all of my hope I also meight doing it that way. Just want to mention that calling

Code: [Select]

dump_file("RAM41.BIN", 0x80000000, 0x40000000);

Didnt started to dump and made my led blink in a different pattern suddenly, so it brought my camera in some glitched state which was fixed after a battery pull.

srsa · « **Reply #165 on:** October 04, 2020, 01:54:04 PM »

Quote from: coon on October 04, 2020, 01:28:11 PM

Code: [Select]
dump_file("RAM41.BIN", 0x80000000, 0x40000000);
Didnt started to dump and made my led blink in a different pattern suddenly, so it brought my camera in some glitched state which was fixed after a battery pull.

Try dumping it in a buffered way, not directly.

coon · « **Reply #166 on:** October 05, 2020, 12:56:42 AM »

Quote from: coon on October 04, 2020, 01:28:11 PM

Dereferencing thousands of invalid pointers didn't crash your cam?

Nevermind, I read your code wrong. You are basically scanning the whole memory for the MARV pointers. I've also done that but "offline" on a 1GB RAM dump and found a structure which meight be the vram_info struct. However, the backbuffer pointer does always seem to be zero!? I need to do some deeper investigation here.

Addresses in this struct seem always to be the same, even after battery pull:

Code: [Select]

0x41100100
0x41340400

By inspecting the buffers at that place I have verified, that I am on the right track. Both buffers contain the same images and have a resolution of 736x480, which matches the resolution of the LCD screen. names_are_hard did some analysis on the image format and found out that it is UYVYAA with JFIF colourspace:

By searching the memory for more MARV signatures I have found two other buffers with a resolution of 960x540, which matches the resolution of the EVF. For some reason the image format is BGRA here:

Code: [Select]

0x2C1E100
0x2E18600

The first buffer is for menu and general overlays:

The second buffer holds the focus point overlay:

names_are_hard has written some python scripts to decode the different vram buffer format. I will merge them into some auto vram image finder / extractor tool and publish it somewhere. Probably here.

There is still a 736x480 buffer left at

Code: [Select]

0x9F624800

Which I haven't dumped yet, because lack of time. I will let you know what's inside soon.

coon · « **Reply #167 on:** October 06, 2020, 12:30:25 AM »

I don't get the colors right yet, but I can draw proper shapes on the screen. We have debug output now.

nikfreak · « **Reply #168 on:** October 06, 2020, 08:17:38 PM »

Keep up the good work.

garry23 · « **Reply #169 on:** October 06, 2020, 08:33:02 PM »

I’ve been watching these developments with interest and much ignorance, but with high hopes.

What I think I see is a ‘quick’ way to get a scripting environment running, ie before, hopefully, we have a rich/full ML environment up and running, ie with menus etc.

Assuming, once again in ignorance, a Basic scripting API can access/control, ie set/get, key functions, eg shutter, aperture, ISO and, ideally, focus distance etc, such a scripting environment will be very handy for photographers.

I could imagine converting major parts of my DOFIS Lua script to a Basic script, ie giving focus DoF and focus bracketing feedback. Crude, but, I suggest, useful low hanging fruit.

But, as I say, I may be talking in ignorance of what is achievable via a Basic scripting feature.

Walter Schulz · « **Reply #170 on:** October 06, 2020, 08:54:07 PM »

Huh? I thought coon and his supporters left scripting and going towards full scale ML coding right now ...
Clarification, please!

garry23 · « **Reply #171 on:** October 06, 2020, 08:58:24 PM »

Yes, I get that, but I have no idea of the time/effort to get a useful Basic scripting API up and running, vs a ‘stable’ full ML environment.

I was only thinking out loud.

names_are_hard · « **Reply #172 on:** October 06, 2020, 10:17:50 PM »

You could certainly get Basic to do pretty much anything, but for anything complicated it's harder than C (anything where Basic doesn't have a function already given to you). For simple stuff, if you don't want menus, or maybe even keys, possibly Basic would be easier. But which tasks are simpler? That's not easy to tell in advance.

Additionally, time spent making things work in Basic doesn't progress ML at all. And, it's a different language, that most of the ML devs won't have used before, so they have to learn it first. If it's the same devs working on it, it takes time away from ML dev, so it's a tradeoff. If you want to learn Canon Basic and work on it, that would be great! There's a lot you can do with it and CHDK documents some of it, with examples.

garry23 · « **Reply #173 on:** October 06, 2020, 11:09:38 PM »

@names_are_hard

I didn’t make myself clear enough.

I was suggesting that maybe having access to Basic might ‘satisfy’ those of us that script, rather than waiting for a Lua implementation.

As I say, I was thinking out load and will now stop thinking

srsa · « **Reply #174 on:** October 06, 2020, 11:30:16 PM »

Quote from: garry23 on October 06, 2020, 11:09:38 PM

I was suggesting that maybe having access to Basic might ‘satisfy’ those of us that script, rather than waiting for a Lua implementation.

I don't think so.
A Basic script can only be started once.
It locks the Canon UI while it runs.
I tried making a shooting script on PowerShots with some tricks (multi-threading, basically), but those tricks crash dual core cameras. The language (its interpreter) is most likely not thread-safe.
Canon Basic scripting is a great tool for early development, dumping memory, setting bootflag, trying things out while running native code isn't working yet on a camera. That's all.

News:

Author Topic: Canon EOS R / RP (Read 193757 times)