Re: [yocto] [meta-rockchip][PATCH] use uuid instead of hard-coding root device

[Trevor Woerner <twoerner@gmail.com>]

On Thu 2021-09-23 @ 09:45:06 PM, Markus Volk wrote:
> 
> Am 23.09.21 um 13:59 schrieb Trevor Woerner:
> > Curious. I boot tested my patch on multiple boards and I've built and booted
> > numerous images on my rock-pi-4b and rock64 boards in the last day or so since
> > I applied the patch. I'll try some "clean" builds and see if that makes a
> > difference. I don't doubt your report (especially since Khem confirmed it),
> > I'd just like to know for myself what's different.
> 
> That is really strange. As soon as there are those /dev/sda* entries in my fstab
> my rock-pi-4c doesn't boot up anymore. As soon as i comment them out or delete them,
> everything is working again.

Thanks for testing. It's also strange that my fstab also has those entries,
but they're apparently ignored in my setup since, commented in or commented
out, they don't seem to affect my board's ability to boot.

> > I wonder if just applying your 2nd patch would be enough (i.e. the one that
> > removes the /dev/sda* lines from /etc/fstab)? It's odd that the first 6
> > entries in the wic file would need UUIDs since it's the SoC's ROM firmware
> > that uses them, and I'm pretty sure the Rockchip firmware isn't using UUIDs
> > (my guess is it's just blindly grabbing whatever it finds at specific
> > offsets). The things stored in those partitions are u-boot related bits (atf,
> > spl, the u-boot binary itself) so by the time Linux starts, those things are
> > already "behind" us. I can't see how adding UUIDs to the partitions holding
> > u-boot would affect how the kernel finds the root partition (?).
> 
> Applying only the second patch should be enough to hide the problem, but as soon as
> one decides to disable WIC_CREATE_EXTRA_ARGS for example because he/she wants /boot to be
> mounted automatically, those non working /dev/sda* entries will be written into fstab again.
> With the first patch they are included like this and are mountable via fstab:
> 
> 
> UUID=0C48-9342	loader1	vfat	defaults	0	0
> UUID=C4D3-D17A	reserved1	vfat	defaults	0	0
> UUID=8FBE-2551	reserved2	vfat	defaults	0	0
> UUID=35FA-8BBB	loader2	vfat	defaults	0	0
> UUID=CFF3-5D80	atf	vfat	defaults	0	0
> UUID=832C-48C4	/boot	vfat	defaults	0	0

I'm surprised mount doesn't complain about those first 5 lines! Those are not
properly-formed fstab(5) entries.

I wouldn't call only applying your second patch a form of "hiding the
problem". Neither what we had before (a bunch of /dev/sda entries) and what
you're proposing (a bunch of malformed fstab(5) entries) should be considered
correct. If a user messes with BSP-level variables, then they should expect
what they get (?).

We can add the --use-uuid line to the /boot entry if you really think it
should be mounted on boot, but we shouldn't use it on the others and cause wic
to generate a bad fstab. There are examples of other boards that don't mount
/boot by default (raspi for sure, and I think bbb too).

I'll try to look deeper to figure out what's generating those /dev/sda
entries. Maybe there's a way to disable them without resorting to
WIC_CREATE_EXTRA_ARGS?

In the mean time I'd like to apply your patch 2/2, if you could please add
your SoB line?

> u-boot is able to find its partitons even if '--use-uuid' is set. As you mentioned u-boot doesn't
> know about uuid but it seems to be able to find its partitions nevertheless. But if '--use-uuid'
> is not set, wic writes /dev/sda* instead of the correct  UUID values to fstab. So its not u-boot that
> needs uuid to be set but fstab.
> Of course it would be nice, if wic didn't try to add the u-boot partitions to fstab at all.
> I guess nobody ever needs to have them mounted into userspace ( except possibly /boot).

Sorry, I wasn't clear. u-boot doesn't use those labels to find u-boot, my
guess is that the SoC's ROM firmware blindly looks at fixed offsets for the
"what to boot" (and therefore isn't using UUIDs either). Either the ROM loads
the atf, which then loads u-boot's spl, or the ROM loads the atf and then
loads u-boot's spl from fixed locations. Perhaps u-boot's spl uses labels to
find u-boot proper, but that's irrelevant.

> > Are you using poky or a distro other than "nodistro"? Perhaps other
> > layers/distros are affecting the build?
> 
> Thats not unlikely. I have a long layer-list in bblayers.conf to build my image:
> 
>   /home/flk/build/poky/meta \
>   /home/flk/build/poky/meta-poky \
>   /home/flk/build/poky/meta-yocto-bsp \
>   /home/flk/build/poky/meta-rockchip \
>   /home/flk/build/poky/meta-rockchip-extras \
>   /home/flk/build/poky/meta-wayland \
>   /home/flk/build/poky/meta-retro \
>   /home/flk/build/poky/meta-retro-wayland \
>   /home/flk/build/poky/meta-rauc \
>   /home/flk/build/poky/meta-openembedded/meta-oe \
>   /home/flk/build/poky/meta-openembedded/meta-multimedia \
>   /home/flk/build/poky/meta-openembedded/meta-networking \
>   /home/flk/build/poky/meta-openembedded/meta-xfce \
>   /home/flk/build/poky/meta-openembedded/meta-gnome \
>   /home/flk/build/poky/meta-openembedded/meta-python \
>   /home/flk/build/poky/meta-openembedded/meta-filesystems \
>   /home/flk/build/poky/meta-arm/meta-arm \
>   /home/flk/build/poky/meta-arm/meta-arm-toolchain \
>   /home/flk/build/poky/meta-kodi \
>   /home/flk/build/poky/meta-browser/meta-chromium \
>   /home/flk/build/poky/meta-browser/meta-firefox \
>   /home/flk/build/poky/meta-clang \

My guess is that Khem probably likes building with a long list of layers as
well ;-) I'll try using poky to see if that changes anything. Using oecore,
bitbake, meta-arm, and meta-rockchip I can't reproduce what you and Khem are
seeing. One of these days I'll have to check to make sure meta-rockchip is
behaving like it should when mixed with other layers.