On 07/14/2016 01:34 AM, Jianxun Zhang wrote: > >> On Jul 13, 2016, at 3:43 PM, Tom Zanussi <[email protected]> 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 >> >> > -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
