| Summary: | [RMC]: Handle machine specific kernel command line differences | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Saul Wold <sgw> |
| Component: | bsps-runtime | Assignee: | Jianxun Zhang <jianxun.zhang> |
| Status: | VERIFIED DUPLICATE | QA Contact: | Jose Perez C <jose.perez.carranza> |
| Severity: | enhancement | ||
| Priority: | High | CC: | alexandru.c.georgescu, california.l.sullivan, cristina-danielax.agurida, dvhart, jose.perez.carranza, yp.kernel.watcher, yp.watcher |
| Version: | unspecified | ||
| Target Milestone: | 2.2 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | On Track to meta-intel | ||
| OS type for building Yocto: | --- | Type of Regression: | New (Never tested) |
| Verified: | Documentation change: | Don't know | |
| Bug Depends on: | |||
| Bug Blocks: | 6362 | ||
|
Description
Saul Wold
2015-12-04 00:57:17 UTC
Saul, We have had some initial talks for a run-time configuration feature where this task should play an important role or be investigated. I would like to do (or re-do if someone already worked it in Yocto) some initial research at feature scope first so that I can align this task within the epic. I will draft some initial memos to fuel our discussion and will update this task accordingly. So, stay tuned. Saul, With some investigation (and guessing), I am working on a draft of proposal with more details of design. This is a mid-way summary on progress and we decided to _hold_ development until we have a clear decision for design direction. The current design is based on a new RMC project (RMC library, SMBIOS parser and RMC tool), a modified UEFI boot loader and a modified installer. The use case is a typical scenario in OE and meta-intel that a boot-loader provides boot options of live-boot and installation. RMC will pick up kernel command line and any file blobs (a functionality beyond this bz8761) associated to board based on probing hardware info from BIOS. These board-specific bits will be deployed to target during installation. But RMC artifacts (binaries, libraries, database) will not be deployed onto target. What left on a provisioned device should be exactly same as the result from a conventional board-specific image. By doing so we avoid any impacts on perf and storage footprint on target. The biggest part, new RMC project, has been implemented with about 1k effective lines in C language that way current design defines. It is hosted on internal git repository for review. The rmc tool now support to get board-specific kernel command line fragment and file blob by name at run-time. So the next step should be make change in a preferred bootloader (gummiboot or newer systemd-boot) to call RMC libraries so it can patch kernel command line before booting kernel, and then we can move forward to installer. However, in the last discussion, our tech lead thinks we need to accommodate our design for a non-bootloader software stack for our internal customer, to have a faster booting procedure. And an image could be flashed in device directly without a boot option. I investigated the feasibility to have a RMC on this non-bootloader schema. Most necessary parts will have to be implemented in kernel since there is no bootloader. And it won't be easy to expose RMC information to user space for further runtime configuration in user space beyond kernel command line. Kernel does have some facilities to parse some SMBIOS fields, but we will need another small change for RMC. In case the work cannot be unstreamed, we will face a big kernel patch carried in a bsp layer all the time. I myself still think we should lay our design on existing boot chain because most of our targets are actually in this category. We always have an EFI boot loader (grub or gummiboot) in OE and meta-intel (People can correct me at this point). I have summarized investigation in high-level design doc for review. It is a question mark for me if we really want to have a special non-bootloader boot chain config in a generic bsp first. If we haven’t had one, probably we should enable and validate a non-bootloader config in BSP first before developing RMC based on it. A boot-chain change could affect other features too. I suggest: First we should ask these internal customers if they really need RMC in their non-bootloader distro image. At least from daily talks in BSP team, we need some way to support run-time kernel command line configuration to make our lives easier. If those customers don't really care it, we can just move forward with existing design. Of course we should make RMC free-impact at their sides - disabling RMC should be very easily. If customers show a lot interest on RMC, we will need to do more scoping and make decisions. The base of design will be changed dramatically with different assumptions. In our last discussion with Saul. We agreed to have existing design as a short-term solution so I will resume the development. But we want RMC bootloader based on new systemd-boot so I need to enable it in OE or meta-intel first. https://bugzilla.yoctoproject.org/show_bug.cgi?id=9419 https://bugzilla.yoctoproject.org/show_bug.cgi?id=6362 was the epic ticket to track RMC requirements including kernel command line this 8761 covers. I think it not necessary now to have this sub-feature ticket for the cmdline. Duplicate it to 6362. *** This bug has been marked as a duplicate of bug 6362 *** Duplicated bug |