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

[Jianxun Zhang]

> On Jul 14, 2016, at 10:07 AM, Saul Wold <saul.wold at intel.com> wrote:
> 
> 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.
Nice, Saul! I will update it in V2.

> 
>>> 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