Canon EOS 1300D / Rebel T6

[critix]

I have disassembled with arm_console, and I searched through 60D values for FOCUS_CONFIRMATION and HALFSHUTTER_PRESSED.
I found the value given by dfort for HALFSHUTTER_PRESSED -> 0x31308.
For FOCUS_CONFIRMATION I found 0x4680.
Is ok this value?
Thanks.

[dfort]

How did you find those values--pattern matching? I found the same by pattern matching but searching for the same pattern on the 1200D resulted in completely different values than what was found to work on that camera. So my guess is that the values that you found are probably not ok.

On Reply #220 a1ex provided some links that if you follow will lead you a wiki article on Struct Guessing. It uses the FOCUS_CONFIRMATION stub as an example. I checked the example against the 550D.109, 60D.111 and 1200D.102 and they all have a structure that looks something like this:

Code: [Select]

(FOCUS STRUCTURE ADDRESS) + 0x4 = FOCUS_CONFIRMATION
So the value we need to search for is 0x4 less than the value of the FOCUS_CONFIRMATION stub that was found for the camera you're using to pattern match to.

After working through the article my guess is this:

1300D

Code: [Select]

#define FOCUS_CONFIRMATION (*(int*)0x5C7D1)
Assuming that the FOCUS STRUCTURE ADDRESS = 0x5C7CD

Look up this string in the disassemblies and the pattern to match is a few lines down from there.

Code: [Select]

"    focusstatus %x,%x":
[EDIT] On second look maybe a better guess would be this?

1300D

Code: [Select]

#define FOCUS_CONFIRMATION (*(int*)0x36EC4)
Assuming that the FOCUS STRUCTURE ADDRESS = 0x36EC0

The 1300D is somewhat different from the other cameras we're using as references so it is a bit tricky to find the right lines that match up.

[a1ex]

Data structures placed at odd addresses are quite rare in the ARM world. The CPU used by these cameras (DIGIC 5 and earlier) cannot even read 32-bit integers from unaligned addresses. That's a warning flag.

From that page, you are looking for something read from memory, at offset 4 within some data structure, and compared to 1. That is:

Code: [Select]

FE166C90   LDR     R0, [R5,#4]
FE166C94   CMP     R0, #1

Then you need to find the address of that data structure, right before the above lines. That address is in R5, not R0.

Whether that actually does what we expect (i.e. becoming TRUE when focus is confirmed, even in MF mode), remains to be seen. On 700D, 650D, 100D and EOS M, apparently it doesn't.

[dfort]

That address is in R5, not R0.

Right--I edited my post after I realized that but maybe you didn't see the update when you made your post.

Code: [Select]

fe166c78:  ldr r5, [pc, #-996] ; fe16689c: (00036ec0)

So we should be on the right track here:

1300D

Code: [Select]

#define FOCUS_CONFIRMATION (*(int*)0x36EC4)

Whether that actually does what we expect (i.e. becoming TRUE when focus is confirmed, even in MF mode), remains to be seen. On 700D, 650D, 100D and EOS M, apparently it doesn't.

Does it work on the 1200D? That's what we (critix and I) are mainly using because it seems to be the closest match to the 1300D. Of course that camera is also fairly early in the development stages. However, if we look at that same section of code (near focusstatus %x,%x) on the cameras you say focus confirmation isn't working, we come up with some different values.

Camera	current value	possible change?
700D	0x24884	0x27660
650D	0x24878	0x275A0
EOSM	0x3F224	0x420F0

I couldn't find it on the 100D using this method but I didn't try very hard.

So how to confirm focus confirmation is confirming? Is there a test for it? Maybe a simple lua script will do the trick?

[EDIT] Is this why trap focus isn't working on these cameras?

[a1ex]

Trap focus was reported to work on 1200D, outside LiveView. I've tried to cover this (FOCUS_CONFIRMATION) in selftest.mo and api_test.lua, but on 700D & co., the focus apparently gets confirmed only during AF; so the tests were passing IIRC, but trap focus was still not working. Not sure how to debug this - maybe capturing a log with MPU messages during confirmation and see what happens in QEMU. This address was found with a very old tool called mem_spy, that shows memory addresses that change as you try stuff on the camera.

[critix]

I compiled the mem_spy module and activated it. I started qemu and I run the selftest module, and get the error below:

[MPU] Received: 08 06 04 0c 03 00 00 00  (PROP_SHOOTING_TYPE - spell #72)
[MPU] Sending : 08 06 04 0c 03 00 01 00  (PROP_SHOOTING_TYPE)
[MPU] Received: 06 05 03 34 00 00  (PROP_Q_POSITION - spell #45)
[MPU] Received: 08 06 00 00 04 00 00 00  (Complete WaitID = 0x80020000 - spell #48)
[MPU] Received: 06 04 04 13 00 00  (unknown - PROP 80020012)
[MPU] Received: 08 06 00 00 04 0c 00 00  (unknown - Complete WaitID)
[MPU] Received: 06 04 09 00 00 00  (unknown - PROP_LV_LENS)
[MPU] Received: 06 05 09 0b 02 00  (unknown - PROP_LV_AF_RESULT)
  6614: 24839.936 [MC] PROP_GUI_STATE 0
  6741: 24843.008 WARN [LVDS] First Get DTS_GetAllRandomData
  6750: 24843.264 [LV] [PATH] GetPathDriveInfo[0]
  6756: 24843.264 WARN [LVDS] First Get DTS_GetAllRandomData
  6758: 24843.520 WARN [LVDS] First Get DTS_GetAllRandomData
  6782: 24843.776 WARN [LVDS] First Get DTS_GetAllRandomData
  6784: 24843.776 WARN [LVDS] First Get DTS_GetAllRandomData
  6800: 24861.952 [CAPD] ERROR Image Power Failure
  6801: 24861.952 [STARTUP] startupErrorRequestChangeCBR : OverWrite (0x82218001 => 0x8221800
[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #75)
[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #75)
  6811: 24909.568 [MC] cam event guimode comp. 0
  6823: 24916.480 [GUI] ERROR ***** Lv GetMovieFrameRateIcon S (81)

Do you know why?
Thanks

[critix]

Hi.
After searches, I found the following values:
File consts.h:

Code: [Select]

#define HIJACK_INSTR_BSS_END 0xFE0C3B14
#define MVR_992_STRUCT (*(void**)(0x315dc+0x4)) // look in MVR_Initialize for AllocateMemory call
#define IMGPLAY_ZOOM_POS_X MEM(0x6FCC4) // Look up *"CentrePos x:%ld y:%ld"
#define IMGPLAY_ZOOM_POS_Y MEM(0x6FCC8) // (0x6FCC4+0x4) Look up *"CentrePos x:%ld y:%ld"
#define VIDEO_PARAMETERS_SRC_3 0x6A95C
#define DISPLAY_SENSOR_POWERED (*(int*)(0x359a0 + 0x18))  // =0x359B8; Look up *"ForceDisableDisplay (%d)"
#define INFO_BTN_NAME "DISP" // like 1200D
#define HALFSHUTTER_PRESSED (*(int*)0x359BC) // look for string "[MC] permit LV instant"
#define FOCUS_CONFIRMATION (*(int*)0x36EC4) // (0x36EC0 + 0x4) see "focusinfo" and Wiki:Struct_Guessing


[critix]

In file fps-engio.c is OK this value?

Code: [Select]

#elif defined(CONFIG_1300D)   
    #define NEW_FPS_METHOD 1
    #define SENSOR_TIMING_TABLE MEM(0x4015C)
    #define VIDEO_PARAMETERS_SRC_3 0x6A95C
    #define TG_FREQ_BASE 28800000
    #undef FPS_TIMER_A_MIN
    #define FPS_TIMER_A_MIN (ZOOM ? 734 : MV1080 ? 546 :576)
    #undef FPS_TIMER_B_MIN
    #define FPS_TIMER_B_MIN (ZOOM ? 1312 : MV480 ? 2000 : MV720 ? 1000 : 2200)
   

[critix]

When I run:

Code: [Select]

./run_canon_fw.sh 1300D,firmware="boot=1" -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdbI got this error:

Code: [Select]

[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #75)
  1328:   825.344 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
  1329:   825.344 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
  1347:   760.320 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
  1348:   760.320 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
  1353:   760.576 [MC] cam event guimode comp. 0
[  DisplayMgr:fe123f78 ] register_interrupt(null, 0x34, 0xfe123e10, 0x1)
  1408:   802.560 [DISP] TurnOnDisplay action Type=0
[  DisplayMgr:fe123f78 ] register_interrupt(null, 0x34, 0xfe123e10, 0x1)
[  DisplayMgr:fe123f78 ] register_interrupt(null, 0x34, 0xfe123e10, 0x1)Why? How can i fixed?

[dfort]

In file fps-engio.c is OK this value?

I think that the timer values need to be found on the actual hardware.

As far as the QEMU error messages, I'm getting that too. Not sure if this is anything significant that needs to be worked out before trying out a minimal build on the camera.

[critix]

Why I get this error:

Code: [Select]

  1348:   510.976 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown Mo[MPU] Received: 06 05 03 19 01 00  (PROP_TFT_STATUS - spell #75)
vieInfo
  1349:   510.976 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
  1367:   511.232 [GUI] ERROR ***** ConvertPropertyMovieDataToMovieSizeKind UnKnown MovieInfo
  1368:   511.232 [GUI] ERROR MovieSize(1), FrameRate(81), ZoomMode(88), MovieMode(0)
  1373:   511.232 [MC] cam event guimode comp. 0
  1411:   551.680 [DISP] TurnOnDisplay action Type=0even I run

Code: [Select]

./run_canon_fw.sh 1300D,firmware="boot=0".
After the qemu starts, the video menu never appears. Not even if I run

Code: [Select]

./run_canon_fw.sh 1300D,firmware="boot=1"

[dfort]

After the qemu starts, the video menu never appears.

Probably because the firmware was dumped with the camera in Photo mode.

There is a way to switch over to Movie mode but it requires having a startup log made with the camera in Movie mode then running the extract_init_spells.py script in qemu-eos/qemu-2.5.0/hw/eos/mpu_spells. This will create a 1300D.h file that when placed in the mpu_spells directory will allow QEMU to start the emulation in a different mode. More about this in this post in the "How to run Magic Lantern into QEMU?!... " topic.

If you create a new firmware dump with the camera in Movie mode and run the new dump in QEMU it should show the video menu--after patching the dump as explained by a1ex in Reply #7.

Note that there might be a way to switch between Photo and Movie modes in QEMU but I'm not sure if that is possible on the 1300D and if so which buttons you need to press.

[a1ex]

On 1300D, the movie mode is on the mode dial. If you press F1 during emulation:
 

Code: [Select]

[MPU] Available keys:
...
- 0/9          : Mode dial (press only)
- V            : Movie mode (press only)
...

Movie mode is 20:

Code: [Select]

#define SHOOTMODE_MOVIE 0x14

If the emulation starts in M mode (3), you should press the "0" key 17 times. Or, just press V. After that, press Q to show the LiveView menu, but the image capture is not emulated.

Then, it will lock up when trying to change the resolution; probably some incorrect MPU message for PROP_VIDEO_MODE. We'll fix that after getting some logs from the camera.

Didn't manage to double-check the latest constants yet; will prepare a FIR after that.

[dfort]

Lots of buttons to press to get to the movie menus but much easier than making a new firmware dump or running extract_init_spells.py on a startup log.

[critix]

I have tried dm-spy-experiments branch merged in my 1300D branch. OK., but when I run

Code: [Select]

./run_canon_fw.sh 1300D,firmware="boot=1" I got this error when enable DebugMsg Log:

Code: [Select]

[MPU] Received: 06 05 03 19 00 00  (PROP_TFT_STATUS - spell #41)
Save configs...
ICache: 8192b, idx=7e0 tag=fffff800 word=1c seg=c0000000
Jump range error: cf2e60 -> fe2993b8 != 22993b8
Patch error at fe2993b4 (jump out of range) = cf2e60
Jump range error: cf2e60 -> fe10fa74 != 210fa74
Patch error at fe10fa70 (jump out of range) = cf2e60What are wrong?

[a1ex]

This one is hard to fix - branch instructions in ARM code cannot go "too far" (they are limited to +/- 32MB around the address of the branch instruction). Normally, the compiler takes care of this (e.g. by using long jumps or inserting veneers - intermediate jumps), but here we are patching existing binary code in the firmware, to jump to our code instead.

I couldn't find an easy fix for this one; while a long jump can be implemented, it may require patching 2 instructions for one function. It's doable though, and other cameras will benefit from this (60D, which has the same problem in some experimental branches, and maybe some newer models too).

On 1300D I'm afraid we can't just use the workaround for 60D (where we load ML at a different address in order to be able to patch things), so a proper fix will be required in order to get some useful debug logs.

[critix]

Thank you. Then I will not continue with dm-spy-experiments branch.
Until you can create the FIR file, what could I do?

[critix]

I run

Code: [Select]

./run_canon_fw.sh 1300D,firmware="boot=1" for dm-spy-experiments and I get crash in Debug -> Free Memory:

Code: [Select]

ASSERT: 0
at SystemIF::KerTask.c:191, guess_mem:39b0
lv:0 mode:3

guess_mem stack: 1a98a8 [1a9978-1a5978]
0xUNKNOWN  @ 41fc:1a9968
0x00C8F0A8 @ c81ca8:1a9920
0xUNKNOWN  @ c8f0f0:1a9908
0x000038FC @ c82158:1a98f8
0x00003CBC @ 39ac:1a98e0
0x00C8036C @ c808d8:1a98a8

Magic Lantern version : Nightly.2018Jul17.1300D110
Mercurial changeset   : c289baed76d1+9dff88575e96+ (1300D)
Built on 2018-07-17 16:33:24 UTC by root@DESKTOP-7QS9FV7.
Free Memory  : 247K + 586KIn CLI I have:

Code: [Select]

[DM] FROM Write Complete!!!
ASSERT : SystemIF::KerTask.c, Task = guess_mem, Line 191
ASSERT : SystemIF::KerTask.c, Task = guess_mem, Line 191
ASSERT : SystemIF::KerTask.c, Task = guess_mem, Line 191Maybe that it helps...

[critix]

I think that the timer values need to be found on the actual hardware.

How can i found the timer values? Must magiclantern run on real camera?

[leygc]

Hi! I know nothing about programing, how can I install ML to my Rebel T6?

[critix]

On  Rebel T6 is not working yet...

[critix]

I have found some values in the const.h file, which are found at 1200D and 550D, but which at 1300D did not appear.

Code: [Select]

// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
#define ROM_ITASK_START 0xFE1296C8
#define ROM_ITASK_END  0xFE129768
#define ROM_CREATETASK_MAIN_START 0xFE0C1B60
#define ROM_CREATETASK_MAIN_END 0xFE0C1EB0
#define ROM_ALLOCMEM_END 0xFE0C1B74
#define ROM_ALLOCMEM_INIT 0xFE0C1B7C
#define ROM_B_CREATETASK_MAIN 0xFE129760

#define ARMLIB_OVERFLOWING_BUFFER 0x310a8 // in AJ_armlib_setup_related3
These values have also been checked by dfort.
But... when make install_qemu I have error:

Code: [Select]

make[1]: Leaving directory '/home/cristi/magic-lantern-1300D/tcc'
[ CC       ]   module.o
[ AR       ]   strrchr.o
[ AR       ]   dietlibc.a
[ AR       ]   lib_a-setjmp.o
[ AR       ]   newlib-libc.a
[ CP       ]   newlib-libm.a
[ CP       ]   gcc-libgcc.a
[ LD       ]   magiclantern
boot-hack.o: In function `init_task_patched':
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:606: undefined reference to `reloc'
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:614: undefined reference to `reloc'
../../src/Makefile.src:197: recipe for target 'magiclantern' failed
make: *** [magiclantern] Error 1
Are not the values found good?

[dfort]

Hint:

platform/1300D.110/consts.h

Code: [Select]

// Used in boot-hack.c with CONFIG_ALLOCATE_MEMORY_POOL
Now look here:

platform/1300D.110/internals.h

Code: [Select]

/** This camera loads ML into the AllocateMemory pool **/
//#define CONFIG_ALLOCATE_MEMORY_POOL

Notice that it is commented out on the 1300D and active on the 1200D and 550D. Can the 1300D use CONFIG_ALLOCATE_MEMORY_POOL? I don't know the answer to that but you can try it out in QEMU.

[critix]

 Yes, i uncomment this line but i get error :

Code: [Select]

[ CP       ]   gcc-libgcc.a
[ LD       ]   magiclantern
boot-hack.o: In function `init_task_patched':
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:606: undefined reference to `reloc'
/home/cristi/magic-lantern-1300D/platform/1300D.110/../../src/boot-hack.c:614: undefined reference to `reloc'
../../src/Makefile.src:197: recipe for target 'magiclantern' failed
make: *** [magiclantern] Error 1


[dfort]

Right, remembering what we did on the EOSM2 there's a lot more to getting CONFIG_ALLOCATE_MEMORY_POOL working. For now I'd recommend commenting out those constants like on the 50D.