[meta-intel] [PATCH 5/6] rmc: add recipe and bbclass for feature "rmc distro"

Saul Wold saul.wold at intel.com
Tue Jul 12 17:21:58 PDT 2016


On Tue, 2016-07-12 at 16:53 -0700, Jianxun Zhang wrote:
> > 
> > On Jul 12, 2016, at 4:29 PM, Saul Wold <saul.wold at 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.zhang at 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!
> > > 


More information about the meta-intel mailing list