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