eMMC devices being probed inconsistently by kernel driver
28 views
Skip to first unread message
Guthrie Hamish
Sep 10, 2025, 4:19:41 AM (2 days ago) Sep 10
to swup...@googlegroups.com
Hi,
We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I
have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
Any ideas?
|
|
|
Hamish Guthrie
Senior Embedded Software Engineer |
|
Kistler Instrumente AG Eulachstrasse 22, 8408 Winterthur, Switzerland Direct +41 52 2241 642, Main Office +41 52 224 11 11 |
|
|
|
|
|
|
|
|
Stefano Babic
Sep 10, 2025, 4:35:24 AM (2 days ago) Sep 10
to Guthrie Hamish, swup...@googlegroups.com
Hi Hamish,
On 9/10/25 10:19, 'Guthrie Hamish' via swupdate wrote:
> Hi,
>
> We have a device with both SD-Card and eMMC being handled by the same
> device driver and normally, the eMMC device comes up on /dev/mmcblk1 and
> the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed
> first and as a result is associated with /dev/mmcblk0.
It is common, it depends which controller has finished the probe first,
and this happens.
>
> For our regular update mechanism I use the /dev/disk/by-partlabel/
> <partition-label> device, so this does not effect us, however, we also
> provision our devices in production using swupdate and our .swu image
> contains partitioning information, and for that I have a partitions
> section which needs to know the device to partition, and there I use /
> dev/mmcblk1, but if the devices are probed incorrectly, this does not
> work, and of course there is no similar symlink to reliably find the
> real device.
>
> Any ideas?
Well, you can set an udev rule for set up a link, or you could detect
the device inside swupdate using a hook:
...
embedded_script = "
function dectect_emmc(image)
.....
end";
....
partitions: (
{
type = "diskpart";
device = "dummy";
hook = "detect_emmc";
....
and generally it is enough a check inside /sys to know which is the
correct one.
Best regards,
Stefano Babic
>
>
>
> Hamish Guthrie
> Senior Embedded Software Engineer
>
> *Kistler Instrumente AG*
> www.kistler.com <https://www.kistler.com/>, myKistler <https://
> www.kistler.com/mykistler?
> utm_source=Outlook_signature&utm_medium=Outlook_signature&utm_campaign=Outlook_signature&utm_id=Outlook_signature>, Contact Service <mailto:Ser...@kistler.com?subject=Service%20request>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/
> AS1P190MB17769D3DC360BE88A2FDC654830EA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/swupdate/AS1P190MB17769D3DC360BE88A2FDC654830EA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
On 9/10/25 10:19, 'Guthrie Hamish' via swupdate wrote:
> Hi,
>
> We have a device with both SD-Card and eMMC being handled by the same
> device driver and normally, the eMMC device comes up on /dev/mmcblk1 and
> the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed
> first and as a result is associated with /dev/mmcblk0.
and this happens.
>
> For our regular update mechanism I use the /dev/disk/by-partlabel/
> <partition-label> device, so this does not effect us, however, we also
> provision our devices in production using swupdate and our .swu image
> contains partitioning information, and for that I have a partitions
> section which needs to know the device to partition, and there I use /
> dev/mmcblk1, but if the devices are probed incorrectly, this does not
> work, and of course there is no similar symlink to reliably find the
> real device.
>
> Any ideas?
the device inside swupdate using a hook:
...
embedded_script = "
function dectect_emmc(image)
.....
end";
....
partitions: (
{
type = "diskpart";
device = "dummy";
hook = "detect_emmc";
....
and generally it is enough a check inside /sys to know which is the
correct one.
Best regards,
Stefano Babic
>
>
>
> Hamish Guthrie
> Senior Embedded Software Engineer
>
>
> Eulachstrasse 22, 8408 Winterthur, Switzerland
>
> Direct +41 52 2241 642, Main Office +41 52 224 11 11
> hamish....@kistler.com <mailto:hamish....@kistler.com>,
> Eulachstrasse 22, 8408 Winterthur, Switzerland
>
> Direct +41 52 2241 642, Main Office +41 52 224 11 11
> www.kistler.com <https://www.kistler.com/>, myKistler <https://
> www.kistler.com/mykistler?
> utm_source=Outlook_signature&utm_medium=Outlook_signature&utm_campaign=Outlook_signature&utm_id=Outlook_signature>, Contact Service <mailto:Ser...@kistler.com?subject=Service%20request>
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "swupdate" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to swupdate+u...@googlegroups.com
> <mailto:swupdate+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> swupdate/
> AS1P190MB17769D3DC360BE88A2FDC654830EA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM <https://groups.google.com/d/msgid/swupdate/AS1P190MB17769D3DC360BE88A2FDC654830EA%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM?utm_medium=email&utm_source=footer>.
Fabio Estevam
Sep 10, 2025, 6:43:11 AM (2 days ago) Sep 10
to Guthrie Hamish, swup...@googlegroups.com
Hi Hamish,
On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
<swup...@googlegroups.com> wrote:
>
> Hi,
>
> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>
> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>
> Any ideas?
There is no guarantee of the probe order in the kernel.
This is a common problem, and there are some solutions:
1. You can pass aliases in the devicetree so that the SDHC controller
associated with the SD card is mmc0 and the one with the eMMC is mmc1.
Example:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15
or
2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
(Search for "run finduuid" inside U-Boot)
On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
<swup...@googlegroups.com> wrote:
>
> Hi,
>
> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>
> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>
> Any ideas?
This is a common problem, and there are some solutions:
1. You can pass aliases in the devicetree so that the SDHC controller
associated with the SD card is mmc0 and the one with the eMMC is mmc1.
Example:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15
or
2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
(Search for "run finduuid" inside U-Boot)
Stefano Babic
Sep 10, 2025, 7:17:06 AM (2 days ago) Sep 10
to swup...@googlegroups.com
On 9/10/25 12:42, Fabio Estevam wrote:
> Hi Hamish,
>
> On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
> <swup...@googlegroups.com> wrote:
>>
>> Hi,
>>
>> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>>
>> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>>
>> Any ideas?
>
> There is no guarantee of the probe order in the kernel.
>
> This is a common problem, and there are some solutions:
>
> 1. You can pass aliases in the devicetree so that the SDHC controller
> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
>
Sure.
> Hi Hamish,
>
> On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
> <swup...@googlegroups.com> wrote:
>>
>> Hi,
>>
>> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>>
>> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>>
>> Any ideas?
>
> There is no guarantee of the probe order in the kernel.
>
> This is a common problem, and there are some solutions:
>
> 1. You can pass aliases in the devicetree so that the SDHC controller
> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
>
> Example:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm/boot/dts/nxp/imx/imx7d-smegw01.dts?h=v6.16.6#n15
>
> or
>
> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>
> (Search for "run finduuid" inside U-Boot)
>
Stefano
Guthrie Hamish
Sep 10, 2025, 11:36:36 PM (2 days ago) Sep 10
to Stefano Babic, swup...@googlegroups.com
Hi Fabio and Stefano,
Thanks for the feedback!
>On 9/10/25 12:42, Fabio Estevam wrote:
>> Hi Hamish,
>>
>> On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
>> <swup...@googlegroups.com> wrote:
>>>
>>> Hi,
>>>
>>> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>>>
>>> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>>>
>>> Any ideas?
>>
>> There is no guarantee of the probe order in the kernel.
>>
>> This is a common problem, and there are some solutions:
>>
>> 1. You can pass aliases in the devicetree so that the SDHC controller
>> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
>>
>Sure.
>> Hi Hamish,
>>
>> On Wed, Sep 10, 2025 at 5:19 AM 'Guthrie Hamish' via swupdate
>> <swup...@googlegroups.com> wrote:
>>>
>>> Hi,
>>>
>>> We have a device with both SD-Card and eMMC being handled by the same device driver and normally, the eMMC device comes up on /dev/mmcblk1 and the SD-Card on /dev/mmcblk0. Occasionally however, the eMMC is probed first and as a result is associated with /dev/mmcblk0.
>>>
>>> For our regular update mechanism I use the /dev/disk/by-partlabel/<partition-label> device, so this does not effect us, however, we also provision our devices in production using swupdate and our .swu image contains partitioning information, and for that I have a partitions section which needs to know the device to partition, and there I use /dev/mmcblk1, but if the devices are probed incorrectly, this does not work, and of course there is no similar symlink to reliably find the real device.
>>>
>>> Any ideas?
>>
>> There is no guarantee of the probe order in the kernel.
>>
>> This is a common problem, and there are some solutions:
>>
>> 1. You can pass aliases in the devicetree so that the SDHC controller
>> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
>>
>Sure.
What I omitted to mention is the device is an x86 platform, so there is no devicetree
>> Example:
>> Example:
>>
>> or
>>
>> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>>
>> (Search for "run finduuid" inside U-Boot)
>>
>This doesn't help if you need the device for partitioning.
>> or
>>
>> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>>
>> (Search for "run finduuid" inside U-Boot)
>>
>This doesn't help if you need the device for partitioning.
It also doesn't help that we are not using u-boot!
Ulrich Teichert
Sep 11, 2025, 8:07:06 AM (22 hours ago) Sep 11
to swupdate
Hi,
>> There is no guarantee of the probe order in the kernel.
>> This is a common problem, and there are some solutions:
>>
>> 1. You can pass aliases in the devicetree so that the SDHC controller
>> associated with the SD card is mmc0 and the one with the eMMC is mmc1.
Ah, that's something I'll will try as soon as I can, because....
>Sure.
What I omitted to mention is the device is an x86 platform, so there is no devicetree
>>
>> or
>>
>> 2. You can use the UUID mechanism to distinguish between the SD card and eMMC.
>>
>> (Search for "run finduuid" inside U-Boot)
>>
>This doesn't help if you need the device for partitioning.
It also doesn't help that we are not using u-boot!
...there's a third option, depending on the kernel version and the MMC kernel driver, but there's no
configuration option for it, you have to patch your kernel: you can force synchronous probing if the
driver supports it. I was lucky, it just worked with the arasan-SD driver:
--------------------- drivers/mmc/host/sdhci-of-arasan.c ----------------------
index ff90331468a1..6edf25e1db5a 100644
@@ -1720,7 +1720,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
static struct platform_driver sdhci_arasan_driver = {
.driver = {
.name = "sdhci-arasan",
- .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .probe_type = PROBE_FORCE_SYNCHRONOUS,
.of_match_table = sdhci_arasan_of_match,
.pm = &sdhci_arasan_dev_pm_ops,
},
index ff90331468a1..6edf25e1db5a 100644
@@ -1720,7 +1720,7 @@ static int sdhci_arasan_remove(struct platform_device *pdev)
static struct platform_driver sdhci_arasan_driver = {
.driver = {
.name = "sdhci-arasan",
- .probe_type = PROBE_PREFER_ASYNCHRONOUS,
+ .probe_type = PROBE_FORCE_SYNCHRONOUS,
.of_match_table = sdhci_arasan_of_match,
.pm = &sdhci_arasan_dev_pm_ops,
},
HTH,
Uli
Nicholas Clark
Sep 11, 2025, 10:00:55 AM (20 hours ago) Sep 11
to Guthrie Hamish, Stefano Babic, swup...@googlegroups.com
Can you solve it with udev rules? Maybe you can detect by manufacturer or some other field that differentiates the two, and use it to create a symlink. Then you can target the device by symlink.
--
You received this message because you are subscribed to the Google Groups "swupdate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swupdate+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/swupdate/AS1P190MB17760E65894BAAF44D318FD18309A%40AS1P190MB1776.EURP190.PROD.OUTLOOK.COM.
Reply all
Reply to author
Forward
0 new messages