SD high-speed not working yet

[cjb]

We've backed out the kernel support for high-speed SD, which was introducing instability. Felix reports that Marvell have it working, so we'll look at their fix after B-1.

There should be a release note with B-1 advising that high-speed cards work, but won't get >8MiB/s.

[johnlin]

Replying to jg: I test issue #397 on B1. That's ok! Can run >8MB BIOS:Q2B17 Image:MIT build:223

[johnlin]

Test Log File

[jg]

High speed SD is as fast as 20MB/second, and requires special SD cards to test. 8 MB/second isn't running at high speed; this needs verification with such a card (which we should have in the lab in Cambridge, and I recommend Quanta also acquire one of these new cards as well). I had to look in several stores to find one a couple months ago.

Richard, could you test ASAP today please? We may have picked up support as part of the 2.19.1 merge. If not, Andres will have work to do; but the CaFE chip definitely needs testing in high speed mode.

[jg]

I gather this is running, but we don't want the risk to introduce it into the build at this date. I'd like it in the first stable build after B2.

[PierreOssman]

I have tested the experimental kernel branch here. I have not been able to produce any error on any of the SD cards I have. So from my point of view, this is good to go.

[jg]

I've got a few more cards I'll have back in Cambridge we should test then; I'm not suggesting you wait to make it available, if you are happy with it, just that yet more testing should be done before we declare this solved.

And somehow, I ended up with John Gilmore's 4gig SD card, which is a new flavor that Pierre doesn't expect the driver to work with yet. Ensuring that at least it functions in "vanilla" card mode would be good.

How fast are you now seeing, anyway?

[wmb@…]

I tested high-speed SD read speed under OFW, using the 4 SD cards that Alan Cunningham of Marvell sent me. The results are:

 Card               Measured       Marketing fluff
 ----------------   -----------    ----------------------------
 Panasonic 512 MB   17.9 MB/sec    (Pro High Speed 20MB/s 133x)
 SanDisk     1 GB   20.8 MB/sec    (Extreme III 20 MB/s)
 pq1         2 GB   21.2 MB/sec    (HiSpeed 150)
 Transcend   4 GB   17.7 MB/sec    (UltraSpeed 150x)

In the measured speeds above, MB means 1,000,000 bytes, not 1024*1024.

The test program was as follows:

ok select /sd ok attach-card . ok high-speed \ In a future version I'll probably make high-speed automatic ok 1 if t( 10 0 do load-base 0 80 true r/w-blocks drop loop )t then

That does 16 (hex 10) iterations of a 128-block (hex 80) read and times the result. (Enclosing it in "1 if ... then" forces the interpreter to precompile the loop, so the time that it takes the interpreter to process the command line does not add to the measured time.

I also did a little hack to reduce the software overhead - I pre-translated the DMA addresses so OFW didn't have to spend time doing that during the transaction setup phase. Without that hack, the speeds were about 3% lower than those cited above.

Note that this is a raw read, without going through any filesystem processing. Just blocks.

Read lengths longer than 128 blocks at a time (e.g. 129 blocks) failed with a data timeout. I don't know where the limitation is at present. I only tried the longer reads with one card (the pq1).

[wmb@…]

The previously-cited problem with >128 block reads was a misconfiguration of register 4 in the CaFe SD section. That register establishes a limit on the length of contiguous DMA transfers. I had it set for 64KiB max DMA (128 x 512 bytes). When I set it to it's max value of 512 KiB, I was able to do transfers up to 1024 blocks (512 KiB).

With 1024-block transfers, I got 22.8 MB/sec read speed from the pq1 2 GB SD card.

[PierreOssman]

Is this bug still valid? Or has it shifted focus to mean "High-speed SD isn't giving us the number we hoped for"?

[jg]

Replying to PierreOssman:

Is this bug still valid? Or has it shifted focus to mean "High-speed SD isn't giving us the number we hoped for"?

Andres, is Pierre's latest and greatest in 303? Should this bug be closed out?

[dilinger]

Pierre's latest and greatest is in 303. Note that we can't actually get more than 12MB/s, but that's due to overhead in the kernel/driver. Obviously, optimizations need to be done, but that's true of lots of other things in the system as well. :)

Closing.