EOS M3 porting [M3] [EOS_M3]

reyalp

Ant
This need to be added for motion detection:

Thanks for catching that, added in r4738

Ant

reyalpIs https://app.assembla.com/spaces/chdk-m3/subversion/source/23/trunk/modules/edgeoverlay.c the most recent version?

Yes. But you can also choose 62ndidiot's variant.

So spytask only starts if you hold this button while the camera is booting?

vice versa

Or do you mean only the romlog code depend on M-Fn ? In that case, what is *(int*)(0x9e5c) & 0x00600000 around spytask?

IIRC there are two types of firmware startup: when battery cover closed after battery insertion and when power button is pressed.

What values does get_vbatt in Lua return, actual voltage (like 7200) or some other value?

I didn't try it. But CHDK OSD displays values between 6800-8400mV

Does it actually use different speeds for zoom in / zoom out? From the manual, it looks like the zoom controls are on the lens, not the body. Can CHDK even detect or send zoom controls on this camera? If not, it should not have zoom keys at all (It's possible we could synthesize them later using other functions or levents)

I don't know anything about zoom speeds. Most EF lenses don't have electromechanical zoom drive(excepting this). But two buttons above jogdial used in playback mode for zooming. Right button also used in viewfinder mode for x1/x5/x10 magnifying.

reyalp

Ant
I don't know anything about zoom speeds. Most EF lenses don't have electromechanical zoom drive. But two buttons above jogdial used in playback mode for zooming. Right button also used in viewfinder mode for x1/x5/x10 magnifying.

Thanks. I'm not sure these should be defined as zoom keys at all (rather than AE lock / AF adjust) , but for now I've updated the comments. If they weren't defined as zoom, we'd have to do something with the menu scale factor adjustment.

Is the INFO button (lower left) assigned to display in CHDK?

Ant

reyalpIs the INFO button (lower left) assigned to display in CHDK?

Yes.

Ant

some comments were updated in stubs_min.S:

Index: /platform/m3/sub/101a/stubs_min.S
===================================================================
--- /platform/m3/sub/101a/stubs_min.S	(revision 4740)
+++ /platform/m3/sub/101a/stubs_min.S	(working copy)
@@ -1,40 +1,40 @@
 #include "stubs_asm.h"
 
 //DEF(led_table,)
-DEF(jpeg_count_str,                0x0016CC64) //@ Found @0xfc0fc46c
+DEF(jpeg_count_str,                0x0016CC64) //@ Found @0xFC1A0A2C
 DEF(file_counter_var,              0x00012460) //@ found by searching for "FileBackupProperty.c" 
 DEF(ctypes, 0xFC5E29F4)		//@ me
 
 // Camera has 2 RAW buffers @ 0x44000000 & 0x4adb54a0
-//DEF(raw_buffers                   ,0xFC607634) //@ FC6CB874 FC607634 ??? Found @0xfc16d43e
+//DEF(raw_buffers                   ,0xFC607634) //@ FC6CB874 ??? Found @0xFC158B60
 DEF(raw_buffers_canon_raw                   ,0xFC6CB874) //@ FC607634
 DEF(raw_buffers_jpeg                         ,0xFC6CB874) //@
-DEF(active_raw_buffer             ,0x0000B3B4) //@ ??? Found @0xfc13fa6c, 0xffffffff when uninited...
+DEF(active_raw_buffer             ,0x0000B3B4) //@ ??? , 0xffffffff when uninited...
 DEF(fileio_semaphore              ,0x000125AC) //@ Found @0xFC06E186
 
-DEF(physw_status                            ,0x0005209😎 //@ Found @0xfc0604ae
-DEF(physw_run                               ,0x000082CC) //@ Found @0xfc0601f6
-DEF(physw_sleep_delay                       ,0x000082D4) //@ Found @0xfc0601f6
+DEF(physw_status                            ,0x0005209😎 //@ Found @0xFC083E76
+DEF(physw_run                               ,0x000082CC) //@ Found @0xFC083BC6
+DEF(physw_sleep_delay                       ,0x000082D4) //@ Found @0xFC083BC6
 
-//DEF(error_table                             ,0xFC63812C) //@ Found @0xfc1abf24
+//DEF(error_table                             ,0xFC63812C) //@ Found @0xFC18E1A0
 
-DEF(levent_table                            ,0xFC63846C) //@ Found @0xfc0a4b40
-DEF(FlashParamsTable                        ,0xFC747DB😎 //@ 0xFC0E15C4-> 0xfc7313a0
+DEF(levent_table                            ,0xFC63846C) //@ Found @0xFC113158
+DEF(FlashParamsTable                        ,0xFC747DB😎 //@ 0xFC0E15C4-> 0xFC746944
 DEF(movie_status                            ,0x00010b0😎 // or 0x10a88
 FAKEDEF(video_compression_rate, 1)
 DEF(full_screen_refresh                     ,0x00012a94) // Found @0xfc2b0f5c
-DEF(canon_menu_active                       ,0x0000C18C) //@ Found @0xfc27d0bc
+DEF(canon_menu_active                       ,0x0000C18C) //@ Found @0xFC32DD9C
 FAKEDEF(canon_shoot_menu_active, 1) // ??? not found
-DEF(playrec_mode                            ,0x0000B454) //@ Found @0xfc27937e
+DEF(playrec_mode                            ,0x0000B454) //@ Found @0xFC325CA4
 FAKEDEF(zoom_status                             ,1) // Found @0xfc30e61c
 //DEF(zoom_status                             ,0x00018b04) // Found @0xfc30e61c
 // focus_len_table contains zoom focus lengths for use in 'get_focal_length' (main.c).
 // each entry contains 2 int value(s), the first is the zoom focus length.
 // there are 102 entries in the table - set NUM_FL to 101
-DEF(focus_len_table                         ,0xfdf6ad20)
+//DEF(focus_len_table                         ,0xfdf6ad20)
 //DEF(zoom_busy                               ,0x00010814) // Found @0xfc1a0998
 //DEF(focus_busy                              ,0x00010694) // Found @0xfc28b964
-DEF(recreview_hold                          ,0x000097B😎 //@ Found @FC34B82A      0xfc2a2c22
+DEF(recreview_hold                          ,0x000097B😎 //@ Found @FC34B83A 
 FAKEDEF(zoom_busy                               ,1)
 FAKEDEF(focus_busy                              ,1)
 // sx280 c&p?
@@ -48,7 +48,7 @@
 DEF(active_bitmap_buffer, 0xC14C) //@ xac10) // or 0xac14? just a guess
 // FAKEDEF(viewport_buffers, 1) // ?
 // FAKEDEF(active_viewport_buffer, 1) // ?
-DEF(current_viewport_buffer       ,0x0000889C) //8878????????????????????????????????
+DEF(current_viewport_buffer       ,0x0000889C) //8878?  Found @FC133DE2
 DEF(viewport_buffers              ,0xFC5F8DE😎 // from memory search, refs to FC5F8DD8
 
 DEF(jog_position,                           0xdb4😎 // 0xdb34 +0x14, +0x18
@@ -57,4 +57,4 @@
 
 //FAKEDEF(enabled_refresh_physical_screen,    1)
 
-DEF(displaytype,                            0x9974) //@ 0x8ea4 + 0x14, found  @ fc135f2a (GetDisplayType)
+DEF(displaytype,                            0x9974) //@ 0x9934 + 0x40, found  @ 0xFC35DD56 (GetDisplayType)

and in /loader/m3 directory:

Index: entry.S
===================================================================
--- entry.S	(revision 4740)
+++ entry.S	(working copy)
@@ -4,5 +4,6 @@
 .code 16
 .align 2
 .syntax unified
+    LDR     SP, =MEMBASEADDR
     B       my_restart
     .ascii  "gaonisoy"
Index: main.c
===================================================================
--- main.c	(revision 4740)
+++ main.c	(working copy)
@@ -16,26 +16,10 @@
 
     core_copy(src, dst, length);
 
-    asm volatile ( // fc095c80 102b/102c
-/*    "movs    r0, #0x78\n"
-    "mcr     p15, 0, r0, c1, c0\n"
-    "movs    r0, #0\n"
-    "mcr     p15, 0, r0, c7, c10, 4\n"
-    "mcr     p15, 0, r0, c7, c5\n"
-    "mcr     p15, 0, r0, c7, c6\n"
-    "movw    r0, #0x4006\n"
-    "mcr     p15, 0, r0, c9, c1\n"
-    "mcr     p15, 0, r0, c9, c1, 1\n"
-    "mrc     p15, 0, r0, c1, c0\n"
-    "orr.w   r0, r0, #0x50000\n"
-    "mcr     p15, 0, r0, c1, c0\n"
-    "movw    r1, #0x4ffc\n"
-    "ldr     r0, =0x12345678\n"
-    "str     r0, [r1, #0]\n"
-    //"ldr     r0, =0xfc020000\n"*/
+    asm volatile ( 
     "mov     r1, %1\n"
     "mov     r0, %0\n"
-    "ldr     r2, =0xfc1300b3\n" // address is OK for 102b and 102c   0xfc12dd3b
+    "ldr     r2, =0xfc1300b3\n" // address is OK for 101a
     "blx     r2\n"              // caching related routine called at fw startup
     "mov     r0, %0\n"
     "add     r0, r0, #1\n"

reyalp

Ant
some comments were updated in stubs_min.S:

Thanks, checked in trunk 4743. It might seem like a small thing but I really appreciate it.

lib.c hook_raw_image_addr was another I wasn't sure whether the comments were just copied, or actually verified for this cam. If they are verified, no need to change the comments.

If you can post more patches, posting them as attachments would be helpful.

Ant

reyalp
lib.c hook_raw_image_addr was another I wasn't sure whether the comments were just copied, or actually verified for this cam. If they are verified, no need to change the comments.

If you are talking about line 118, I will check it later. Now I can only say, that DNG shooting works normally in PATM modes and camera uses the same buffers for RAW and JPG.
P.S. RBF fonts are too small for new cameras. I was trying ML fonts, but there is a difference in special symbols.

Ant

In Auto mode camera uses the same buffers: raw_buffers_jpeg[] = raw_buffers_canon_raw[] = raw_buffers[].

So hook_raw_image_addr function was simplified:

Index: lib.c
===================================================================
--- lib.c	(revision 4743)
+++ lib.c	(working copy)
@@ -106,24 +106,9 @@
 //    return raw_buffers[(active_raw_buffer&3)];
     // observed values 0-2, 3 would index something that doesn't look like a raw fb in the jpeg case
     int i=active_raw_buffer&3;
-/*    _LogCameraEvent(0x20,"lc: hria: %i %i %08x %i",i, camera_info.state.mode_shooting,
-                                              camera_info.state.mode_shooting,
-                                              shooting_get_prop(PROPCASE_IMAGE_FORMAT));
-*/
-    // if(i>2) {
-        // i=0;
-    // }
-    if( camera_info.state.mode_shooting == MODE_AUTO) {
-        // AUTO mode (canon raw can't be enabled in AUTO)
-        return (char *)0x435ee300; // TODO unclear if this is only buffer, or if used in all AUTO sub modes
-    }else if(shooting_get_prop(PROPCASE_IMAGE_FORMAT) == 1) {
-    // canon raw disabled - uses up to 3 raw buffers
-        return raw_buffers_jpeg[i];
-    } else {
-        // canon raw enabled - different address, not clear if it ever uses multiple buffers
-        return raw_buffers_canon_raw[i];
-    }
-    // TODO most scene modes seem to use different addresse(s)
+    if(i>2) i=0;
+    return raw_buffers[i];
+        // TODO most scene modes seem to use different addresse(s)
 }
 
 /* char *hook_alt_raw_image_addr()
Index: sub/101a/stubs_min.S
===================================================================
--- sub/101a/stubs_min.S	(revision 4743)
+++ sub/101a/stubs_min.S	(working copy)
@@ -5,10 +5,8 @@
 DEF(file_counter_var,              0x00012460) //@ found by searching for "FileBackupProperty.c"
 DEF(ctypes, 0xFC5E29F4)		//@ me
 
-// Camera has 2 RAW buffers @ 0x44000000 & 0x4adb54a0
-//DEF(raw_buffers                   ,0xFC607634) //@ FC6CB874 ??? Found @0xFC158B60
-DEF(raw_buffers_canon_raw                   ,0xFC6CB874) //@ FC607634
-DEF(raw_buffers_jpeg                         ,0xFC6CB874) //@
+// Camera has 3 RAW buffers @ 0x4464F8C8, 0x46FB98A8, 0x49923888
+DEF(raw_buffers                   ,0xFC6CB874) // Found @0xFC4071F8 & 0xFC407080
 DEF(active_raw_buffer             ,0x0000B3B4) //@ ??? , 0xffffffff when uninited...
 DEF(fileio_semaphore              ,0x000125AC) //@ Found @0xFC06E186

But CHDKPTP gives me "ERROR: init failed" when I try to make DNG Remote Shoot in Auto mode.

And I didn't found raw data in memory dump which was made after shooting in Scene mode.

reyalp

Ant
In Auto mode camera uses the same buffers: raw_buffers_jpeg[] = raw_buffers_canon_raw[] = raw_buffers[].

So hook_raw_image_addr function was simplified:

Thanks. Checked in, trunk 4744.

On G7X, the raw buffer addresses varied depending on whether Canon raw was enabled. If you haven't, it would be good to check whether this is true on M3.

Most people will probably use Canon raw rather than CHDK, but having the raw buffers correct allows scripts to do stuff with the raw buffer. It may also allow capturing raw in some modes where Canon raw is not available.

But CHDKPTP gives me "ERROR: init failed" when I try to make DNG Remote Shoot in Auto mode.

in platform_camera.h, this port has

#define CAM_DISABLE_RAW_IN_AUTO 1

which should disable all CHDK raw / dng in auto mode. If there is actually a valid raw buffer in auto, you can take that out. There's a comment that says something about quick press, but that might be copied from another cam.

I notice platform_camera.h also has

#define CAM_HAS_ND_FILTER 1

which I assume isn't true. Also

#define CAM_HAS_JOGDIAL 0

which I mentioned earlier. It should either be #undef (if no jogdial, or the code is not implemented), or #define 1. From the manual, it looks like it has a jogdial and another control dial.

Ant

I found that in Hybrid Auto mode raw buffers have different addresses than in PATM and Auto modes. I don't know will CHDK be used in Hybrid Auto mode.

Added an experimental feature that could be helpfull for third party batteries.
It disables Battery Authentication Menu and enables Battery Icon.

build r31 for fw v1.0.1 can be found in attachment

EDIT:
removed because of position of forum administration 😀

62ndidiot

I wonder if different buffer addresses could be the reason for g7x and sx60hs crashes in hybrid auto mode?
@reyalp

reyalp

62ndidiot
I wonder if different buffer addresses could be the reason for g7x and sx60hs crashes in hybrid auto mode?
@reyalp

This can't explain the G7X crash in hybrid auto when loading with firm update, because the crash happens when CHDK DNG is not enabled. CHDK only uses the address if raw is enabled, or your are using a script function like shot_histogram or rawops that accesses the raw buffer, and is only likely to crash if it modifies the buffer (DNG for byte reversing + badpixel, or rawop write)

srsa_4c

I have mixed feelings about disabling the battery warning completely. It might make some important people angry (I'm not talking about CHDK users). Does ML do anything like that?

reyalp

srsa_4c
I have mixed feelings about disabling the battery warning completely. It might make some important people angry (I'm not talking about CHDK users). Does ML do anything like that?

I'm definitely hesitant to include this, FWIW.

Ant

srsa_4cDoes ML do anything like that?

Is RAW video recording "like that"?
There is also another way(not software) to disable the battery warning, but it's less safe.
But if CHDK comunity is afraid, I can remove this feature.

It's interesting that camera is collecting information about batteries usage(G7X too) and maybe sends it to somewhere...

caminfo.xml

3.21KB

reyalp

Ant

srsa_4cDoes ML do anything like that?

Is RAW video recording "like that"?

IMO, no.

My feeling is that it is different raw video or other features the CHDK and ML add. In general someone who was going to buy a full professional video rig isn't going to suddenly be satisfied with a mid-range DSLR because of ML. There's probably a few exceptions, but I would expect them to a small fraction of an already small user base.

The difference with the battery check is that Canon implemented it specifically to discourage the use of 3rd party batteries. I'm not fond of this kind of accessory lock-in, but bypassing it would move CHDK from a hobby project which generally encourages people to buy Canon hardware to something that encourages people to buy hardware that Canon is actively trying to stop people from using.

It is also possible that this check isn't purely motivated by copy protection. 3rd party batteries are notorious for doing things like replacing the thermistors with resistors, and otherwise ignoring best-practice engineering. If the firmware pushes "genuine" batteries to the limit assuming a particular design, it might have undesirable side effects when it does the same on a cheap clone.

It's interesting that camera is collecting information about batteries usage(G7X too) and maybe sends it to somewhere...

This would certainly be something interesting to investigate.

Also to be clear, my reluctance to is to including this hack as a standard feature in the official CHDK SVN. It's not for me to tell anyone what they should research or discuss.

Ant

reyalp
It is also possible that this check isn't purely motivated by copy protection. 3rd party batteries are notorious for doing things like replacing the thermistors with resistors, and otherwise ignoring best-practice engineering.

You are talking like Canon's employee. 😀
Considering the price of genuine batteries, I think, it's worst-practice marketing(like Apple).

If the firmware pushes "genuine" batteries to the limit assuming a particular design, it might have undesirable side effects when it does the same on a cheap clone.

I understand that the company wants to protect themselves from undesirable consequences, but one time warning is enough.

Why CHDK don't show warnings at first(every) startup?

waterwingz

Ant

reyalp
It is also possible that this check isn't purely motivated by copy protection. 3rd party batteries are notorious for doing things like replacing the thermistors with resistors, and otherwise ignoring best-practice engineering.

You are talking like Canon's employee. 😀
Considering the price of genuine batteries, I think, it's worst-practice marketing(like Apple).

I own nine different Powershots - six of which use Canon proprietary batteries (i.e. not standard AA cells). I have one genuine Canon battery for each and many low cost 3rd party batteries as well.

All the Canon batteries still function properly, although the oldest have somewhat diminished capacity of course. Of the 3rd party batteries (i have several per camera and many different "brands") more than half have swollen up enough that they don't fit into their camera very well, and about 20% will no longer charge.

No Canon employee or marketing here. Simple facts.

(btw - for the little I paid for the 3rd party brands, I just treat them as "semi-disposable" batteries).

reyalp

Ant
You are talking like Canon's employee. 😀
Considering the price of genuine batteries, I think, it's worst-practice marketing(like Apple).

I agree that they are probably doing it to boost their profits on accessories. However, it is a well documented fact that many of the cheap clones are not as well engineered as the official ones.

The trend in battery tech is to squeeze out more performance by using more sophisticated electronics to run things closer to the edge (*cough* samsung), so IMO it's not entirely out of the question that there were factors other than greed involved.

This is all speculation though, and mostly irrelevant to the question of whether bypassing the check risks pissing Canon off.

I understand that the company wants to protect themselves from undesirable consequences, but one time warning is enough.

That would certainly be my preference, but Canon didn't ask me.

62ndidiot

Perhaps it would be possible to include a script to disable battery compatibility checks or set them however the user likes. Does chdk support the idea of a script executed at startup like a users profile?

« Previous Page Next Page »