SPI to the SD card specifications

[uminded]

Does anybody know what the SPI running the CD card is capable of? SD interfaces range from 1 to 4 lanes and single to quad data rates in the 20-104mhz range.

Just looking for a high data throughput interface for a peripheral that doesn't require the overhead of USB framing.

[martinayotte]

According to schematic, the SDCard is attached in QIO mode, but we still need to figure out if software use it that way.

[uminded]

According to schematic, the SDCard is attached in QIO mode, but we still need to figure out if software use it that way.

I'm quite busy the next few weeks but I may dig through the curated linux kernel modules and figure out how they are running the SD card. QSPI is pretty standard and given the specs say they support 256gig cards I imagine its QSPI >60MHZ for a minimum 15mb/s transfer rate. Theoretically, you can run a QSPI at 100MHZ with quad data rate to achieve 100mb/s throughput sans error checking.

[S1ntax]

Question what speed sd card do you recommend for the pine book? All that it States in the wiki is that it is sdxc compatible.

Sent from my SAMSUNG-SM-G920A using Tapatalk

[robbiemacg]

Reopening this thread. I'm curious to know what cards people are using currently, if anyone's encountered serious issues.

I'm additionally curious to know if any of those currently working with the hardware have partitioned things in such a way as to distribute system and data across eMMC and SD.

[xalius]

The SD card is connected in 4bit / 3.3V SDR25 (25MB/s) mode like on the normal Pine boards, the eMMC is connected in 8bit / 1.8V mode and uses HS-200 (200MB/s) mode.

As with any SBC running normal OS stuff, speed grade of the card is less important than the random I/O performance which is sadly not specified by vendors atm and can well be bad for cards that have high speed grades. Currently most people have good experience with the Samsung 32/64GB EVO(+) cards (see sdcard thread in the beginner forum). The SD-card association has recently released two new 'application' grades for new cards (A1/A2) that try to give an idea of the random I/O performance of cards for applications.

https://forum.pine64.org/showthread.php?...3#pid12693

http://forum.armbian.com/index.php/topic...rformance/

http://www.cnx-software.com/2017/06/13/m...ps-tricks/

[robbiemacg]

Thanks for the thoughtful response. I feel you've pointed me in the right direction.

[dkryder]

i have been a user of samsung evo plus 16GB for 2 years . reading the comments on this forum about samsung that mentions 32/64 GB evo plus as being a goto card i decided to try 2 32 GB cards on my various sbc units. i could detect no advantage to using 32GB over 16GB cards other than twice the storage capacity. now the fact that a 32GB card can operate at the same level as a 16GB card may be an advantage if you need the additional storage. sd cards are, in my experience fickle and can be corrupted fairly easily. that being the case i have never had much use for over 16GB in a sbc. i'll stick with using my 32GB in cameras.

[pfeerick]

i have been a user of samsung evo plus 16GB for 2 years . reading the comments on this forum about samsung that mentions 32/64 GB evo plus as being a goto card i decided to try 2 32 GB cards on my various sbc units. i could detect no advantage to using 32GB over 16GB cards other than twice the storage capacity. now the fact that a 32GB card can operate at the same level as a 16GB card may be an advantage if you need the additional storage.  sd cards are, in my experience fickle and can be corrupted fairly easily. that being the case i have never had much use for over 16GB in a sbc. i'll stick with using my 32GB in cameras.

I'm seeing conflicting information on that atm. A post from 2016 which I would rely on in order to say one way or the other indicates that there is very little different between a Samsung EVO+ 32 and 64GB card, and nor is there any really difference between a Samsung EVO 64GB and Samsung EVO+ 64GB card. I suspect things would be different with a A2 class card (are there any out yet?), but that's not what we're talking about. 

I seem to remember seeing a discussion with some performance numbers indicating that the Samsung EVO 32 was faster than the Samsung EVO 64, but I can't find it again. Regardless, you can see that the Samsung EVO is the best performing of the cards in this set for the all important random writes. Being a class 10 card, it's sequential speeds are excellent anyway, but its random I/O is actually far superior to even the the A1 class spec. 



Credit: tkaiser, https://forum.armbian.com/index.php?/top...rformance/

[xalius]

For flash based media in general more free blocks gives the sdcard/emmc/ssd controller more room to work with for optimization and block wear management. That being said the controller is a black box for each device and we dont really know what it's algorithms are. Personally I leave a 8GB swap partition on my 64GB cards that more or less never gets used but makes sure there are blocks that are never really written to available...