Maximum SD card size for BBB

[Jonmar]

Greetings everyone,

What is the maximum size SD or SDHC flash memory card that the "BeagleBone Black" will support ?

Also, what is the recommended speed class (e.g. Class 4, Class 10, etc.) ?

Thank you in advance for your help :-)

Jonmar

[Robert Nelson]

On Thu, Jul 17, 2014 at 5:05 PM, 'Jonmar' via BeagleBoard
<beagl...@googlegroups.com> wrote:
> Greetings everyone,
>
> What is the maximum size SD or SDHC flash memory card that the "BeagleBone
> Black" will support ?
>
> Also, what is the recommended speed class (e.g. Class 4, Class 10, etc.) ?

From the AM335x manual:

MMC, SD, SDIO 2.0 port:

Complies with MMC4.3, SD, SDIO 2.0 Specifications

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[William Pretty Security]

You probably want about 8GB class 10 for sure.

I don’t know if there is a maximum size of uSD card.

 

The class 4 uSD cards aren’t very reliable.

 

http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4716 / Virus Database: 3986/7869 - Release Date: 07/17/14

[John Syn]

From: William Pretty Security <bill....@xplornet.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Date: Thursday, July 17, 2014 at 4:14 PM
To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: RE: [beagleboard] Maximum SD card size for BBB

You probably want about 8GB class 10 for sure.

I don’t know if there is a maximum size of uSD card.

16GB is about the same price as 8GB. At Amazon, 16GB class 10 is about $8.

[William Pretty Security]

Quite right, but given that Ubuntu with GUI is about 3GB, isn’t the other 13 kind of a waste ??

 

http://www.packtpub.com/building-a-home-security-system-with-beaglebone/book

No virus found in this message.
Checked by AVG - www.avg.com

Version: 2014.0.4716 / Virus Database: 3986/7863 - Release Date: 07/16/14

No virus found in this message.
Checked by AVG - www.avg.com

Version: 2014.0.4716 / Virus Database: 3986/7871 - Release Date: 07/17/14

[John Syn]

From: William Pretty Security <bill....@xplornet.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Thursday, July 17, 2014 at 6:51 PM

To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: RE: [beagleboard] Maximum SD card size for BBB

Quite right, but given that Ubuntu with GUI is about 3GB, isn’t the other 13 kind of a waste ??

Flash has a finite number of writes so with wear leveling, you want to have a much free space as possible to prevent flash failure. If it is the same price, always get the bigger one ;-)

Regards,

John

[William Pretty Security]

Actually John, I’ve been having that exact problem !

 

How does ‘wear leveling’ work ?

I have been using an external USB key as temp storage.

 

Bill

[John Syn]

From: William Pretty Security <bill....@xplornet.com>
Reply-To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>

Date: Thursday, July 17, 2014 at 7:58 PM

To: "beagl...@googlegroups.com" <beagl...@googlegroups.com>
Subject: RE: [beagleboard] Maximum SD card size for BBB

Actually John, I’ve been having that exact problem !

 

How does ‘wear leveling’ work ?

I have been using an external USB key as temp storage.

http://en.wikipedia.org/wiki/Wear_leveling

For development purposes, don’t use SDCards. Rather use NFS to mount a rootfs on your desktop. 

In the field, use a read only rootfs and create a separate partition for storage. Flash has to erase a block before writing a byte. If you have a logging application, create a buffer in ram which is the size of your flash erase block and write data to buffer and only write the buffer to disk when the buffer is full. Alternatively, use a power fail detection circuitry and only write to SDCard on power failure. There are a lot of techniques like this that prolong the life of flash. 

Regards,

John

[c...@isbd.net]

William Pretty Security <bill....@xplornet.com> wrote:
> [-- text/plain, encoding 7bit, charset: ISO-8859-1, 112 lines --]

>
> Quite right, but given that Ubuntu with GUI is about 3GB, isn't the other 13
> kind of a waste ??
>

Er, don't you need some space for user files? :-)

--
Chris Green
·

[William Pretty Security]

Thanks John J

[William Hermans]

We use two BBB's here, and both use 16GB class 10 cards. I've heard that 32GB works too, but no hands on.

AS john said first you want more space( unused, or free space ) on your sd card to help facilitate wear leveling, *AND* if you're going to be doing lots of writing for development purposes. Move your rootfs to an NFS share.

[ericg]

I am currently running on an 8GB Class 4 card.

Needed this to fit Debian on a card and still have space left to work with.

These instructions made it easy to flash the card with the 2GB image, then expand the file system size after the fact.

http://elinux.org/Beagleboard:Expanding_File_System_Partition_On_A_microSD

[Eric Fort]

I'm using a 32GB SD card, so yes it works.  Has anyone tried 64GB and larger cards yet?  64 or 128GB would be insanely nice!

Eric

[liyaoshi]

As I understand , its not about the size , its about the eMMC spec support , 

While sdhc up to support 32G card , the new spec call sdxc ? this will support up to 2T , but this is not support by ti omap3/dm81xx/am335x ,only support by omap5

So , when you see  a card with sdxc trademark. it should NOT support by beagle .even its less than 32G

[Eric Fort]

so can someone link to something definitive stating that for the beagle bone (black) 32GB SDHC is the biggest card supported (assuming this is correct)?

Eric

[Robert Nelson]

On Mon, Jul 21, 2014 at 10:34 AM, Eric Fort <eric...@gmail.com> wrote:
> so can someone link to something definitive stating that for the beagle bone
> (black) 32GB SDHC is the biggest card supported (assuming this is correct)?

From:
http://en.wikipedia.org/wiki/Secure_Digital#SDXC

The Secure Digital eXtended Capacity (SDXC) format, announced in
January 2009 and defined in Version 3.01 of the SD specification,
supports cards up to 2 TB (2048 GB), compared to a limit of 32 GB for
SDHC cards in the SD 2.0 specification. SDXC adopts Microsoft's exFAT
file system as a mandatory feature.

aka:
microSDHC 32GB is your limit..

[Gerald Coley]

And I can confirm this is correct.

Gerald

[Eric Fort]

so one is completely unable to reformat an SDXC card with another filesystem type such as ext3?  Is it simply a filesystem issue or are there hardware differences to be overcome?

Eric

[Robert Nelson]

On Tue, Jul 22, 2014 at 10:03 PM, Eric Fort <eric...@gmail.com> wrote:
> so one is completely unable to reformat an SDXC card with another filesystem
> type such as ext3? Is it simply a filesystem issue or are there hardware
> differences to be overcome?

hardware...

http://kb.sandisk.com/app/answers/detail/a_id/2520/~/sd%2Fsdhc%2Fsdxc-specifications-and-compatibility

[liyaoshi]

Its about sdhc cmd format ，some sdhc cmd/resp will get different length from sdxc

[Eric Fort]

so that sounds like a software issue not a hardware issue.  When I refer to hardware I really mean the electrical signaling on the interface to the host.  only thing I can think of there is some subsystem in an soc ends up being too smart for it's own good in trying to handle those commands such that the host never actually sees the commands being sent/received on the interface.  cmd length sounds like a linux kernel driver issue.

Eric

[Robert Nelson]

On Tue, Jul 22, 2014 at 11:25 PM, Eric Fort <eric...@gmail.com> wrote:
> so that sounds like a software issue not a hardware issue. When I refer to
> hardware I really mean the electrical signaling on the interface to the
> host. only thing I can think of there is some subsystem in an soc ends up
> being too smart for it's own good in trying to handle those commands such
> that the host never actually sees the commands being sent/received on the
> interface. cmd length sounds like a linux kernel driver issue.

You realize if that soc subsystem wasn't "too smart" you'd have to use
the Cortex A8 to manually batch every mmc cmd/data access. I'm sorry,
i'd rather use the cpu cycles for something useful.

If you need more then 32GB get a usb flash or usb sata drive. It's way
cheaper then any most microSDXC devices.

[liyaoshi]

Its not about software , Its about how hardware implement a stack / spec.

You can read this first , to understand how a sdxc stack runs failed on a sdhc host

https://www.sdcard.org/downloads/pls/simplified_specs/part1_410.pdf

[Eric Fort]

Robert,

Yes, I suppose you have a point, but this does sound like another good use for one of the PRUs.

Eric

[Eric Fort]

yaoshi,

thanks for the link, that pretty well lays it out and gives what I was looking for as to what and why.

Eric

[Brian]

Do SDXC cards work in the BBB? Or is it SDHC cards only? 

[Brian]

Maybe the correct question is what does the BBB have? 

Because SDXC uses a different file system called exFAT and it works differently than standard SD cards, this new format is NOT backwards compatible with host devices that only take SD (128MB to 2GB) or host devices that only take SDHC (4GB to 32GB). Most host devices built after 2010 should be SDXC compatible."

Is it an SDHC or SDXC?

On Monday, July 21, 2014 11:00:35 AM UTC-5, Gerald wrote:

[Robert Nelson]

On Thu, Nov 20, 2014 at 10:10 PM, Brian <neo...@gmail.com> wrote:
> Do SDXC cards work in the BBB? Or is it SDHC cards only?

As mentioned in this thread "SDXC" cares are not supported on the bbb
thru the internal mmc interface connected to the microSD slot.

microSDHC 32GB is your limit..

If you want "SDXC" you'll need a usb adapter that supports them.

[Robert Nelson]

On Thu, Nov 20, 2014 at 10:12 PM, Brian <neo...@gmail.com> wrote:
> Maybe the correct question is what does the BBB have?
>
> Because SDXC uses a different file system called exFAT and it works
> differently than standard SD cards, this new format is NOT backwards
> compatible with host devices that only take SD (128MB to 2GB) or host
> devices that only take SDHC (4GB to 32GB). Most host devices built after
> 2010 should be SDXC compatible."
>
> Is it an SDHC or SDXC?

The "ip" block on the am335x can not handle "SDXC", you'll have to use
an external usb adapter to use SDXC cards on the bbb.

[Brian Heckathorne]

Thank you very much that info should be in the bbb wiki very helpful and good to know. Especially that a usb device could solve the issue. I take lots of pictures order of thousands and need the space but dont want to goto a power hungry usb disk drive.

--
For more options, visit http://beagleboard.org/discuss
---

You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/rK3y2ih1kig/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[William Hermans]

So buy a flash memory stick ? Or put a ssd in an external enclosure . . .

You received this message because you are subscribed to the Google Groups "BeagleBoard" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.

[Philip Polstra]

Would SDXC work if reformatted to get rid of Microsoft's proprietary exFAT filesystem or is the hardware limited to 32GB?  Just curious, haven't needed anything larger than 32.

[liyaoshi]

Again , Its not about filesystem , its about SD SPEC V3.0 (SDXC) vs SD SPEC V2.0 (SDHC)

You can NOT use SDXC card on a SDHC host ,some SD v3.0 CMD will over size in v2.0

This is a hardware spec limited

[Robert Nelson]

Humm... So i picked up an SDXC card a few weeks back, but this
conversation reminded me i should just test it to prove it for once an
and all... Well...


debian@beaglebone:~$ uname -r
3.8.13-bone67
debian@beaglebone:~$ dmesg
[ 98.159775] mmc0: host does not support reading read-only switch.
assuming write-enable.
[ 98.161943] mmc0: new high speed SDXC card at address aaaa
[ 98.165780] mmcblk1: mmc0:aaaa SU64G 59.4 GiB
[ 98.169334] mmcblk1: p1
[ 172.261473] mmcblk1: p1
[ 277.923870] EXT4-fs (mmcblk1p1): mounted filesystem with ordered
data mode. Opts: (null)

(mmcblk1 is SDXC)
debian@beaglebone:~$ sudo hdparm -tT /dev/mmcblk1

/dev/mmcblk1:
Timing cached reads: 448 MB in 2.00 seconds = 224.03 MB/sec
Timing buffered disk reads: 58 MB in 3.02 seconds = 19.23 MB/sec

(mmcblk0 is eMMC which i booted off of..)
debian@beaglebone:~$ sudo hdparm -tT /dev/mmcblk0

/dev/mmcblk0:
Timing cached reads: 424 MB in 2.01 seconds = 211.39 MB/sec
Timing buffered disk reads: 66 MB in 3.05 seconds = 21.66 MB/sec

Well let's see if i can boot off the SDXC card..

[Robert Nelson]

Zero'ed out the eMMC:

debian@beaglebone:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
mmcblk1boot0 179:16 0 1M 1 disk
mmcblk1boot1 179:24 0 1M 1 disk
mmcblk0 179:0 0 59.5G 0 disk
└─mmcblk0p1 179:1 0 59.5G 0 part /
mmcblk1 179:8 0 1.8G 0 disk
debian@beaglebone:~$ dmesg | grep mmcblk0
[ 0.870861] mmcblk0: mmc0:aaaa SU64G 59.4 GiB
[ 0.872373] mmcblk0: p1
[ 2.624594] EXT4-fs (mmcblk0p1): mounted filesystem with ordered
data mode. Opts: (null)
[ 7.353348] EXT4-fs (mmcblk0p1): re-mounted. Opts: (null)
[ 8.346567] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro
[ 25.319932] lun0: LUN: removable file: /dev/mmcblk0p1

This is a:

SanDisk Ultra 64GB micro SDXC

[William Hermans]

Robert, So am I reading this correctly, and you've got the system to boot off an SDXC card ? Well at least mounting the rootfs from it ?

[Robert Nelson]

On Fri, Nov 21, 2014 at 4:11 PM, William Hermans <yyr...@gmail.com> wrote:
> Robert, So am I reading this correctly, and you've got the system to boot
> off an SDXC card ? Well at least mounting the rootfs from it ?

That is correct, it's been running tests all day. I've been trying to
find a good sdxc implementation manual, as i thought they changed the
base command set. Unless SanDisk, put their own hardware
compatibility layer..

[liyaoshi]

This is  surprise me 

Can someone do another test  like one single file over than 32G ?

[Paul Giordano]

I installed a SanDisk 64G, reformatted the partition as ext4.

Gio@beaglebone:~$ mount

(...)

/dev/mmcblk0p1                          61241372   53064  61188308    1% /mnt

Gio@beaglebone:~$ python

Python 2.7.3 (default. Mar 14 2014, 17:55:54)

[GCC 4.6.3] on linux2

Type "help", "copyright", "credits" or "License" for more information.

>>> 1024*1024*33

34603008

>>>

Gio@beaglebone:~$ date

Wed Apr 23 21:40:16 UTC 2014

Gio@beaglebone:~$ dd if=/dev/zero of=/mnt/test.file bs=1024 count=34603008

34603008+0 records in

34603008+0 records out

35433480192 Bytes (35 GB) copied, 4940.65 s, 7.2 MB/s

Gio@beaglebone:~$ date

Wed Apr 23 23:04:58 UTC 2014

Gio@beaglebone:~$ date

Wed Apr 23 23:08:02 UTC 2014

Gio@beaglebone:~$ sha1sum /mnt/test.file

6854fc38cb41ed19a43ade369bfba28ae0ec72d8  /mnt/test.file

Gio@beaglebone:~$ date

Wed Apr 23 23:41:33 UTC 2014

Well, it took a while. 1 hour 19 minutes to create, 30 minutes to read.

(I obviously haven't set up NTP yet! Guess I better do that.)

[William Hermans]

Well, it took a while. 1 hour 19 minutes to create, 30 minutes to read.

(I obviously haven't set up NTP yet! Guess I better do that.)

Is that and older kernel with an older device tree overlay ? Almost seems as though the 4bit patch has not been applied to your device tree overlay.

[Paul Giordano]

 3.8.13-bone47, I just got the board. I'm updating now, we'll check on the times again.

[William Hermans]

That is the same kernel version I am running. As I recall the patch was applied back somewhere around 3.8.13-bone2x.

--

[Robert Nelson]

On Sun, Nov 23, 2014 at 2:36 PM, William Hermans <yyr...@gmail.com> wrote:
> That is the same kernel version I am running. As I recall the patch was
> applied back somewhere around 3.8.13-bone2x.

Well, i was seeing 20Mb/sec read via hdparm, so the 30minutes to read
makes sense..

I wonder if the deal with the ip, is we just don not have UHS-I/UHS-II support..

http://en.wikipedia.org/wiki/Secure_Digital#Ultra_High_Speed_bus

On a side note, none of my usb-sdhc adapters can read my SanDisk sdxc
card without a kernel opps on x86, (v3.18-rc5) so i can't test till i
get back to work.

[William Hermans]

I wonder if the deal with the ip, is we just don not have UHS-I/UHS-II support..

http://en.wikipedia.org/wiki/Secure_Digital#Ultra_High_Speed_bus

On a side note, none of my usb-sdhc adapters can read my SanDisk sdxc
card without a kernel opps on x86, (v3.18-rc5) so i can't test till i
get back to work.

I was wondering about this the other night. Not the specifics, as I pretty much know nothing about the low level standards of each implementation. But the idea that similar hardware can be enabled or disabled in software. Thus making for an easy "hack" to get more features by paying less.

This sort of thing has after all been done before. . .

[Robert Nelson]

On Sun, Nov 23, 2014 at 2:51 PM, William Hermans <yyr...@gmail.com> wrote:

I wonder if the deal with the ip, is we just don not have UHS-I/UHS-II support..

http://en.wikipedia.org/wiki/Secure_Digital#Ultra_High_Speed_bus

On a side note, none of my usb-sdhc adapters can read my SanDisk sdxc
card without a kernel opps on x86, (v3.18-rc5) so i can't test till i
get back to work.

I was wondering about this the other night. Not the specifics, as I pretty much know nothing about the low level standards of each implementation. But the idea that similar hardware can be enabled or disabled in software. Thus making for an easy "hack" to get more features by paying less.

This sort of thing has after all been done before. . .

Plus, we were assuming "SanDisk" just threw out their old "controller" and did the SDXC implementation by scratch.  They probably just saved the man hours and bolted the SDXC support on the older "controller"..

But i wonder how they are donig the >32GB limitation of SDHC... if only the SDHC/SDXC spec was open! ;)

Regards,

[Paul Giordano]

Ah. Thanks for letting me know. I thought about trying the debian kernel at 3.13, but maybe I'll wait on that. Neat board so far. 

[William Hermans]

Paul, the only real differences between 3.8.x and say 3.14.x is. . .

1. SGX support.
2. USB hotplug.
3. Device tree overlay are used differently - Depending.

If I forgot something, someone else will speak up I'm sure, but those are the 3 most important features in my own mind.

SGX support is still there in 3.8.x, *somewhat* but is frame buffer only if I am remembering right.

Hot plugging USB, or even ethernet while the system is up and running will cause a seg fault or kernel oops. Which just means you need to power down, make your changes, and power back up.

Dynamically loading device tree files while the system is up ( no reboots needed ) can only be done with 3.8.x. Charles S has also made a set of generic device tree overlays that allow for pin multiplexing on the fly for both kernel branches though. Although, this is somewhat limited if i understand correctly. Unloading a device tree file still requires a reboot though. At least for 3.8.x, unless things have recently changed without my knowledge.

Anyway, you can scour the groups for information or even use google to find out more and possibly accurate information on all the above.

[liyaoshi]

seems Ti update am335x mmc ip from dm814x

http://www.ti.com/lit/ug/sprugz8e/sprugz8e.pdf

page 2260

while from 

http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf

page 4104

• Support for SDA 3.0 Part A2 programming model

This mean am335x can support sdxc card , maybe just lack of 200M clock and ddr mode 

[Robert Nelson]

On Sun, Nov 23, 2014 at 8:13 PM, liyaoshi <liya...@gmail.com> wrote:
>
> seems Ti update am335x mmc ip from dm814x
>
> http://www.ti.com/lit/ug/sprugz8e/sprugz8e.pdf
> page 2260
>
> while from
>
> http://www.ti.com/lit/ug/spruh73k/spruh73k.pdf
> page 4104
>
> • Support for SDA 3.0 Part A2 programming model
>
> This mean am335x can support sdxc card , maybe just lack of 200M clock and
> ddr mode

A search on that turned up:

https://www.sdcard.org/downloads/pls/simplified_specs/archive/partA2_300.pdf

https://www.sdcard.org/downloads/pls/simplified_specs/

[Robert Nelson]

From the am335x errata sheet:

MMC0, MMC1, MMC2 Interfaces
– Only Standard (STD) and High Speed (HS) modes are supported. SDR12,
SDR25, SDR50 modes
as defined in SD3.0 specification are not supported.

So it's complaint to SD3.0 except for the transfer speeds.

I guess if your TI and you have that issue, it's just safer to
advertise it as "SD/SDHC" only. Instead of having users complain
about it being "SDXC" and piss ass slow.. ;)

[Jesus Garcia]

I'm using a Sandisk 64GB microSD, no issues.

beaglebone:/card/player# lsblk

NAME         MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

mmcblk1boot0 179:16   0     2M  1 disk 

mmcblk1boot1 179:24   0     2M  1 disk 

mmcblk0      179:0    0  59.5G  0 disk 

└─mmcblk0p1  179:1    0  59.5G  0 part /card

mmcblk1      179:8    0   3.6G  0 disk 

├─mmcblk1p1  179:9    0    96M  0 part /boot/uboot

└─mmcblk1p2  179:10   0   3.5G  0 part /

On Thursday, July 17, 2014 6:05:01 PM UTC-4, Jonmar wrote:

Greetings everyone,

What is the maximum size SD or SDHC flash memory card that the "BeagleBone Black" will support ?

Also, what is the recommended speed class (e.g. Class 4, Class 10, etc.) ?

Thank you in advance for your help :-)

Jonmar

[smi...@gmail.com]

I have a 128GB SD Card, that I use in one of my laptops to store install files, some backups, etc. This machine runs Linux so the SD is formatted ext4. I used gparted to srink partition on this SD to 96GB and made another 32GB partition at the end. I then put this into my BBB. I could mount both partitions, I could write files to them and I did a fsck.ext4 -f on both again in my DELL laptop. No issues. Card is a Sandisk mmc0: new high speed SDXC card at address aaaa according to dmesg.