Adding aliases to mmc

Adding aliases to mmc

[Fabio Estevam]

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.

Thanks,

Fabio Estevam

Re: Adding aliases to mmc

[Fabio Estevam]

Hi Dirk,

On Tue, Sep 17, 2013 at 3:04 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.

I simplied your patch a bit:

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 1a3163f..94f842b 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2026,7 +2026,7 @@ static struct mmc_blk_data
*mmc_blk_alloc_req(struct mmc_card *card,
     struct mmc_blk_data *md;
     int devidx, ret;

-    devidx = find_first_zero_bit(dev_use, max_devices);
+    devidx = find_next_zero_bit(dev_use, max_devices, card->host->devidx);
     if (devidx >= max_devices)
         return ERR_PTR(-ENOSPC);
     __set_bit(devidx, dev_use);
@@ -2044,7 +2044,8 @@ static struct mmc_blk_data
*mmc_blk_alloc_req(struct mmc_card *card,
      * index anymore so we keep track of a name index.
      */
     if (!subname) {
-        md->name_idx = find_first_zero_bit(name_use, max_devices);
+        md->name_idx = find_next_zero_bit(name_use, max_devices,
+                card->host->devidx);
         __set_bit(md->name_idx, name_use);
     } else
         md->name_idx = ((struct mmc_blk_data *)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index abc8cf0..e11a6af 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -524,8 +524,9 @@ static int sdhci_esdhc_imx_probe(struct
platform_device *pdev)
     struct sdhci_pltfm_host *pltfm_host;
     struct sdhci_host *host;
     struct esdhc_platform_data *boarddata;
-    int err;
+    int err, ret;
     struct pltfm_imx_data *imx_data;
+    struct device_node *np = pdev->dev.of_node;

     host = sdhci_pltfm_init(pdev, &sdhci_esdhc_imx_pdata, 0);
     if (IS_ERR(host))
@@ -602,6 +603,13 @@ static int sdhci_esdhc_imx_probe(struct
platform_device *pdev)
                     host->mmc->parent->platform_data);
     }

+
+    if (np) {
+        ret = of_alias_get_id(np, "mmcblk");
+        if (ret >= 0)
+            host->mmc->devidx = ret;
+    }
+
     /* write_protect */
     if (boarddata->wp_type == ESDHC_WP_GPIO) {
         err = mmc_gpio_request_ro(host->mmc, boarddata->wp_gpio);
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 3b0c33a..8209f72 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -362,6 +362,8 @@ struct mmc_host {

     unsigned int        slotno;    /* used for sdio acpi binding */

+    /* preferred mmc block device index (mmcblkX) */
+    unsigned int        devidx;
     unsigned long        private[0] ____cacheline_aligned;
 };

What do you think?
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Dirk Behme]

Hi Fabio,

Am 18.09.2013 02:06, schrieb Fabio Estevam:
> Hi Dirk,
>
> On Tue, Sep 17, 2013 at 3:04 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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.
>
> I simplied your patch a bit:
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index 1a3163f..94f842b 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -2026,7 +2026,7 @@ static struct mmc_blk_data
> *mmc_blk_alloc_req(struct mmc_card *card,
>       struct mmc_blk_data *md;
>       int devidx, ret;
>
> -    devidx = find_first_zero_bit(dev_use, max_devices);
> +    devidx = find_next_zero_bit(dev_use, max_devices, card->host->devidx);
>       if (devidx >= max_devices)
>           return ERR_PTR(-ENOSPC);
>       __set_bit(devidx, dev_use);
> @@ -2044,7 +2044,8 @@ static struct mmc_blk_data
> *mmc_blk_alloc_req(struct mmc_card *card,
>        * index anymore so we keep track of a name index.
>        */
>       if (!subname) {
> -        md->name_idx = find_first_zero_bit(name_use, max_devices);
> +        md->name_idx = find_next_zero_bit(name_use, max_devices,
> +                card->host->devidx);
>           __set_bit(md->name_idx, name_use);
>       } else
>           md->name_idx = ((struct mmc_blk_data *)
> diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
> b/drivers/mmc/host/sdhci-esdhc-imx.c
> index abc8cf0..e11a6af 100644
> --- a/drivers/mmc/host/sdhci-esdhc-imx.c
> +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
> @@ -524,8 +524,9 @@ static int sdhci_esdhc_imx_probe(struct
> platform_device *pdev)
>       struct sdhci_pltfm_host *pltfm_host;
>       struct sdhci_host *host;
>       struct esdhc_platform_data *boarddata;
> -    int err;
> +    int err, ret;
>       struct pltfm_imx_data *imx_data;
> +    struct device_node *np = pdev->dev.of_node;
>
>       host = sdhci_pltfm_init(pdev, &sdhci_esdhc_imx_pdata, 0);
>       if (IS_ERR(host))
> @@ -602,6 +603,13 @@ static int sdhci_esdhc_imx_probe(struct
> platform_device *pdev)
>                       host->mmc->parent->platform_data);
>       }
>
> +
> +    if (np) {
> +        ret = of_alias_get_id(np, "mmcblk");
> +        if (ret >= 0)
> +            host->mmc->devidx = ret;
> +    }
> +
>       /* write_protect */
>       if (boarddata->wp_type == ESDHC_WP_GPIO) {
>           err = mmc_gpio_request_ro(host->mmc, boarddata->wp_gpio);
> diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
> index 3b0c33a..8209f72 100644
> --- a/include/linux/mmc/host.h
> +++ b/include/linux/mmc/host.h
> @@ -362,6 +362,8 @@ struct mmc_host {
>
>       unsigned int        slotno;    /* used for sdio acpi binding */
>
> +    /* preferred mmc block device index (mmcblkX) */
> +    unsigned int        devidx;
>       unsigned long        private[0] ____cacheline_aligned;
>   };
>
> What do you think?

Do you like to send this as a proper patch? Following the recent 
discussion it sounds to me that there is really some need for 
something like this. Then we could discuss the technical details.

Best regards

Dirk

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

Re: Adding aliases to mmc

[Fabio Estevam]

Hi Dirk,

On Sun, Sep 22, 2013 at 3:48 AM, Dirk Behme <dirk.behme@gmail.com> wrote:

> Do you like to send this as a proper patch? Following the recent discussion
> it sounds to me that there is really some need for something like this. Then
> we could discuss the technical details.

Please do so.

Thanks,

Fabio Estevam

Re: Adding aliases to mmc

[Fabio Estevam]

Hi Dirk,

On Sun, Sep 22, 2013 at 12:24 PM, Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Dirk,
>
> On Sun, Sep 22, 2013 at 3:48 AM, Dirk Behme <dirk.behme-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
>> Do you like to send this as a proper patch? Following the recent discussion
>> it sounds to me that there is really some need for something like this. Then
>> we could discuss the technical details.
>
> Please do so.

Sorry, I misread your email. I can submit it to the list.

Regards,

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

Re: Adding aliases to mmc

[Dirk Behme]

Hi Fabio,

Am 17.09.2013 20:04, schrieb Fabio Estevam:
> 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.

If I remember the history correctly, instead of the approach linked 
above, I've submitted an alternative solution:

http://marc.info/?l=linux-mmc&m=134423822729031

But this hasn't found it's way into mainline, too.

Best regards

Dirk



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

Re: Adding aliases to mmc

[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 unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Dirk Behme]

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)?

Best regards

Dirk

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

Re: Adding aliases to mmc

[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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Dirk Behme]

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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Stephen Warren]

On 09/18/2013 11:22 PM, Dirk Behme wrote:
...
> 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.

As I said above, whatever generates the filesystem image can easily
embed the appropriate UUID in the system's boot scripts or bootloader
environment. There's no need to run the "part" command at run-time if
there's a more appropriate flow for your situation.

Re: Adding aliases to mmc

[Dirk Behme]

Am 20.09.2013 18:05, schrieb Stephen Warren:
> On 09/18/2013 11:22 PM, Dirk Behme wrote:
> ...
>> 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.
>
> As I said above, whatever generates the filesystem image can easily
> embed the appropriate UUID in the system's boot scripts or bootloader
> environment. There's no need to run the "part" command at run-time if
> there's a more appropriate flow for your situation.

Using a simple boot loader as an example, there are no boot scripts or 
boot loader environment. The only thing the boot loader does is 
loading the device tree and the kernel into RAM. Where do you want to 
embed an UUID in such a product?

To my understanding, the UUID is different for each SD card/eMMC, correct?

Best regards

Dirk

Re: Adding aliases to mmc

[Stephen Warren]

On 09/20/2013 10:37 AM, Dirk Behme wrote:
> Am 20.09.2013 18:05, schrieb Stephen Warren:
>> On 09/18/2013 11:22 PM, Dirk Behme wrote:
>> ...
>>> 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.
>>
>> As I said above, whatever generates the filesystem image can easily
>> embed the appropriate UUID in the system's boot scripts or bootloader
>> environment. There's no need to run the "part" command at run-time if
>> there's a more appropriate flow for your situation.
> 
> Using a simple boot loader as an example, there are no boot scripts or
> boot loader environment. The only thing the boot loader does is loading
> the device tree and the kernel into RAM. Where do you want to embed an
> UUID in such a product?

I think the initrd would be typical.

> To my understanding, the UUID is different for each SD card/eMMC, correct?

Yes by default.

Although for an embedded product with a fixed eMMC, there's no reason
you couldn't make every device have the same UUID for the fixed device.
Obviously you wouldn't want to do that for any removable device.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Dirk Behme]

Am 20.09.2013 19:03, schrieb Stephen Warren:
> On 09/20/2013 10:37 AM, Dirk Behme wrote:
>> Am 20.09.2013 18:05, schrieb Stephen Warren:
>>> On 09/18/2013 11:22 PM, Dirk Behme wrote:
>>> ...
>>>> 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.
>>>
>>> As I said above, whatever generates the filesystem image can easily
>>> embed the appropriate UUID in the system's boot scripts or bootloader
>>> environment. There's no need to run the "part" command at run-time if
>>> there's a more appropriate flow for your situation.
>>
>> Using a simple boot loader as an example, there are no boot scripts or
>> boot loader environment. The only thing the boot loader does is loading
>> the device tree and the kernel into RAM. Where do you want to embed an
>> UUID in such a product?
>
> I think the initrd would be typical.

An embedded system typically doesn't have an initrd. The kernel boots 
directly into the rootfs on SD/eMMC.

>> To my understanding, the UUID is different for each SD card/eMMC, correct?
>
> Yes by default.
>
> Although for an embedded product with a fixed eMMC, there's no reason
> you couldn't make every device have the same UUID for the fixed device.

How do you make the eMMC on 1000 boards have the same UUID?

How do you ensure that this eMMC is enumerated as mmcblk0, always? 
Independent if there is a SD card in the second/removable slot at boot 
time or not?

Best regards

Dirk

Re: Adding aliases to mmc

[Sascha Hauer]

Hi Dirk,

On Sat, Sep 21, 2013 at 07:23:27AM +0200, Dirk Behme wrote:
> Am 20.09.2013 19:03, schrieb Stephen Warren:
> >On 09/20/2013 10:37 AM, Dirk Behme wrote:
> >>Am 20.09.2013 18:05, schrieb Stephen Warren:
> >>>On 09/18/2013 11:22 PM, Dirk Behme wrote:
> >>>...
> >>>>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.
> >>>
> >>>As I said above, whatever generates the filesystem image can easily
> >>>embed the appropriate UUID in the system's boot scripts or bootloader
> >>>environment. There's no need to run the "part" command at run-time if
> >>>there's a more appropriate flow for your situation.
> >>
> >>Using a simple boot loader as an example, there are no boot scripts or
> >>boot loader environment. The only thing the boot loader does is loading
> >>the device tree and the kernel into RAM. Where do you want to embed an
> >>UUID in such a product?
> >
> >I think the initrd would be typical.
> 
> An embedded system typically doesn't have an initrd. The kernel
> boots directly into the rootfs on SD/eMMC.
> 
> >>To my understanding, the UUID is different for each SD card/eMMC, correct?
> >
> >Yes by default.
> >
> >Although for an embedded product with a fixed eMMC, there's no reason
> >you couldn't make every device have the same UUID for the fixed device.
> 
> How do you make the eMMC on 1000 boards have the same UUID?

The same way you ensure an identical partition table in these 1000
boards. The disk signature is just a four byte value at offset 440 in
the MBR. Set this to your birthday or whatever on all boards, pass
root=PARTUUID=<yourbirthday>-01 on all boards and you're done.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Re: Adding aliases to mmc

[Michael Olbrich]

Hi,

On Sat, Sep 21, 2013 at 09:42:38AM +0200, Sascha Hauer wrote:
> On Sat, Sep 21, 2013 at 07:23:27AM +0200, Dirk Behme wrote:
> > Am 20.09.2013 19:03, schrieb Stephen Warren:
> > >On 09/20/2013 10:37 AM, Dirk Behme wrote:
> > >>Am 20.09.2013 18:05, schrieb Stephen Warren:
> > >>>On 09/18/2013 11:22 PM, Dirk Behme wrote:
> > >>>...
> > >>>>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.
> > >>>
> > >>>As I said above, whatever generates the filesystem image can easily
> > >>>embed the appropriate UUID in the system's boot scripts or bootloader
> > >>>environment. There's no need to run the "part" command at run-time if
> > >>>there's a more appropriate flow for your situation.
> > >>
> > >>Using a simple boot loader as an example, there are no boot scripts or
> > >>boot loader environment. The only thing the boot loader does is loading
> > >>the device tree and the kernel into RAM. Where do you want to embed an
> > >>UUID in such a product?
> > >
> > >I think the initrd would be typical.
> > 
> > An embedded system typically doesn't have an initrd. The kernel
> > boots directly into the rootfs on SD/eMMC.
> > 
> > >>To my understanding, the UUID is different for each SD card/eMMC, correct?
> > >
> > >Yes by default.
> > >
> > >Although for an embedded product with a fixed eMMC, there's no reason
> > >you couldn't make every device have the same UUID for the fixed device.
> > 
> > How do you make the eMMC on 1000 boards have the same UUID?
> 
> The same way you ensure an identical partition table in these 1000
> boards. The disk signature is just a four byte value at offset 440 in
> the MBR. Set this to your birthday or whatever on all boards, pass
> root=PARTUUID=<yourbirthday>-01 on all boards and you're done.

Until someone inserts a SD-Card with the same disk signature...

Always booting from eMMC is a quite important use case for embedded
systems. And so far the only reliable solution seems to be an initrd. And
using an initrd is not acceptable in many cases. Certainly not just to
figure out where the rootfs is.

Regards,
Michael

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Sascha Hauer]

On Sat, Sep 21, 2013 at 02:30:51PM +0200, Michael Olbrich wrote:
> Hi,
> 
> > > 
> > > An embedded system typically doesn't have an initrd. The kernel
> > > boots directly into the rootfs on SD/eMMC.
> > > 
> > > >>To my understanding, the UUID is different for each SD card/eMMC, correct?
> > > >
> > > >Yes by default.
> > > >
> > > >Although for an embedded product with a fixed eMMC, there's no reason
> > > >you couldn't make every device have the same UUID for the fixed device.
> > > 
> > > How do you make the eMMC on 1000 boards have the same UUID?
> > 
> > The same way you ensure an identical partition table in these 1000
> > boards. The disk signature is just a four byte value at offset 440 in
> > the MBR. Set this to your birthday or whatever on all boards, pass
> > root=PARTUUID=<yourbirthday>-01 on all boards and you're done.
> 
> Until someone inserts a SD-Card with the same disk signature...

Indeed. That would be a nice way to boot your own rootfs on otherwise
locked devices ;)

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

RE: Adding aliases to mmc

[Chaiken, Alison]

Stephen Warren writes:
>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.

Why may network devices have static IPs and yet storage devices can't have static names?    Isn't insisting on dynamic names the same as insisting on DHCP?   

The  distinction appears to be historical, in that DHCP has been around a long time, but no one cared about boot times of MMC-based devices until relatively recently.    Doesn't the same argument apply to all aliases, not to mention "chosen" node?   Consider what Russell King said recently:

http://thread.gmane.org/gmane.linux.kernel/1532141/focus=1532265

I understand that there is a widespread desire to institute a new level of quality control in the device-tree, but if we are agreeing on a new rule, let's be explicit about it.

-- 
Alison Chaiken
Mentor Embedded Software
Fremont CA USA
GMT-8--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding aliases to mmc

[Stephen Warren]

On 09/20/2013 12:30 AM, Chaiken, Alison wrote:
> Stephen Warren writes:
>> 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.
> 
> Why may network devices have static IPs and yet storage devices can't have static names? 

Ethernet devices have MAC addresses as their unique ID. Block devices
have PARTUUIDs and filesystems have UUIDs. The IP address is keyed to
the MAC address.

(In desktop distributions these days, I believe that MAC address
typically drives device name via renaming, and then device name indexes
the network configuration, which then determines the IP. Alternatively,
MAC address drives IP address via DHCP).

To my mind, using UUIDs as the key rather than device name is exactly
the same situation, not a different one.

...
> I understand that there is a widespread desire to institute a new level of quality control in the device-tree, but if we are agreeing on a new rule, let's be explicit about it.

(please word-wrap your email)

I don't believe this has anything at all to do with device tree; my
first experience with this issue was long before DT.

The issue is that block device IDs cannot be equal to controller IDs, since:

* Mount an SD card -> assigned an ID at run-time
* Physically unplug it  -> ID kept since it's still referenced
* Plug a new card back in -> assigned a new ID at run-time

Therefore, there's no 1:1 match possible between SD/MMC controllers and
SD/MMC block device names. It's dynamic.

The same is true of USB mass storage devices too, I believe.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html