EOS M3 porting - page 71 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 66 67 68 69 70 [71] 72 73 74 75   Go Down

EOS M3 porting

  • 746 Replies
  • 428161 Views
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #700 on: 14 / February / 2022, 11:50:59 »
Advertisements
@reyalp @srsa_4c

As you know EOS M cameras running Powershot based firmware have a problem described there.
I found a solution for quick power-off (for fw.101a, see attachment) but not sure that it can be applied for all lenses.

So I need some advise for choosing the best implementation:
1. Creating camera specific menu item for enabling/disabling my patch.
2. Creating camera specific module.
3. Using startup script for installing my patch(if it possible)

Logged
*

Online reyalp

  • ******
  • 14126
Re: EOS M3 porting
« Reply #701 on: 14 / February / 2022, 12:56:11 »
Quote from: Ant on 14 / February / 2022, 11:50:59
@reyalp @srsa_4c

As you know EOS M cameras running Powershot based firmware have a problem described there.
I found a solution for quick power-off (for fw.101a, see attachment) but not sure that it can be applied for all lenses.

So I need some advise for choosing the best implementation:
1. Creating camera specific menu item for enabling/disabling my patch.
2. Creating camera specific module.
3. Using startup script for installing my patch(if it possible)
Your code is only in boot.c, so it doesn't need a module.
To add a menu option, you can just put it under a platform_camera.h ifdef, like many other ins gui.c. I'd suggest something like CAM_EOS_LENS_SHUTDOWN_FIX (did we ever find out if M10 is affected as well?)
You'll need to add a conf item to store the value, and it should reset when the platform changes (though it won't actually do anything on platforms without the boot.c code). It might be preferable to make it only apply to certain lenses, but I don't know if you have this information, and IDing them in the CHDK UI could be problematic. From your earlier posts, it sounds like it would only affect non-Canon EF-M lenses in any case.
You will need your logic in boot.c to check the conf value at run time. If possible (the thing you patch is called when needed, not something that starts up a task or whatever), I'd make disconnect4_my a C function that checks the conf item, and calls the original or new code based on the conf.
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #702 on: 14 / February / 2022, 14:15:48 »
Quote from: reyalp on 14 / February / 2022, 12:56:11
if you have this information, and IDing them

According to Page 77, many lenses have the same ID. Thus, it is also necessary to check LENS NAME and store the list of affected lenses somewhere in CHDK folder. But some lenses do not report their names completely.

Although it is possible, my concerns are exaggerated and this patch is harmless to all lenses.
Logged
*

Online reyalp

  • ******
  • 14126
Re: EOS M3 porting
« Reply #703 on: 14 / February / 2022, 18:29:37 »
Quote from: Ant on 14 / February / 2022, 14:15:48
According to Page 77, many lenses have the same ID. Thus, it is also necessary to check LENS NAME and store the list of affected lenses somewhere in CHDK folder. But some lenses do not report their names completely.

Although it is possible, my concerns are exaggerated and this patch is harmless to all lenses.
In that case, a simple on-off conf options seems fine to me.
Logged
Don't forget what the H stands for.
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #704 on: 15 / February / 2022, 08:32:19 »
I am trying to generate a patch that can be installed from the script.

arm-none-eabi-gcc -march=armv7-r -mthumb -fPIC -O1 -c pic.c
arm-none-eabi-objdump -dS pic.o

But the result is not good:
Code: [Select]
pic.o:     file format elf32-littlearm


Disassembly of section .text:

00000000 <disconnect4_my>:
   0:   e92d 43f8       stmdb   sp!, {r3, r4, r5, r6, r7, r8, r9, lr}
   4:   6884            ldr     r4, [r0, #8]
   6:   f04f 7880       mov.w   r8, #16777216   ; 0x1000000
   a:   4f78            ldr     r7, [pc, #480]  ; (1ec <loc_fc2f12f0+0x4>)
   c:   466a            mov     r2, sp
   e:   4641            mov     r1, r8
  10:   68a6            ldr     r6, [r4, #8]
  12:   6838            ldr     r0, [r7, #0]
  14:   f7ff effe       blx     0 <sub_fc302180>
  18:   b108            cbz     r0, 1e <loc_fc2f1400>
  1a:   2501            movs    r5, #1
  1c:   e000            b.n     20 <loc_fc2f1402>

0000001e <loc_fc2f1400>:
  1e:   2500            movs    r5, #0

00000020 <loc_fc2f1402>:
  20:   2002            movs    r0, #2
  22:   f7ff fffe       bl      0 <sub_fc2efc32>
  26:   f7ff fffe       bl      0 <sub_fc2efa86>
  2a:   f7ff fffe       bl      0 <sub_fc2f46d4>
  2e:   6838            ldr     r0, [r7, #0]
  30:   4641            mov     r1, r8
  32:   f7ff effe       blx     0 <sub_fc302300>
  36:   b16e            cbz     r6, 54 <loc_fc2f1436>
  38:   b1a5            cbz     r5, 64 <loc_fc2f1446>
  3a:   2001            movs    r0, #1
  3c:   f7ff fffe       bl      0 <sub_fc2efc32>
  40:   f7ff fffe       bl      0 <sub_fc2f473a>
  44:   2000            movs    r0, #0
  46:   f7ff fffe       bl      0 <sub_fc0f823c>

  ...


How to implement firmware subs for position-independent code?
Logged
*

Online reyalp

  • ******
  • 14126
Re: EOS M3 porting
« Reply #705 on: 15 / February / 2022, 15:22:35 »
Quote from: Ant on 15 / February / 2022, 08:32:19
I am trying to generate a patch that can be installed from the script.
I don't understand. What script? Why not just make this a menu option controlled by an ifdef, with the workaround logic in boot.c? I'm happy to add this to the official source as long is it has minimal impact on other ports.

Quote
How to implement firmware subs for position-independent code?
You mean a binary that can be loaded at any address that can call firmware code? That would require a "long" call (load some register, then blx to it, or call something that jumps with ldr pc). AFAIK there's no way for gcc / binutils to automatically generate for inline asm. You'd need to replicate stubs_auto.S (but linked only to your code), or re-write the inline asm to manually implement long calls.  But again, I don't understand the reason for trying to do this, it's a tiny amount of code that only affects one port. Just put it in boot.c and and put the menu option under and ifdef.
Logged
Don't forget what the H stands for.
*

Offline Caefix

  • *****
  • 948
  • Sorry, busy deleting test shots...
Re: EOS M3 porting
« Reply #706 on: 09 / May / 2022, 14:20:25 »
Just found in untouched trunk  :-[
Quote
// D:\hostluaPortable\CHDK-Shell\trunk\trunk-6077\platform\m3\main.c
#define NUM_FL      101
const int zoom_points = NUM_FL;
It should be 1, to identify Eos-cam from script with:  ;) ... ILC = get_zoom_points()==1

Quote
// D:\hostluaPortable\CHDK-Shell\trunk\trunk-6077\platform\m3\camera.h
// missing / defaults to 5. :
    #undef  CAM_CIRCLE_OF_CONFUSION
    #define CAM_CIRCLE_OF_CONFUSION             19  // CoC value for camera/sensor (see http://www.dofmaster.com/digital_coc.html)
Logged
All lifetime is a loan from eternity.
*

Offline atlanta23

  • *
  • 1
Re: EOS M3 porting
« Reply #707 on: 01 / June / 2022, 17:58:16 »
Leute, wie bekomme ich überhaupt CHDK drauf auf die M10 ?
Logged
*

Offline Ant

  • *****
  • 509
Re: EOS M3 porting
« Reply #708 on: 02 / June / 2022, 06:18:44 »
Logged
*

Offline Caefix

  • *****
  • 948
  • Sorry, busy deleting test shots...
Re: EOS M3 porting
« Reply #709 on: 02 / June / 2022, 11:38:12 »
Logged
All lifetime is a loan from eternity.
Pages: 1 ... 66 67 68 69 70 [71] 72 73 74 75   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal