Re: Adding aliases to mmc

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Am 18.09.2013 19:13, schrieb Stephen Warren:
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.

If you have an embedded system were you just care a little about boot time you don't want to do anything like U-Boot's "part uuid" every time you boot. Or even worse, you just have a minimalistic boot loader (e.g. U-Boot's SPL) which doesn't know anything about UUIDs and file systems.

As mentioned above, no I don't think UUIDs work for production embedded systems.

Best regards

Dirk

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux