> On Jul 14, 2016, at 10:07 AM, Saul Wold <[email protected]> wrote: > > On Thu, 2016-07-14 at 08:05 -0500, Tom Zanussi wrote: >> On 07/14/2016 01:34 AM, Jianxun Zhang wrote: >>> >>> >>>> >>>> On Jul 13, 2016, at 3:43 PM, Tom Zanussi <[email protected] >>>> .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... >>> > A better clearer name here would be rmc-systemd-boot.bbclass that way > when we get grub-efi working with an rmc-grub-efi.bbclass or switch to > the IMAGE_FEATURES. Nice, Saul! I will update it in V2.
> >>> 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. >> > I am probably the closed expert right now, and yes, ultimately having > this as an IMAGE_FEATURE would be great, but we are not there yet. > > I also verified how bbclass overriding/extending works. > >> 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. >> > I think the best interface currently available is via the EFI_PROVIDER, > this given the timeline and target audience. > > If we try to turn this on it's head and create the IMAGE_FEATURE now, I > think we will miss the mark, but I can try and help with this if we > believe it's important to change direction. > > I have time now that CCB and Bug stuff has calmed down > > Sau! > >> 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
