On Tue, 2016-07-12 at 16:53 -0700, Jianxun Zhang wrote: > > > > On Jul 12, 2016, at 4:29 PM, Saul Wold <saul.w...@intel.com> 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
> > > > > > > > > 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 <jianxun.zh...@linux.intel.com> > > > --- > > > 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. > > > > > 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? > 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 meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel