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

[Tom Zanussi]

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

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.

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