MicroSD for removable storage on BBB?

GoogleGroups
1

When I use SD storage on any of my other ARM linux boxes, the local flash memory is mmcblk0, and the SD/microSD card shows up as mmcblk1 - you can insert and remove the SD card at will, using it as removable storage; this is after all the primary use case for SD cards. Using it as a root fs (particularly with microSD) is still always an option.

When I use the microSD on the BBB, none of this works. If the microSD is not inserted at boot, then it will never be recognized by the kernel even if I insert a card later; if it is available at boot it becomes mmcblk0, displacing local flash which becomes mmcblk1, and if I ever then remove the card (even if no filesystems are mounted on it) I’ll get “INFO: task mmcqd/0:71 blocked for more than 60 seconds.” and a kernel panic.

I suspect that the problem is in the device tree configuration. I used dtc to get at the source (pasted below). The mmc1 is the microSD and mmc2 is the 2G eMMC (hence the “ti,non-removable” line). Apparently FDT uses 1-up counting. Anyway, I’ve tried swapping the names of the entries - this just leads to neither being recognized at boot. I’ve tried adding the “broken-cd” flag documented in mmc.txt in the kernel tree - this does not let the card be recognized if inserted after boot, and does not stop the kernel panic if it is removed after boot. There’s no other documented option that I can see.

Is there a way to fix this, or is microSD on the BBB fundamentally broken?

Thanks,

Patrick

PS: I’m not asking about the problem of needing a uEnv.txt on the SD card - that’s a related but separate issue.

PPS: Here’s the DTS from the default BBB device tree file:

2

The microSD support on BeagleBone Black, fundamentally lacks working SW out of the box…

Gerald

3

First, the media which is booted from shows up as mmcblk0 always on the BBB. So it does not matter if it is an SD card or eMMC. Well this only applies to SD vs eMMC. If you boot from a network, or USB it might be different.

As for the boot order, or what the BBB boots from this can be and often is determined by uEnv.txt… Although pressing and holding the boot button when booting cant change this. In order to boot from eMMC while an SD card is inserted, you need to have a properly configured uEnv.txt file variables. something such as this:

mmcdev=1
bootpart=1:2
mmcroot=/dev/mmcblk1p2 ro



In your uEnv.txt file should allow you to boot from the eMMC with an SD card inserted into the SD card slot.
4

William,
I’m not talking about what uboot sees, or which device/partition holds the kernel or rootfs. Once control switches to the kernel, uboot no longer matters. I’m talking about what the kernel sees, and wondering why I can’t insert/remove a microSD card without causing a kernel panic.
Patrick

5

Furthermore, your statement about mmcblk0 is incorrect. If the microSD card is present, I don’t have to boot from it. I can interrupt uboot, run a simple sequence of commands, and boot from eMMC without ever touching the microSD card, and the microSD card still shows up as mmcblk0.
And I really don’t care whether the microSD displaces eMMC and causes device renaming (that is a lame problem, but solvable by UUIDs and/or udev rules). But if I can’t insert/remove microSD cards after boot time, I may as well give up on microSD altogether.

Patrick

6

Well hotplug is a known issue, and afaik is a kernel related problem. This effects the SD slot, and USB. Never heard of or experienced a kernel panic though. Not saying I do not believe you, just saying that I have hot-plugged both USB and the SD card slot and have not personally experienced this. What happens for me, the device in question, may work for one more hot-plug, but will fail any further attempts.

7

William,
The only hotplug problems I’ve had with USB have been due to it taking too much current, or plugging in a hub that feeds power back to the host. Once I switched to a powered hub that does not feed anything back, everything was fine; the same issue affects the pi, and the same hub solves that problem on the pi. Now I can plug/unplug USB devices, including storage, optical mice etc, without any problem.

This is a completely separate issue.

Are you saying that if you have a microSD card attached at boot, and you remove it post-boot, you don’t get a kernel panic 1 minute later? What happens for you when you run a blkid or partprobe? Does it still think the card is in there?

Patrick

8

I stand corrected. It looks like now, I also have the same issue now. I do not exactly get a panic message. In fact I get no message at all. However the beaglebone black that has been runing fine for days straight suddenly started acting funny after i removed the SD card, and reinserted it.

df -h would not function at all, but uname -a did. blkid would not work either, I guess I’ll have to hook up my serial debug device again. ALthough I am not sure if that will help. THe problem seems to be silent for me. Perhaps using the $optargs debug parameter in uEnv.txt will help ?

This is new however. This has not happened for me in the past, so it may be one of the latest kernel version I’ve built ?

root@arm:~# uname -a
Linux arm 3.8.13-bone21 #1 SMP Sat Jun 15 19:36:33 MST 2013 armv7l GNU/Linux

This is debian wheezy by the way, and I boot from a USB hard drive. Using ethernet for LAN connection, and powered via USB 3.0. The USB hard drive is an external case + seagate baracuda ATA that is self powered.

9

I should have said earlier that /var/log/messages does not seem to have any related messages either. Although I have not grepped yet for exactness

10

Just repeated what I did earlier( twice ), that is removed sd card reinserted issued some disk utility commands, and nothing. BBB is still up and running. However, running blkid, and other disk utilities when the SD card is out did not change the output. Read: it seems the system still thinks it is plugged in, when it is in fact removed.

11

I cannot see how removing the SD card that is the boot device can be a
good thing for a linux kernel
If it was just SD card storage and you issue the unmount command sure
or if the kernel has some kind of hot swap mechanism to allow that

am i wrong that removing the boot device is a bad thing ?

12

Seems to me this is a hot plug issue. I still have a barely updated Angstrom on the eMMC, and it exhibits none of these problems. Granted, it does not even find the SD card once it is plugged in too.

login as: root
root@192.168.xxx.5’s password:
root@beaglebone:~# uname -a
Linux beaglebone 3.8.8 #1 SMP Fri Apr 19 22:34:54 CEST 2013 armv7l GNU/Linux

SD card not yet inserted.

root@beaglebone:~# fdisk -l |grep mmc
Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes
/dev/mmcblk0p1 * 63 144584 72261 c W95 FAT32 (LBA)
/dev/mmcblk0p2 144585 3743144 1799280 83 Linux
Disk /dev/mmcblk0boot1: 1 MB, 1048576 bytes
Disk /dev/mmcblk0boot0: 1 MB, 1048576 bytes

root@beaglebone:~# partprobe -s
/dev/sda: msdos partitions 1
/dev/mmcblk0: msdos partitions 1 2

repeatedly inserted / removed SD card a few times. Finally leaving it inserted.

root@beaglebone:~# fdisk -l |grep mmc
Disk /dev/mmcblk0: 1920 MB, 1920991232 bytes
/dev/mmcblk0p1 * 63 144584 72261 c W95 FAT32 (LBA)
/dev/mmcblk0p2 144585 3743144 1799280 83 Linux
Disk /dev/mmcblk0boot1: 1 MB, 1048576 bytes
Disk /dev/mmcblk0boot0: 1 MB, 1048576 bytes

root@beaglebone:~# partprobe -s
/dev/sda: msdos partitions 1
/dev/mmcblk0: msdos partitions 1 2

root@beaglebone:~# date
Fri Dec 31 17:51:24 MST 1999
root@beaglebone:~# date
Fri Dec 31 17:53:19 MST 1999
root@beaglebone:~#

I should have issued the date command right after I logged in ( used to Debian doing that automatically for me ), but at least this should show that it did run for at least a couple minutes after I inserted / removed the SD card several times, In fact, it is happily blinking away still as I write the message.

As for message logs, aside from grepping dmesg, I am not sure what else I can check in Angstrom. As I do not know Angstrom very well. Either way, I am fairly sure I would get no useful / related information back. As kernel 3.8.8 Seems to completely ignore the SD card after boot.

Still running …

root@beaglebone:~# date
Fri Dec 31 18:01:45 MST 1999

13

William,
The panic message only shows up via the serial port. So you’re experiencing exactly the same behavior as me - if you have the SD card plugged in at boot time, then removing it will cause a kernel panic; if you don’t have it plugged in at boot time, the kernel completely ignores it no matter how many times you insert/remove.

Patrick

14

Wulf Man,
What is this “boot device” to which you refer?

If you’re talking about the rootfs, then yes it would be bad to remove that, but my rootfs is on the eMMC.

If you think that having an SD card in at boot makes it automatically the rootfs, then you’re wrong. The default uboot config looks for an SD card and if it finds one looks for a uEnv.txt file on it; after that, uboot is done with the SD card, unless that uEnv.txt tells it to boot from SD.

Patrick

15

no kidding
i use a SD card to boot from

16

All things being equal, if the hotplug issues were not causing problems. Removing then re-inserting the drive in of its self should not cause any problems.

At least I have demonstrated this to myself several times by restarting an NFS server ( which my beaglebone black has booted from in the past ). While the Beaglebone black kept running. Of course I did not issue any commands until the server was back up, and live again.

Anyhow, perhaps I will attempt to dig into this deeper myself at some later point. But I am not sure if I would be able to find the exact problem.

17

By the by Patrick, this happened to me while booted off a USB hard drive. However, the USB boot process in my case does require MLO, u-boot.img, and uEnv.txt to be on the SD card. Of course this also means the SD card is inserted at boot time as well.

18

I know this is 1.5 years later, but I seem to be running into the same issue and am having a hard time finding anything as to how to solve this:
https://groups.google.com/d/msg/beagleboard/IeLSZ19NbMU/xeND-QH0AAAJ

Interestingly, hot plug for the uSD card works for me on a 3.8.13 kernel under Debian Wheezy (3.8.13-bone79 to be precise), so this must have been fixed in the meantime. However, it fails to work on a 4.1.15 kernel under Ubuntu 14.04.3 (4.1.15-ti-r40 to be precise). Would this be because it wasn’t compiled into the kernel?