On 08/04/2016 08:42 PM, Jianxun Zhang wrote: > >> On Aug 4, 2016, at 3:55 PM, Tom Zanussi <[email protected]> wrote: >> >> On 08/04/2016 05:41 PM, Jianxun Zhang wrote: >>> >>>> On Aug 4, 2016, at 2:26 PM, Tom Zanussi <[email protected]> >>>> wrote: >>>> >>>> On 08/04/2016 04:11 PM, Jianxun Zhang wrote: >>>>> >>>>>> On Aug 4, 2016, at 7:31 AM, Tom Zanussi <[email protected]> >>>>>> wrote: >>>>>> >>>>>> 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. >>>>> >>>>> Tom, >>>>> This is the list of tickets I filed today. The first section is what I >>>>> collected during submission. The later part is for other improvement in >>>>> RMC and test case. >>>>> I should have added you in CC list of each of them. But if I missed any, >>>>> feel free to add yourself. Please also add comments for anything >>>>> inaccurately reflects our discussion. >>>>> >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10081 >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10083 >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10084 >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10085 >>>>> >>>> >>>> Looks ok, but I think there are a couple things missing, mainly the >>>> interface issue we keep going around in circles on, and there's >>>> something about detecting errors at build-time, but nothing about runtime. >>>> >>> I think interface issue is captured in 10084. It decouples RMC with >>> EFI_PROVIDER. But please feel free to file another bug if I get lost in >>> circling. >>> >>> The installer show deployment information in console. I don’t think >>> bootloader should fail or toss warning message when there is no data or db >>> for a board. Or are you suggesting anything else? Please feel free to >>> assign me a ticket as a following up. >>> >> >> You modify the bootloader to call libraries to gather data from the >> board and query the rmc db. The libraries and the database itself can >> be buggy or corrupt, and cause unintended failures. How does the user >> differentiate a failure from these causes vs an expected lack of >> configuration? > > We start troubleshoot SW problems when we start to believe we did right but > cannot get expected result. RMC is just another piece of software, so no > difference here. If user believes everything is correct but SW doesn’t work > as expected/documented, it is time to debug. > > You just remind me that Cal once asked me to add some dumpers to convert > binaries (fingerprint and db) back to human-readable blobs for > troubleshooting. I created another ticket for this request. > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10092 >
Yes, that would definitely help a lot. > But I don’t think these efforts will be capable of differentiating all > unexpected results from wrong input and SW bug. > It would probably be enough to have a settable mode that would be verbose about what it was doing. Combined with the dumper, I think that would be enough so that most of the time you could figure out what's going on without resorting to a debugger or adding printfs to the code.. Tom >> Tom >> >>>> There are also minor things that were touched on, such as the complete >>>> copy of the installer from oe-core, and forcing the user to specify each >>>> part of the path individually to create a file in the installer, etc. >>>> >>> 10085 implicitly covers installer's copy topic. There will be no copy or >>> patch of installer in meta-intel once RMC is in OE. >>> >>> I have explained why developers have to specify path for each file and >>> shall not delegate this work to RMC (Thread "Re: [meta-intel] [PATCHv3 6/6] >>> rmc: document and examples for RMC feature”) >>> >>> I think you didn’t bother this before just because you don’t care it and >>> assume “default” attribute of what copied to a target’s partition are >>> always “right”. With the existing OE installer, how does user specify >>> a FS attribute not default during installation, specifically when rootfs is >>> read-only? This should be a generic topic, not RMC-specific. >>> >>> >>> >>>> Tom >>>> >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10086 >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10087 >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10088 >>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10089 >>>>> >>>>> I appreciate your effort on RMC review and merge, and specially enjoy our >>>>> good discussion in these threads. >>>>> >>>>> >>>>>> >>>>>>> >>>>>>>> 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
