[Letux-kernel] Subtle issue with U-Boot and kernel and SD card UUIDs

Belisko Marek marek.belisko at gmail.com
Tue May 23 14:23:55 CEST 2017

Hi Nikolaus,

On Tue, May 23, 2017 at 12:02 PM, H. Nikolaus Schaller
<hns at goldelico.com> wrote:
> Hi Marek,
>> Am 23.05.2017 um 11:25 schrieb Belisko Marek <marek.belisko at gmail.com>:
>> Hi Nikoalus,
>> On Tue, May 23, 2017 at 10:42 AM, H. Nikolaus Schaller
>> <hns at goldelico.com> wrote:
>>> Hi,
>>> I recently flashed the eMMC of the OMAP5EVM and the Pyra and now a subtle issue
>>> has surfaced.
>>> If I boot without SD card from eMMC everything is fine.
>>> But if I boot from the SD card it works fine for U-Boot and loading the kernel,
>>> but the kernel loaded from SD card mounts the rootfs from eMMC and does not find
>>> any loadable modules (unless kernels are exactly the same version).
>>> I could trace the u-boot-kernel interaction down to the uboot environment
>>>        finduuid=part uuid mmc ${mmcdev}:2 uuid
>>>        args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
>> I was facing similar issue yesterday but my root looks like
>> root=LABEL=rootfsA. I just drop LABEL=rootfsA and replace by /dev/sdb2
>> (in my case) and it works fine.
> Yes, this is the "old style" way of defining the root by a hard-coded name.
Yes I know. I'm using grub  as bootloader so there could be something
else which prevent label to work.
Maybe it's bootloader which needs to translate LABEL=something to map
to correct block device? Do you have any idea about that?
> But the problem is that there is no guarantee any more in modern kernels
> that sdb2 is not sdc2 on next boot. Depending on which other devices
> are plugged in.
> And I want the bootargs to somehow be the same if I boot from eMMC or SD
> card. Or we have to ask users to configure uEnv.txt each time they plug
> in different cards...
> As long as the device just has one device of each type it is stable.
>> I was trying shortly look to kernel source and I cannot find anything
>> related to LABEL but for your case it should work (please loon for
>> comment for function name_to_dev_t in ini/do_mounts.c)
>> Hope this helps.
> The problem with LABEL is that they all have the same label by the way
> the makesd script is doing the partitioning. It creates a "boot" and one
> "rootfs" partition. And then we have the same problem: the eMMC provides
> a "rootfs" partition as well as the SD card that is plugged in.
> And, I can't make the label match the numbering scheme U-Boot is assuming
> (mmc 0:2 vs. mmc 1:2).
> The UUID approach was invented to solve all these issues. But for that it
> should work...
>>> This is not at all wrong and should do what it is intended for: map the mmc
>>> device numbers from U-Boot in a way that the kernel can assign a different
>>> order (and it does!).
>>> This is done by translating the device numbers into a unique code, i.e. the
>>> UUID.
>>> Now why does it not work in my setup?
>>> Breaking into the U-Boot console shows the problem:
>>> => part list mmc 0
>>> Partition Map for MMC device 0  --   Partition Type: DOS
>>> Part    Start Sector    Num Sectors     UUID            Type
>>>  1     128             778233          00000000-01     0c Boot
>>>  2     778361          14786439        00000000-02     83
>>> => part list mmc 1
>>> Partition Map for MMC device 1  --   Partition Type: DOS
>>> Part    Start Sector    Num Sectors     UUID            Type
>>>  1     128             386656          00000000-01     0c Boot
>>>  2     386784          7346464         00000000-02     83
>>> =>
>>> Both, the eMMC and the SD card have the same UUIDs i U-Boot and therefore
>>> the kernel picks up the wrong one...
>>> Now how can they have the same UUID? It should be unique, shouldn't it?
>>> That is strange since after booting into Linux (still without
>>> kernel modules), I can look up how Linux sees the storage partitions:
>>> root at letux:~# blkid
>>> /dev/mmcblk0p1: LABEL="boot" UUID="E052-71A6" TYPE="vfat"
>>> /dev/mmcblk0p2: LABEL="rootfs" UUID="5db8fefe-f8d2-46e4-828a-ab4fe1b8f9b4" TYPE="ext3"
>>> /dev/mmcblk1p1: LABEL="boot" UUID="ED66-B684" TYPE="vfat"
>>> /dev/mmcblk1p2: LABEL="rootfs" UUID="cd5f3d4c-c562-4aa0-893c-9fa9e9bd64a9" TYPE="ext3"
>>> /dev/mmcblk0: PTTYPE="dos"
>>> /dev/mmcblk1: PTTYPE="dos"
>>> root at letux:~#
>>> And there, we have nice UUIDs!
>>> Looks as if U-Boot does not recognize them. But the kernel still can mount
>>> some rootfs by "root=PARTUUID=00000000-02". Strange.
> I have digged a little into the U-Boot code and the 'part list' command
>         http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=cmd/part.c;h=414031e6f3e06a391d4c053ea6eefe7b72e0da75;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l110
> calls part_print().
> There appear to be different part_print subfunctions for each partition scheme.
> iMac:src hns$ fgrep part_print -R System.map
> System.map:8001b084 T part_print
> System.map:8001b744 T part_print_dos
> System.map:8001bc58 t part_print_iso
> System.map:8001c118 T part_print_efi
> iMac:src hns$
> And since I format the SD cards by MBR format, I guess part_print_dos() is called.
>         http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l261
> This finally calls
>         http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l50
> There it simply prints %08x-%02x which corresponds to our PARTUUID=00000000-02
> So it appears as if U-Boot is not capable of detecting the full UUID of an ext3 partition on a MBR disk while the kernel does.
> What I have seen while going through the code: there is some CONFIG_PARTITION_TYPE_GUID
> Maybe we need to define it?
Maybe yes. Did you try to use GPT partitioning? UUID then should be "real" UUID.
> BR
> Nikolaus
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel



as simple and primitive as possible
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com

More information about the Letux-kernel mailing list