On 09/18/2013 11:01 AM, Dirk Behme wrote:
> Am 18.09.2013 17:17, schrieb Stephen Warren:
>> On 09/17/2013 12:04 PM, Fabio Estevam wrote:
>>> Hi Dirk,
>>>
>>> I have adapted your patch at:
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
>>>
>>>
>>> and tested it on 3.12-rc1 on a mx6qsabresd board.
>>>
>>> Do you have plans to submit it? Maybe as a RFC?
>>>
>>> It solves the mmcblkX order issue on my tests and it would be nice we
>>> could have this problem addressed.
>>
>> Patches to make mmc block devices have static names have been proposed
>> in the past and rejected. I think the main reason is that the block
>> device names are (or can be) dynamic, so anything that assumes a
>> particular naming scheme is simply broken.
>>
>> The correct solution is to use e.g. root=UUID=xxx or root=PARTUUID=xxx,
>> or similar techniques for other filesystems (e.g. /etc/fstab)
> 
> To my understanding this doesn't work if you need to have your rootfs on
> a SD card/eMMC with different UUIDs on each board (SD card/eMMC)?

That works fine.

If you're using filesystem UUIDs (root=UUID=), then whatever generates
your boot script (which is presumably stored in the filesystem you care
about) needs to put the correct UUID into the script when the script is
generated. This is presumably part of the install process, or part of a
post kernel-install hook, just like generating grub.cfg is.

If you're using partition UUIDs (root=PARTUUID=), then you can follow
that same scheme too...

... or if using a recent U-Boot, run the "part uuid" command to
determine the partition UUID at run-time, and use that to construct the
kernel command-line.

Any bootloader could implement equivalent functionality. In fact, any
bootloader that can read ext* (or whatever filesystem) could in fact
read the filesystem UUID too, and apply the same technique to root=UUID=
too.
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to