This is the response from SD card to some commands. We need CMD41:
And Upgrader.bin works the same?
QuoteBut I'm not sure about this solution: SD power is switched off but the card still can get power via data lines...Yes, that's a concern, the SD spec specifically mentions that "DAT, CMD, and CLK should be disconnected or drivento logical 0 by the host" when the card is powered down.Perhaps there's a more proper version of SD power control somewhere that also drives the above mentioned pins to a low state?
But I'm not sure about this solution: SD power is switched off but the card still can get power via data lines...
Do we know the SetSDPwrPort function doesn't already do this?
On M3 it switches only GPIO 6.
But there is another function 0x010E16C8 called from SD1stInit task that changes the state of six GPIO ports including GPIO 6.
It worked, but card speed remained below 21MB/s. On this camera, startup times increased significantly when I left the SD powered off.
Now I have tested the new routine (0x10e173c for M10), same behaviour as with the simple SetSDPwrPort (fast boot, UHS active). It needs a running OS (calls SleepTask), so I called it from Startup task.
In the previous thread on SD power, I noticed that turning it off and then trying file access worked, after a quite long delay. My guess is that something errors out and resets, but from G7X it seems like the reset doesn't include getting back to high speed mode. It wouldn't be surprising for the firmware to stay on a slow mode once an error has been encountered
QuoteNow I have tested the new routine (0x10e173c for M10), same behaviour as with the simple SetSDPwrPort (fast boot, UHS active). It needs a running OS (calls SleepTask), so I called it from Startup task.I tried this on g7x (100d sub_010e638b), called where diskboot start code used to be. Using the wintec-2012 card SD info function shows 1.8V Support, and benchmarks are much improved (writes around ~32 MB/s, though I did have one run around 20)
I notice that in the Canon code (sub_010e647c, SdPower.c), this function is called based on the return value of sub_010e659a.
If this routine is indeed doing what we think it's doing (lowering SD signal lines followed by removing SD power), calling it during boot should have the potential of clearing up much or all our card problems (on previous DIGICs too).
I'm considering releasing test builds with this "card off during boot" mod. It doesn't seem like it could be harmful.
The sx280 probably needs more testing, to determine whether it is capable of UHS speed (the hw obviously is).
Too bad that I can't check what really happens on the SD lines.
I will try to make a benchmark that can be run without CHDK.
It's strange that calling 0x010E16C8 function in the beginning of task_Startup has no affect.
but it's host driven, so should be at L logical level, I guess
Another idea: perhaps we could try executing the diskboot-related routine (after powering down the card), only removing the part that actually loads the diskboot...?
=<loadcbbench.lua
.return call_func_ptr(<load address>,<Open address>,<Write address>,<Close address>,<GetSystemTime address>)