Hi!
We see sometimes with different DB410c that the boot from emmc hangs. The logs suggest, that /dev/mmcblk0 and /dev/mmcblk1 are interchanged, i.e. sd card and emmc are confused. As we do not have an sd card inserted, and we need rootwait cmd line option to wait for the device to come online, the boot hangs waiting for rootfs to appear. We use OpenEmbedded, if that matters. Does someone have more insights on why this can happen?? Iff it can happen?!
Regards,
Matthias
I wasn’t aware of this issue but it is avoided for Debian through the use of an initramfs meaning we locate the root filesystem using a unique ID rather than by using the device name. A similar approach would work for OpenEmbedded but I think the process for creating the initramfs would be rather different.
Hi,
I guess, that would work. Since we do not use SD Card slot when booting from emmc, my workaround right now is to remove SD Card slot from Device Tree, which also solved the issue.
Maybe, I will have a look into that initramfs… May be a little difficult, since we use A/B rootfs partitioning sheme with a ro rootfs… We need to pass the right parition from the boot loader into the kernel somehow…
Regards,
Matthias
root=UUID=aaaaaa picks up the filesystem UUID which might be risky since the A/B could both have the same ID (although you could easily configure your CI system to avoid it 
).
The alternative is root=PARTUUID=aaaaaa or root=PARTLABEL=rootfs-a which will pick up the strings from the partition table instead. If you author the partition table carefully this allows you to give A and B well known but distinct names.
Oh… or a simpler approach might be to see if adding DT aliases can give you stable enumeration.
There’s a patch to do that here although I didn’t keep reading to find out if anything like this was merged:
https://patchwork.kernel.org/patch/8984261/
Indeed this is what I was looking for. Thank you!
Patches welcome if you want to share where you’re done . DB410C is essentially fully supported in upstream Linux so sharing in this case would meand contributing the patches directly to LKML.
This patch was never merged and I don’t think it will get merged ever soon. Folks who oppose the DT probe order have a valid reason. The host allocation scheme (depends on the order which the host probes the mmc controllers) is common across different peripherals like usb, ethernet, sata etc… So it is really upto the userspace to handle the rootfs location work by using UUID, PARTUUID etc…
Each sub-system seems to be handling it differently. SPI handling of DT policy is fairly neat (given devices like the buspirate are USB SPI devices and therefore SPI must handle dynamic situations). The aliases are scanned and the highest alias (+1) becomes the lowest value that can be allocated dynamically… this allows devices that must be dynamically numbered to coexist with SoC peripherals with DT controlled values.
