Re: [meta-intel] Mohonpeak64 DPDK Build Failure
Hi Rahul,
Will you be able to get me the patch?
Thanks
From: Ashish Dalela (adalela)
Sent: Monday, July 18, 2016 6:01 PM
To: 'Gupta, Rahul KumarXX' ;
meta-intel@yoctoproject.org
Cc: Tan, Raymond ; Pradeep Munakala (pmunakal)
Subject: RE: Mohonpeak64 DPDK Build Failure
Thanks Rahul.
I had indeed updated the do_configure_preprend() as follows:
do_configure_prepend () {
sed -e
"s#CONFIG_RTE_LIBRTE_POWER=y#CONFIG_RTE_LIBRTE_POWER=${CONFIG_EXAMPLE_VM_POWER_MANAGER}#"
-i ${S}/config/common_linuxapp
echo "CONFIG_RTE_BUILD_SHARED_LIB=y" >> ${S}/config/common_linuxapp
}
I had forgotten I made this change, but I was able to get a successful static
build after removing the shared lib change. I, however, want to build shared
libs.
I made the change you suggested to dpdk-16.04/mk/rte.lib.mk and I see the error
in the install stage:
install: cannot stat
'/home/adalela/poky15/build/tmp/work/mohonpeak64-poky-linux/dpdk/16.04-r0/dpdk-16.04/x86_64-ivshmem-linuxapp-gcc/lib/*.a':
No such file or directory
I will wait for your patch. Thanks for the help.
Ashish
From: Gupta, Rahul KumarXX [mailto:rahul.kumarxx.gu...@intel.com]
Sent: Monday, July 18, 2016 3:33 PM
To: Ashish Dalela (adalela) mailto:adal...@cisco.com>>;
meta-intel@yoctoproject.org
Cc: Tan, Raymond mailto:raymond@intel.com>>
Subject: RE: Mohonpeak64 DPDK Build Failure
Then when I build dpdk, I get the following error in compile:
x86_64-poky-linux-gcc -m64
-Wl,--version-script=/home/adalela/poky15/build/tmp/work/mohonpeak64-poky-linux/dpdk/16.04-r0/dpdk-16.04/lib/librte_eal/linuxapp/eal/rte_eal_version.map
-L/home/adalela/poky15/build/tmp/sysroots/mohonpeak64/usr/lib -shared eal.o
eal_hugepage_info.o eal_memory.o eal_thread.o eal_log.o eal_pci.o eal_pci_uio.o
eal_pci_vfio.o eal_pci_vfio_mp_sync.o eal_debug.o eal_lcore.o eal_timer.o
eal_interrupts.o eal_alarm.o eal_ivshmem.o eal_common_lcore.o
eal_common_timer.o eal_common_memzone.o eal_common_log.o eal_common_launch.o
eal_common_pci.o eal_common_pci_uio.o eal_common_memory.o eal_common_tailqs.o
eal_common_errno.o eal_common_cpuflags.o eal_common_string_fns.o
eal_common_hexdump.o eal_common_devargs.o eal_common_dev.o eal_common_options.o
eal_common_thread.o eal_common_proc.o rte_malloc.o malloc_elem.o malloc_heap.o
rte_keepalive.o rte_cpuflags.o -ldl -lpthread -lgcc_s -lrt
-Wl,-soname,librte_eal.so.2.1 -o librte_eal.so.2.1
/home/adalela/poky15/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/ld:
cannot find crti.o: No such file or directory
/home/adalela/poky15/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/ld:
cannot find crtbeginS.o: No such file or directory
/home/adalela/poky15/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/ld:
cannot find /lib/libpthread.so.0
/home/adalela/poky15/build/tmp/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/5.3.0/ld:
cannot find /usr/lib/libpthread_nonshared.a
collect2: error: ld returned 1 exit status
make[6]: *** [librte_eal.so.2.1] Error 1
make[5]: *** [eal] Error 2
make[5]: *** Waiting for unfinished jobs
It looks that you are building the shared library for lib_rte_eal. It is built
static by default. I can reproduce this problem when building shared
librte_eal.so and will send a patch to fix it soon.
Can you try changing CONFIG_RTE_BUILD_SHARED_LIB to "n" in the dpdk config?
This will ensure that the libs are built statically.
If you want to build shared libs, you may have to pass EXTRA_CFLAGS in rte
Makefile like such:
# Override the definition of LD here, since we're linking with CC
-LD := $(CC) $(CPU_CFLAGS) $(EXTRA_CFLAGS)
+LD := $(CC) $(CPU_CFLAGS)
Thanks,
Rahul Kumar Gupta
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCHv3 1/6] rmc: Add Runtime Machine Configuration (RMC) project
RMC recipe fetch RMC project and build it more than once in
build time:
RMC tool is built for host architecture (native). The tool for
host is used to generate RMC database in build time.
RMC tool is also built for target architecture, so that scripts
in user space can call RMC tool on a running target. Developers
can also boot a target and run rmc tool to obtain fingerprint
for a new board type.
RMC libraries are compiled for both of UEFI context and user
space. They are always linked in RMC tool and can be linked
into an EFI bootloader. The recipes don't install libraries
for target's user space until we have a new client needs it.
The rmc-db.bbclass provides functions to generate rmc database
file for other software components to reuse.
We absorb a patch from Tom Zanussi to update source location with
the public link. We could put this change in another commit, but
leaving the replaced internal link in this commit could cause
trouble when people bisect the project but don't have access to
the internal location:
--
rmc: Update to use public repo
The repo the rmc recipe was pointing to was private - it's now public
Signed-off-by: Tom Zanussi
common/recipes-bsp/rmc/rmc.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-bsp/rmc/rmc.inc b/common/recipes-bsp/rmc/rmc.inc
index c046e2e..bdf930d 100644
--- a/common/recipes-bsp/rmc/rmc.inc
+++ b/common/recipes-bsp/rmc/rmc.inc
@@ -15,7 +15,7 @@ LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://COPYING;md5=bcdd376d27b26bde6afadd67aa3c8b07"
-SRC_URI = "git://g...@git.yoctoproject.org/rmc;protocol=ssh"
+SRC_URI = "git://git.yoctoproject.org/rmc"
...
--
Signed-off-by: Jianxun Zhang
---
classes/rmc-db.bbclass| 92 +++
common/recipes-bsp/rmc/rmc.bb | 46 ++
2 files changed, 138 insertions(+)
create mode 100644 classes/rmc-db.bbclass
create mode 100644 common/recipes-bsp/rmc/rmc.bb
diff --git a/classes/rmc-db.bbclass b/classes/rmc-db.bbclass
new file mode 100644
index 000..0fb4c27
--- /dev/null
+++ b/classes/rmc-db.bbclass
@@ -0,0 +1,92 @@
+# RMC database bbclass
+# provide functions to generate RMC database file on build host (native)
+
+DEPENDS += "rmc-native"
+
+# rmc_generate_db()
+# $1: a list of directories. Each directory holds directories for a group of
+# boards.
+# $2: path_name of rmc generates database file and records
+#
+# WARNING: content of directory of database file will be removed.
+#
+# Each board directory shall contain a fingerprint file (*.fp) at least, with
+# optional file blob(s) associated to the type of board. If a board directory
+# has no file blob, no record is created for that board.
+#
+# An example of two directories each of which contains two boards for RMC:
+# (All file and directory names are for illustration purpose.)
+#
+# dir_1/
+# board_1/
+# board_1_fingerprint.fp
+# file_1.blob
+# board_2/
+# board_2.fp
+# dir_2/
+# board_3/
+# b3.fp
+# file_1.blob
+# file_2.conf
+# board_4/
+# board_foo.fp
+# mylib.config
+#
+# To generate a RMC database "rmc.db" with data of all (actually 3) of boards
in
+# a directory "deploy_dir":
+#
+# rmc_generate_db "dir_1 dir_2" "deploy_dir/rmc.db"
+#
+# The board_2 will be skipped. No record or any data for it is packed in
+# generated database because it only contains a fingerprint file.
+#
+
+rmc_generate_db () {
+ RMC_BOARD_DIRS=$1
+
+ if [ "$#" -ne 2 ]; then
+ echo "rmc_generate_db(): Wrong number of arguments: $#"
+ return 1
+ fi
+
+ RMC_DB_DIR=$(dirname "$2")
+ RMC_RECORDS=""
+
+ rm -rf ${RMC_DB_DIR}
+ mkdir -p ${RMC_DB_DIR}
+
+ # generate rmc database
+ for topdir in ${RMC_BOARD_DIRS}; do
+ # For all board dirs in a topdir:
+ CUR_BOARD_DIRS=$(find ${topdir}/* -type d)
+ for board_dir in ${CUR_BOARD_DIRS}; do
+ # FIXME: we shall fail when having more than one .fp
file
+ CUR_FINGERPRINT=$(find ${board_dir}/ -name "*.fp")
+
+ # disallow a board directory without any fingerprint
file in it.
+ if [ -z "${CUR_FINGERPRINT}" ]; then
+ echo "Cannot find RMC fingerprint file in
${board_dir}"
+ return 1
+ fi
+
+ CUR_FILES=$(find ${board_dir}/ -type f |grep -v '\.fp$'
|| true)
+
+ # allow a directory only with fingerprint file.
Developer may
+ # check in fingerprint for future use.
+ if [ -z "${CUR_FILES}" ]; then
+ continue
+ fi
+
+ CUR_TAG=$(echo "${board_dir}"|sed 's/\//-/g')
+ CUR_RECO
[meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
V3 addresses feedbacks for V2, also includes other fixes: () Explicitly tell user overriding is a temporary solution in README () Move back two readme files back to top dir () Move RMC README to /documentation/rmc/ () Replace wrong EFI_PROVIDER info with Distro feature in RMC README () patches have been squashed () Now any new change of files in a board dir can be effective with a rebuild. () removing tmp dir in build won't cause build issue. (it is uncesesary either) () amend commit messages () amend installation logic in database recipe Jianxun Zhang (6): rmc: Add Runtime Machine Configuration (RMC) project gnu-efi: Add GUID for SMBIOS 3 entry point structure systemd-boot: load board-specific entry and kernel cmdline EFI installer: deploy board-specific data and kernel cmdline rmc: add recipe and bbclass for RMC feature rmc: document and examples for RMC feature classes/rmc-db.bbclass | 92 ++ classes/rmc-systemd-boot.bbclass | 12 + ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes common/recipes-bsp/rmc/rmc-db.bb | 46 +++ common/recipes-bsp/rmc/rmc.bb | 46 +++ .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ ...d-board-specific-boot-entries-from-RMC-da.patch | 241 +++ ...pport-global-kernel-command-line-fragment.patch | 66 .../initrdscripts/files/init-install-efi.sh| 315 +++ .../initramfs-live-install-efi_%.bbappend | 1 + conf/layer.conf| 16 + documentation/rmc/README | 337 + 31 files changed, 1301 insertions(+) create mode 100644 classes/rmc-db.bbclass create mode 100644 classes/rmc-systemd-boot.bbclass create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/install.conf create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/mylib.conf create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp create mode 100644 common/recipes-bsp/rmc/rmc-db.bb create mode 100644 common/recipes-bsp/rmc/rmc.bb create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot.bbappend create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot/0003-sd-boot-Support-global-kernel-command-line-fragment.patch create mode
[meta-intel] [PATCHv3 2/6] gnu-efi: Add GUID for SMBIOS 3 entry point structure
UEFI spec has different GUIDs for 32 and 64 bit SMBIOS
entry point structure. This change adds definition for
64 bit GUID, so that software linked with gnu-efi can
have it for x86_64 architecture.
Signed-off-by: Jianxun Zhang
---
...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++
common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 ++
2 files changed, 34 insertions(+)
create mode 100644
common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
diff --git
a/common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
b/common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
new file mode 100644
index 000..c86bf08
--- /dev/null
+++
b/common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
@@ -0,0 +1,32 @@
+From 4b2d610bbeb6d8a421abd62c8112456e7b35fd75 Mon Sep 17 00:00:00 2001
+From: Jianxun Zhang
+Date: Wed, 1 Jun 2016 15:04:22 -0700
+Subject: [PATCH] Add GUID for SMBIOS 3 entry point structure
+
+64 bit entry point structure has a different GUID from the
+existing 32 bit version.
+
+Upstream-Status: Pending
+
+Signed-off-by: Jianxun Zhang
+---
+ inc/efiapi.h | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/inc/efiapi.h b/inc/efiapi.h
+index 14cd939..7e3e1d6 100644
+--- a/inc/efiapi.h
b/inc/efiapi.h
+@@ -895,6 +895,9 @@ typedef struct _EFI_BOOT_SERVICES {
+ #define SMBIOS_TABLE_GUID\
+ { 0xeb9d2d31, 0x2d88, 0x11d3, {0x9a, 0x16, 0x0, 0x90, 0x27, 0x3f, 0xc1,
0x4d} }
+
++#define SMBIOS3_TABLE_GUID\
++{ 0xf2fd1544, 0x9794, 0x4a2c, {0x99, 0x2e, 0xe5, 0xbb, 0xcf, 0x20, 0xe3,
0x94} }
++
+ #define SAL_SYSTEM_TABLE_GUID\
+ { 0xeb9d2d32, 0x2d88, 0x11d3, {0x9a, 0x16, 0x0, 0x90, 0x27, 0x3f, 0xc1,
0x4d} }
+
+--
+2.7.4
+
diff --git a/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
b/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
new file mode 100644
index 000..b20e6e3
--- /dev/null
+++ b/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
@@ -0,0 +1,2 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/gnu-efi:"
+SRC_URI += "file://0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch"
--
2.7.4
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCHv3 3/6] systemd-boot: load board-specific entry and kernel cmdline
Invoke RMC APIs in this bootloader to query board-specific data
from RMC database(DB) file on ESP. Data can be boot entries or a
global kernel boot command line fragment specific to a type of
board supported in RMC DB.
Bootloader queries a file blob named BOOTENTRY.CONFIG from RMC
DB first. In success, bootloader parses BOOTENTRY.CONFIG to get
name of each boot entry file associated to the type of running
board, and then tries to load the entry into internal config data
structure. Eventually, bootloader shows RMC boot entries as well
as other boot entries added from other sources in boot menu.
BOOTENTRY.CONFIG has a very simple format - every line is a boot
entry file's name. For example, to specify two boot entries in it:
boot.conf
install.conf
Bootloader also seeks another file named KBOOTPARAM in RMC dB.
when it can obtain this file associated to the type of running
board, it appends what in file to the end of kernel command
line before it boots up kernel. The appending is effective on
every boot entry, so it is called "global" cmdline fragment.
When Bootloader doesn't get config, an entry or cmdline fragment
for the type of board, it simply move to next steps.
Signed-off-by: Jianxun Zhang
---
.../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++
...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 +++
...d-board-specific-boot-entries-from-RMC-da.patch | 241 +
...pport-global-kernel-command-line-fragment.patch | 66 ++
4 files changed, 358 insertions(+)
create mode 100644 common/recipes-bsp/systemd-boot/systemd-boot.bbappend
create mode 100644
common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
create mode 100644
common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch
create mode 100644
common/recipes-bsp/systemd-boot/systemd-boot/0003-sd-boot-Support-global-kernel-command-line-fragment.patch
diff --git a/common/recipes-bsp/systemd-boot/systemd-boot.bbappend
b/common/recipes-bsp/systemd-boot/systemd-boot.bbappend
new file mode 100644
index 000..f42434c
--- /dev/null
+++ b/common/recipes-bsp/systemd-boot/systemd-boot.bbappend
@@ -0,0 +1,20 @@
+DEPENDS += "rmc"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/systemd-boot:"
+
+EXTRA_OEMAKE += 'EFI_LDFLAGS="-L${STAGING_DIR_HOST}/usr/lib"
EFI_CFLAGS="-I${STAGING_INCDIR}/rmc/efi -DRMC_EFI"'
+
+# Pin systemd revision down for systemd-boot recipe.
+# Patches could not be applied cleanly when systemd in OE is updated,
+# though we don't expect a lot of changes could happen in bootloader.
+# RMC is designed to support a large number of types of boards, so we
+# should do explicit update with validation to prevent regression even
+# resolving conflicts for a new tip could be done in a short time.
+
+# Revision: systemd 230 in OE
+SRCREV = "3a74d4fc90cb322a4784a3515bef7118c8f8c5ba"
+
+SRC_URI += "file://0001-sd-boot-Link-RMC-libraries-into-bootloader.patch \
+
file://0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch \
+
file://0003-sd-boot-Support-global-kernel-command-line-fragment.patch \
+ "
diff --git
a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
new file mode 100644
index 000..c8867a2
--- /dev/null
+++
b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
@@ -0,0 +1,31 @@
+From b7775f24928fca01600cac1077ff3f215aa6362d Mon Sep 17 00:00:00 2001
+From: Jianxun Zhang
+Date: Sat, 21 May 2016 18:52:07 -0700
+Subject: [PATCH 1/3] sd-boot: Link RMC libraries into bootloader
+
+Add two RMC libraries into bootloader binary. EFI stub is not changed
+until we really need rmc in stub.
+
+Upstream-Status: Pending
+
+Signed-off-by: Jianxun Zhang
+---
+ Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Makefile.am b/Makefile.am
+index 305099a..ff21ebd 100644
+--- a/Makefile.am
b/Makefile.am
+@@ -2802,7 +2802,7 @@ $(top_builddir)/src/boot/efi/%.o:
$(top_srcdir)/src/boot/efi/%.c $(addprefix $(t
+
+ $(systemd_boot_solib): $(systemd_boot_objects)
+ $(AM_V_CCLD)$(LD) $(efi_ldflags) $(systemd_boot_objects) \
+- -o $@ -lefi -lgnuefi $(shell $(CC) -print-libgcc-file-name); \
++ -o $@ -lefi -lgnuefi -lrmclefi -lrsmpefi $(shell $(CC)
-print-libgcc-file-name); \
+ nm -D -u $@ | grep ' U ' && exit 1 || :
+
+ $(systemd_boot): $(systemd_boot_solib)
+--
+2.7.4
+
diff --git
a/common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch
b/common/recipes-bsp/systemd-boot/systemd-boot/0002-sd-boot-Load-board-specific-boot-entries-from-RMC-da.patch
new file mode 100644
index 000..89816ef
--- /dev/null
+++
b/common/recipes-bsp/systemd-boot/systemd-boot/00
[meta-intel] [PATCHv3 4/6] EFI installer: deploy board-specific data and kernel cmdline
Extend the existing init-install-efi.sh in OE to call RMC tool
so that it can deploy file blobs and a global kernel cmdline
fragment associated to the type of current running board.
At first, it tries to retrieve a special configuration file
INSTALLER.CONFIG associated to the board from RMC database file
on ESP.
If the config file is fetched successfully, installer parses
configuration file to know which file blobs should be deployed
from database to target, also with other necessary information
like FS attributes of deployed file.
If a rule in config file is to create a directory, installer
creates it accordingly. Developer must direct installer to create
new directory first if destination of a file is in that directory
by adding a '/' at the end of a line.
The below is an example of INSTALLER.CONFIG. It directs installer to
deploy a boot entry boot.conf to EFI partition, create a
directory /etc/mylib/ on target's rootfs, and deploy a config
file mylib.conf in the created directory. The first several lines
started with '#' are comment.
efi_entry_dir:root:disk:770:/boot/loader/entries/
boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
mylibdir:root:root:770:/tgt_root/etc/mylib/
mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
When installer cannot get config file for the type of running board,
it skips any board-specific deployment. If a command fails for a file,
installer simply move to the next file.
After all the boot entries are deployed, installer seeks a config file
KBOOTPARAM from RMC database file. In success, it appends the content
of KBOOTPARAM to the end of kernel command line of every deployed
entry. KBOOTPARAM works as a global kernel command line fragment
specific to the type of running board.
The installer is a copy of EFI installer script in OE meta:
./recipes-core/initrdscripts/files/init-install-efi.sh
(1f2a01b02e9e175cad4cf05b3ff7430bba232eb6)
Signed-off-by: Jianxun Zhang
---
.../initrdscripts/files/init-install-efi.sh| 315 +
.../initramfs-live-install-efi_%.bbappend | 1 +
2 files changed, 316 insertions(+)
create mode 100644 common/recipes-core/initrdscripts/files/init-install-efi.sh
create mode 100644
common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
diff --git a/common/recipes-core/initrdscripts/files/init-install-efi.sh
b/common/recipes-core/initrdscripts/files/init-install-efi.sh
new file mode 100644
index 000..ec685d3
--- /dev/null
+++ b/common/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -0,0 +1,315 @@
+#!/bin/sh -e
+#
+# Copyright (c) 2016, Intel Corporation.
+# All rights reserved.
+#
+# install.sh [device_name] [rootfs_name]
+#
+# This file is a copy of file with same name in OE:
+# meta/recipes-core/initrdscripts/files/. We modify
+# it for RMC feature to deploy file blobs from RMC
+# database file to target.
+
+PATH=/sbin:/bin:/usr/sbin:/usr/bin
+
+# We need 20 Mb for the boot partition
+boot_size=20
+
+# 5% for swap
+swap_ratio=5
+
+# Get a list of hard drives
+hdnamelist=""
+live_dev_name=`cat /proc/mounts | grep ${1%/} | awk '{print $1}'`
+live_dev_name=${live_dev_name#\/dev/}
+# Only strip the digit identifier if the device is not an mmc
+case $live_dev_name in
+mmcblk*)
+;;
+*)
+live_dev_name=${live_dev_name%%[0-9]*}
+;;
+esac
+
+echo "Searching for hard drives ..."
+
+for device in `ls /sys/block/`; do
+case $device in
+loop*)
+# skip loop device
+;;
+sr*)
+# skip CDROM device
+;;
+ram*)
+# skip ram device
+;;
+*)
+# skip the device LiveOS is on
+# Add valid hard drive name to the list
+case $device in
+$live_dev_name*)
+# skip the device we are running from
+;;
+*)
+hdnamelist="$hdnamelist $device"
+;;
+esac
+;;
+esac
+done
+
+if [ -z "${hdnamelist}" ]; then
+echo "You need another device (besides the live device
/dev/${live_dev_name}) to install the image. Installation aborted."
+exit 1
+fi
+
+TARGET_DEVICE_NAME=""
+for hdname in $hdnamelist; do
+# Display found hard drives and their basic info
+echo "---"
+echo /dev/$hdname
+if [ -r /sys/block/$hdname/device/vendor ]; then
+echo -n "VENDOR="
+cat /sys/block/$hdname/device/vendor
+fi
+if [ -r /sys/block/$hdname/device/model ]; then
+echo -n "MODEL="
+cat /sys/block/$hdname/device/model
+fi
+if [ -r /sys/block/$hdname/device/uevent ]; then
+echo -n "UEVENT="
+cat /sys/block/$hdname/device/uevent
+fi
+echo
+# Get user choice
+while true; do
+echo -n "Do you want to install this image there? [y/n] "
+read answer
+if [ "$answer" = "y" -o "$answer" = "n" ]; then
+
[meta-intel] [PATCHv3 5/6] rmc: add recipe and bbclass for RMC feature
RMC Feature is based on RMC project, systemd-boot, EFI installer
to enable a single generic image, built for multiple platforms,
automatically applies customization and quirks specific to a type
of boards at runtime.
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:
DISTRO_FEATURES_append = " rmc"
Based on Saul Wold's initial work on a feature switch, RMC patches
in systemd-boot, installer and gnu-efi aren't built unless the
feature is enabled.
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_BOARD_DATA_DIRS
is the interface to developers. How-to information will be provided
with examples in following patches.
Signed-off-by: Jianxun Zhang
---
classes/rmc-systemd-boot.bbclass | 12 +++
common/recipes-bsp/rmc/rmc-db.bb | 46
conf/layer.conf | 16 ++
3 files changed, 74 insertions(+)
create mode 100644 classes/rmc-systemd-boot.bbclass
create mode 100644 common/recipes-bsp/rmc/rmc-db.bb
diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-systemd-boot.bbclass
new file mode 100644
index 000..ad2cf10
--- /dev/null
+++ b/classes/rmc-systemd-boot.bbclass
@@ -0,0 +1,12 @@
+# rmc-systemd-boot bbclass
+# Deploy central RMC database file to ESP
+
+IMAGE_INSTALL_append = " rmc"
+
+inherit systemd-boot
+
+do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
+
+efi_populate_append() {
+install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db ${DEST}/rmc.db
+}
diff --git a/common/recipes-bsp/rmc/rmc-db.bb b/common/recipes-bsp/rmc/rmc-db.bb
new file mode 100644
index 000..fdb72bf
--- /dev/null
+++ b/common/recipes-bsp/rmc/rmc-db.bb
@@ -0,0 +1,46 @@
+SUMMARY = "Central RMC Database"
+DESCRIPTION = "Generate a centralized RMC database for RMC feature. \
+Fingerprints and data for all boards supported are specified by variable \
+RMC_BOARD_DATA_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 rmc-db.bbappend.Refer to rmc-db bbclass for more \
+information."
+
+LICENSE = "MIT"
+
+LIC_FILES_CHKSUM =
"file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
+
+inherit rmc-db
+
+RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/boards/"
+RMC_DB_DIR = "${WORKDIR}/db"
+
+# Let sstate be aware of change in any added board directories
+do_generate_rmc_db[file-checksums] = "${@get_rmc_top_dirs_list(d)}"
+
+# derived from get_lic_checksum_file_list(d) in base.bbclass in OE
+def get_rmc_top_dirs_list(d):
+dirlist = []
+dirs = d.getVar("RMC_BOARD_DATA_DIRS", True) or ''
+topdirs = dirs.split()
+for each in topdirs:
+dirlist.append(each + ":" + str(os.path.exists(each)))
+return " ".join(dirlist)
+
+do_generate_rmc_db () {
+ rmc_generate_db "${RMC_BOARD_DATA_DIRS}" "${RMC_DB_DIR}"/rmc.db
+}
+
+addtask generate_rmc_db after do_compile
+
+inherit deploy
+
+do_deploy () {
+ if [ -f ${RMC_DB_DIR}/rmc.db ]; then
+ install -m 0400 ${RMC_DB_DIR}/rmc.db ${DEPLOYDIR}
+ else
+ echo "Warning: no RMC central database found, skip deployment."
+ fi
+}
+
+addtask deploy after do_generate_rmc_db
diff --git a/conf/layer.conf b/conf/layer.conf
index d8e5000..8e22186 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,3 +15,19 @@ LICENSE_PATH += "${LAYERDIR}/common/custom-licenses"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_intel = "3"
+
+
+# Exclude RMC patches unless RMC Feature is eanbled
+RMC_BBMASK :=
"${LAYERDIR}/common/recipes-bsp/systemd-boot/systemd-boot.*\.bbappend \
+
${LAYERDIR}/common/recipes-core/initrdscripts/initramfs-live-install-efi.*\.bbappend
\
+ ${LAYERDIR}/common/recipes-bsp/gnu-efi/gnu-efi.*\.bbappend"
+
+BBMASK += "${RMC_BBMASK}"
+
+BBMASK_remove = "${@bb.utils.contains('DISTRO_FEATURES', 'rmc',
'${RMC_BBMASK}', '', d)}"
+
+# Override EFI_PROVIDER when RMC Feature is enabled
+
+EFI_PROVIDER_rmc_bootloader = "rmc-systemd-boot"
+
+OVERRIDES_append = ":${@bb.utils.contains('DISTRO_FEATURES', 'rmc',
'rmc_bootloader', '', d)}"
--
2.7.4
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoprojec
[meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
Provide a README for RMC feature. Also check in fingerprints and
configuration data for several boards as examples for users.
They can be used for validation too.
Signed-off-by: Jianxun Zhang
---
.../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 +
.../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes
common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 +
.../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 +
.../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 +
common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 +
.../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes
.../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 +
.../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 +
.../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes
.../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 +
.../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 +
common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 +
common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 +
common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 +
common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 +
common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes
documentation/rmc/README | 337 +
18 files changed, 381 insertions(+)
create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf
create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf
create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/install.conf
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/mylib.conf
create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp
create mode 100644 documentation/rmc/README
diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
b/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
new file mode 100644
index 000..b2fabe8
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
@@ -0,0 +1,2 @@
+boot.conf
+install.conf
diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
b/common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
new file mode 100644
index
..86ecea7344bfc744f7f9d57f3f1810d6f7ba0db1
GIT binary patch
literal 116
zcmZQ%Ehx%QDNQbk&r8frWe71eFbHvEV8SZOB2boERGgWg$KaV)lA5Ctq^aOolAo&)
p;;X6P91yAyWo&L@px~fjsAp{K?oq{1&rp1_02dA-n(p
literal 0
HcmV?d1
diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
b/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
new file mode 100644
index 000..f1578e0
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
@@ -0,0 +1,4 @@
+title T100T(32bit) boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot loglevel=8
diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
b/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
new file mode 100644
index 000..67e7eb1
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
@@ -0,0 +1,4 @@
+title T100T(32bit) install
+linux /vmlinuz
+initrd /initrd
+options LABEL=install-efi
diff --git a/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
new file mode 100644
index 000..cb01ced
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
@@ -0,0 +1 @@
+boot.conf
diff --git a/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
b/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
new file mode 100644
index 000..6e789cd
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
@@ -0,0 +1,4 @@
+title Minnow Max boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot console=ttyS0,115200n8
diff --git a/common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
b/common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
new file mode 100644
index
..3c5a286f33ad2e6b17de3bb610160532ce5d65cf
GIT binary patch
literal 143
zcmZQ%Ehx%QDNQbk&r8frWe9Wh@o|j|^K=bYa5PW|@No=r^AGZ6U_w>po0*rFU+$Ej
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
> V3 addresses feedbacks for V2, also includes other fixes:
>
> () Explicitly tell user overriding is a temporary solution in README
>
> () Move back two readme files back to top dir
>
> () Move RMC README to /documentation/rmc/
>
> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README
>
> () patches have been squashed
>
> () Now any new change of files in a board dir can be effective with a rebuild.
>
> () removing tmp dir in build won't cause build issue. (it is uncesesary
> either)
>
> () amend commit messages
>
> () amend installation logic in database recipe
>
Just noting things as I see them. Seeing this warning builing v3:
WARNING: rmc-db-1.0-r0 do_unpack: rmc-db: the directory ${WORKDIR}/${BP}
(/usr/local/dev/yocto/rmc-test-v3/build/tmp/work/corei7-64-poky-linux/rmc-db/1.0-r0/rmc-db-1.0)
pointed to by the S variable doesn't exist - please set S within the
recipe to point to where the source has been unpacked to
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH] intel-microcode: Update to the 20160714 version
[PATCH] intel-microcode: Update to the 20160714 version >From the OpenXT Project ( http://openxt.org ) refs: https://openxt.atlassian.net/browse/OXT-668 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH] intel-microcode: Update to the 20160714 version
From: Christopher Clark
Dates changed in Licence file required CHKSUM update
>From the OpenXT Project ( http://openxt.org )
refs: OXT-668
Signed-off-by: Christopher Clark
---
.../{intel-microcode_20151106.bb => intel-microcode_20160714.bb} | 8
1 file changed, 4 insertions(+), 4 deletions(-)
rename common/recipes-core/microcode/{intel-microcode_20151106.bb =>
intel-microcode_20160714.bb} (87%)
diff --git a/common/recipes-core/microcode/intel-microcode_20151106.bb
b/common/recipes-core/microcode/intel-microcode_20160714.bb
similarity index 87%
rename from common/recipes-core/microcode/intel-microcode_20151106.bb
rename to common/recipes-core/microcode/intel-microcode_20160714.bb
index f168b7d..e5047ea 100644
--- a/common/recipes-core/microcode/intel-microcode_20151106.bb
+++ b/common/recipes-core/microcode/intel-microcode_20160714.bb
@@ -11,11 +11,11 @@ DESCRIPTION = "The microcode data file contains the latest
microcode\
if the file is placed in the /etc/firmware directory of the Linux system."
LICENSE = "Intel-Microcode-License"
-LIC_FILES_CHKSUM = "file://microcode.dat;md5=0c9b76c8fa021400a15b3fd71a71977b"
+LIC_FILES_CHKSUM = "file://microcode.dat;md5=d8c57b35388b4b9f970f5377fcdfc486"
-SRC_URI = "http://downloadmirror.intel.com/25512/eng/microcode-${PV}.tgz";
-SRC_URI[md5sum] = "288dc721fb39d71457ef2f5a49161f57"
-SRC_URI[sha256sum] =
"096e39489eef67666be652e81fa372a06b74f39ea3d565dc0287242c668717e7"
+SRC_URI = "http://downloadmirror.intel.com/26156/eng/microcode-${PV}.tgz";
+SRC_URI[md5sum] = "84e4c0530dc38fd7b804daf894b1bdf9"
+SRC_URI[sha256sum] =
"f3a9c6fc93275bf1febc26f7c397ac93ed5f109e47fb52932f6dbd5cfdbc840e"
DEPENDS = "iucode-tool-native"
S = "${WORKDIR}"
--
2.1.4
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH] intel-microcode: Update to the 20160714 version
From: Christopher Clark
Dates changed in Licence file required CHKSUM update
>From the OpenXT Project ( http://openxt.org )
refs: OXT-668
Signed-off-by: Christopher Clark
---
.../{intel-microcode_20151106.bb => intel-microcode_20160714.bb} | 8
1 file changed, 4 insertions(+), 4 deletions(-)
rename common/recipes-core/microcode/{intel-microcode_20151106.bb =>
intel-microcode_20160714.bb} (87%)
diff --git a/common/recipes-core/microcode/intel-microcode_20151106.bb
b/common/recipes-core/microcode/intel-microcode_20160714.bb
similarity index 87%
rename from common/recipes-core/microcode/intel-microcode_20151106.bb
rename to common/recipes-core/microcode/intel-microcode_20160714.bb
index f168b7d..e5047ea 100644
--- a/common/recipes-core/microcode/intel-microcode_20151106.bb
+++ b/common/recipes-core/microcode/intel-microcode_20160714.bb
@@ -11,11 +11,11 @@ DESCRIPTION = "The microcode data file contains the latest
microcode\
if the file is placed in the /etc/firmware directory of the Linux system."
LICENSE = "Intel-Microcode-License"
-LIC_FILES_CHKSUM = "file://microcode.dat;md5=0c9b76c8fa021400a15b3fd71a71977b"
+LIC_FILES_CHKSUM = "file://microcode.dat;md5=d8c57b35388b4b9f970f5377fcdfc486"
-SRC_URI = "http://downloadmirror.intel.com/25512/eng/microcode-${PV}.tgz";
-SRC_URI[md5sum] = "288dc721fb39d71457ef2f5a49161f57"
-SRC_URI[sha256sum] =
"096e39489eef67666be652e81fa372a06b74f39ea3d565dc0287242c668717e7"
+SRC_URI = "http://downloadmirror.intel.com/26156/eng/microcode-${PV}.tgz";
+SRC_URI[md5sum] = "84e4c0530dc38fd7b804daf894b1bdf9"
+SRC_URI[sha256sum] =
"f3a9c6fc93275bf1febc26f7c397ac93ed5f109e47fb52932f6dbd5cfdbc840e"
DEPENDS = "iucode-tool-native"
S = "${WORKDIR}"
--
2.1.4
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH] intel-microcode: Update to the 20160714 version
[PATCH] intel-microcode: Update to the 20160714 version >From the OpenXT Project ( http://openxt.org ) refs: https://openxt.atlassian.net/browse/OXT-668 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
> On Jul 21, 2016, at 9:08 AM, Tom Zanussi wrote:
>
> On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
>> V3 addresses feedbacks for V2, also includes other fixes:
>>
>> () Explicitly tell user overriding is a temporary solution in README
>>
>> () Move back two readme files back to top dir
>>
>> () Move RMC README to /documentation/rmc/
>>
>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README
>>
>> () patches have been squashed
>>
>> () Now any new change of files in a board dir can be effective with a
>> rebuild.
>>
>> () removing tmp dir in build won't cause build issue. (it is uncesesary
>> either)
>>
>> () amend commit messages
>>
>> () amend installation logic in database recipe
>>
>
> Just noting things as I see them. Seeing this warning builing v3:
>
>
> WARNING: rmc-db-1.0-r0 do_unpack: rmc-db: the directory ${WORKDIR}/${BP}
> (/usr/local/dev/yocto/rmc-test-v3/build/tmp/work/corei7-64-poky-linux/rmc-db/1.0-r0/rmc-db-1.0)
> pointed to by the S variable doesn't exist - please set S within the
> recipe to point to where the source has been unpacked to
I didn’t see this issue until I update my poky today. The check is already
there for a while, but I guess someone could enforce it recently.
It looks like a corner case since we don’t have SRC_URI and unpack that
requires an explicit ${S}.
Sorry for the late finding, will fix it.
Thanks!
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
Hi Jianxun, On 07/21/2016 03:37 AM, Jianxun Zhang wrote: > V3 addresses feedbacks for V2, also includes other fixes: > > () Explicitly tell user overriding is a temporary solution in README > > () Move back two readme files back to top dir > > () Move RMC README to /documentation/rmc/ > > () Replace wrong EFI_PROVIDER info with Distro feature in RMC README > > () patches have been squashed > > () Now any new change of files in a board dir can be effective with a rebuild. > > () removing tmp dir in build won't cause build issue. (it is uncesesary > either) > > () amend commit messages > > () amend installation logic in database recipe > It seems to be working in general and I see updates when I change, but I seem to be getting extra boot menu items I didn't ask for. I have a BOOTENTRY.CONFIG with just this: boot.conf and in boot.conf: title NextUnitofComputing Gen3 boot linux /vmlinuz initrd /initrd options LABEL=mybootlabel I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see two entries before it: boot install I would expect to see only what I have in my configuration. Or am I doing something wrong? Tom > Jianxun Zhang (6): > rmc: Add Runtime Machine Configuration (RMC) project > gnu-efi: Add GUID for SMBIOS 3 entry point structure > systemd-boot: load board-specific entry and kernel cmdline > EFI installer: deploy board-specific data and kernel cmdline > rmc: add recipe and bbclass for RMC feature > rmc: document and examples for RMC feature > > classes/rmc-db.bbclass | 92 ++ > classes/rmc-systemd-boot.bbclass | 12 + > ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ > common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + > .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + > .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes > common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + > .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + > .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + > common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + > .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes > .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + > .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + > .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes > .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + > .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + > common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + > common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + > common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + > common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + > common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes > common/recipes-bsp/rmc/rmc-db.bb | 46 +++ > common/recipes-bsp/rmc/rmc.bb | 46 +++ > .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ > ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ > ...d-board-specific-boot-entries-from-RMC-da.patch | 241 +++ > ...pport-global-kernel-command-line-fragment.patch | 66 > .../initrdscripts/files/init-install-efi.sh| 315 +++ > .../initramfs-live-install-efi_%.bbappend | 1 + > conf/layer.conf| 16 + > documentation/rmc/README | 337 > + > 31 files changed, 1301 insertions(+) > create mode 100644 classes/rmc-db.bbclass > create mode 100644 classes/rmc-systemd-boot.bbclass > create mode 100644 > common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch > create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf > create mode 100644 common/recipes-bsp/rmc
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
> On Jul 21, 2016, at 11:37 AM, Tom Zanussi wrote: > > Hi Jianxun, > > On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >> V3 addresses feedbacks for V2, also includes other fixes: >> >> () Explicitly tell user overriding is a temporary solution in README >> >> () Move back two readme files back to top dir >> >> () Move RMC README to /documentation/rmc/ >> >> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >> >> () patches have been squashed >> >> () Now any new change of files in a board dir can be effective with a >> rebuild. >> >> () removing tmp dir in build won't cause build issue. (it is uncesesary >> either) >> >> () amend commit messages >> >> () amend installation logic in database recipe >> > > It seems to be working in general and I see updates when I change, but I > seem to be getting extra boot menu items I didn't ask for. > > I have a BOOTENTRY.CONFIG with just this: > > boot.conf > > and in boot.conf: > > title NextUnitofComputing Gen3 boot > linux /vmlinuz > initrd /initrd > options LABEL=mybootlabel > > I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see > two entries before it: > > boot > install > > I would expect to see only what I have in my configuration. Or am I > doing something wrong? > Tom, No, you don’t do anything wrong. It is designed that way. Any boot entry you pack in RMC are addition to the two default entries “boot” and “install” which are built from OE. There are different routes to add entries. OE allows user to bring their own boot entries in build (GUMMIBOOT_ENTRIES), so we should not override these. However, we cannot assume which entry should be replaced/overridden at runtime too because what you see in boot menu is title filed which could be anything from user. User could be confused when he realize there are two boot or install options, but he can quickly change titles in conf file to differentiate. An expectation is installer. RMC deployment is always effective no matter which install option is selected so that RMC deployment on a supported board is guaranteed. Thanks > Tom > > >> Jianxun Zhang (6): >> rmc: Add Runtime Machine Configuration (RMC) project >> gnu-efi: Add GUID for SMBIOS 3 entry point structure >> systemd-boot: load board-specific entry and kernel cmdline >> EFI installer: deploy board-specific data and kernel cmdline >> rmc: add recipe and bbclass for RMC feature >> rmc: document and examples for RMC feature >> >> classes/rmc-db.bbclass | 92 ++ >> classes/rmc-systemd-boot.bbclass | 12 + >> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ >> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + >> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + >> .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes >> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + >> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + >> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + >> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + >> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes >> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + >> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + >> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes >> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + >> .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + >> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + >> common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + >> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + >> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + >> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes >> common/recipes-bsp/rmc/rmc-db.bb | 46 +++ >> common/recipes-bsp/rmc/rmc.bb | 46 +++ >> .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ >> ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ >> ...d-board-specific-boot-entries-from-RMC-da.patch | 241 +++ >> ...pport-global-kernel-command-line-fragment.patch | 66 >> .../initrdscripts/files/init-install-efi.sh| 315 +++ >> .../initramfs-live-install-efi_%.bbappend | 1 + >> conf/layer.conf| 16 + >> documentation/rmc/README | 337 >> + >> 31 files changed, 1301 insertions(+) >> create mode 100644 classes/rmc-db.bbclass >> create mode 100644 classes/rmc-systemd-boot.bbclass >> create mode 100644 >> common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch >> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend >> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG >> create mode 100644 common/recipes-bsp/rmc/board
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 02:22 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >> wrote: >> >> Hi Jianxun, >> >> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>> V3 addresses feedbacks for V2, also includes other fixes: >>> >>> () Explicitly tell user overriding is a temporary solution in README >>> >>> () Move back two readme files back to top dir >>> >>> () Move RMC README to /documentation/rmc/ >>> >>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>> >>> () patches have been squashed >>> >>> () Now any new change of files in a board dir can be effective with a >>> rebuild. >>> >>> () removing tmp dir in build won't cause build issue. (it is uncesesary >>> either) >>> >>> () amend commit messages >>> >>> () amend installation logic in database recipe >>> >> >> It seems to be working in general and I see updates when I change, but I >> seem to be getting extra boot menu items I didn't ask for. >> >> I have a BOOTENTRY.CONFIG with just this: >> >> boot.conf >> >> and in boot.conf: >> >> title NextUnitofComputing Gen3 boot >> linux /vmlinuz >> initrd /initrd >> options LABEL=mybootlabel >> >> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >> two entries before it: >> >> boot >> install >> >> I would expect to see only what I have in my configuration. Or am I >> doing something wrong? >> > Tom, > No, you don’t do anything wrong. It is designed that way. Any boot entry you > pack in RMC are addition to the two default entries “boot” and “install” > which are built from OE. There are different routes to add entries. > > OE allows user to bring their own boot entries in build (GUMMIBOOT_ENTRIES), > so we should not override these. > > However, we cannot assume which entry should be replaced/overridden at > runtime too because what you see in boot menu is title filed which could be > anything from user. > > User could be confused when he realize there are two boot or install options, > but he can quickly change titles in conf file to differentiate. > Yes, I certainly was confused to see two boot entries. Even if I rename them like you suggest, how do I rename them to avoid confusion for the user i.e. which boot do I use, and if I'm supposed to ignore the other one, why is it there? To me it seems reasonable to assume that an rmc user would expect rmc menu management to be owned by rmc and not be surprised by other options from the base bootloader. Or to say it a different way, what's the use case for an rmc user to want to manage menu items in two separate places, the base bootloader and rmc? > An expectation is installer. RMC deployment is always effective no matter > which install option is selected so that RMC deployment on a supported board > is guaranteed. > I can see cases where an 'install' menu item isn't wanted or needed, like for example on an already-installed system. Tom > Thanks > >> Tom >> >> >>> Jianxun Zhang (6): >>> rmc: Add Runtime Machine Configuration (RMC) project >>> gnu-efi: Add GUID for SMBIOS 3 entry point structure >>> systemd-boot: load board-specific entry and kernel cmdline >>> EFI installer: deploy board-specific data and kernel cmdline >>> rmc: add recipe and bbclass for RMC feature >>> rmc: document and examples for RMC feature >>> >>> classes/rmc-db.bbclass | 92 ++ >>> classes/rmc-systemd-boot.bbclass | 12 + >>> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ >>> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + >>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + >>> .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes >>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + >>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + >>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + >>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + >>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes >>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + >>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + >>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes >>> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + >>> .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + >>> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + >>> common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + >>> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + >>> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + >>> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes >>> common/recipes-bsp/rmc/rmc-db.bb | 46 +++ >>> common/recipes-bsp/rmc/rmc.bb | 46 +++ >>> .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ >>> ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ >>> ...d-board-specific-boot-entries-from-RMC-
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
> On Jul 21, 2016, at 1:07 PM, Tom Zanussi wrote: > > On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >>> wrote: >>> >>> Hi Jianxun, >>> >>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: V3 addresses feedbacks for V2, also includes other fixes: () Explicitly tell user overriding is a temporary solution in README () Move back two readme files back to top dir () Move RMC README to /documentation/rmc/ () Replace wrong EFI_PROVIDER info with Distro feature in RMC README () patches have been squashed () Now any new change of files in a board dir can be effective with a rebuild. () removing tmp dir in build won't cause build issue. (it is uncesesary either) () amend commit messages () amend installation logic in database recipe >>> >>> It seems to be working in general and I see updates when I change, but I >>> seem to be getting extra boot menu items I didn't ask for. >>> >>> I have a BOOTENTRY.CONFIG with just this: >>> >>> boot.conf >>> >>> and in boot.conf: >>> >>> title NextUnitofComputing Gen3 boot >>> linux /vmlinuz >>> initrd /initrd >>> options LABEL=mybootlabel >>> >>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >>> two entries before it: >>> >>> boot >>> install >>> >>> I would expect to see only what I have in my configuration. Or am I >>> doing something wrong? >>> >> Tom, >> No, you don’t do anything wrong. It is designed that way. Any boot entry you >> pack in RMC are addition to the two default entries “boot” and “install” >> which are built from OE. There are different routes to add entries. >> >> OE allows user to bring their own boot entries in build (GUMMIBOOT_ENTRIES), >> so we should not override these. >> >> However, we cannot assume which entry should be replaced/overridden at >> runtime too because what you see in boot menu is title filed which could be >> anything from user. >> >> User could be confused when he realize there are two boot or install >> options, but he can quickly change titles in conf file to differentiate. >> > > Yes, I certainly was confused to see two boot entries. Even if I rename > them like you suggest, how do I rename them to avoid confusion for the > user i.e. which boot do I use, and if I'm supposed to ignore the other > one, why is it there? I think we shouldn’t enforce any naming policy here at this point. This is out of RMC control. Will user complain for confusion caused be another “boot” from a conf file added via the existing GUMMIBOOT_ENTRIES? I am not suggesting user to “ignore” other boot entries. I should say RMC just provides another source of boot entries. It is totally up to user for how to provide an entry, what should be in that entry, and eventually which entry to boot system. If we overrides any entries, I guess we will miss corner cases when people still want to boot a supported target with default settings... > > To me it seems reasonable to assume that an rmc user would expect rmc > menu management to be owned by rmc and not be surprised by other options > from the base bootloader. Or to say it a different way, what's the use > case for an rmc user to want to manage menu items in two separate > places, the base bootloader and rmc? > >> An expectation is installer. RMC deployment is always effective no matter >> which install option is selected so that RMC deployment on a supported board >> is guaranteed. >> > > I can see cases where an 'install' menu item isn't wanted or needed, > like for example on an already-installed system. If you mean not to show “RMC install” on an installed system, this is achieved by not putting conf files of installation in INSTALLER.CONFIG. NUC 6 example can be a reference. It has two RMC boot entries, but only directs installer to put boot.conf on target. :-) So you won’t see “install” after installation. Showing it or not, this is a “policy” defined by you as user. RMC provides you a runtime mechanism to make policies effective. Thanks > > Tom > >> Thanks >> >>> Tom >>> >>> Jianxun Zhang (6): rmc: Add Runtime Machine Configuration (RMC) project gnu-efi: Add GUID for SMBIOS 3 entry point structure systemd-boot: load board-specific entry and kernel cmdline EFI installer: deploy board-specific data and kernel cmdline rmc: add recipe and bbclass for RMC feature rmc: document and examples for RMC feature classes/rmc-db.bbclass | 92 ++ classes/rmc-systemd-boot.bbclass | 12 + ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes common/recipes-bsp/rm
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 04:35 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 1:07 PM, Tom Zanussi wrote: >> >> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi wrote: Hi Jianxun, On 07/21/2016 03:37 AM, Jianxun Zhang wrote: > V3 addresses feedbacks for V2, also includes other fixes: > > () Explicitly tell user overriding is a temporary solution in README > > () Move back two readme files back to top dir > > () Move RMC README to /documentation/rmc/ > > () Replace wrong EFI_PROVIDER info with Distro feature in RMC README > > () patches have been squashed > > () Now any new change of files in a board dir can be effective with a > rebuild. > > () removing tmp dir in build won't cause build issue. (it is uncesesary > either) > > () amend commit messages > > () amend installation logic in database recipe > It seems to be working in general and I see updates when I change, but I seem to be getting extra boot menu items I didn't ask for. I have a BOOTENTRY.CONFIG with just this: boot.conf and in boot.conf: title NextUnitofComputing Gen3 boot linux /vmlinuz initrd /initrd options LABEL=mybootlabel I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see two entries before it: boot install I would expect to see only what I have in my configuration. Or am I doing something wrong? >>> Tom, >>> No, you don’t do anything wrong. It is designed that way. Any boot entry >>> you pack in RMC are addition to the two default entries “boot” and >>> “install” which are built from OE. There are different routes to add >>> entries. >>> >>> OE allows user to bring their own boot entries in build >>> (GUMMIBOOT_ENTRIES), so we should not override these. >>> >>> However, we cannot assume which entry should be replaced/overridden at >>> runtime too because what you see in boot menu is title filed which could be >>> anything from user. >>> >>> User could be confused when he realize there are two boot or install >>> options, but he can quickly change titles in conf file to differentiate. >>> >> >> Yes, I certainly was confused to see two boot entries. Even if I rename >> them like you suggest, how do I rename them to avoid confusion for the >> user i.e. which boot do I use, and if I'm supposed to ignore the other >> one, why is it there? > I think we shouldn’t enforce any naming policy here at this point. This is > out of RMC control. Will user complain for confusion caused be another “boot” > from a conf file added via the existing GUMMIBOOT_ENTRIES? > You're the one suggesting renaming some to avoid confusing the user (because apparently we can't get rid of the two boot entries we didn't specify in rmc), nobody mentioned a naming policy. > I am not suggesting user to “ignore” other boot entries. I should say RMC > just provides another source of boot entries. It is totally up to user for > how to provide an entry, what should be in that entry, and eventually which > entry to boot system. > Multiple sources of boot entries is just confusing. > If we overrides any entries, I guess we will miss corner cases when people > still want to boot a supported target with default settings... > So how can we not make the corner cases drive the default of what most users would expect? i.e. make the default be that the user only sees the menu entries specified via rmc? with a fallback for the corner case users to see the other entries? >> >> To me it seems reasonable to assume that an rmc user would expect rmc >> menu management to be owned by rmc and not be surprised by other options >> from the base bootloader. Or to say it a different way, what's the use >> case for an rmc user to want to manage menu items in two separate >> places, the base bootloader and rmc? >> >>> An expectation is installer. RMC deployment is always effective no matter >>> which install option is selected so that RMC deployment on a supported >>> board is guaranteed. >>> >> >> I can see cases where an 'install' menu item isn't wanted or needed, >> like for example on an already-installed system. > > If you mean not to show “RMC install” on an installed system, this is > achieved by not putting conf files of installation in INSTALLER.CONFIG. > No, I'm not asking about what gets installed, I was just mentioning a case where you wouldn't want to see the install entry. Maybe the question to ask is - how do I get rid of those two extra boot and install entries? And maybe the answer should be the default.. Tom > NUC 6 example can be a reference. It has two RMC boot entries, but only > directs installer to put boot.conf on target. :-) So you won’t see “install” > after installation. > > Showing it or not, this is a “policy” defined by you as user. RMC
Re: [meta-intel] [PATCHv3 1/6] rmc: Add Runtime Machine Configuration (RMC) project
On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
> RMC recipe fetch RMC project and build it more than once in
> build time:
>
> RMC tool is built for host architecture (native). The tool for
> host is used to generate RMC database in build time.
>
> RMC tool is also built for target architecture, so that scripts
> in user space can call RMC tool on a running target. Developers
> can also boot a target and run rmc tool to obtain fingerprint
> for a new board type.
>
> RMC libraries are compiled for both of UEFI context and user
> space. They are always linked in RMC tool and can be linked
> into an EFI bootloader. The recipes don't install libraries
> for target's user space until we have a new client needs it.
>
> The rmc-db.bbclass provides functions to generate rmc database
> file for other software components to reuse.
>
> We absorb a patch from Tom Zanussi to update source location with
> the public link. We could put this change in another commit, but
> leaving the replaced internal link in this commit could cause
> trouble when people bisect the project but don't have access to
> the internal location:
> --
> rmc: Update to use public repo
>
> The repo the rmc recipe was pointing to was private - it's now public
> Signed-off-by: Tom Zanussi
>
> common/recipes-bsp/rmc/rmc.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/recipes-bsp/rmc/rmc.inc b/common/recipes-bsp/rmc/rmc.inc
> index c046e2e..bdf930d 100644
> --- a/common/recipes-bsp/rmc/rmc.inc
> +++ b/common/recipes-bsp/rmc/rmc.inc
> @@ -15,7 +15,7 @@ LICENSE = "MIT"
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=bcdd376d27b26bde6afadd67aa3c8b07"
>
> -SRC_URI = "git://g...@git.yoctoproject.org/rmc;protocol=ssh"
> +SRC_URI = "git://git.yoctoproject.org/rmc"
> ...
> --
>
> Signed-off-by: Jianxun Zhang
> ---
> classes/rmc-db.bbclass| 92
> +++
> common/recipes-bsp/rmc/rmc.bb | 46 ++
> 2 files changed, 138 insertions(+)
> create mode 100644 classes/rmc-db.bbclass
> create mode 100644 common/recipes-bsp/rmc/rmc.bb
>
> diff --git a/classes/rmc-db.bbclass b/classes/rmc-db.bbclass
> new file mode 100644
> index 000..0fb4c27
> --- /dev/null
> +++ b/classes/rmc-db.bbclass
> @@ -0,0 +1,92 @@
> +# RMC database bbclass
> +# provide functions to generate RMC database file on build host (native)
> +
> +DEPENDS += "rmc-native"
> +
> +# rmc_generate_db()
> +# $1: a list of directories. Each directory holds directories for a group of
> +# boards.
> +# $2: path_name of rmc generates database file and records
> +#
> +# WARNING: content of directory of database file will be removed.
> +#
> +# Each board directory shall contain a fingerprint file (*.fp) at least, with
> +# optional file blob(s) associated to the type of board. If a board directory
> +# has no file blob, no record is created for that board.
> +#
> +# An example of two directories each of which contains two boards for RMC:
> +# (All file and directory names are for illustration purpose.)
> +#
> +# dir_1/
> +# board_1/
> +# board_1_fingerprint.fp
> +# file_1.blob
> +# board_2/
> +# board_2.fp
> +# dir_2/
> +# board_3/
> +# b3.fp
> +# file_1.blob
> +# file_2.conf
> +# board_4/
> +# board_foo.fp
> +# mylib.config
> +#
I was easily able to accidentally create nonsense configuration and
nothing told me it was wrong.
For example, in my BOOTENTRY.CONFIG I mistyped a filename that didn't exist:
doesntexistboot.conf
It would seem that would be something the user would definitely be
interested in knowing (along with any other errors in .conf files
themselves), especially since there doesn't seem to be any way on the
target to tell what the source of the problem is.
It seems you should be able to detect that when generating the db file
on the host at least.
Basically there doesn't seem to be any way to determine the cause of
problems other than inspection, which is going to cause lots of
complaints from users.
Tom
> +# To generate a RMC database "rmc.db" with data of all (actually 3) of
> boards in
> +# a directory "deploy_dir":
> +#
> +# rmc_generate_db "dir_1 dir_2" "deploy_dir/rmc.db"
> +#
> +# The board_2 will be skipped. No record or any data for it is packed in
> +# generated database because it only contains a fingerprint file.
> +#
> +
> +rmc_generate_db () {
> + RMC_BOARD_DIRS=$1
> +
> + if [ "$#" -ne 2 ]; then
> + echo "rmc_generate_db(): Wrong number of arguments: $#"
> + return 1
> + fi
> +
> + RMC_DB_DIR=$(dirname "$2")
> + RMC_RECORDS=""
> +
> + rm -rf ${RMC_DB_DIR}
> + mkdir -p ${RMC_DB_DIR}
> +
> + # generate rmc database
> + for topdir in ${RMC_BOARD_DIRS}; do
> + # For all board dirs in a topdir:
> + CUR_BOARD_DIRS=$(find ${topdir}/* -type d)
> + fo
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
On 07/21/2016 03:37 AM, Jianxun Zhang wrote: > Provide a README for RMC feature. Also check in fingerprints and > configuration data for several boards as examples for users. > They can be used for validation too. > > Signed-off-by: Jianxun Zhang [...] > + > +Note 3: > +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to > the > +board, then tries to fetch each file specified in this config file, and then > +deploy the file onto target with its permissions, UID, GID and other > attributes > +also specified in this config file if file for the board can be retrieved > from > +RMC database. The format of this file is (# is for comment line) > + > +# name:uid:gid:mode:path_on_target > +# to create a directory, add a “/” at the end of path_on_target: > +audio_policy:0:0:600:/etc/audio/ > +audio_def_policy:0:0:600:/etc/audio/audio_policy > + > +The first line tells RMC installer to create a directory “audio” in /etc. If > any > +parent directory doesn’t exist, installer will create it. The above example > +creates /etc/audio directory first, then fetch a file named > “audio_def_policy” > +from RMC database for the board, then copy it to /etc/audio/ with a new name > +“audio_policy”. > + This example explicitly creates the /etc/audio directory first, then the audio_policy file inside. It seems you're doing this here just as an example, but when I tried without creating the /etc/audio directory first, it failed... Tom > +If this config file is not provided, only default entries “boot” and > “install” > +from OE are in boot menu. The name of this config file is what installer > looks > +up first, so it must be “INSTALLER.CONFIG”. > + > + -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
> On Jul 21, 2016, at 3:41 PM, Tom Zanussi wrote: > > On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >> Provide a README for RMC feature. Also check in fingerprints and >> configuration data for several boards as examples for users. >> They can be used for validation too. >> >> Signed-off-by: Jianxun Zhang > > [...] > >> + >> +Note 3: >> +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to >> the >> +board, then tries to fetch each file specified in this config file, and then >> +deploy the file onto target with its permissions, UID, GID and other >> attributes >> +also specified in this config file if file for the board can be retrieved >> from >> +RMC database. The format of this file is (# is for comment line) >> + >> +# name:uid:gid:mode:path_on_target >> +# to create a directory, add a “/” at the end of path_on_target: >> +audio_policy:0:0:600:/etc/audio/ >> +audio_def_policy:0:0:600:/etc/audio/audio_policy >> + >> +The first line tells RMC installer to create a directory “audio” in /etc. >> If any >> +parent directory doesn’t exist, installer will create it. The above example >> +creates /etc/audio directory first, then fetch a file named >> “audio_def_policy” >> +from RMC database for the board, then copy it to /etc/audio/ with a new name >> +“audio_policy”. >> + > > This example explicitly creates the /etc/audio directory first, then the > audio_policy file inside. It seems you're doing this here just as an > example, but when I tried without creating the /etc/audio directory > first, it failed… Great catch! The correct information is in commit msg of installer patch, but not updated in README. :-( Will fix this. > > Tom > >> +If this config file is not provided, only default entries “boot” and >> “install” >> +from OE are in boot menu. The name of this config file is what installer >> looks >> +up first, so it must be “INSTALLER.CONFIG”. >> + >> + > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
On 07/21/2016 06:02 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 3:41 PM, Tom Zanussi wrote: >> >> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>> Provide a README for RMC feature. Also check in fingerprints and >>> configuration data for several boards as examples for users. >>> They can be used for validation too. >>> >>> Signed-off-by: Jianxun Zhang >> >> [...] >> >>> + >>> +Note 3: >>> +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to >>> the >>> +board, then tries to fetch each file specified in this config file, and >>> then >>> +deploy the file onto target with its permissions, UID, GID and other >>> attributes >>> +also specified in this config file if file for the board can be retrieved >>> from >>> +RMC database. The format of this file is (# is for comment line) >>> + >>> +# name:uid:gid:mode:path_on_target >>> +# to create a directory, add a “/” at the end of path_on_target: >>> +audio_policy:0:0:600:/etc/audio/ >>> +audio_def_policy:0:0:600:/etc/audio/audio_policy >>> + >>> +The first line tells RMC installer to create a directory “audio” in /etc. >>> If any >>> +parent directory doesn’t exist, installer will create it. The above example >>> +creates /etc/audio directory first, then fetch a file named >>> “audio_def_policy” >>> +from RMC database for the board, then copy it to /etc/audio/ with a new >>> name >>> +“audio_policy”. >>> + >> >> This example explicitly creates the /etc/audio directory first, then the >> audio_policy file inside. It seems you're doing this here just as an >> example, but when I tried without creating the /etc/audio directory >> first, it failed… > Great catch! The correct information is in commit msg of installer patch, but > not updated in README. :-( > Will fix this. > So, the fix is to make the code match "If any parent directory doesn’t exist, installer will create it". Seems like that's the right fix.. Tom >> >> Tom >> >>> +If this config file is not provided, only default entries “boot” and >>> “install” >>> +from OE are in boot menu. The name of this config file is what installer >>> looks >>> +up first, so it must be “INSTALLER.CONFIG”. >>> + >>> + >> > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 4/6] EFI installer: deploy board-specific data and kernel cmdline
On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
> Extend the existing init-install-efi.sh in OE to call RMC tool
> so that it can deploy file blobs and a global kernel cmdline
> fragment associated to the type of current running board.
>
> At first, it tries to retrieve a special configuration file
> INSTALLER.CONFIG associated to the board from RMC database file
> on ESP.
>
> If the config file is fetched successfully, installer parses
> configuration file to know which file blobs should be deployed
> from database to target, also with other necessary information
> like FS attributes of deployed file.
>
> If a rule in config file is to create a directory, installer
> creates it accordingly. Developer must direct installer to create
> new directory first if destination of a file is in that directory
> by adding a '/' at the end of a line.
>
> The below is an example of INSTALLER.CONFIG. It directs installer to
> deploy a boot entry boot.conf to EFI partition, create a
> directory /etc/mylib/ on target's rootfs, and deploy a config
> file mylib.conf in the created directory. The first several lines
> started with '#' are comment.
>
> efi_entry_dir:root:disk:770:/boot/loader/entries/
> boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
> mylibdir:root:root:770:/tgt_root/etc/mylib/
> mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
>
> When installer cannot get config file for the type of running board,
> it skips any board-specific deployment. If a command fails for a file,
> installer simply move to the next file.
>
> After all the boot entries are deployed, installer seeks a config file
> KBOOTPARAM from RMC database file. In success, it appends the content
> of KBOOTPARAM to the end of kernel command line of every deployed
> entry. KBOOTPARAM works as a global kernel command line fragment
> specific to the type of running board.
>
> The installer is a copy of EFI installer script in OE meta:
> ./recipes-core/initrdscripts/files/init-install-efi.sh
> (1f2a01b02e9e175cad4cf05b3ff7430bba232eb6)
>
It seems like this is the wrong way to go - to have another copy of the
same exact file, which is quite large, somewhere else in the system.
Besides the obvious duplication, what happens when bugs are found in one
- is this going to track all patches to the original?
I suppose that since having rmc in meta-intel is just a stopover to
oe-core, it's a temporary situation, but even still, it would be nice if
it would be possible to make and submit changes to the original (I guess
when rmc is in oe-core, it will need them anyway) and use them from rmc
in meta-intel..
Tom
> Signed-off-by: Jianxun Zhang
> ---
> .../initrdscripts/files/init-install-efi.sh| 315
> +
> .../initramfs-live-install-efi_%.bbappend | 1 +
> 2 files changed, 316 insertions(+)
> create mode 100644
> common/recipes-core/initrdscripts/files/init-install-efi.sh
> create mode 100644
> common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
>
> diff --git a/common/recipes-core/initrdscripts/files/init-install-efi.sh
> b/common/recipes-core/initrdscripts/files/init-install-efi.sh
> new file mode 100644
> index 000..ec685d3
> --- /dev/null
> +++ b/common/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -0,0 +1,315 @@
> +#!/bin/sh -e
> +#
> +# Copyright (c) 2016, Intel Corporation.
> +# All rights reserved.
> +#
> +# install.sh [device_name] [rootfs_name]
> +#
> +# This file is a copy of file with same name in OE:
> +# meta/recipes-core/initrdscripts/files/. We modify
> +# it for RMC feature to deploy file blobs from RMC
> +# database file to target.
> +
> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
> +
> +# We need 20 Mb for the boot partition
> +boot_size=20
> +
> +# 5% for swap
> +swap_ratio=5
> +
> +# Get a list of hard drives
> +hdnamelist=""
> +live_dev_name=`cat /proc/mounts | grep ${1%/} | awk '{print $1}'`
> +live_dev_name=${live_dev_name#\/dev/}
> +# Only strip the digit identifier if the device is not an mmc
> +case $live_dev_name in
> +mmcblk*)
> +;;
> +*)
> +live_dev_name=${live_dev_name%%[0-9]*}
> +;;
> +esac
> +
> +echo "Searching for hard drives ..."
> +
> +for device in `ls /sys/block/`; do
> +case $device in
> +loop*)
> +# skip loop device
> +;;
> +sr*)
> +# skip CDROM device
> +;;
> +ram*)
> +# skip ram device
> +;;
> +*)
> +# skip the device LiveOS is on
> +# Add valid hard drive name to the list
> +case $device in
> +$live_dev_name*)
> +# skip the device we are running from
> +;;
> +*)
> +hdnamelist="$hdnamelist $device"
> +;;
> +esac
> +;;
> +esac
> +done
> +
> +if [ -z "${hdnamelist}" ]; then
> +echo "You need another device (besides the live devic
Re: [meta-intel] [PATCHv3 1/6] rmc: Add Runtime Machine Configuration (RMC) project
> On Jul 21, 2016, at 3:35 PM, Tom Zanussi wrote: > > On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >> RMC recipe fetch RMC project and build it more than once in >> build time: >> >> RMC tool is built for host architecture (native). The tool for >> host is used to generate RMC database in build time. >> >> RMC tool is also built for target architecture, so that scripts >> in user space can call RMC tool on a running target. Developers >> can also boot a target and run rmc tool to obtain fingerprint >> for a new board type. >> >> RMC libraries are compiled for both of UEFI context and user >> space. They are always linked in RMC tool and can be linked >> into an EFI bootloader. The recipes don't install libraries >> for target's user space until we have a new client needs it. >> >> The rmc-db.bbclass provides functions to generate rmc database >> file for other software components to reuse. >> >> We absorb a patch from Tom Zanussi to update source location with >> the public link. We could put this change in another commit, but >> leaving the replaced internal link in this commit could cause >> trouble when people bisect the project but don't have access to >> the internal location: >> -- >> rmc: Update to use public repo >> >> The repo the rmc recipe was pointing to was private - it's now public >> Signed-off-by: Tom Zanussi >> >> common/recipes-bsp/rmc/rmc.inc | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/common/recipes-bsp/rmc/rmc.inc b/common/recipes-bsp/rmc/rmc.inc >> index c046e2e..bdf930d 100644 >> --- a/common/recipes-bsp/rmc/rmc.inc >> +++ b/common/recipes-bsp/rmc/rmc.inc >> @@ -15,7 +15,7 @@ LICENSE = "MIT" >> >> LIC_FILES_CHKSUM = "file://COPYING;md5=bcdd376d27b26bde6afadd67aa3c8b07" >> >> -SRC_URI = "git://g...@git.yoctoproject.org/rmc;protocol=ssh" >> +SRC_URI = "git://git.yoctoproject.org/rmc" >> ... >> -- >> >> Signed-off-by: Jianxun Zhang >> --- >> classes/rmc-db.bbclass| 92 >> +++ >> common/recipes-bsp/rmc/rmc.bb | 46 ++ >> 2 files changed, 138 insertions(+) >> create mode 100644 classes/rmc-db.bbclass >> create mode 100644 common/recipes-bsp/rmc/rmc.bb >> >> diff --git a/classes/rmc-db.bbclass b/classes/rmc-db.bbclass >> new file mode 100644 >> index 000..0fb4c27 >> --- /dev/null >> +++ b/classes/rmc-db.bbclass >> @@ -0,0 +1,92 @@ >> +# RMC database bbclass >> +# provide functions to generate RMC database file on build host (native) >> + >> +DEPENDS += "rmc-native" >> + >> +# rmc_generate_db() >> +# $1: a list of directories. Each directory holds directories for a group of >> +# boards. >> +# $2: path_name of rmc generates database file and records >> +# >> +# WARNING: content of directory of database file will be removed. >> +# >> +# Each board directory shall contain a fingerprint file (*.fp) at least, >> with >> +# optional file blob(s) associated to the type of board. If a board >> directory >> +# has no file blob, no record is created for that board. >> +# >> +# An example of two directories each of which contains two boards for RMC: >> +# (All file and directory names are for illustration purpose.) >> +# >> +# dir_1/ >> +# board_1/ >> +# board_1_fingerprint.fp >> +# file_1.blob >> +# board_2/ >> +# board_2.fp >> +# dir_2/ >> +# board_3/ >> +# b3.fp >> +# file_1.blob >> +# file_2.conf >> +# board_4/ >> +# board_foo.fp >> +# mylib.config >> +# > > I was easily able to accidentally create nonsense configuration and > nothing told me it was wrong. > > For example, in my BOOTENTRY.CONFIG I mistyped a filename that didn't exist: > > doesntexistboot.conf > > It would seem that would be something the user would definitely be > interested in knowing (along with any other errors in .conf files > themselves), especially since there doesn't seem to be any way on the > target to tell what the source of the problem is. > > It seems you should be able to detect that when generating the db file > on the host at least. > > Basically there doesn't seem to be any way to determine the cause of > problems other than inspection, which is going to cause lots of > complaints from users. > The feature’s design will be coupled with different things if we just copy that parser from installer to bbclass. DB is created in a generic function in build time. INSTALLER.CONFIG is a special (policy) file for EFI installer. A better way is to have a special hook to DB function, so that each client (bootloader, installer) can add its checker at build time. Totally agree with you that we need checkers. Could I fix this after 1st merge? > Tom > > >> +# To generate a RMC database "rmc.db" with data of all (actually 3) of >> boards in >> +# a directory "deploy_dir": >> +# >> +# rmc_generate_db "dir_1 dir_2" "deploy_dir/rmc.db" >> +# >> +# The board_2 will be skipped. No
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
> On Jul 21, 2016, at 4:14 PM, Tom Zanussi wrote: > > On 07/21/2016 06:02 PM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 3:41 PM, Tom Zanussi >>> wrote: >>> >>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: Provide a README for RMC feature. Also check in fingerprints and configuration data for several boards as examples for users. They can be used for validation too. Signed-off-by: Jianxun Zhang >>> >>> [...] >>> + +Note 3: +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to the +board, then tries to fetch each file specified in this config file, and then +deploy the file onto target with its permissions, UID, GID and other attributes +also specified in this config file if file for the board can be retrieved from +RMC database. The format of this file is (# is for comment line) + +# name:uid:gid:mode:path_on_target +# to create a directory, add a “/” at the end of path_on_target: +audio_policy:0:0:600:/etc/audio/ +audio_def_policy:0:0:600:/etc/audio/audio_policy + +The first line tells RMC installer to create a directory “audio” in /etc. If any +parent directory doesn’t exist, installer will create it. The above example +creates /etc/audio directory first, then fetch a file named “audio_def_policy” +from RMC database for the board, then copy it to /etc/audio/ with a new name +“audio_policy”. + >>> >>> This example explicitly creates the /etc/audio directory first, then the >>> audio_policy file inside. It seems you're doing this here just as an >>> example, but when I tried without creating the /etc/audio directory >>> first, it failed… >> Great catch! The correct information is in commit msg of installer patch, >> but not updated in README. :-( >> Will fix this. >> > > So, the fix is to make the code match "If any parent directory doesn’t > exist, installer will create it". Seems like that's the right fix.. Nope. Developer must explicitly direct installer to create dir for new file first. This is because only developer knows FS attributes for dir to be created. Code is right but readme is wrong. > new directory first if destination of a file is in that directory > by adding a '/' at the end of a line. > If a rule in config file is to create a directory, installer > creates it accordingly. Developer must direct installer to create > new directory first if destination of a file is in that directory > by adding a '/' at the end of a line. > > Tom > >>> >>> Tom >>> +If this config file is not provided, only default entries “boot” and “install” +from OE are in boot menu. The name of this config file is what installer looks +up first, so it must be “INSTALLER.CONFIG”. + + -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
On 07/21/2016 06:33 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 4:14 PM, Tom Zanussi wrote: >> >> On 07/21/2016 06:02 PM, Jianxun Zhang wrote: >>> On Jul 21, 2016, at 3:41 PM, Tom Zanussi wrote: On 07/21/2016 03:37 AM, Jianxun Zhang wrote: > Provide a README for RMC feature. Also check in fingerprints and > configuration data for several boards as examples for users. > They can be used for validation too. > > Signed-off-by: Jianxun Zhang [...] > + > +Note 3: > +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific > to the > +board, then tries to fetch each file specified in this config file, and > then > +deploy the file onto target with its permissions, UID, GID and other > attributes > +also specified in this config file if file for the board can be > retrieved from > +RMC database. The format of this file is (# is for comment line) > + > +# name:uid:gid:mode:path_on_target > +# to create a directory, add a “/” at the end of path_on_target: > +audio_policy:0:0:600:/etc/audio/ > +audio_def_policy:0:0:600:/etc/audio/audio_policy > + > +The first line tells RMC installer to create a directory “audio” in > /etc. If any > +parent directory doesn’t exist, installer will create it. The above > example > +creates /etc/audio directory first, then fetch a file named > “audio_def_policy” > +from RMC database for the board, then copy it to /etc/audio/ with a new > name > +“audio_policy”. > + This example explicitly creates the /etc/audio directory first, then the audio_policy file inside. It seems you're doing this here just as an example, but when I tried without creating the /etc/audio directory first, it failed… >>> Great catch! The correct information is in commit msg of installer patch, >>> but not updated in README. :-( >>> Will fix this. >>> >> >> So, the fix is to make the code match "If any parent directory doesn’t >> exist, installer will create it". Seems like that's the right fix.. > Nope. Developer must explicitly direct installer to create dir for new file > first. This is because only developer knows FS attributes for dir to be > created. Code is right but readme is wrong. > Seems like they should be created with default attributes, which they can of course override by doing it directly - it's very tedious for the user to manually create each directory otherwise. Tom > >> new directory first if destination of a file is in that directory >> by adding a '/' at the end of a line. > > >> If a rule in config file is to create a directory, installer >> creates it accordingly. Developer must direct installer to create >> new directory first if destination of a file is in that directory >> by adding a '/' at the end of a line. > > > >> >> Tom >> Tom > +If this config file is not provided, only default entries “boot” and > “install” > +from OE are in boot menu. The name of this config file is what installer > looks > +up first, so it must be “INSTALLER.CONFIG”. > + > + > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 4/6] EFI installer: deploy board-specific data and kernel cmdline
> On Jul 21, 2016, at 4:21 PM, Tom Zanussi wrote:
>
> On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
>> Extend the existing init-install-efi.sh in OE to call RMC tool
>> so that it can deploy file blobs and a global kernel cmdline
>> fragment associated to the type of current running board.
>>
>> At first, it tries to retrieve a special configuration file
>> INSTALLER.CONFIG associated to the board from RMC database file
>> on ESP.
>>
>> If the config file is fetched successfully, installer parses
>> configuration file to know which file blobs should be deployed
>> from database to target, also with other necessary information
>> like FS attributes of deployed file.
>>
>> If a rule in config file is to create a directory, installer
>> creates it accordingly. Developer must direct installer to create
>> new directory first if destination of a file is in that directory
>> by adding a '/' at the end of a line.
>>
>> The below is an example of INSTALLER.CONFIG. It directs installer to
>> deploy a boot entry boot.conf to EFI partition, create a
>> directory /etc/mylib/ on target's rootfs, and deploy a config
>> file mylib.conf in the created directory. The first several lines
>> started with '#' are comment.
>>
>> efi_entry_dir:root:disk:770:/boot/loader/entries/
>> boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
>> mylibdir:root:root:770:/tgt_root/etc/mylib/
>> mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
>>
>> When installer cannot get config file for the type of running board,
>> it skips any board-specific deployment. If a command fails for a file,
>> installer simply move to the next file.
>>
>> After all the boot entries are deployed, installer seeks a config file
>> KBOOTPARAM from RMC database file. In success, it appends the content
>> of KBOOTPARAM to the end of kernel command line of every deployed
>> entry. KBOOTPARAM works as a global kernel command line fragment
>> specific to the type of running board.
>>
>> The installer is a copy of EFI installer script in OE meta:
>> ./recipes-core/initrdscripts/files/init-install-efi.sh
>> (1f2a01b02e9e175cad4cf05b3ff7430bba232eb6)
>>
>
> It seems like this is the wrong way to go - to have another copy of the
> same exact file, which is quite large, somewhere else in the system.
> Besides the obvious duplication, what happens when bugs are found in one
> - is this going to track all patches to the original?
>
> I suppose that since having rmc in meta-intel is just a stopover to
> oe-core, it's a temporary situation, but even still, it would be nice if
> it would be possible to make and submit changes to the original (I guess
> when rmc is in oe-core, it will need them anyway) and use them from rmc
> in meta-intel..
The installer is a copy from OE but modified for RMC. Diff this file and OE’s
will show you the delta for RMC.
I don’t have a better way so far to just have a fragment of this script in
meta-intel based on OE’s. Yes, ideally,
we don’t need to carry this bit if RMC is in OE. But it looks strange to submit
this RMC delta to OE without
other pieces now. I can try to change this file into a patch, but I don’t know
if it can work.
We should pursue upstreaming it into OE although my initial thought is taking
meta-intel as RMC’s home.
V4 just merged latest OE version, BTW.
>
> Tom
>
>> Signed-off-by: Jianxun Zhang
>> ---
>> .../initrdscripts/files/init-install-efi.sh| 315
>> +
>> .../initramfs-live-install-efi_%.bbappend | 1 +
>> 2 files changed, 316 insertions(+)
>> create mode 100644
>> common/recipes-core/initrdscripts/files/init-install-efi.sh
>> create mode 100644
>> common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
>>
>> diff --git a/common/recipes-core/initrdscripts/files/init-install-efi.sh
>> b/common/recipes-core/initrdscripts/files/init-install-efi.sh
>> new file mode 100644
>> index 000..ec685d3
>> --- /dev/null
>> +++ b/common/recipes-core/initrdscripts/files/init-install-efi.sh
>> @@ -0,0 +1,315 @@
>> +#!/bin/sh -e
>> +#
>> +# Copyright (c) 2016, Intel Corporation.
>> +# All rights reserved.
>> +#
>> +# install.sh [device_name] [rootfs_name]
>> +#
>> +# This file is a copy of file with same name in OE:
>> +# meta/recipes-core/initrdscripts/files/. We modify
>> +# it for RMC feature to deploy file blobs from RMC
>> +# database file to target.
>> +
>> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
>> +
>> +# We need 20 Mb for the boot partition
>> +boot_size=20
>> +
>> +# 5% for swap
>> +swap_ratio=5
>> +
>> +# Get a list of hard drives
>> +hdnamelist=""
>> +live_dev_name=`cat /proc/mounts | grep ${1%/} | awk '{print $1}'`
>> +live_dev_name=${live_dev_name#\/dev/}
>> +# Only strip the digit identifier if the device is not an mmc
>> +case $live_dev_name in
>> +mmcblk*)
>> +;;
>> +*)
>> +live_dev_name=${live_dev_name%%[0-9]*}
>> +;;
>> +esac
>> +
>> +echo "Searching for hard drives ..."
>> +
>> +for device in `ls /sy
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
> On Jul 21, 2016, at 2:50 PM, Tom Zanussi wrote: > > On 07/21/2016 04:35 PM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi >>> wrote: >>> >>> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: > On Jul 21, 2016, at 11:37 AM, Tom Zanussi > wrote: > > Hi Jianxun, > > On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >> V3 addresses feedbacks for V2, also includes other fixes: >> >> () Explicitly tell user overriding is a temporary solution in README >> >> () Move back two readme files back to top dir >> >> () Move RMC README to /documentation/rmc/ >> >> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >> >> () patches have been squashed >> >> () Now any new change of files in a board dir can be effective with a >> rebuild. >> >> () removing tmp dir in build won't cause build issue. (it is uncesesary >> either) >> >> () amend commit messages >> >> () amend installation logic in database recipe >> > > It seems to be working in general and I see updates when I change, but I > seem to be getting extra boot menu items I didn't ask for. > > I have a BOOTENTRY.CONFIG with just this: > > boot.conf > > and in boot.conf: > > title NextUnitofComputing Gen3 boot > linux /vmlinuz > initrd /initrd > options LABEL=mybootlabel > > I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see > two entries before it: > > boot > install > > I would expect to see only what I have in my configuration. Or am I > doing something wrong? > Tom, No, you don’t do anything wrong. It is designed that way. Any boot entry you pack in RMC are addition to the two default entries “boot” and “install” which are built from OE. There are different routes to add entries. OE allows user to bring their own boot entries in build (GUMMIBOOT_ENTRIES), so we should not override these. However, we cannot assume which entry should be replaced/overridden at runtime too because what you see in boot menu is title filed which could be anything from user. User could be confused when he realize there are two boot or install options, but he can quickly change titles in conf file to differentiate. >>> >>> Yes, I certainly was confused to see two boot entries. Even if I rename >>> them like you suggest, how do I rename them to avoid confusion for the >>> user i.e. which boot do I use, and if I'm supposed to ignore the other >>> one, why is it there? >> I think we shouldn’t enforce any naming policy here at this point. This is >> out of RMC control. Will user complain for confusion caused be another >> “boot” from a conf file added via the existing GUMMIBOOT_ENTRIES? >> > > You're the one suggesting renaming some to avoid confusing the user > (because apparently we can't get rid of the two boot entries we didn't > specify in rmc), nobody mentioned a naming policy. Sorry if I miss your point. What we are discussing is (a) if titles could be confusing, or (b) if you have multiple boot entries to boot a board. For the naming aspect (a), it is totally up to developer or users. For the later case (b), it could depend on what functionality behind an entry, like “ubuntu 3.2.6” or “mem-test x86”. I could just say “RMC NUC 6 boot” below a “boot” to mark it from RMC feature for NUC 6. Is this exact you are concerned? > >> I am not suggesting user to “ignore” other boot entries. I should say RMC >> just provides another source of boot entries. It is totally up to user for >> how to provide an entry, what should be in that entry, and eventually which >> entry to boot system. >> > > Multiple sources of boot entries is just confusing. > I don’t think sources are the real problem or I could misunderstand this comment. I don’t think sources are confusing. The existing gummiboot/systemd-boot already supports multiple sources, not only reading conf files from ESP. >> If we overrides any entries, I guess we will miss corner cases when people >> still want to boot a supported target with default settings... >> > > So how can we not make the corner cases drive the default of what most > users would expect? i.e. make the default be that the user only sees > the menu entries specified via rmc? with a fallback for the corner case > users to see the other entries? I suggest we don’t guess it for most of users since we don’t have solid data. But what I could do later is to hack systemd-boot so it won’t load _any_ entries from disk once RMC entries for the board are available. But that means you cannot add an new entry and make it effective on a live-boot disk. I feel this arbitrary solution, well, could bring more corner cases. Let me know if this can be in a fix plan. > >>>
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 08:05 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 2:50 PM, Tom Zanussi wrote: >> >> On 07/21/2016 04:35 PM, Jianxun Zhang wrote: >>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi wrote: On 07/21/2016 02:22 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >> wrote: >> >> Hi Jianxun, >> >> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>> V3 addresses feedbacks for V2, also includes other fixes: >>> >>> () Explicitly tell user overriding is a temporary solution in README >>> >>> () Move back two readme files back to top dir >>> >>> () Move RMC README to /documentation/rmc/ >>> >>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>> >>> () patches have been squashed >>> >>> () Now any new change of files in a board dir can be effective with a >>> rebuild. >>> >>> () removing tmp dir in build won't cause build issue. (it is uncesesary >>> either) >>> >>> () amend commit messages >>> >>> () amend installation logic in database recipe >>> >> >> It seems to be working in general and I see updates when I change, but I >> seem to be getting extra boot menu items I didn't ask for. >> >> I have a BOOTENTRY.CONFIG with just this: >> >> boot.conf >> >> and in boot.conf: >> >> title NextUnitofComputing Gen3 boot >> linux /vmlinuz >> initrd /initrd >> options LABEL=mybootlabel >> >> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >> two entries before it: >> >> boot >> install >> >> I would expect to see only what I have in my configuration. Or am I >> doing something wrong? >> > Tom, > No, you don’t do anything wrong. It is designed that way. Any boot entry > you pack in RMC are addition to the two default entries “boot” and > “install” which are built from OE. There are different routes to add > entries. > > OE allows user to bring their own boot entries in build > (GUMMIBOOT_ENTRIES), so we should not override these. > > However, we cannot assume which entry should be replaced/overridden at > runtime too because what you see in boot menu is title filed which could > be anything from user. > > User could be confused when he realize there are two boot or install > options, but he can quickly change titles in conf file to differentiate. > Yes, I certainly was confused to see two boot entries. Even if I rename them like you suggest, how do I rename them to avoid confusion for the user i.e. which boot do I use, and if I'm supposed to ignore the other one, why is it there? >>> I think we shouldn’t enforce any naming policy here at this point. This is >>> out of RMC control. Will user complain for confusion caused be another >>> “boot” from a conf file added via the existing GUMMIBOOT_ENTRIES? >>> >> >> You're the one suggesting renaming some to avoid confusing the user >> (because apparently we can't get rid of the two boot entries we didn't >> specify in rmc), nobody mentioned a naming policy. > Sorry if I miss your point. What we are discussing is (a) if titles could be > confusing, or (b) if you have multiple boot entries to boot a board. For the > naming aspect (a), it is totally up to developer or users. For the later case > (b), it could depend on what functionality behind an entry, like “ubuntu > 3.2.6” or “mem-test x86”. I could just say “RMC NUC 6 boot” below a “boot” to > mark it from RMC feature for NUC 6. Is this exact you are concerned? > >> >>> I am not suggesting user to “ignore” other boot entries. I should say RMC >>> just provides another source of boot entries. It is totally up to user for >>> how to provide an entry, what should be in that entry, and eventually >>> which entry to boot system. >>> >> >> Multiple sources of boot entries is just confusing. >> > I don’t think sources are the real problem or I could misunderstand this > comment. I don’t think sources are confusing. The existing > gummiboot/systemd-boot already supports multiple sources, not only reading > conf files from ESP. > >>> If we overrides any entries, I guess we will miss corner cases when people >>> still want to boot a supported target with default settings... >>> >> >> So how can we not make the corner cases drive the default of what most >> users would expect? i.e. make the default be that the user only sees >> the menu entries specified via rmc? with a fallback for the corner case >> users to see the other entries? > > I suggest we don’t guess it for most of users since we don’t have solid data. > But what I could do later is to hack systemd-boot so it won’t load _any_ > entries from disk once RMC entries for the board are available. But that > means you cannot add an new entry and make it effe
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
> On Jul 21, 2016, at 8:13 PM, Tom Zanussi wrote: > > On 07/21/2016 08:05 PM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 2:50 PM, Tom Zanussi >>> wrote: >>> >>> On 07/21/2016 04:35 PM, Jianxun Zhang wrote: > On Jul 21, 2016, at 1:07 PM, Tom Zanussi > wrote: > > On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >>> wrote: >>> >>> Hi Jianxun, >>> >>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: V3 addresses feedbacks for V2, also includes other fixes: () Explicitly tell user overriding is a temporary solution in README () Move back two readme files back to top dir () Move RMC README to /documentation/rmc/ () Replace wrong EFI_PROVIDER info with Distro feature in RMC README () patches have been squashed () Now any new change of files in a board dir can be effective with a rebuild. () removing tmp dir in build won't cause build issue. (it is uncesesary either) () amend commit messages () amend installation logic in database recipe >>> >>> It seems to be working in general and I see updates when I change, but I >>> seem to be getting extra boot menu items I didn't ask for. >>> >>> I have a BOOTENTRY.CONFIG with just this: >>> >>> boot.conf >>> >>> and in boot.conf: >>> >>> title NextUnitofComputing Gen3 boot >>> linux /vmlinuz >>> initrd /initrd >>> options LABEL=mybootlabel >>> >>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >>> two entries before it: >>> >>> boot >>> install >>> >>> I would expect to see only what I have in my configuration. Or am I >>> doing something wrong? >>> >> Tom, >> No, you don’t do anything wrong. It is designed that way. Any boot entry >> you pack in RMC are addition to the two default entries “boot” and >> “install” which are built from OE. There are different routes to add >> entries. >> >> OE allows user to bring their own boot entries in build >> (GUMMIBOOT_ENTRIES), so we should not override these. >> >> However, we cannot assume which entry should be replaced/overridden at >> runtime too because what you see in boot menu is title filed which could >> be anything from user. >> >> User could be confused when he realize there are two boot or install >> options, but he can quickly change titles in conf file to differentiate. >> > > Yes, I certainly was confused to see two boot entries. Even if I rename > them like you suggest, how do I rename them to avoid confusion for the > user i.e. which boot do I use, and if I'm supposed to ignore the other > one, why is it there? I think we shouldn’t enforce any naming policy here at this point. This is out of RMC control. Will user complain for confusion caused be another “boot” from a conf file added via the existing GUMMIBOOT_ENTRIES? >>> >>> You're the one suggesting renaming some to avoid confusing the user >>> (because apparently we can't get rid of the two boot entries we didn't >>> specify in rmc), nobody mentioned a naming policy. >> Sorry if I miss your point. What we are discussing is (a) if titles could be >> confusing, or (b) if you have multiple boot entries to boot a board. For the >> naming aspect (a), it is totally up to developer or users. For the later >> case (b), it could depend on what functionality behind an entry, like >> “ubuntu 3.2.6” or “mem-test x86”. I could just say “RMC NUC 6 boot” below a >> “boot” to mark it from RMC feature for NUC 6. Is this exact you are >> concerned? >> >>> I am not suggesting user to “ignore” other boot entries. I should say RMC just provides another source of boot entries. It is totally up to user for how to provide an entry, what should be in that entry, and eventually which entry to boot system. >>> >>> Multiple sources of boot entries is just confusing. >>> >> I don’t think sources are the real problem or I could misunderstand this >> comment. I don’t think sources are confusing. The existing >> gummiboot/systemd-boot already supports multiple sources, not only reading >> conf files from ESP. >> If we overrides any entries, I guess we will miss corner cases when people still want to boot a supported target with default settings... >>> >>> So how can we not make the corner cases drive the default of what most >>> users would expect? i.e. make the default be that the user only sees >>> the menu entries specified via rmc? with a fallback for the corner case >>> users to see the other entries? >> >> I suggest we don’t guess it for most of users since we do
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
> On Jul 21, 2016, at 4:39 PM, Tom Zanussi wrote: > > On 07/21/2016 06:33 PM, Jianxun Zhang wrote: >> >>> On Jul 21, 2016, at 4:14 PM, Tom Zanussi >>> wrote: >>> >>> On 07/21/2016 06:02 PM, Jianxun Zhang wrote: > On Jul 21, 2016, at 3:41 PM, Tom Zanussi > wrote: > > On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >> Provide a README for RMC feature. Also check in fingerprints and >> configuration data for several boards as examples for users. >> They can be used for validation too. >> >> Signed-off-by: Jianxun Zhang > > [...] > >> + >> +Note 3: >> +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific >> to the >> +board, then tries to fetch each file specified in this config file, and >> then >> +deploy the file onto target with its permissions, UID, GID and other >> attributes >> +also specified in this config file if file for the board can be >> retrieved from >> +RMC database. The format of this file is (# is for comment line) >> + >> +# name:uid:gid:mode:path_on_target >> +# to create a directory, add a “/” at the end of path_on_target: >> +audio_policy:0:0:600:/etc/audio/ >> +audio_def_policy:0:0:600:/etc/audio/audio_policy >> + >> +The first line tells RMC installer to create a directory “audio” in >> /etc. If any >> +parent directory doesn’t exist, installer will create it. The above >> example >> +creates /etc/audio directory first, then fetch a file named >> “audio_def_policy” >> +from RMC database for the board, then copy it to /etc/audio/ with a new >> name >> +“audio_policy”. >> + > > This example explicitly creates the /etc/audio directory first, then the > audio_policy file inside. It seems you're doing this here just as an > example, but when I tried without creating the /etc/audio directory > first, it failed… Great catch! The correct information is in commit msg of installer patch, but not updated in README. :-( Will fix this. >>> >>> So, the fix is to make the code match "If any parent directory doesn’t >>> exist, installer will create it". Seems like that's the right fix.. >> Nope. Developer must explicitly direct installer to create dir for new file >> first. This is because only developer knows FS attributes for dir to be >> created. Code is right but readme is wrong. >> > > Seems like they should be created with default attributes, which they > can of course override by doing it directly - it's very tedious for the > user to manually create each directory otherwise. > Unfortunately, that’s developers destiny. I don’t think there is a default setting fit all situations. Such info can only be from developers. You won’t be able to fix it when rootfs is installed as read-only on target. Developers are paid to get everything right in delivery... BTW, I do have “mkdir -p” ! :-) > Tom > > >> >>> new directory first if destination of a file is in that directory >>> by adding a '/' at the end of a line. >> >> >>> If a rule in config file is to create a directory, installer >>> creates it accordingly. Developer must direct installer to create >>> new directory first if destination of a file is in that directory >>> by adding a '/' at the end of a line. >> >> >> >>> >>> Tom >>> > > Tom > >> +If this config file is not provided, only default entries “boot” and >> “install” >> +from OE are in boot menu. The name of this config file is what >> installer looks >> +up first, so it must be “INSTALLER.CONFIG”. >> + >> + -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
