Chris Ball wrote at Monday, April 04, 2011 11:58 AM:
>
> Hi Stephen,
>
> On Mon, Apr 04 2011, Stephen Warren 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".
>
> The standard way to solve this is to use an initrd that performs the
> naming (and mounting) that you'd like based on characteristics of the
> device or card -- this could include making mmcblk{0,1} always attach
> to the controllers that you're expecting it to. It's hard enough to get
> device naming policy right that we don't usually try to do it in-kernel.
Chris,
Thanks for the very quick response.
I have a followup question: How could the initrd identify each device, in
order to know which names to assign to them, or which one to mount?
Is there a way to query the block device to determine which host controller
ID it's connected to? Querying device size is pretty easy, but the user
could easily happen to choose an SD card of the same size as the internal
MMC for example.
I believe that x86 desktop distros typically use filesystem or device UUIDs
for this purpose in the initrd, but in the distro I'm using, there is
typically neither any UUID, nor an initrd. Equally, it's pretty easy with
grub to edit grub.cfg/menu.cfg to contain the correct UUID during install
or if it ever changes. Modifying U-Boot's saved environment (boot commands)
to include the a UUID would be more challenging, especially since
the boot commands are typically stored in the system's ROM/flash, whereas
the filesystem may be on some completely random user-supplied SD card.
Thanks.
--
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
