Author Topic: Canon EOS 1300D / Rebel T6 (Read 274048 times)

a1ex · « **Reply #150 on:** January 13, 2018, 09:00:10 AM »

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

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

No debug logs enabled.

adamnock · « **Reply #151 on:** January 13, 2018, 09:03:32 AM »

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

nikfreak · « **Reply #152 on:** January 13, 2018, 09:40:43 AM »

congrats

shadowlab · « **Reply #153 on:** January 13, 2018, 08:19:20 PM »

Hey A1ex,

When I was going over your published your commit https://bitbucket.org/hudson/magic-lantern/commits/77336969687da991a4d87269d3260f67a00e829e?at=1300D

I noticed

Code: [Select]

+# 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:

http://support-in.canon-asia.com/contents/IN/EN/0400290302.html

DeinGott · « **Reply #154 on:** January 14, 2018, 10:30:53 PM »

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

dfort · « **Reply #155 on:** January 14, 2018, 10:40:48 PM »

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.

a1ex · « **Reply #156 on:** January 15, 2018, 07:43:17 AM »

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

Code: [Select]

hg pull --rebase -r 1300D https://bitbucket.org/hudson/magic-lantern
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...

DeinGott · « **Reply #157 on:** January 15, 2018, 06:46:30 PM »

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

https://bitbucket.org/shorst/magic-lantern

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?

Code: [Select]

#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

DeinGott · « **Reply #158 on:** January 15, 2018, 10:11:34 PM »

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)

Code: [Select]

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

a1ex · « **Reply #159 on:** January 15, 2018, 10:40:43 PM »

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: https://a1ex.bitbucket.io/ML/states/index.html

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:

Code: [Select]

./run_canon_fw.sh 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.

Code: [Select]

./run_canon_fw.sh 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:

Code: [Select]

b *0xFE2BEA5C
commands
  silent
  print_current_location
  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
  commands
    silent
    print_current_location
    printf "CreateStateObject => %x at %x\n", $r0, $pc
    c
  end

  c
end

Invocation:

Code: [Select]

./run_canon_fw.sh 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:

Code: [Select]

( ./run_canon_fw.sh 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.

kennetrunner · « **Reply #160 on:** January 15, 2018, 10:56:52 PM »

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

a1ex · « **Reply #161 on:** January 15, 2018, 11:04:56 PM »

Arrow keys are working here; QEMU identifies the keys from scancode, so look them up here: http://www.marjorie.de/ps2/scancode-set1.htm

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.

kennetrunner · « **Reply #162 on:** January 15, 2018, 11:13:39 PM »

@DeinGott - about the symbols not found issue: this post might help https://www.magiclantern.fm/forum/index.php?topic=17969.msg183657#msg183657

dfort · « **Reply #163 on:** January 16, 2018, 12:10:26 AM »

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.

DeinGott · « **Reply #164 on:** January 16, 2018, 09:00:26 AM »

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.

a1ex · « **Reply #165 on:** January 16, 2018, 10:39:56 AM »

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

Code: [Select]

[     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).

DeinGott · « **Reply #166 on:** January 16, 2018, 03:47:29 PM »

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

thx ..

Code: [Select]

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

DeinGott · « **Reply #167 on:** January 16, 2018, 09:46:05 PM »

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

Code: [Select]

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:

Code: [Select]

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
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:FE11CEBC LDMFD   SP!, {R4,LR}
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..

Code: [Select]

stefan@morbo-3: ~/Develop/qemu% ./run_canon_fw.sh 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

Code: [Select]

stefan@morbo-3: ~/Develop/qemu% ./run_canon_fw.sh 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)

a1ex · « **Reply #168 on:** January 16, 2018, 10:16:36 PM »

Yes, there may be different audio chips - the ones we know are listed here: http://magiclantern.wikia.com/wiki/Datasheets

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).

DeinGott · « **Reply #169 on:** January 16, 2018, 10:48:23 PM »

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?

a1ex · « **Reply #170 on:** January 17, 2018, 09:02:10 AM »

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).

DeinGott · « **Reply #171 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?

cbbrowne · « **Reply #172 on:** January 23, 2018, 09:44:47 PM »

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...

a1ex · « **Reply #173 on:** January 24, 2018, 09:18:42 AM »

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, bench.mo, selftest.mo (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

critix · « **Reply #174 on:** February 28, 2018, 05:52:55 PM »

Has no change been made?
Thanks.

News:

Author Topic: Canon EOS 1300D / Rebel T6 (Read 274048 times)

dfort

dfort