> On Jul 12, 2016, at 5:21 PM, Saul Wold <[email protected]> wrote: > > On Tue, 2016-07-12 at 16:53 -0700, Jianxun Zhang wrote: >>> >>> On Jul 12, 2016, at 4:29 PM, Saul Wold <[email protected]> wrote: >>> >>> On Tue, 2016-07-12 at 10:59 -0700, Jianxun Zhang wrote: >>>> >>>> The new added recipe and bbclass put modified systemd-boot, >>>> EFI installer and rmc work together to enable a single >>>> generic image, built for multiple platforms, automatically >>>> applies customization specific to the type of a running board. >>>> >>>> In another word, you will see a single image behaves differently >>>> and intelligently according to the type of board it is running >>>> on. >>>> >>>> To Enable this feature: add this line in conf file: >>>> EFI_PROVIDER = "rmc-distro" >>>> >>> As mentioned before I strong discourage the use of distro here. >>> Saul, >> I don’t know much about naming rules in YP, but I am open for any >> suggestions. I will fix it in V2 with any name reviewer are okay >> with. >> > I think just rmc would be fine here, you can combine the 2 bbclasses Saul, The discussion around the last item in this mail explains why we should split rmc project and a RMC-based single image feature. If you agree with the last item, the “rmc” terminology could be best for bare rmc project. I have a proposal at the last item, let me know if it’s okay.
>> >>> >>>> >>>> For a supported board, this feature can : >>>> () show and boot with board-specific boot entries in boot menu >>>> in live-boot and post-installation. >>>> >>>> () apply a kernel cmdline fragment to the end of cmdline to boot >>>> Linux kernel. This is effective for any boot entry user chooses >>>> in >>>> boto menu. >>>> >>>> () create directory and deploy files only for the type of the >>>> running board to target's file systems. What left on target after >>>> installation is just same as the result from installing a >>>> conventional >>>> image customized for a single type of hardware. >>>> >>>> To add support of new boards, a new variable >>>> RMC_DISTRO_BOARD_DIRS >>>> is the interface to developers. How-to information will be >>>> provided >>>> with examples in following patches. >>>> >>>> Signed-off-by: Jianxun Zhang <[email protected]> >>>> --- >>>> classes/rmc-distro.bbclass | 49 >>>> ++++++++++++++++++++++++++++++++++++ >>>> common/recipes-bsp/rmc/rmc-distro.bb | 28 +++++++++++++++++++++ >>>> 2 files changed, 77 insertions(+) >>>> create mode 100644 classes/rmc-distro.bbclass >>>> create mode 100644 common/recipes-bsp/rmc/rmc-distro.bb >>>> >>>> diff --git a/classes/rmc-distro.bbclass b/classes/rmc- >>>> distro.bbclass >>>> new file mode 100644 >>>> index 0000000..a7fd226 >>>> --- /dev/null >>>> +++ b/classes/rmc-distro.bbclass >>>> @@ -0,0 +1,49 @@ >>>> +# RMC Distro class >>>> +# EFI population is provided by EFI bootloader bbclasses and >>>> called >>>> by >>>> +# image-live.bbclass. We haven't found another way to install a >>>> file >>>> +# from a non-bootloader project into EFI partition without an >>>> extra >>>> +# change in OE to do so. These functions are not exposed and >>>> EFI_PROVIDER >>>> +# seems the only chance we can ask image-live.bbclass to call a >>>> procedure >>>> +# we defined. >>>> +# >>>> +# Ideally, we should have a way to call the >>>> ${EFI_CLASS}:efi_populate, and >>>> +# append or prepend installing rmc database file logic to the >>>> base. >>>> +# >>>> +# This class works as a workaround when we don't want to cause a >>>> change in >>>> +# OE. We simply copy efi_populate() from systemd-boot and append >>>> rmc >>>> +# distro installation in this function. >>>> +# >>>> +# The class is also intended to be the switch of rmc distro. Set >>>> +# EFI_PROVIDER = "rmc-distro" in a conf file to enable it. >>>> + >>>> +IMAGE_INSTALL_append = " rmc" >>>> + >>>> +inherit systemd-boot >>>> + >>>> +do_bootimg[depends] += "${MLPREFIX}rmc-distro:do_deploy" >>>> + >>>> +efi_populate() { >>>> + # original systemd-boot section >>>> + DEST=$1 >>>> + >>>> + EFI_IMAGE="systemd-bootia32.efi" >>>> + DEST_EFI_IMAGE="bootia32.efi" >>>> + if [ "${TARGET_ARCH}" = "x86_64" ]; then >>>> + EFI_IMAGE="systemd-bootx64.efi" >>>> + DEST_EFI_IMAGE="bootx64.efi" >>>> + fi >>>> + >>>> + install -d ${DEST}${EFIDIR} >>>> + # systemd-boot requires these paths for configuration >>>> files >>>> + # they are not customizable so no point in new vars >>>> + install -d ${DEST}/loader >>>> + install -d ${DEST}/loader/entries >>>> + install -m 0644 ${DEPLOY_DIR_IMAGE}/${EFI_IMAGE} >>>> ${DEST}${EFIDIR}/${DEST_EFI_IMAGE} >>>> + install -m 0644 ${SYSTEMD_BOOT_CFG} >>>> ${DEST}/loader/loader.conf >>>> + for i in ${SYSTEMD_BOOT_ENTRIES}; do >>>> + install -m 0644 ${i} ${DEST}/loader/entries >>>> + done >>>> + >>> If this is all the same as the original systemd-boot efi_populate, >>> you >>> can just add the below via a efi_populate_append() function >>> >> I think the bbclass must explicitly export the function to do that, >> but that requires a change in OE that >> I want to avoid this time. >> >> I checked "3.4.5. Flexible Inheritance for Class Functions” in BB >> user manual and that’s why patch is done this way. >> > Hmm, I just tested adding _append and it worked as I expected (got two > copies of efi_populate in the script. Saul, Thanks to try it out. Did I misunderstand 3.4.5 in BB doc? hmm, I will change it in V2 if it works. > >> >>> >>> Why can't this be part of the rmc.bbclass? >>> >>>> >>>> + # append logic to add rmc database file into EFI >>>> partition. >>>> + install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db >>>> ${DEST}/rmc.db >>>> +} >>>> diff --git a/common/recipes-bsp/rmc/rmc-distro.bb >>>> b/common/recipes- >>>> bsp/rmc/rmc-distro.bb >>>> new file mode 100644 >>>> index 0000000..2fbe5bb >>>> --- /dev/null >>>> +++ b/common/recipes-bsp/rmc/rmc-distro.bb >>>> @@ -0,0 +1,28 @@ >>>> +SUMMARY = "RMC distro image" >>>> +DESCRIPTION = "Generate a centralized RMC database for RMC >>>> distro >>>> image. \ >>>> +The fingerprints and data for all boards supported in distro >>>> image >>>> are \ >>>> +specified by variable RMC_DISTRO_BOARD_DIRS which is a list of >>>> top \ >>>> +directories that contains subdirectories for boards. Developers >>>> can >>>> add \ >>>> +their top directories by appending them to this variable in a >>>> bbappend \ >>>> +file of this recipe. Refer to rmc-native bbclass for details." >>>> + >>>> +LICENSE = "MIT" >>>> + >>>> +inherit rmc-native >>>> + >>>> +RMC_DISTRO_BOARD_DIRS ?= "" >>> How about just RMC_BOARD_DATA_DIRS? >> Sure. I know you don’t like “distro” here. No worries, all of this >> will be fixed in V2. >>> >>> >>>> >>>> +RMC_DB_DIR = "${WORKDIR}/db" >>>> + >>>> +do_generate_rmc_db () { >>>> + rmc_generate_db "${RMC_DISTRO_BOARD_DIRS}" >>>> "${RMC_DB_DIR}"/rmc.db >>>> +} >>>> + >>>> +addtask generate_rmc_db after do_compile >>>> + >>>> +inherit deploy >>>> + >>>> +do_deploy () { >>>> + install -m 0400 ${RMC_DB_DIR}/rmc.db ${DEPLOYDIR} || >>>> true >>>> +} >>>> + >>>> +addtask deploy after do_generate_rmc_db >>> Why create a new recipe, can't this be part of the main rmc recipe? >> The main recipe, assuming you mean rmc.bb, is for bare rmc project. >> "rmc-distro” (sorry) is built based on rmc project. In this way, >> these functions can work independently for reuse. >> >> () you can build rmc tool and libraries just like other projects >> pulled in YP for target for target (and also host) >> () You can use rmc-native class to build your RMC database in your >> project’s local dir and decide how it is deployed into image. >> This is done with rmc-native. What in rmc-distro.bb is just the first >> _instance_ to use this service. >> > maybe rmc-db.bb then since it's provide the db file? Saul, I think it is a good idea because what it does is generate a centralized ‘db’ inside rmc project build path. I propose these to address all feedbacks on naming in V2: () rmc.bb -> rmc.bb (no change, it is for bare rmc project) () rmc-distro.bb -> rmc-db.bb (as you suggested) () rmc-native.bb -> (merged into rmc.bb, I will try it) () rmc-native.bbclass -> rmc-db.bbclass (it uses native tool to make db) () rmc-distro.bbclass-> rmc-boot.bbclass. user sets EFI_PROVIDER=rmc-boot to enable rmc image feature. This is the only odd ball in my proposal, but it may not be totally absurd. It inherits systemd-boot anyway. Later we could use MACHINE_FEATURE or DISTRO_FEATURE to enable “rmc-image” feature to replace an EFI bootloader-like name to enable the whole thing. Assume the word “image” is okay here. :-) > >> Actually, as I said in cover, splitting bare rmc project and “rmc- >> distro” is a big change since the old work people pulled. >> > I did not realize it was going to be this. >> Thanks >> >> >>> >>> >>> Sau! >>>> -- _______________________________________________ meta-intel mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-intel
