[meta-intel] [PATCH 6/6] rmc: document and examples for rmc distro feature

[Saul Wold]

On Thu, 2016-07-14 at 08:05 -0500, Tom Zanussi wrote:
> On 07/14/2016 01:34 AM, Jianxun Zhang wrote:
> > 
> > 
> > > 
> > > On Jul 13, 2016, at 3:43 PM, Tom Zanussi <tom.zanussi at linux.intel
> > > .com> wrote:
> > > 
> > > On 07/13/2016 04:21 PM, Jianxun Zhang wrote:
> > > > 
> > > > 
> > > [...]
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > +
> > > > > > +
> > > > > > +Enable
> > > > > > +--------------------------------------------------------
> > > > > > ------------------------
> > > > > > +To Enable RMC distro feature in build, add the below line
> > > > > > in a conf file:
> > > > > > +EFI_PROVIDER="rmc-distro"
> > > > > > +
> > > > > Is rmc-distro actually meant to be an EFI provider?  I know
> > > > > you only
> > > > > support systemd-boot for now, but assuming there was also
> > > > > support in
> > > > > grub-efi for rmc, how would the user specify that?
> > > > Tom,
> > > > BTW, I proposed to change it to “rmc-boot” in another reply to
> > > > Saul. I think we should have a better switch later. Technically
> > > > developer can modify any software to use RMC project, so yours
> > > > is a valid point. But for this “rmc image” feature, locking
> > > > down to a bootloader greatly simplifies the maintenance. I
> > > > actually did a shopping among existing EFI bootloaders in YP
> > > > and go with systemd-boot...
> > > > 
> > > Well, you're calling it an image feature, and it does seem like
> > > it's a
> > > feature you're adding to an image, but EFI_PROVIDER="rmc-boot"
> > > doesn't
> > > capture that.  I'm not saying this is the way to do it - I hope
> > > some
> > > build system expert could suggest an appropriate way to do this,
> > > but I'd
> > > expect that if I wanted to add support for RMC to an image, I'd
> > > do
> > > something more like:
> > > 
> > > IMAGE_FEATURES += "rmc"
> > > 
> > > EFI_PROVIDER="systemd-boot" or EFI_PROVIDER="grub-efi"
> > > 
> > > That also simplifies the naming…
> > Tom,
> > () As what I proposed, “rmc” is for rmc project. We should split
> > the new project with this image feature. The later one modified
> > bootloader and installer to call rmc project  to have an end-to-end 
> > solution. It is the first (combo) user case of RMC. rmc project’s
> > recipe and bbclass is intended to be reused by other software in
> > the future.
> > 
> > () If user specify another bootloader “grub-efi” but don’t have RMC
> > change in it, this setup actually breaks image feature. RMC DB is
> > installed via an EFI bootloader bbclass. This is the only interface
> > I found to deploy a file to ESP without changing OE - inherit from
> > systemd-boot bbclass or override it.
> > 
> > () BTW, I think inherit from systemd-boot is better than reuse
> > “EFI_PROVIDER=systemd-boot” since people may want to have systemd-
> > boot without rmc image feature. That means we will have a rmc-
> > boot.bbclass inheriting systemd-boot...
> > 
A better clearer name here would be rmc-systemd-boot.bbclass that way
when we get grub-efi working with an rmc-grub-efi.bbclass or switch to
the IMAGE_FEATURES.

> > I know EFI_PROVIDER=rmc-boot is strange as a switch of whole image
> > feature. Do we have some ways to use IMAGE_FEATURE and still
> > enforce only using bootloader we suppport?
> > 
> > Not an expert at these points. I will work on other feedbacks first
> > and  let’s go back to this based on new series.
> > 
> Right, I'm not an expert either on these points of wrt build system
> implementation - let's just agree at a high level first.
> 
I am probably the closed expert right now, and yes, ultimately having
this as an IMAGE_FEATURE would be great, but we are not there yet.

I also verified how bbclass overriding/extending works.

> To me, it behaves like an attribute which when set modifies something
> to
> give it that attribute if it applies, but doesn't break it if it
> doesn't
> apply.
> 
> So the user should be able to specify the bootloader of choice like
> as
> they do now, and if the 'rmc' attribute is set, it's built with rmc
> support, and if not, it isn't.  And if the user sets the 'rmc'
> attribute
> for a bootloader that can't support rmc, it's just ignored (and
> warned
> about) but doesn't break anything.
> 
> If we can agree on that, then we can work on looking at the most
> appropriate build system interface to use.
> 
I think the best interface currently available is via the EFI_PROVIDER,
this given the timeline and target audience.

If we try to turn this on it's head and create the IMAGE_FEATURE now, I
think we will miss the mark, but I can try and help with this if we
believe it's important to change direction.

I have time now that CCB and Bug stuff has calmed down

Sau!

> As for the name, it doesn't matter what the rmc project is called -
> the
> attribute name used by the build system can refer to it any way it
> wants.  Actually, it would be good to give it a more descriptive name
> than an acronym like 'rmc', but I can't think of anything at the
> moment...
> 
> Tom
> 
> 
> 
> > 
> > > 
> > > 
> > > Also, although you may have shopped around for the best EFI
> > > bootloader,
> > > it may not be the best one tomorrow or for someone else.
> > > 
> > > So I think we need to get this right for supporting multiple
> > > EFI_PROVIDERS.  This is an externally visible interface and if we
> > > go
> > > with a hack to start with, we'll break anyone using it in the
> > > future
> > > when we have to change it - better to start with something
> > > extensible..
> > > 
> > > 
> > > > 
> > > > Copy my proposal here:
> > > > Saul,
> > > > I think it is a good idea because what it does is generate a
> > > > centralized ‘db’ inside rmc project build path.
> > > > I propose these to address all feedbacks on naming in V2:
> > > > () rmc.bb -> rmc.bb (no change, it is for bare rmc project)
> > > > () rmc-distro.bb -> rmc-db.bb (as you suggested)
> > > > () rmc-native.bb -> (merged into rmc.bb, I will try it)
> > > > () rmc-native.bbclass -> rmc-db.bbclass (it uses native tool to
> > > > make db)
> > > > () rmc-distro.bbclass-> rmc-boot.bbclass.
> > > > user sets EFI_PROVIDER=rmc-boot to enable rmc image feature.
> > > > This is the only odd ball in my proposal, but it may not be
> > > > totally absurd. It inherits systemd-boot anyway. Later we could
> > > > use MACHINE_FEATURE or DISTRO_FEATURE to enable “rmc-image”
> > > > feature to replace an EFI bootloader-like name to enable the
> > > > whole thing. Assume the word “image” is okay here. :-)
> > > > 
> > > > 
> > > > > 
> > > > > 
> > > [...]
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > +
> > > > > > +If no any board-specific configuration becomes effective
> > > > > > on your board but it
> > > > > > +works on other boards of same product, you can run rmc
> > > > > > tool to obtain
> > > > > > +fingerprint file on your board and compare it with
> > > > > > fingerprint of a working
> > > > > > +board. It is possible they have different firmware
> > > > > > versions and unluckily, some
> > > > > > +information for fingerprint changes between two versions.
> > > > > > You can update BIOS
> > > > > > +on every board to the same BIOS version if it is feasible.
> > > > > > Otherwise you have
> > > > > > +to treat them as two different type of boards. We could
> > > > > > extend rmc design to
> > > > > > +allow multiple fingerprints in a board directory as a
> > > > > > workaround.
> > > > > > +
> > > > > Would it be possible to do some kind of fingerprint
> > > > > wildcarding in
> > > > > addition/instead?
> > > > This case shouldn’t happen quite often for launched products
> > > > because board in product won’t be changed on user’s hands. I
> > > > think wild card approach could cause ambiguity hard to debug
> > > > when RMC load data wrongly for a board type.
> > > > 
> > > > My plan is to support multiple fingerprints for a single type
> > > > of board later.
> > > > 
> > > > Sometimes FW engineers do things out of our control and
> > > > expectation.
> > > > > 
> > > > > 
> > > OK, but it seems strange to have two identical boards that have
> > > nothing
> > > but trivial firmware differences treated as separate types by the
> > > system.
> > > 
> > > Tom
> > > 
> > >