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

Thu Jul 14 10:06:58 PDT 2016

> On Jul 14, 2016, at 6:05 AM, Tom Zanussi <tom.zanussi at linux.intel.com> 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...
>> 
>> 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.
() This is first point - what shall be used as switch or attribute for _image_ feature in discussion.

I think this refactor work is worthy for a bugzilla ticket to track. I am not happy with current solution with EFI_PROVIDER either. We need some better solution/attribute to capture whole _image_ feature. Just put some detailed thoughts in the following paragraphs.
> 
> 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.
() Then there is 2nd point for this rmc _image_ feature - the desired behavior when it is enabled or not.

Disabling - this is the default option now. I don’t have a patch to enable rmc _image_ feature in machine conf this time. That means we shouldn’t see anything broken (build and runtime) once patches are merged, assuming they are correctly done. But this is achieved in an implicit way. Patches in systemd-boot and installer are still effective in build, but the output generic images shall work as before. Changes in bootloader and installer won’t complain or fail when board is not supported in DB, or DB or tool is not found, at run time.

Enabling - I use EFI_PROVIDER to kick off everything now. I agree with you to refactor it. We can’t control users specify another bootloarder. It is a nice idea to give user a warning when they enable  _image_ feature with a not supported bootloader. I need to check the parsing sequence of EFI_PROVIDER to make sure we can catch it at build time. Given what’s done for disabling mode, not breaking anything is supported. Actually, when you pull the patches and build it without EFI_PROVIDER=rmc-xxxxx, you are testing this case somehow. By default, grub-efi is used in intel-core* target, plus an installer patched for rmc _image_ feature. No failure  in build or runtime shall happen.

> If we can agree on that, then we can work on looking at the most
> appropriate build system interface to use.
The only thing I want to repeat is we still need to spilt rmc project and a feature based on rmc project. Here I use “image” feature for our discussion.
I think we agree with most of points here. I will file a bugzilla to cover the above. But if you find I bugged more in and need more clarifications. Feel free to let me know.

Sometimes “I think you know what I am talking about” doesn’t work… :-)

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