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

[Tom Zanussi]

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

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