| Summary: | RMC: Clarify to use RMC_BOARD_DATA_DIRS to specify board data directories | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Jianxun Zhang <jianxun.zhang> | ||||||||
| Component: | bsps-meta-intel | Assignee: | Jianxun Zhang <jianxun.zhang> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | Medium | CC: | sgw | ||||||||
| Version: | 2.2 | ||||||||||
| Target Milestone: | 2.3 | ||||||||||
| Hardware: | x86 | ||||||||||
| OS: | Multiple | ||||||||||
| Whiteboard: | |||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |||||||||
| Attachments: |
|
||||||||||
I am not sure that what you propose would be correct, since you can't count on how a layer is organized, I think the DATA_DIRS belongs in the context of the recipe and next exposed at a higher level. Saul, I think the bottom line is to decouple RMC with bootloader stuff since this feature is more than playing with bootloaders. It shouldn't rely on bootloader as we have suggested. For the location variable, I am okay to follow any typical model in OE. If you have foresee moving it to conf is problematic, I am okay to keep it in recipe. But the using RMC_BOARD_DATA_DIRS should be the direction per my opinion. We actually already tell usr to append to this variable and verified this usage, but I haven't check if it can bypass rmc.db's generation. It could be helpful to list scenarios from an user perspective to clarify what I am pursuing. Putting one of these lines in a local.conf, then do an incremental build base on whatever from a previous successful build of the same image, () with RMC_BOARD_DATA_DIRS = "" (disable the default) No any rmc.db files should be built out or left in build dir and final hdd image () RMC_BOARD_DATA_DIRS_append = " /junky_boards/" rmc.db files packed with data from both default boards dir in meta-intel AND junky_boards dir shall be in the build and final hddimg. All rmc.db files should be identical. RMC_BOARD_DATA_DIRS = "/junky_boards/" (override the default) rmc.db files packed with data ONLY from junky_boards dir shall be in the build and final hddimg. All rmc.db files should be identical. # RMC_BOARD_DATA_DIRS = " " (white spaces only) same result as the case of RMC_BOARD_DATA_DIRS = "" I think these are intuitive behaviors users expect, I am working on a WIP patch to satisfy all of these. Created attachment 3585 [details]
WIP Patch: Support disabling db generation
Upload a WIP version which seems working most cases, but the cache/sstate in my build could have been messed up when swapping different feeds to the interface variable many times.
Need more test anyway.
Created attachment 3589 [details]
Submitted Patch to meta-intel
Uploaded the submitted patch to meta-intel
http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=368673eab1344fee79932e2dd96289fa6748d8be Patch has been merged in meta-intel master branch. I change the state accordingly. For verification: The master tip including this patch shall behave identically like before without using the new usages. By default the rmc.db should be in hddimg image. |
Created attachment 3570 [details] WIP Patch: Promote using RMC_BOARD_DATA_DIRS The variable RMC_BOARD_DATA_DIRS is designed to be the interface to upper layers to specify/append/override data directories for boards when generating rmc db. However, it is a little obscure in the implementation and we need to clarify its usage in documentation/rmc/README: () The line RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/boards/" hard-coded in rmc-db.bb seems better to be in conf/machine/include/meta-intel.inc. () The recent modified rmc README suggests users to switch to an EFI bootloaders when they want to bypass the default rmc.db. I think this should be amended to override RMC_BOARD_DATA_DIRS, although we do need EFI bootloader interface to deploy rmc.db at this stage, because: 1. It may not be acceptable in real use case to force an image to have a different bootloader setting just for this use case. 2. rmc is designed generic as much as possible. Ideally, Its usages should not depends on any bootlaoder which is 'client' of rmc. If user really needs to bypass the default board data, overriding the existing RMC_BOARD_DATA_DIRS should be more appropriate. I attached a WIP patch here to illustrate my thoughts and as a base for further work and tests.