Re: GRUB issue on device priority

[Leif Lindholm <leif.lindholm@linaro.org>]

Apologies for delay in responding.

On Thu, Nov 09, 2017 at 04:41:55PM +0800, Haojian Zhuang wrote:
> > > In the HiKey platform, I prepared the same driver for both eMMC and
> > > SD. So the device paths are in below.
> > > SD: /HardwareVendor(0d51905b-b77e-452a-a2c0-eca0cc8d514a)[9: 00 e0 23 f7 00 00 00 00 00 ]/UnknownMessaging(1a)/EndEntire
> > > eMMC: /HardwareVendor(0d51905b-b77e-452a-a2c0-eca0cc8d514a)[9: 00 d0 23 f7 00 00 00 00 00]/UnknownMessaging(1d)/Ctrl(0)/EndEntire
> > > 
> > > #define MSG_SD_DP                   0x1A
> > > #define MSG_EMMC_DP                 0x1D
> > > 
> > > In the second level, the device paths are different.
> > > 
> > > And GRUB resort the sequence by ascending order (with above
> > > code). So SD device always gets higher priority than eMMC device.
> > > 
> > > If we always use installer to install OS, it may not an issue. Since
> > > installer could create grub.cfg by itself. But it imports another
> > > issue on lacking of persistent variable storage. And we need to
> > > deploy system without installer on embedded device.
> > 
> > Yes, this is the bit which is interesting, and why I requested you
> > post this problem to edk2-devel.
> > 
> > I believe that we need to have a sensible way to deal with embedded
> > platforms that do not have operating systems "installed" to them, but
> > rather written as images to flash devices.
> > 
> > So, can you clarify a few things for me?:
> > - Where is GRUB located in your (pre-SD) system?
> 
> In eMMC.
>
> > - Where is GRUB located in your SD system?
>
> In SD.
>
> > - Are you looking for a way to support GRUB being located on either
> >    eMMC or SD? Or are you looking to always have GRUB loaded from eMMC?
> 
> GRUB could be located in either in eMMC or SD.

OK, so which one should be loaded in preference if both exist?

I.e., what if you write a GRUB to eMMC via USB uplink, and at some
later point you insert an uSD card?

One (hackish, but at least predictable) way of resolving this would be
to implement a PlatformBootManagerLib that never connects more than
one of those devices. Alternatively one that always disconnects the
one not used for booting.

(Yes, I always argue that we should try to use a single library across
most/all ARM platforms, but in order to figure out the useful
abstractions that would make this possible, it would be worth to have
some different versions implementing different features.)

/
    Leif