Canon EOS 1300D / Rebel T6

Started by the12354, October 03, 2016, 11:51:34 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.


hg blame src/fw-signature.h | grep 1300D

Are you able to navigate the menus and use the camera normally?

No debug logs enabled.


Menu nav no issues. Changing menu option (image qual) saving, turn off/on, confirm still set, reload HW, still set (config writes working)
LiveView working normally. Took a photo, scared myself because I was set to 8s expose and thought it had crashed, file saved onto SD no issue.

Yep, all looks fine. And HW shows back up straight up on any change.

No issue on debug, just checking incase I should expect it and there was a FIO write problem.

Gotcha on firmware sig


[size=8pt]70D.112 & 100D.101[/size]


Hey A1ex,

When I was going over your published your commit

I noticed

+# no 1300D firmware yet?
+CANON_NAME_FIR      = 5D300133.FIR
+FIRMWARE_ID         = 0x80000404

Canon did post the current 1.1.0 to their site a little while ago:


so confirmed on my hw as well. Did not upload the ml files to the card. So missing ml files :)

but still different from qemu: hw: 0x3d8461b5 vs qemu: 0xCD12E936 .. am i correct that the qemu variant is tainted by the cache hack? and we should update the signature in src/fw-signature.h


Quote from: DeinGott on January 14, 2018, 10:30:53 PM
...we should update the signature in src/fw-signature.h

Yes, the same thing happened to me on the EOSM2. AFAIK QEMU skips the firmware signature so it will still work.


@DeinGott: were you able to sync your source with my changes?

hg pull --rebase -r 1300D
hg up 1300D -C
hg blame src/fw-signature.h | grep 1300D

The cache uninstallation trick (done for HELO1303.FIR) is not committed; it was a cache_unlock(); sync_caches(); added at the top of my_big_init_task. I want to apply this one on all other models booting with this method.

Besides, QEMU is unable to emulate the cache hack uninstallation, so even with the above, the signature will be computed correctly in reboot.c (where it's needed to boot), but it would be displayed as in #147. I should fix that somehow in the emulation.

@dfort: the M2 signature issue was fixed; check c33141cd12a9 and the (updated) guide.

@shadowlab: thanks, I couldn't find it on Canon Europe a few days ago; now it's there...


since i code a bit more, i forked the repo to my own bitbucket.

so yes the merge were successfull :)

i still have a problem to find the STATE objects. Do you have any easy way to find them?

#define DISPLAY_STATEOBJ (*(struct state_object **)0x2480) // posible: 0x000318C8

#define EVF_STATE (*(struct state_object **)0x3737C) // hope this is correct
#define MOVREC_STATE (*(struct state_object **)0x5720) // still 600D
#define SDS_FRONT3_STATE (*(struct state_object **)0x3660) // still 600D


btw. Still get some errors, but the ml menu is loading

if someone knows howto get rid of the SYMBOLS not found error (the file is on the sd)

stefan@morbo-3: ~/Develop/qemu% l /Volumes/EOS_DIGITAL/ML/modules/1300D_110.sym
-rwxrwxrwx  1 stefan  staff    34K 15 Jan 22:13 /Volumes/EOS_DIGITAL/ML/modules/1300D_110.sym


Quote from: DeinGott on January 15, 2018, 06:46:30 PM
i still have a problem to find the STATE objects. Do you have any easy way to find them?

Got a bunch of them for the other models:

These should be called by CreateStateObject; first argument is a string with their name, so they should come up in QEMU with -d calls. Let's try:

./ 1300D,firmware="boot=0" -d calls |& grep --text EvfState
    call 0xFE2BEA5C(fea7f8a2 "EvfState", 0, fe8b2260, e)                         at [Startup:fe1a3d20:fe0de6b8]

Okay, so CreateStateObject is 0xFE2BEA5C.

./ 1300D,firmware="boot=0" -d calls |& grep --text 0xFE2BEA5C
    (many state objects created)

We need to know where the pointers to these state objects are stored. Let's try logging RAM writes right after CreateStateObject returns. This function calls a couple of others, so it's not easy to grep these logs; let's try a custom GDB logging hook:

b *0xFE2BEA5C
  printf "CreateStateObject(%s, 0x%x, %d, %d)\n", $r0, $r2, $r3, *(int*)$sp

  # note: I could have used log_result instead of this block, but wanted to get something easier to grep
  tbreak *$lr
    printf "CreateStateObject => %x at %x\n", $r0, $pc



./ 1300D,firmware="boot=0" -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdb
[     Startup:fe12d9b8 ] CreateStateObject(SCSState, 0xfe8a80a4, 20, 12)
Temporary breakpoint 13 at 0xfe12d9bc
[     Startup:fe127b1c ] CreateStateObject => 796c50 at fe12d9bc

We expect a memory write right after CreateStateObject returns, so let's try grep:

( ./ 1300D,firmware="boot=0" -d ramw -s -S & arm-none-eabi-gdb -x 1300D/debugmsg.gdb ) |& grep --text CreateStateObject -A 1 | grep 'CreateStateObject\|ram'
[     Startup:fe12d9b8 ] CreateStateObject(SCSState, 0xfe8a80a4, 20, 12)
[     Startup:fe127b1c ] CreateStateObject => 796d18 at fe12d9bc
[ram]    at Startup:FE12D9BC:FE127B20 [0x00035A74] <- 0x796D18  : was 0x0;

Not a very pretty display, but should find most of them, as they are created during startup.

Some of these are no longer used in the source (such as SDS_FRONT3_STATE); I should clean them up.


You guys seem to have done a ton of work in my (several month) absense... :-)
I did some stub finding a while back, but much of it is written form in my notebook, which is at work - I'll dig that out tomorrow and share it.

Also - I got my dev environment created again and got the GUI displaying in QEMU - but not all the buttons work (no arrow keys for example) is this expected, or do people have it working fully in QEMU ?

Thanks .. Ken


Arrow keys are working here; QEMU identifies the keys from scancode, so look them up here:

Just noticed drive mode isn't working (DlgShootOlcDrive.c GetGuidanceIndex DriveMode err), but can be fixed easily with MPU_SPELL_SET_OTHER_CAM(1300D, 600D) in mpu.c, rather than 60D. Will commit that after updating the tests (not today). It's just a nitpick anyway (it won't interfere with porting ML).

edit: fix committed.




Quote from: a1ex on January 15, 2018, 07:43:17 AM
@dfort: the M2 signature issue was fixed; check c33141cd12a9 and the (updated) guide.

Great. I'll try it out and report on the EOSM2 topic. BTW--great progress on QEMU. This last build went pretty much on autopilot.


a1ex i found all that were present in the state-object.h. (like three) are there more needed? did not scanl through all the code .. i am still investigating, why the state error occures

I still get an error in the Propmgr. But since i did not check that all the props are there and correct it is expected.


I've got a different address for EVF_STATE with the above commands:

[     Startup:fe1a3d20 ] CreateStateObject(EvfState, 0xfe8b2260, 14, 10)
[     Startup:fe127b1c ] CreateStateObject => 9334c4 at fe1a3d24
[ram]    at Startup:FE1A3D24:FE127B20 [0x00037930] <- 0x9334C4  : was 0x0;

The PropMgr error is very interesting - PROP_HANDLER( PROP_MVR_REC_START ) in audio-common.c - it probably affects all other models without CONFIG_AUDIO_CONTROLS, but somehow ended up unnoticed. Some serious cleanup needed here.

Best guess: Canon's give_semaphore didn't throw an assertion on invalid semaphores in earlier firmwares - at least in 5D3, it just returns an error code without assert (so that invalid give_semaphore call was basically a NOP).


Ok with your method i have now a lot more States: :) thx ..

Dmstate: 0x39DD0
PropState: 0x38DB0
MFCMGRState: 0x39B50
EmState 0x36F24
FMnormalState 0x38558
SrmState 0x36FD0
Srmexmem1State 0x3702C
Srmexmem2State 0x37030
ScsState 0x35A74
ScseshutState 0x35A78
ScssrState 0x35A7C
SbsState 0x35AE8
SpsState 0x35B60
TomState 0x38500
FssState 0x36E94
AudioLevelStateSig 0x38CD0
SdsFrontState 0x36158
SdsFrontState 0x3615C
SdsFrontState 0x36160
SdsFrontState 0x36164
SdsFrontState 0x36168
SdsRearState 0x36078
SdsRearState 0x3607C
SdsRearState 0x36080
SoundEffetStateSig 0x38CDC
AsifState 0x38CF0
ActrlState 0x3D9DC
MovwState 0x3872C
MovrecState 0x38744
MovplayState 0x38750
MovrState 0x3BBE8
LvcdevState 0x37EE4
GmtState 0x933F68 // somehow off but valid
GmtMovieState 0x933F6C
GmtwakuState 0x933F70
EvfState 0x37930
ColorcalcState 0x380F8
AewbState 0x941C70
LvfaceState 0x37990
MotionDetectState 0x37DE8
MotionManagerState 0x94BB10
UsbControlPipe 0x6135C
UsbDataPipeBulkIn 0x61360
UsbDataPipeBulkOut 0x61364
UsbDataPipeInterupt 0x61368
UsbDeviceEvent 0x6136C
PtpdpsState 0x98D644
CeresState 0x38540
FcsState 0x36EA4
NwComState 0x3A504
MetactgState 0x3BC50
FrState 0xA478B4
FwState 0xA47AF0
VoiState 0x3BB34
SoundState 0x3BBCC
WavreaderState 0x40400
MrkState 0x3BB20
RdState 0x38124
DpState 0x371B4
DpimgeditState 0x3792C
InnerdevelopState 0x39C68
SasState 0x36270
SasState 0x36274
SasState 0x36278
SasState 0x3627C
SasState 0x36280
DisplayState 0x318B8
DisplayStateWithImgMute 0x318BC


is it posible they changed the way how they address the audio_ic? in powerSpeakerOnForWav they call it normaly like this:

ROM1_7:FF06A570 PowerSpeakerForWAV                      ; CODE XREF: PowerAudioOutput+24p
ROM1_7:FF06A570                 STMFD   SP!, {R4,LR}
ROM1_7:FF06A574                 ADR     R2, aPowerspeakerforwav ; "PowerSpeakerForWAV"
ROM1_7:FF06A578                 MOV     R1, #3
ROM1_7:FF06A57C                 MOV     R0, #0x14
ROM1_7:FF06A580                 BL      DryosDebugMsg
ROM1_7:FF06A584                 LDR     R4, =byte_274C
ROM1_7:FF06A588                 MOV     R1, #0
ROM1_7:FF06A58C                 LDR     R0, [R4,#(dword_2780 - 0x274C)]
ROM1_7:FF06A590                 BL      take_semaphore
ROM1_7:FF06A594                 LDR     R0, =0x5507
ROM1_7:FF06A598                 BL      _audio_ic_write
ROM1_7:FF06A59C                 LDR     R0, =0x4903
ROM1_7:FF06A5A0                 BL      _audio_ic_write
ROM1_7:FF06A5A4                 MOV     R0, #0x4B00
ROM1_7:FF06A5A8                 BL      _audio_ic_write
ROM1_7:FF06A5AC                 LDR     R0, =0x2713
ROM1_7:FF06A5B0                 BL      _audio_ic_write
ROM1_7:FF06A5B4                 LDR     R0, =0x271F
ROM1_7:FF06A5B8                 BL      _audio_ic_write
ROM1_7:FF06A5BC                 LDR     R0, =0x4901
ROM1_7:FF06A5C0                 BL      _audio_ic_write
ROM1_7:FF06A5C4                 ADD     R0, R4, #0x58
ROM1_7:FF06A5C8                 LDRB    R0, [R0,#(byte_2A4F - 0x27A4)]
ROM1_7:FF06A5CC                 ORR     R0, R0, #0x6B00
ROM1_7:FF06A5D0                 BL      _audio_ic_write
ROM1_7:FF06A5D4                 LDR     R0, [R4,#(dword_2780 - 0x274C)]
ROM1_7:FF06A5D8                 LDMFD   SP!, {R4,LR}
ROM1_7:FF06A5DC                 B       give_semaphore
ROM1_7:FF06A5DC ; End of function PowerSpeakerForWAV

but on the 1300D it looks more like this:

ROM1:FE11CE60 PowerSpeakerForWAV                      ; CODE XREF: sub_FE11D1CC:loc_FE11D21Cp
ROM1:FE11CE60                                         ; SelectOutCheckFOut+68p
ROM1:FE11CE60 STMFD   SP!, {R4,LR}
ROM1:FE11CE64 ADR     R2, aPowerspeakerforwav         ; "PowerSpeakerForWAV"
ROM1:FE11CE68 MOV     R1, #3
ROM1:FE11CE6C MOV     R0, #0x14
ROM1:FE11CE70 BL      DryosDebugMsg
ROM1:FE11CE74 LDR     R4, =unk_31B5C
ROM1:FE11CE78 MOV     R1, #0
ROM1:FE11CE7C LDR     R0, [R4,#(unk_31BA4 - 0x31B5C)]
ROM1:FE11CE80 BL      takeSemaphore_ram
ROM1:FE11CE84 LDR     R0, =unk_FE8CAC8C
ROM1:FE11CE88 BL      sub_FE2B36D4
ROM1:FE11CE8C LDR     R0, [R4,#(unk_31B74 - 0x31B5C)]
ROM1:FE11CE90 CMP     R0, #0
ROM1:FE11CE94 BNE     loc_FE11CEB0
ROM1:FE11CE98 LDRB    R1, [R4,#(unk_31B61 - 0x31B5C)]
ROM1:FE11CE9C LDR     R0, =unk_FE8CACC8
ROM1:FE11CEA0 BL      sub_FE2B3A18
ROM1:FE11CEA4 LDRB    R1, [R4,#(unk_31B61 - 0x31B5C)]
ROM1:FE11CEA8 LDR     R0, =unk_FE8CAD20
ROM1:FE11CEAC BL      sub_FE2B3A18
ROM1:FE11CEB0 loc_FE11CEB0                            ; CODE XREF: PowerSpeakerForWAV+34j
ROM1:FE11CEB0 MOV     R0, #1
ROM1:FE11CEB4 STR     R0, [R4,#0x2C]
ROM1:FE11CEB8 LDR     R0, [R4,#0x48]
ROM1:FE11CEC0 B       giveSemaphore_ram
ROM1:FE11CEC0 ; End of function PowerSpeakerForWAV

Am I missing a point? can i switch it of somehow? The whole audio stuff is now via serial i would guess..

stefan@morbo-3: ~/Develop/qemu% ./ 1300D,firmware="boot=0" -d debugmsg |& grep SerialCommand_Send
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x1080000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x3960000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x5000000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x7000000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x9030000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xb050000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xf080000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x21010000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xff001b58]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x21020000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xff001b58]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x3960000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x5000000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x7000000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x9030000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xb050000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xf080000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd010000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd030000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd070000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xd0f0000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x55080000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x3b160000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x27130000]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0xff004e20]
[     Startup:fe2b3724 ] (14:03) SerialCommand_Send[0x271f0000]
[   AudioCtrl:fe2b3724 ] (14:03) SerialCommand_Send[0x3b160000]

vs. old

stefan@morbo-3: ~/Develop/qemu% ./ 600D,firmware="boot=0" -d debugmsg |& grep 'Reg('               
[     Startup:ff06a16c ] (14:03) Reg(0x0D) Data(0x0001)
[     Startup:ff06a16c ] (14:03) Reg(0x0F) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0x01) Data(0x0008)
[     Startup:ff06a16c ] (14:03) Reg(0x01) Data(0x0008)
[     Startup:ff06a16c ] (14:03) Reg(0x03) Data(0x0096)
[     Startup:ff06a16c ] (14:03) Reg(0x05) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0x07) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0x09) Data(0x0003)
[     Startup:ff06a16c ] (14:03) Reg(0x0B) Data(0x0005)
[     Startup:ff06a16c ] (14:03) Reg(0x0F) Data(0x0004)
[     Startup:ff06a16c ] (14:03) Reg(0x0D) Data(0x0003)
[     Startup:ff06a16c ] (14:03) Reg(0x0D) Data(0x000f)
[     Startup:ff06a16c ] (14:03) Reg(0x61) Data(0x000b)
[     Startup:ff06a16c ] (14:03) Reg(0x63) Data(0x000b)
[     Startup:ff06a16c ] (14:03) Reg(0x65) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0xB1) Data(0x0001)
[     Startup:ff06a16c ] (14:03) Reg(0xB3) Data(0x0008)
[     Startup:ff06a16c ] (14:03) Reg(0xB5) Data(0x0008)
[     Startup:ff06a16c ] (14:03) Reg(0xB7) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0xB9) Data(0x000b)
[     Startup:ff06a16c ] (14:03) Reg(0xBB) Data(0x0070)
[     Startup:ff06a16c ] (14:03) Reg(0xBD) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0xBF) Data(0x0001)
[     Startup:ff06a16c ] (14:03) Reg(0xC1) Data(0x0004)
[     Startup:ff06a16c ] (14:03) Reg(0xC3) Data(0x0005)
[     Startup:ff06a16c ] (14:03) Reg(0xC5) Data(0x000d)
[     Startup:ff06a16c ] (14:03) Reg(0xC7) Data(0x0070)
[     Startup:ff06a16c ] (14:03) Reg(0xC9) Data(0x0010)
[     Startup:ff06a16c ] (14:03) Reg(0xCB) Data(0x0000)
[     Startup:ff06a16c ] (14:03) Reg(0x31) Data(0x0002)
[     Startup:ff06a16c ] (14:03) Reg(0x21) Data(0x0001)
[     Startup:ff06a16c ] (14:03) Reg(0x21) Data(0x0002)
[     Startup:ff06a16c ] (14:03) Reg(0x21) Data(0x0006)
[     Startup:ff06a16c ] (14:03) Reg(0x3B) Data(0x001b)
[     Startup:ff06a16c ] (14:03) Reg(0x6B) Data(0x0010)


Yes, there may be different audio chips - the ones we know are listed here:

Audio functionality for recent models was not reverse engineered yet (partly because Canon has manual audio controls, unlike on older DIGIC 4). There is the new-sound-system branch which attempts to rewrite the audio side, but last time I've tried it, it was crashing quite often, so it needs some polishing. As I don't really use the audio features, its priority is low from my side (but others are, of course, welcome to look into it).


ok the stubs schould be more or less complete now there is current interupt and task max missing but the rest should be correct. do you know why the propmgr has the assert called?


Yes, answered earlier.

current_interupt should be 0x640 (from the GDB script); task_max should be visible in DryOS info functions in the serial console (mkcfg, objinfo).


ok.. without the PROP_HANDLER( PROP_MVR_REC_START ) the image is booting without errors on qemu .. what should be the next steps?


Quote from: DeinGott on January 18, 2018, 09:35:34 PM
ok.. without the PROP_HANDLER( PROP_MVR_REC_START ) the image is booting without errors on qemu .. what should be the next steps?

Oh dear, things have gotten kind of hung up.  I wonder what next steps are, too...


Some ideas:

- find the date of the latest changeset mentioning 1300D
- play with ML menus in QEMU and document which ones fail
- run api_test.lua,, (some tests will fail in QEMU; document them)
- double-check the stubs (at least one of them is wrong), consts and other model-specific parameters (prefer to be done by other users)
- enable CONFIG_PROP_REQUEST_CHANGE and test the features enabled by this as well (in the emulator, of course)
- look in other recent porting threads; nothing useful?
- proof-read the QEMU guide (already asked more times than I can count)
- anything else you think you can improve


Has no change been made?
Canon 1300D, 500D, EOS M, EOS M2