Kishore Kadiyala wrote at Tuesday, April 05, 2011 12:38 AM: > > Hi Stephen, > > On Mon, Apr 4, 2011 at 11:09 PM, Stephen Warren <swarren@xxxxxxxxxx> wrote: > > Chris et. al., > > > > I'm working on an ARM system that contains at least two MMC/SD devices; > > specifically the board has an internal MMC device, and an SD card slot, > > although the SoC has four MMC/SD hosts IIRC. > > > > The kernel's naming of these devices is dynamic. If the SD card is not > > plugged in, the internal MMC is always known as mmcblock0. If the SD card > > is plugged in too, sometimes the internal MMC is mmcblk0 and sometimes it's > > mmcblk1. I assume this is timing related; 2.6.37 usually seemed to name > > them "in order", whereas 2.6.38 usually seems to name them "backwards". > > > > This causes problems with the bootloader scripts I'm using, which assumes > > that the internal MMC is always device 0 and the SD slot is always device 1, > > and hence provides kernel command-line argument root=/dev/mmcblk0p3 or > > root=/dev/mmcblk1p3 based on whether it booted from SD or internal MMC (SD > > is searched for a valid image first by the bootloader). > > Just follow this thread which discusses the same but for OMAP4 controller > http://www.mail-archive.com/linux-omap@xxxxxxxxxxxxxxx/msg47853.html Kishore, thanks for the pointer. However, I don't see anything in that thread that affects MMC block device IDs. The thread ended with the original poster requesting the patch be dropped, since he'd made a mistake in his bootloader settings. Just perhaps the registration order change is enough to change the timing of device (memory device, not host controller?) probing, which just happens to affect the ID assignment? > One solution could be make your internal MMC always registered as mmcblk0 > and the removable one as next device. That's essentially what the patch I gave previously does. -- nvpublic -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
