EmbeddedRelated.com
Forums
The 2026 Embedded Online Conference

Verifying SD Cards

Started by rickman May 3, 2016
On Wed, 04 May 2016 08:08:25 -0400
DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote:

> On Wed, 04 May 2016 02:24:33 -0700, mike <ham789@netzero.net> Gave us: > > >Problem is that you have no way of telling which (if any) is the > >real McCoy. > > > There are no McCoy brand memory sticks.
So if you see one you know it's been doctored. <sorry> -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
On 5/4/2016 4:25 AM, druck wrote:
> On 04/05/2016 08:50, rickman wrote: >> On 5/4/2016 12:44 AM, rickman wrote: >>> On 5/3/2016 11:40 PM, Dr. Dynamite wrote: >>>> Speed Class Rating: UHS-I / Class 10 >>>> Read Speed: Up to 85 MB/s >>>> Class 10 video recording performance > > [Snip] > >>> I did find a review that had a benchmark on a PC where they actually saw >>> read speeds of 74 MB/s. > > [Snip] > >> Oh yeah, that review was on the 128 GB card. Another review on the 64 >> GB card used H2testw and saw 59 and 21 MB/s for reading and writing >> respectively, > > If you are using a UHS-1 card in a normal SDHC or SDXC reader you wont > see the full performance. You need a UHS-1 capable USB3 reader to > benchmark them on a PC. The Raspberry Pi isn't UHS-1 so wont get as high > a speed.
Seems worse than that, the Raspberry Pi is not SDXC/EXFAT compatible. SDXC means sizes larger than 32 GB. Those devices are formatted as exFAT and so won't boot from that partition. But they can be booted by creating more than one partition with the first being FAT32. I think the other partition can be exFAT. I don't see anything about a speed limitation. In fact, UHS-1 has a speed of 13 MB/s and speeds higher than this have already been measured on the rPi. So what about the rPi would limit UHS-1 performance? "UHS-I has a bus interface speed of up to 104 MB/s." http://www.integralmemory.com/faq/what-uhs-1 I don't get why they keep increasing the size capabilities of the SD cards so incrementally. SDHC only covered 4 GB to 32 GB expanding the size 16 fold. SDXC expands the range another 64 fold. Why so little? Memory capacity will continue to ramp up doubling every two years, so why not give the standard some legs? SDXC will need to be replaced in another 8 to 10 years. -- Rick C
On 5/4/2016 6:45 AM, Theo Markettos wrote:
> In comp.sys.raspberry-pi Paul Rubin <no.email@nospam.invalid> wrote: >> The $11.50 card you got is an EVO+? Hmm, you didn't mention that >> earlier. It's interesting and I wonder if it's real. There could be >> another level of fakery: you could conceivably have gotten an actual >> 64GB card that was not an EVO+. I don't know what's happening with the >> EVO+ cards though: prices are all over the place. > > On the Pi, have a look around /sys/class/mmc_host/ or > /sys/block/mmcblk or a similar location. > This gives you parameters from the card itself - here's a list: > https://www.kernel.org/doc/Documentation/mmc/mmc-dev-attrs.txt > > On a fake, these details are often bogus - for example a serial number of > '0' or '99' is suspect, while a serial of '24592839DFSDFJSD' is more > plausible (google it. If someone else has the same serial number, something > is wrong) > > This only works if you have a directly-connected MMC/SDHCI controller - not > if the card is attached by USB. > > http://www.bunniestudios.com/blog/?page_id=1022 > is the canonical reference for this kind of fishy-ness.
Thanks. When I get my 64 GB card booted on the pi, I'll check the internal info. -- Rick C
On Wed, 04 May 2016 14:40:05 +0100, Ahem A Rivet's Shot  
<steveo@eircom.net> wrote:

> On Wed, 04 May 2016 08:08:25 -0400 > DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: > >> On Wed, 04 May 2016 02:24:33 -0700, mike <ham789@netzero.net> Gave us: >> >> >Problem is that you have no way of telling which (if any) is the >> >real McCoy. >> >> >> There are no McCoy brand memory sticks. > > So if you see one you know it's been doctored. > > <sorry> >
Could be it's dead, Jim. -- Bah, and indeed, Humbug
On 5/4/2016 5:24 AM, mike wrote:
> On 5/3/2016 2:33 PM, rickman wrote: >> On 5/3/2016 4:42 PM, Paul Rubin wrote: >>> rickman <gnuarm@gmail.com> writes: >>>> I found an eBay vendor with a really *great* price on 64 GB microSDXC >>>> cards and ordered one ($11.50 shipped). >>> >>> Pretty good, but unless you need 100s of them I'd stick with name >>> brand cards with known good performance for a few bucks more: >>> >>> http://www.adorama.com/ISGMBMC64DAA.html >> >> So you think it is better to pay $18.99 for a Samsung EVO+ 64 GB rather >> than paying $11.50 for a Samsung EVO+ 64 GB? > > I think it's better to pay $18.99 for a Samsung EVO+ 64GB rather > than paying $11.50 for one that may have a sticker that says > it's a Samsung EVO+ 64GB, but isn't. > Problem is that you have no way of telling which (if any) is the > real McCoy.
That last sentence is the point. I don't know if any of these cards is the "real McCoy". In researching this I found reports of getting fake cards from mainstream brick and mortar retailers. So who *can* you trust?
> I wrote a little test program that tests for fakeness (less storage > than advertised) in a minute or so, but never had any SDXC cards > or reader to test it on. Does work on 128GB USB3 sticks. > > Back in the 16GB days, I used to take a laptop > to pickup Craigslist cards. I disappointed more than a few sellers > when I verified that their cards were fake. Don't think I ever found > a REAL 16GB flash card locally on Craigslist. > > Speed has more than one dimension. I only care about big file transfers > for backups and app-install files. Can test that by copying a big > file with a program that shows the copy speed. Gets a lot more complex > if you care about lotsa small files.
I'm more concerned with day to day operations than backups. Backups will likely be done over the network anyway and so will be limited by those speeds. -- Rick C
On 5/3/2016 4:50 PM, Martin Riddle wrote:
> On Tue, 3 May 2016 10:54:56 -0400, rickman <gnuarm@gmail.com> wrote: > >> I found an eBay vendor with a really *great* price on 64 GB microSDXC >> cards and ordered one ($11.50 shipped). It was shipped from within the >> US so it came in a few days. I've used H2testw to verify that it really >> is 64 GB and got this message... "Warning: Only 61052 of 61053 MByte >> tested." A dialog pops up saying this is normal if you are using NTFS, >> but I formatted it in exFAT. So is this a problem? >> >> The intended use is in the rPi, so I will try firing that up later today >> and see if I can run a similar test there. I'd like to verify the speed >> of the card. What utility would be good for that? >> >> If the card checks out I'm going to order several more. > > Does the Pi have a version of 'Bonnie' to run? Ive used that for RAI > testing in the past.
I'm not up on the pi with this card yet. Turns out 64 GB has crossed a line and I'll have to do special formatting to use it. -- Rick C
On Wed, 4 May 2016 14:40:05 +0100, Ahem A Rivet's Shot
<steveo@eircom.net> Gave us:

>On Wed, 04 May 2016 08:08:25 -0400 >DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: > >> On Wed, 04 May 2016 02:24:33 -0700, mike <ham789@netzero.net> Gave us: >> >> >Problem is that you have no way of telling which (if any) is the >> >real McCoy. >> >> >> There are no McCoy brand memory sticks. > > So if you see one you know it's been doctored. > > <sorry>
Bob's yer uncle.
On Wed, 4 May 2016 10:06:54 -0400, rickman <gnuarm@gmail.com> Gave us:

>Seems worse than that, the Raspberry Pi is not SDXC/EXFAT compatible.
How fucking lame. Use a superior device. Yes it costs more but you get what you pay for. https://www.solid-run.com/product/cubox-i4x4/ Much more their other far superior products. https://www.solid-run.com/marvell-armada-family/
On Wed, 04 May 2016 15:14:39 +0100, "Kerr Mudd-John" <admin@127.0.0.1>
Gave us:

>On Wed, 04 May 2016 14:40:05 +0100, Ahem A Rivet's Shot ><steveo@eircom.net> wrote: > >> On Wed, 04 May 2016 08:08:25 -0400 >> DecadentLinuxUserNumeroUno <DLU1@DecadentLinuxUser.org> wrote: >> >>> On Wed, 04 May 2016 02:24:33 -0700, mike <ham789@netzero.net> Gave us: >>> >>> >Problem is that you have no way of telling which (if any) is the >>> >real McCoy. >>> >>> >>> There are no McCoy brand memory sticks. >> >> So if you see one you know it's been doctored. >> >> <sorry> >> >Could be it's dead, Jim.
I'm a doctor, Jim, not a memory card maker! "Brain, brain.... what is brain?"
In comp.sys.raspberry-pi rickman <gnuarm@gmail.com> wrote:
> Seems worse than that, the Raspberry Pi is not SDXC/EXFAT compatible. > SDXC means sizes larger than 32 GB. Those devices are formatted as > exFAT and so won't boot from that partition. But they can be booted by > creating more than one partition with the first being FAT32. I think > the other partition can be exFAT.
SDXC is a card type. You have a different initialisation procedure for SD or SDHC or SDXC. The Pi supports SDXC. exFAT is a disc format. If you're using Debian you need to install exfat-fuse. Or you can reformat to something more sensible. The Pi boot partition has to be FAT. exFAT is not FAT. Supporting exFAT would require a) a more complex format to be implemented in the relatively small mask ROM on the SoC, b) making that implementation bomb-proof in the face of all the strange cards out there and c) paying a patent licence to Microsoft for every Pi shipped. The simpler and cheaper option is not to use exFAT.
> I don't see anything about a speed limitation. In fact, UHS-1 has a > speed of 13 MB/s and speeds higher than this have already been measured > on the rPi. So what about the rPi would limit UHS-1 performance? > > "UHS-I has a bus interface speed of up to 104 MB/s."
You can set the emmc_clock in config.txt - it's usually 100MHz. I think that will be the upper limit on speed, but I don't remember all the modes that are listed in the spec (there is a 208 MHz mode in there I think, which is where 104MB/s comes from). Since I haven't seen the Arasan IP core documentation I don't know what the hardware actually supports.
> I don't get why they keep increasing the size capabilities of the SD > cards so incrementally. SDHC only covered 4 GB to 32 GB expanding the > size 16 fold. SDXC expands the range another 64 fold. Why so little? > Memory capacity will continue to ramp up doubling every two years, so > why not give the standard some legs? SDXC will need to be replaced in > another 8 to 10 years.
This irritates me too. Lack of support can reduce the longevity of existing devices (it's now getting trickier to buy 2GB cards to work on old non-SDHC devices, for instance). The initialisation process is 'just software' so it's possible to upgrade an existing device to support SDHC/SDXC/etc, but in many things (cameras, USB readers etc) the software doesn't get upgraded. Theo (who has a vendor-supplied SD IP core which does initialisation in hardware, which makes supporting SDHC much more painful)
The 2026 Embedded Online Conference