On 08/03/2016 07:49 PM, Jianxun Zhang wrote: > >> On Aug 3, 2016, at 4:15 PM, Tom Zanussi <[email protected]> wrote: >> >> Hi Jianxun, >> >> On 08/03/2016 01:04 PM, Jianxun Zhang wrote: >>> Hi Saul, Tom & others, >>> >>> This is the V5 submission of RMC work with new enhancements and fixes over >>> V4 also with some minor adjustments in rmc README file and commit messages. >>> >> >> Although I'm a bit dismayed that we seem to have come full circle and >> are back at the EFI_PROVIDER="rmc-systemd-boot" interface, I went ahead >> and merged these 10 patches anyway- it doesn't seem we'll be able to >> make progress toward fleshing out this feature otherwise. > > I agree and also feel we are circling on this matter with what we can have > now. > > () multiple switches are logically predictable if no overriding is allowed. > We also need to clarify our thoughts on if we really want to have a single > feature switch in this case. > > () What we can do is to seek/improve another interface in OE, not to use > EFI_PROVIDER for non-bootloader RMC functions like db deployment stuff. > > >> >> Please file a bug addressing that interface issue, as well as for the >> other issues we identified along the way and that remain unaddressed. >> > > Yes, I will add this one into bz ticket list I am going to file, just waiting > their merge (I just don’t feel filing bugs for pending patches make much > sense technically.) >
All merged, so no need to wait now. Please add me to the cc: list for all the bugs you file related to this, thanks. > >> The most important ones in addition being: >> >> - rmc should be useful for all yocto-supported platforms, not just the >> ones in meta-intel. Because it only supports Intel platforms at the >> moment, and to give it some exposure, it makes sense to have it in >> meta-intel at least initially, but it really should be in oe-core. >> Adding support for other platforms should also help generalize the code >> in the process. So please file a bug to add support for the other >> platforms and move it out of meta-intel. >> > > I agree with you to push it to OE, just want to be more precisely for > supported scope even when it is in OE. RMC is based on EFI and SMBIOS so I > should say any platforms with these FW features should be supported naturally. > We have EFI features in OE already, so this won’t be a blocker. But for other > arch not with required FW, I am not sure how much RMC could help. > Well, the first step as implemented here requires those things. But surely the general idea of tailoring images based on fingerprints generalizes to other platforms. > Also sharing my understanding on generating code/file approach in OE, I think > when people don’t have an alternative solution to manage customizations, they > need the approach. But I hope we can rethink it when a runtime solution > is on horizon. > > I cannot see why providing variables, with logic behind them, to users could > be better or more flexible than having board-specific files, if the later way > can managed file copies outside of generic stack. > > I don’t mind you or anyone forward this newbie’s opinion to any OE people, > seriously. I do have concern on this OE philosophy. > > But I will file a ticket so that we can check in these thoughts and > requirements. > > >> - there currently is really no way to debug a failing rmc configuration >> or run-time other than by inspection. There needs to be support in both >> the host and the target to flag invalid configurations and trace what's >> happening at run-time when something goes wrong and it's not apparent >> what the problem is. >> > > RMC is designed as “don’t fail anything at runtime if we don’t fetch > board-data successfully”. And image with RMC shall be functional on > non-supported boards in general. > Sorry, failing silently even if that maps to something legal isn't useful. > These design goals could be a part of reasons attracting complains. > > I will file a ticket for this with others. Let me see what I can improve, no > worries. > Thanks, Tom > >> Thanks, >> >> Tom >> >>> I tried my best to keep doc, commit msg and function consistent when we >>> modify the feature's behavior back and forth. Feel free to let me know any- >>> thing out of sync... >>> >>> Jianxun Zhang (10): >>> rmc: Add Runtime Machine Configuration (RMC) project >>> gnu-efi: Add GUID for SMBIOS 3 entry point structure >>> systemd-boot: load board-specific entry and kernel cmdline >>> EFI installer: deploy board-specific data and kernel cmdline >>> rmc: add recipe and bbclass for RMC feature >>> rmc: document and examples for RMC feature >>> rmc: support broxton-m platform >>> rmc: support post-installation hook POSTINSTALL.sh >>> rmc: update document and NUC Gen 6 for post-installation hook >>> rmc: don't install boot entries when RMC entries exist >>> >>> classes/rmc-db.bbclass | 92 ++++++ >>> classes/rmc-systemd-boot.bbclass | 12 + >>> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ >>> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + >>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + >>> .../rmc/boards/T100-32bit/T100-32bit.fp | Bin 0 -> 116 bytes >>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + >>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + >>> common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM | 1 + >>> common/recipes-bsp/rmc/boards/broxton-m/bm.fp | Bin 0 -> 83 bytes >>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + >>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + >>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes >>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG | 1 + >>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + >>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes >>> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG | 2 + >>> .../rmc/boards/nucgen6/INSTALLER.CONFIG | 6 + >>> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + >>> .../recipes-bsp/rmc/boards/nucgen6/POSTINSTALL.sh | 7 + >>> common/recipes-bsp/rmc/boards/nucgen6/boot.conf | 4 + >>> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + >>> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + >>> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes >>> common/recipes-bsp/rmc/rmc-db.bb | 48 +++ >>> common/recipes-bsp/rmc/rmc.bb | 46 +++ >>> .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ >>> ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ >>> ...d-board-specific-boot-entries-from-RMC-da.patch | 263 +++++++++++++++ >>> ...pport-global-kernel-command-line-fragment.patch | 66 ++++ >>> .../initrdscripts/files/init-install-efi.sh | 339 >>> ++++++++++++++++++++ >>> .../initramfs-live-install-efi_%.bbappend | 1 + >>> conf/layer.conf | 10 + >>> documentation/rmc/README | 356 >>> +++++++++++++++++++++ >>> 34 files changed, 1370 insertions(+) >>> create mode 100644 classes/rmc-db.bbclass >>> create mode 100644 classes/rmc-systemd-boot.bbclass >>> create mode 100644 >>> common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch >>> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend >>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG >>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp >>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM >>> create mode 100755 common/recipes-bsp/rmc/boards/broxton-m/bm.fp >>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG >>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp >>> create mode 100644 >>> common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG >>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/POSTINSTALL.sh >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/install.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/mylib.conf >>> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp >>> create mode 100644 common/recipes-bsp/rmc/rmc-db.bb >>> create mode 100644 common/recipes-bsp/rmc/rmc.bb >>> create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot.bbappend >>> create mode 100644 >>> common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch >>> create mode 100644 >>> common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch >>> create mode 100644 >>> common/recipes-bsp/systemd-boot/systemd-boot/0003-sd-boot-Support-global-kernel-command-line-fragment.patch >>> create mode 100644 >>> common/recipes-core/initrdscripts/files/init-install-efi.sh >>> create mode 100644 >>> common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend >>> create mode 100644 documentation/rmc/README >>> >> > -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
