Skip to content

Conversation

@benwynn
Copy link

@benwynn benwynn commented Oct 29, 2025

The current code only calculates sectors for SDHC, with a max of 32G
The new code will calculate sectors for SDXC, with a max of 2T

C_SIZE is 22 bits[69:48] and the high 2 bits of csd[7] are required
to be 0, currently, so i'm not masking them off.

The max value for C_SIZE is 0x3FFEFF, so C_SIZE+1*1024 is a 32-bit number.

The current code only calculates sectors for SDHC, with a max of 32G
The new code will calculate sectors for SDXC, with a max of 2T

C_SIZE is 22 bits[69:48] and the high 2 bits of csd[7] are required
to be 0, currently, so i'm not masking them off.

The max value for C_SIZE is 0x3FFEFF, so C_SIZE+1*1024 is a 32-bit number.

Signed-off-by: Ben Wynn <bwynn@glowie.com>
@benwynn benwynn changed the title drivers/storage/sdcard: updating sector calculation for CSD v2.0 sdcard: Updating sector calculation for SDXC. Oct 29, 2025
@benwynn
Copy link
Author

benwynn commented Oct 30, 2025

will fix issue #1053

@AJMansfield
Copy link

Is there anything you could do to add a test for this to sdtest.py?

@benwynn
Copy link
Author

benwynn commented Nov 10, 2025

Is there anything you could do to add a test for this to sdtest.py?

I'd be happy to work on it... is there a framework for mocking out the hardware, or is that test run against a particular sdcard?

@AJMansfield
Copy link

AJMansfield commented Nov 10, 2025

I think it's just run against real hardware, though of no particular spec; changing the test to one that requires SDXC hardware to pass isn't an issue. (From experience, it's actually more difficult to get non-SDXC cards these days...)

As for what operation to actually test with, you're probably more familiar than I here --- but the thought that comes to mind is if there's a way to attempt to operate on a large sparse file or a small file that's in a high-numbered sector past the end of the max SDHC sector number. If the only way to actually exercise this change is to write >32GB of data though, that should probably be added as a second test that isn't run by default --- but having the test code already prepared will make it a lot easier for a maintainer to verify the change either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants