sd card interface logic and kickstart routines presupposes a block size of 512 byte

[Mat2]

If I am not wrong, the SD interface logic assume an internal buffer size of 512 byte. However, the SD card specification > 1.x extend possible block sizes from 512 up to 2048 bytes. As there exist known access problems for some SD card controllers assuming lower block lengths as initially registered, future, card-producer specific compatibility problems are likely.

There exist multiple dependencies which limit a fast work around:

• 1. The SD interface logic is block size dependent (sdcardio.vhdl, lines 1181..1192)
• The FDC emulation logic also assumes a natural block size of 512 byte (= logic block size)
• Relevant kickstart routines depend on a buffer size of 512 byte (kickstart.a65, lines 1181-1192)
• There exist no independent abstraction between kickstart, SD interface logic and controller interface

Suggestion:
In most cases this possible compatibility problem is avoidable by initially limit the registered block size to 512 byte for read and write operations (Transfer Block Size register = 0200h). This should be done somehow at controller reset (sd_reset). However, it's a hack which does not work in few cases.

[gardners]

If I understand correctly, for the vast majority of SD cards, we can set them to 512 byte blocks, and avoid the problem that way. My feeling is that this has a compelling simpliicity, compared with complicating the whole stack with variable block sizes.

Paul.

[Mat2]

That's correct. Exception are some controllers which seem only support block sizes of a constant depth. These are fortunately not widespread in use.

[gardners]

Hello,

Okay. I would put a higher priority on us adding the 4-bit wide transfer
mode, which would greatly increase the maximum speed of the SD interface
ahead of other block sizes.

Paul.

On Sun, May 8, 2016 at 7:12 PM, Matthias Schirm [email protected]
wrote:

That's correct. Exception are some controllers which seem only support
block sizes of a constant depth. These are fortunately not widespread in
use.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#52 (comment)

[lgblgblgb]

Hmm, sorry for dropping in, but as far as I know only SPI mode usage of SD cards does not requires "host license" ... But IANAL, and of course it's not that I want to be not constructive here ... AFAIK SD cards specifies 25MHz of the maximum SPI clock but maybe it's card dependent (well, 400KHz is the minimal which should be supported - AFAIK, again - but I guess any modern cards would laugh on this rule). But even with 25MHz, the 'raw' bandwidth would be around to 3Mbytes/sec, which is not so bad ... In the SD-card cartridge for the Enterprise-128 computer (Z80 based) fixed 14MHz is used without any problem with any cards I could test with, even breaking the rule that init time SPI clock should be only 400KHz at the detection phase, or such (if I remember correctly) ... Also, I haven't met any cards which cannot be switched into 512 bytes sector mode (though with writes, it can degrade the write performance at least, better than the suggested block size for the given card, that's true ...).

[Mat2]

as written, there exist a few controllers which can't handle different sector lengths. I have here one of such cards for testing purposes (Samsung) and as I see it this is caused in certain circumstances by ambiguous formulations of the standard.

[gardners]

We are already using ~25MHz (24MHz IIRC), so we can already get close to
3MB/sec. However, it would still be nice to be able to get more like
10MB/sec.

Paul.

On Mon, May 9, 2016 at 4:27 AM, Matthias Schirm [email protected]
wrote:

as written, there exist a few controllers which can't handle different
sector lengths. I have here one of such cards for testing purposes
(Samsung) and as I see it this is caused in certain circumstances by
ambiguous formulations of the standard.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#52 (comment)

[lgblgblgb]

Sorry, I guess I seriously underestimated the needed power here :)