Maximum SD card size for BBB

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

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.

Regards,

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

Robert,

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

Eric

yaoshi,

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

Eric

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

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?

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.

Regards,

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.

Regards,

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.

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

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.

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

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..

Regards,

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

Regards,

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..

Regards,

This is surprise me

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

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.

1024102433

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.)

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.