| Summary: | RMC: Bring supported RMC functions to systemd-boot efi stub | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Mikko Ylinen <mikko.ylinen> | ||||||||
| Component: | bsps-meta-intel | Assignee: | Mikko Ylinen <mikko.ylinen> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | enhancement | ||||||||||
| Priority: | Medium+ | CC: | bluelightning, jianxun.zhang, randy.macleod, sgw | ||||||||
| Version: | 2.2 | ||||||||||
| Target Milestone: | 2.3 M3 | ||||||||||
| Hardware: | x86 | ||||||||||
| OS: | Multiple | ||||||||||
| Whiteboard: | |||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||||
| Attachments: |
|
||||||||||
|
Description
Mikko Ylinen
2017-01-13 08:52:52 UTC
Mikko, Thanks for bring this to us. we excluded RMC support in EFI stub when the use case was not clear. It should be very similar as what we did in main systemd-boot boot loader once stub can load RMC database into mem at runtime. There could be some dependency and things to be clarified: () I think we only support building a standalone main bootloader (systemd-boot.bbclass) in OE. You may already enable stub in a upper layer, but we need to have it in OE or meta-intel BSP first unless the solution happens at that higher layer. (To have another ticket?) () There could be more than one option for the location of RMC database when seeing the embedded image with stub. Keeping it on ESP (FAT partition) as what we did can keep design image-agnostic unless we face other requirements or preferences, say, the way you want to verify things in an image on boot. Just share these initial thoughts without much investigation. (In reply to comment #1) > Mikko, > Thanks for bring this to us. we excluded RMC support in EFI stub when the > use case was not clear. It should be very similar as what we did in main > systemd-boot boot loader once stub can load RMC database into mem at runtime. True. You'll find one concrete use-case in Ostro OS where the kernel, initrd, cmdline, and the stub is bundled in a single EFI executable. I'd need this setup to utilize RMC too. > > () I think we only support building a standalone main bootloader > (systemd-boot.bbclass) in OE. You may already enable stub in a upper layer, > but we need to have it in OE or meta-intel BSP first unless the solution > happens at that higher layer. (To have another ticket?) I'm working on making it possible to build the systemd-boot's EFI stub in OE-Core and submitting the "combo EFI app" functionality there too. Before that's in place, I'd be happy to test any patch that enables RMC in the stub. I will work on this with Mikko to bring RMC into systemd-boot stub. I think we could prototype it in EFI context first without a real embedded image in meta-intel. Mikko, Currently we patched systemd-boot to have these RMC functionalities in the main boot loader: () Loading board-specific conf files from RMC db at boot I don't see the support of conf files in EFI stub. I assume we won't have this feature in stub. () A global command line fragment (KBOOTPARAM) It is appended to the base cmdline before booting kernel at runtime. A base cmdline can be from a conf file generated by OE or a board-specific conf in RMC. If stub won't support conf file, a base version of cmdline working as default could be packed into embedded image by ostro This is for boards not checked in RMC database. Appending to the base cmdline, or overriding it, should be clarified. (more for use cases, less on coding) () EFI installer deploy conf files on ESP in installation. (actually, it also deploy any files to rootfs for user space) I am not sure if Ostro has an installer use case at this point. This is related but not _in_ EFI bootloader. Created attachment 3595 [details]
WIP Patch: [RMC]-support-global-kernel-cmdline-fragment.path
Mikko, I attached a WIP patch that fetches a board-specific command line fragment and appends it to the base command line. I tried it in EFI shell on my broxton-m board and I can see stub gets the fragment if I put a print message to show it. However, no more test has been done. You will need to add it in meta-intel or your systemd-boot layer to make it effective in a Yocto or Ostro build. Please also refer to my previous comment #3 for some clarifications. (In reply to comment #3) > > () A global command line fragment (KBOOTPARAM) For me to get started, KBOOTPARAM is enough. (In reply to comment #5) > I attached a WIP patch that fetches a board-specific command line fragment > and appends it to the base command line. Thanks! Saul & Mikko, Just for the tracking's sake, you may want to add "blocked by" in this task since the final result depends on enabling stub and embedded image build, although technically we could merge this without breaking anything first in meta-intel... Created attachment 3598 [details]
Updated 'Link RMC' patch
Created attachment 3599 [details]
WIP Patch v2: [RMC]-support-global-kernel-cmdline-fragment.patch
v2 of the "add RMC in stub" patch.
(In reply to comment #5) > I tried it in EFI shell on my broxton-m board and I can see stub gets the > fragment if I put a print message to show it. However, no more test has been > done. You will need to add it in meta-intel or your systemd-boot layer to > make it effective in a Yocto or Ostro build. v2 uploaded. I noticed the fragment was found OK but the system never booted with the new cmdline. That was because linux_exec() only copied the "old" part. Another observation: Joule 5700 maps to the broxton-m fingerprint (both get the same signature). I'm not sure that's expected. Fixed by my patch set merged in meta-intel http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=7fba4baa0ec6e5e02b1bd6da55dec2746a56b381 |