On Tue, May 23, 2017 at 2:23 PM, Belisko Marek marek.belisko@gmail.com wrote:
Hi Nikolaus,
On Tue, May 23, 2017 at 12:02 PM, H. Nikolaus Schaller hns@goldelico.com wrote:
Hi Marek,
Am 23.05.2017 um 11:25 schrieb Belisko Marek marek.belisko@gmail.com:
Hi Nikoalus,
On Tue, May 23, 2017 at 10:42 AM, H. Nikolaus Schaller hns@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?
Too fast hitting Send button: http://mulix.livejournal.com/84768.html so it's completely in initrd not in kernel :-)
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@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@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#l110calls 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#l261This finally calls
http://git.goldelico.com/?p=gta04-uboot.git;a=blob;f=disk/part_dos.c;h=ed78334a9dd85059c81dc744692fa6dd34308853;hb=0c5e26e7886ea7d2d934f65e2e6cbf15a2b52bc8#l50There 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@openphoenux.org http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel
BR,
marek
-- 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
BR,
marek