feat: add SD overclocking support for DIGIC 4 SD bodies

[wavesoft]

This PR adds a new Debug menu option that appears on DIGIC 4 bodies with an SD card and enables overclocking the SD controller itself.

Normally SDHC cards operate at a maximum of 48 MHz in High-Speed mode. Newer UHS-class cards are capable of higher clocks, but they usually do so in a UHS configuration at 1.8 V for better signal integrity. This change stays in the High-Speed path and instead raises the SD root clock (PLL1) above Canon's 48 MHz setting. PLL1 seems not to clock any other domains of the camera, making this a relatively safe addition.

The menu offers 48 / 72 / 96 / 144 MHz. An overclock at 72 MHz gives about 1.5× throughput, and at 96 MHz about 2×. Signal integrity is not guaranteed the higher you go - 144 MHz is labeled DANGER and wedged the SD driver on the card used for testing (with a dirty-flag recovery path that resets to stock after a failed boot). But you might have better luck with yours.

Settings are applied at boot after DryOS finishes card bring-up; a restart is required after changing the menu. Post-apply write/read verification refuses to keep a broken clock, and the feature self-disables if PLL1 is not the expected stock word at init (so it stays inert on unexpected silicon).

Benchmarked ~40 MB/s on an EOS 600D (with a SanDisk Extreme 128GB):

Notes

• Compile-gated to CONFIG_DIGIC_IV && !CONFIG_CF_SLOT (500D / 550D / 600D / 60D / 1100D). Distinct from the existing Digic 5+ sd_uhs module.
• Only validated PLL divider words are used; off-grid words can hard-hang the camera.

[mungewell]

This is awesome. Kind of late night here, but I picked the test build from your other ticket and tested SDCard with my T3i.

5min SDCard test:

• 30MB/s @ 72MHz
• 35MB/S @ 96MHz
• failed @ 140MHz

Lexar Silver Plus 256GB, LMSSIPL256G-BNABU

Looks like my MLVApp doesn't like the compressed raws, but I was able to shoot a whole 9s of 1280x720 14bit (uncompressed) 29.97fps.... way better than before.

I'll take the camera on a wander tomorrow to test out some other settings.

[mungewell]

PS. I also have a T2i if you want me to test that too... ;-)

[reticulatedpines]

Please be aware that this is not thoroughly tested and will have higher risk than a normal build!

Looks like my MLVApp doesn't like the compressed raws, but I was able to shoot a whole 9s of 1280x720 14bit (uncompressed) 29.97fps.... way better than before.

Can you describe "doesn't like" in more detail? Is there an error message? What behaviour do you see?

[mungewell]

@reticulatedpines Understood, camera (and/or hair) may burst into flames without warning.

I was incorrect about MLVApp. It threw an error with one of my (corrupt) files. Otherwise 1st frame of 14bit-lossess is junk, but the rest are OK. Off to shoot more...

[wavesoft]

Right, that's what I noticed too, I think I need to increase the number of warm-up frames. It sometimes is 4, some other times it is 6, but I guess it can sometimes be longer.... (or I can find out what is causing this warm-up corruption 🤣)

[reticulatedpines]

Re getting this code into the repo, the best way is probably to integrate both this code, and the 200D code in sd.c into sd_uhs module, then rename that module sd_clock (since it has three different methods to change SD clock, and they're not all UHS related).

Do you want to do that for this code? That way you get your name on it. If you don't care, I can do all of it, though it likely won't happen this month.

[wavesoft]

Yup, sounds good, I will prepare the mod 👍

[wavesoft]

Pushed the conversion into a module. Folded Digic 5 and Digic 4 versions into the same module (now named sd_clock.

Once loaded you can find the menu option on prefs:

Tested on EOS 600D, looking for testers for other cameras 😄

Here are some new builds (Digic 4):

• EOS 500D / Rebel T1i
• EOS 550D / Rebel T2i
• EOS 600D / Rebel T3i

And some for Digic 5 (for validation):

• EOS 650D / Rebel T4i
• EOS 700D / Rebel T5i

Let me know if you need any specific build for your camera

[mungewell]

Here you go... got lazy and ran the 1minute benchmark.

T2i: Lexar "633x" 32GB
(LSDMI32BBNL633A)
1min = 1GB
48: 14.1 / 22.8 / 21.0 / 22.6 GB/s
72: 27.8 / 34.7 / 27.8 / 34.9 GB/s
96: 33.7 / 41.8 / 33.7 / 41.1 GB/s

T2i: Lexar "Silver Plus" 256GB
(LMSSIPL256G-BNABU)
1min = 1GB
48: 21.3 / 22.3 / 28.9 / 22.4 GB/s
72: 27.6 / 34.3 / 27.5 / 23.6 GB/s
96: 33.8 / 41.2 / 33.8 / 41.6 GB/s

T3i: Lexar "633x" 128GB
(LSDMI128BBNL633A)
1min = 1GB
48: 21.6 / 22.6 / 21.6 / 22.7 GB/s
72: 31.2 / 32.2 / 31.2 / 32.1 GB/s
96: 38.2 / 32.2 / 32.0?/ 45.2 GB/s
96: 38.2 / 44.7 / 38.5 / 44.6 GB/s

T3i: Lexar "Silver Plus" 256GB
(LMSSIPL256G-BNABU)
1min = 1GB
48: 21.8 / 22.3 / 21.7 / 22.3 GB/s
72: 30.9 / 30.7 / 30.9 / 30.2 GB/s
96: 36.6 / 40.3 / 36.4 / 36.0 GB/s

[reticulatedpines]

I can't take these commits the way they're currently structured.

The refactor of sd_uhs code is mostly line noise and undesired, with significant changes to comments that make them less informative. I think there are some good changes in here, but it's hard to tell which are which; this commit does too much. Decisions about how to change menu items always need discussion with the team (we support a lot of cams and it's very common for some to have weird menu or feature quirks).

The first commit in the current sequence adds a module: 6e56718

That module is removed two commits later. Much better to never have the sd_overclock module. You needed it for dev work, but upstream never needs it; make it look like you put it in sd_uhs directly.

Please make the first commit in this PR add your code to the existing sd_uhs module, in some way that at least one, physically tested D4 cam is supported, and all existing D5 support is unchanged.

Any other changes are not required, but you can attempt them if you'd enjoy it. If you want to, please make these later commits, so it's easier for me to take the essential changes first without needing to revert anything.

[wavesoft]

Ok, so I did a clean-up on the PR, making the changes purely additive so that it's easier to review. I can follow-up with another PR (or a commit if you like) that cleanly renames that module?

[covershow1-wq]

Let me know if you need any specific build for your camera

Would be great to have a build for 1100D. I have a spare body for testing purposes.

[reticulatedpines]

Would be great to have a build for 1100D. I have a spare body for testing purposes.

Please don't use dev tickets as a place for unrelated requests. If we require additional testers we will notify people in our Discord. Thanks.