Good work. Can you share some details about how you did it?
00320: InitFileModules:0x010f0007: [CMD55, 0x00000000]00320: CommonDrivers:0x010f192d: [Read, 0x00000001]00320: InitFileModules:0x010eff7f: [CMD41, 0x51100000]00320: CommonDrivers:0x010f192d: [Read, 0x00000001]00320: InitFileModules:0x003a8b3b: [Read, 0xff8000ff]00320: InitFileModules:0x003a8b47: [Read, 0x204f3f41]00320: InitFileModules:0x010effad: [Resp, 0x204f3f41.ff8000ff]00320: InitFileModules:0x010f0007: [CMD55, 0x00000000]00330: PhySw:0x010f192d: [Read, 0x00000001]00330: InitFileModules:0x010eff7f: [CMD41, 0x51100000]00330: CommonDrivers:0x010f192d: [Read, 0x00000001]00330: InitFileModules:0x003a8b3b: [Read, 0xff8000ff]00330: InitFileModules:0x003a8b47: [Read, 0x20833f41]00330: InitFileModules:0x010effad: [Resp, 0x20833f41.ff8000ff]00350: InitFileModules:0x010f0007: [CMD55, 0x00000000]00350: DefMarkRomCopyTask:0x010f192d: [Read, 0x00000001]00350: InitFileModules:0x010eff7f: [CMD41, 0x51100000]00350: DefMarkRomCopyTask:0x010f192d: [Read, 0x00000001]00350: InitFileModules:0x003a8b3b: [Read, 0xff8000ff]00350: InitFileModules:0x003a8b47: [Read, 0x20833fc0]00350: InitFileModules:0x010effad: [Resp, 0x20833fc0.ff8000ff]00350: InitFileModules:0x010eead7: [CMD11, 0x00000000]00350: DefMarkRomCopyTask:0x010f192d: [Read, 0x00000002]00350: InitFileModules:0x010f1605: [Read, 0x00000003]00350: InitFileModules:0x010eeaff: CMD11_VoltageSwitch(0) sdconWaitInterrupt() NG!00430: InitFileModules:0x010eeb41: [Read, 0x8000000f]00430: InitFileModules:0x010ee391: [CMD2, 0x00000000]
The function call in Startup task that we always remove (the diskboot one) also initializes the card, but probably not in its full performance mode (just so it can access the card and load diskboot.bin, if any). Too bad that we can't log how that works the first time (it would require modified firmware).
Your finding likely means that it's actually CHDK that slows down the card.
Forcing UHS mode is not likely a good solution (not all cards are UHS), we need to find something else. Either resetting the card, or keeping it powered off for some time.
Code: [Select]00320: CommonDrivers:0x010f192d: [Read, 0x00000001]
00320: CommonDrivers:0x010f192d: [Read, 0x00000001]
I was trying to uncomment function fc0637b2 (commenting fc063804) but I've got some errors during SD i/o.
I was trying to measure SD speed using Canon basic script without CHDK but it works slowly (4 MB/s)
QuoteForcing UHS mode is not likely a good solution (not all cards are UHS), we need to find something else. Either resetting the card, or keeping it powered off for some time.It could increase system startup time.
What's 'Read"?
010F3F08 SD_read_reg ; CODE XREF: sddomWaitR1Busy+12p010F3F08 ; sddomWaitR1Busy+40p010F3F08 ; sddomWaitR1Busy+5Ap010F3F08 ; sddomWaitR1Busy+76p ...010F3F08 1E 4A LDR R2, =0x1106C38010F3F0A A1 F1 60 51 SUB.W R1, R1, #0x38000000010F3F0E 52 F8 20 00 LDR.W R0, [R2,R0,LSL#2]010F3F12 40 58 LDR R0, [R0,R1]010F3F14 70 47 BX LR
Yes, but question is how much. Some early ports do something like that in their loader (or at least, comments indicate that).We could also switch off power right at CHDK start (boot.c) and restore it before InitFileModules starts.
Overriding S18A bit I've managed to increase my benchmark results:
con 3> =return call_event_proc('Driver.Create')4:return:0con 4> =return call_event_proc('SetSDPwrPort',0)5:return:0con 5> =return call_event_proc('SetSDPwrPort',1)6:return:0
00330: InitFileModules:0x010effad: [Resp, 0x20833f41.ff8000ff]
It would be more helpful if you will log the responces from card, like this Code: [Select]00330: InitFileModules:0x010effad: [Resp, 0x20833f41.ff8000ff]
Stupid question: why do we need to restart main firmware from the beginning instead patching CreateTask function after DISKBOOT.BIN will be loaded?
I'm not clear what you are asking for. If you can explain what specifically this is, I'll try to do it, but my free time is limited so I'd rather not spend it guessing.
The address DISKBOOT.BIN is loaded is on top of the OS data (on digic 6, it's 0x8000, on older cams 0x1900, both right on top of all the kernel stuff), so the running system is totally clobbered once the diskboot is loaded. That's why we do the whole dance with copy and restart, and then modify the heap address in the Canon code to skip the space we copied our binary to.
con 4> =return call_event_proc('SetSDPwrPort',0)
00370: InitFileModules:0x010eff7f: [CMD41, 0x51100000]00370: ClockSave:0x010f192d: [Read Reg:0xc8060010=0x00000001]00370: InitFileModules:0x003a8b53: [Read Reg:0xc8060034=0xff8000ff]00370: InitFileModules:0x003a8b5f: [Read Reg:0xc8060038=0x20833fc1]00370: InitFileModules:0x010effad: [Resp, 0x20833fc1.ff8000ff]
Quote from: reyalp on 28 / April / 2017, 02:08:50con 4> =return call_event_proc('SetSDPwrPort',0)I put this in the boot () function before installing the patches.
But I'm not sure about this solution: SD power is switched off but the card still can get power via data lines...