Hi Marek, regarding the "LABEL=" I think it is not handled by U-Boot. U-Boot only has some support for partition UUIDs.
What I have seen while going through the code: there is some CONFIG_PARTITION_TYPE_GUID Maybe we need to define it?
Maybe yes.
Doesn't seem to make a difference.
Did you try to use GPT partitioning? UUID then should be "real" UUID.
No, we have used MBR for all OMAP3/4/5/am335x devices so far.
I am not sure if the "MLO in FAT partition" approach works for GPT at all.
I have tried to find some background information about the MBR and UUID without great success... I start to hate open source because of the closed (aka missing) documentation :)
And to increase confusion, there even seems to be a difference between root=UUID=... and root=PARTUUID=...
https://wiki.archlinux.org/index.php/Persistent_block_device_naming#Boot_man...
So to all my knowledge so far:
* DOS knows a "disk label" - but that is not the partition UUID we need here. * U-Boot does not provide a good uuid for MBR based SD cards * OMAP needs a MBR formatted SD * the "UUID" shown by kernel blkid might be randomly assigned (have not tried to find out) * (s)fdisk has no mechanism to define UUIDs for partitions - tune2fs could, but that is not what U-Boot can identify
By the way: this UUID thing is a strong argument against creating SD cards by dd-ing some .img to the raw disk. They will all share the UUIDs and are not uniquely identified any more.
I have checked again the U.Boot code of print_part_dos() and it appears as it it should be able to print some "disksig" if CONFIG_PARTITION_UUIDS is enabled. But it is difficult to understand the code.
BR, Nikolaus