SD overclocking, success on digic6

reyalp

Inspired by magic lantern success enabling higher write speeds (see here for example), I decided to look into how hard it might be to do on digic 6 powershots. While I haven't yet investigated the more extreme stuff, it turns out useful gains appear to easily available, and in my testing so far (at least a few hundred DNGs in everyday use), I haven't encountered instability or data loss.

I'm still figuring out how to expose it in the CHDK UI, but I've checked in sig finder changes for digic 6 and 7 to find related functions.

For anyone interested in testing, the addresses can be used for the attached script. It currently supports G7 X, SX710 and SX730, but you can get all the require functions from your ports funcs_by_name.csv, or I can easily add others on request.

To use it:
Pick a speed id (details in following post), run the script. Use -1 to show the current speed id without changing anything. The default speed for U3 UHS cards appears to be 6. Lower values are slower. 7 and 8 are faster. 9 may be faster but requires an additional variable or calling a different function. Values 10 and up are likely for non-UHS cards.

Results, using cbbench:
Samsung EVO 64 GB stock

min 3070 max 3080 avg 3078 avg speed 41 MB/s

speed_id = 8

min 2000 max 2020 avg 2011 avg speed 63 MB/s

Above was in playback but rec mode seems similar. (Use autotest.m for rec if desired). Card freshly low level formatted exFAT in camera, then formatted FAT32 using mkfs.vfat, default settings.

The CHDK benchmark module shows broadly similar improvements, as well as dramatic improvement in read, but is highly variable. CHDK raw save time is around 500ms, which matches a ~60 MB/s write speed. Unfortunately, DNG benefits much less, due to reversing and likely inefficiency in the parallel reversing code doing a bunch of small writes and sleeps.

CrystalMark sequential write for this card using a cheap USB3 card reader is around 70 Mbyte/s

Notably, slower cards seems to work fine with high speed id numbers, they just don't gain as much performance. For example, junk 64 GB Team card that gets ~26 MB/s without overclocking scores around 34 with speed_id 8, while somewhat better PNY card goes from 35 to 50. Nothing in the relevant code path obviously jumps out as "if the card doesn't support, fall back to a lower speed", and the fact that the speed is higher than stock suggests it's not erroring and resetting. Not really clear what's happening, but perhaps these cards are fine talking to the SD interface at high speed, but are limited by how fast they can read/write flash.

In any case, I suspect this means even better results are possible with faster cards. I never bothered getting really fast cards for these cams since the they seemed to top out around 40 MByte/s with cards that go much faster in a card reader.

edit 2025/08/12:
fixed incorrect address for g7x 100d GetSpd.
2025/08/16:
Fixed "tune" elapsed time on success

sdoc.lua

1.95KB

reyalp

Technical details:
The basic speed setting is done a function I've called SD_ChgClkSpd (as is my usual practice, camel case names are inferred from Canon strings, but here I've added SD_ since it's otherwise not clear what clock it refers. Functions that didn't have an obvious name are snake_case).

Like most low level SD related functions, the first parameter is a value I call sd_id. This identifies the SD interface, and is almost certainly always zero for the SD card on powershots. However, many of these cameras contain a wifi interface that uses SDIO, and low level SD interface code appears to be somewhat shared on Digic 6 (and likely earlier), so there are code paths where other sd_id may really not be 0. On Digic 7, strings imply the "Lime" CPU has its own SDIO interface for the network card, so presumably it doesn't connect to the main arm cores.

SD_ChgClkSpd and related functions take a second argument I've called speed_id, which I interpret as a mode enum that identifies a set of speed related settings. On Digic 6, the possible values range from 0 to 19, though some values are not supported by the whole firmware. This eventually gets passed down to SetSDClkFrequency, which contains a switch statement that turns enum into values written to MMIOs.

The values are split into two ranges, from 0-9 and 10-19 on digic 6. Digic 7 follows a similar pattern but the numbers are different.

For SD cards on digic 6, the values of interest appear to be in the 0-9 range. Values from 10 and up appear to be non-UHS, both 1 gig SD (not SDHC) and 4g class 4 show 13.

A caller of SD_ChgClkSpd (sx710 101a 0x010e3020) suggests the speed_id values map to the following "Frequency" values

although I believe the actual setup is more complicated than a single "frequency", and it's not clear to me how this aligns (or not) with the SD specs, or which of the speed related values are changed by SD_ChgClkSpd

Additionally, SDIO / network related strings (sx710 101a 0x010e1a04) suggest the values from 10 and up

11: 18
12: 24
13: 48

For digic 7, g7x2 function (101a e051ec74) maps the "frequency" values as follows

Note a debug message "Not Support For Musa !!" is associated with 4 (80), although the function returns normally when that value is used. (AFAIK "Musa" refers to Digic 7 or some part of it)

Strings in the 200D firmware (1.0.1 e0247e0a) identify the following, which generally matches the g7x2 function

0: 1_8V_210K
1: 1_8V_20_0M
2: 1_8V_24_4M
3: 1_8V_48_8M
4: 1_8V_65_0M
5: 1_8V_97_5M
6: 1_8V_111_4M
7: 1_8V_130_0M
8: 1_8V_156_0M
9: 1_8V_195_0M
10: 3_3V_210K
11: 3_3V_20_0M
12: 3_3V_24_4M
13: 3_3V_48_8M

After several intermediate calls, SD_ChgClk ends up calling SetSDClkFrequency, which converts the speed_id value into a set of values that are mostly used to set MMIOs.

It's possible that programming these values directly would allow more extreme overclocks as ML has achieved. I haven't investigated much, but some values appear superficially similar to those set in ML overclocking code

I chose to use SD_ChgClkSpd rather than one of the intermediate functions because it takes and releases a semaphore associated with low level SD control, and the intervening calls don't do much.

sddomChangeClockSpeed checks the requested speed against limits, which very depending whether it's in the UHS (<10) or non-UHS range and clamps the value the allowed range. The UHS limit on D6 is 8, meaning the value 9 is not available although it's present in the underlying code. The limit can be bypassed by poking the limit variable (the script supports this if limitvar is defined). Doing this and overriding to 9 appears to give similar performance to 8, at least with the cards I have. These limits are in the firmware initialized data, in my testing they do not appear to vary at run time: In other words, it appears to be a soft limit in firmware, not based on the specific card.

The function between sddomChangeClockSpeed and SetSDClkFrequency (unnamed, sx710 101a 010f21ae) saves the new value in a "current speed id" variable.

Thanks to @names_are_hard for pointing me the 200d code, which contains a function (1.0.1 e02b72e😎 (SddomUHSTuning) which iterates through speed_id 6 - 9 and calls some function to test if it works. This made me realize I could probably just call SD_ChgClkSpd at runtime, where I'd previously assumed I'd have to hook it into the normal initialization process.

The SD_GetSpd functions returns two values via pointers. The first is unknown, but likely related to card card type. I've seen 1 for SD and non-UHS SDHC, and 4 for UHS. The second value is the speed id.

The "tune" options calls SddomUHSTuningSamplingPoint" (aka UTuSmPt) after changing the speed. The SD spec theoretically requires requires tuning at higher clock speeds, but I didn't notice any difference calling it or not. The 200d auto speed tuning mentioned above also appears to use something similar. On Digic 6, the function does not support speed id 9, and returns an error if this is set. The CMD 19 spam I noticed long ago is related to tuning.