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 -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
