[meta-intel] [PATCHv5 10/10] rmc: don't install boot entries when RMC entries exist

[Jianxun Zhang]

RMC installer copies RMC entries after copying default entries. But
default entries aren't overwritten when RMC entries have different file
names from them, so they will be kept on target after installation.

RMC Bootloader skips loading default entries when it can get RMC entries
from RMC database file. However, RMC database file isn't deployed onto
target in installation by design.

As a result, default entries show up along with deployed RMC entries once
target reboots after installation.

We cannot get rid of these default entries in RMC deployment section because
it doesn't know which entry file should be removed.

An easier way is not to deploy default entries when any boot entry files
assumingly from RMC are already deployed at a later step. Similar logic
applies to loader.conf too.

Signed-off-by: Jianxun Zhang 
---
 .../initrdscripts/files/init-install-efi.sh| 31 +-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/common/recipes-core/initrdscripts/files/init-install-efi.sh 
b/common/recipes-core/initrdscripts/files/init-install-efi.sh
index 0b2ee46..7148005 100644
--- a/common/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/common/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -208,21 +208,14 @@ fi
 mount $bootfs /boot
 echo "Preparing boot partition..."
 
-# RMC deployment
-RMC_CMD=/src_root/usr/bin/rmc
-RMC_DB=/run/media/$1/rmc.db
-
 EFIDIR="/boot/EFI/BOOT"
 mkdir -p $EFIDIR
-
 # Copy the efi loader
 cp /run/media/$1/EFI/BOOT/*.efi $EFIDIR
 
-# We only support gummiboot/systemd-boot. Leave grub-efi not changed.
-if [ -d /run/media/$1/loader ]; then
-# copy config files for gummiboot
-cp -dr /run/media/$1/loader /boot
-fi
+# RMC deployment
+RMC_CMD=/src_root/usr/bin/rmc
+RMC_DB=/run/media/$1/rmc.db
 
 # We don't want to quit when a step failed. For example,
 # a file system could not support some operations.
@@ -298,9 +291,21 @@ fi
 if [ -d /run/media/$1/loader ]; then
 rootuuid=$(blkid -o value -s PARTUUID ${rootfs})
 GUMMIBOOT_CFGS="/boot/loader/entries/*.conf"
-# delete the install entry
-# fixme: If RMC did deploy install.conf at previous steps, it is purged 
here...
-rm -f /boot/loader/entries/install.conf
+if [ -d /boot/loader ]; then
+# Don't override loader.conf RMC already deployed
+if [ ! -f /boot/loader/loader.conf ]; then
+cp /run/media/$1/loader/loader.conf /boot/loader/
+fi
+# only copy built OE entries when RMC entries don't exist.
+if [ ! -d /boot/loader/entries ] || [ ! ls /boot/loader/entries/*.conf 
&>/dev/null ]; then
+cp -dr /run/media/$1/loader/entries /boot/loader
+fi
+else
+# copy config files for gummiboot
+cp -dr /run/media/$1/loader /boot
+# delete the install entry
+rm -f /boot/loader/entries/install.conf
+fi
 # delete the initrd lines
 sed -i "/initrd /d" $GUMMIBOOT_CFGS
 # delete any LABEL= strings
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCHv5 08/10] rmc: support post-installation hook POSTINSTALL.sh

[Jianxun Zhang]

POSTINSTALL.sh provides developer a final chance to retouch
almost anything deployed on target before unmounting partitions
and reboot at the end of an installation session.

RMC installer executes this script if it can be queried from
RMC database file for the running board.

Some steps to make system bootable still happen after this hook.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-core/initrdscripts/files/init-install-efi.sh | 8 
 1 file changed, 8 insertions(+)

diff --git a/common/recipes-core/initrdscripts/files/init-install-efi.sh 
b/common/recipes-core/initrdscripts/files/init-install-efi.sh
index e12a9d2..0b2ee46 100644
--- a/common/recipes-core/initrdscripts/files/init-install-efi.sh
+++ b/common/recipes-core/initrdscripts/files/init-install-efi.sh
@@ -267,6 +267,14 @@ if [ -f "${RMC_DB}" ] && [ -f "${RMC_CMD}" ]; then
 else
echo "INSTALLER.CONFIG is not found, skip RMC deployment"
 fi
+
+# Final retouching by calling post-install hook
+if ${RMC_CMD} -B POSTINSTALL.sh -d "${RMC_DB}" -o /tmp/POSTINSTALL.sh; then
+echo "Found POSTINSTALL.sh execute it..."
+chmod 500 /tmp/POSTINSTALL.sh
+/tmp/POSTINSTALL.sh
+rm -rf /tmp/POSTINSTALL.sh
+fi
 fi
 set -e
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCHv5 07/10] rmc: support broxton-m platform

[Jianxun Zhang]

Add broxton-m fingerprint and global kernel bootparam fragment
into rmc.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM |   1 +
 common/recipes-bsp/rmc/boards/broxton-m/bm.fp  | Bin 0 -> 83 bytes
 2 files changed, 1 insertion(+)
 create mode 100644 common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
 create mode 100755 common/recipes-bsp/rmc/boards/broxton-m/bm.fp

diff --git a/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM 
b/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
new file mode 100644
index 000..5ad14b4
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
@@ -0,0 +1 @@
+video=efifb maxcpus=4 noxsave reboot=efi kmemleak=off console=ttyS2,115200
diff --git a/common/recipes-bsp/rmc/boards/broxton-m/bm.fp 
b/common/recipes-bsp/rmc/boards/broxton-m/bm.fp
new file mode 100755
index 
..135a7a5dceb99124a5de183edd9c7d071656351b
GIT binary patch
literal 83
zcmZQ%Ehx%QDNQbk&r8frWpFCWuPDjSQ}AVALX`-131(msC`&CW&dkqa2sL&!WThttps://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)

[Jianxun Zhang]

> On Aug 3, 2016, at 4:15 PM, Tom Zanussi  wrote:
> 
> Hi Jianxun,
> 
> On 08/03/2016 01:04 PM, Jianxun Zhang wrote:
>> Hi Saul, Tom & others,
>> 
>> This is the V5 submission of RMC work with new enhancements and fixes over
>> V4 also with some minor adjustments in rmc README file and commit messages.
>> 
> 
> Although I'm a bit dismayed that we seem to have come full circle and
> are back at the EFI_PROVIDER="rmc-systemd-boot" interface, I went ahead
> and merged these 10 patches anyway- it doesn't seem we'll be able to
> make progress toward fleshing out this feature otherwise.

I agree and also feel we are circling on this matter with what we can have now.

() multiple switches are logically predictable if no overriding is allowed. We 
also need to clarify our thoughts on if we really want to have a single feature 
switch in this case.

() What we can do is to seek/improve another interface in OE, not to use 
EFI_PROVIDER for non-bootloader RMC functions like db deployment stuff.


> 
> Please file a bug addressing that interface issue, as well as for the
> other issues we identified along the way and that remain unaddressed.
> 

Yes, I will add this one into bz ticket list I am going to file, just waiting 
their merge (I just don’t feel filing bugs for pending patches make much sense 
technically.)


> The most important ones in addition being:
> 
> - rmc should be useful for all yocto-supported platforms, not just the
> ones in meta-intel.  Because it only supports Intel platforms at the
> moment, and to give it some exposure, it makes sense to have it in
> meta-intel at least initially, but it really should be in oe-core.
> Adding support for other platforms should also help generalize the code
> in the process.  So please file a bug to add support for the other
> platforms and move it out of meta-intel.
> 

I agree with you to push it to OE, just want to be more precisely for supported 
scope even when it is in OE. RMC is based on EFI and SMBIOS so I should say any 
platforms with these FW features should be supported naturally.
We have EFI features in OE already, so this won’t be a blocker. But for other 
arch not with required FW, I am not sure how much RMC could help.

Also sharing my understanding on generating code/file approach in OE, I think 
when people don’t have an alternative solution to manage customizations, they 
need the approach. But I hope we can rethink it when a runtime solution
is on horizon.

I cannot see why providing variables, with logic behind them, to users could be 
better or more flexible than having board-specific files, if the later way can 
managed file copies outside of generic stack. 

I don’t mind you or anyone forward this newbie’s opinion to any OE people, 
seriously. I do have concern on this OE philosophy.

But I will file a ticket so that we can check in these thoughts and 
requirements.


> - there currently is really no way to debug a failing rmc configuration
> or run-time other than by inspection.  There needs to be support in both
> the host and the target to flag invalid configurations and trace what's
> happening at run-time when something goes wrong and it's not apparent
> what the problem is.
> 

RMC is designed as “don’t fail anything at runtime if we don’t fetch board-data 
successfully”. And image with RMC shall be functional on non-supported boards 
in general.

These design goals could be a part of reasons attracting complains.

I will file a ticket for this with others. Let me see what I can improve, no 
worries.


> Thanks,
> 
> Tom
> 
>> I tried my best to keep doc, commit msg and function consistent when we
>> modify the feature's behavior back and forth. Feel free to let me know any-
>> thing out of sync...
>> 
>> Jianxun Zhang (10):
>>  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
>>  rmc: support broxton-m platform
>>  rmc: support post-installation hook POSTINSTALL.sh
>>  rmc: update document and NUC Gen 6 for post-installation hook
>>  rmc: don't install boot entries when RMC entries exist
>> 
>> 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

Re: [meta-intel] [PATCHv5 06/10] rmc: document and examples for RMC feature

[Jianxun Zhang]

> On Aug 4, 2016, at 7:43 AM, Tom Zanussi  wrote:
> 
> On 08/03/2016 01:04 PM, 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 
>> ---
>> .../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   | 343 
>> +
>> 18 files changed, 387 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

Re: [meta-intel] [PATCHv5 06/10] rmc: document and examples for RMC feature

[Jianxun Zhang]

> On Aug 4, 2016, at 10:45 AM, Tom Zanussi  wrote:
> 
> On 08/04/2016 12:39 PM, Jianxun Zhang wrote:
>> 
>>> On Aug 4, 2016, at 7:43 AM, Tom Zanussi  wrote:
>>> 
>>> On 08/03/2016 01:04 PM, 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 
>>>> ---
>>>> .../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   | 343 
>>>> +
>>>> 18 files changed, 387 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

Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)

[Jianxun Zhang]

> On Aug 4, 2016, at 7:31 AM, Tom Zanussi  wrote:
> 
> On 08/03/2016 07:49 PM, Jianxun Zhang wrote:
>> 
>>> On Aug 3, 2016, at 4:15 PM, Tom Zanussi  wrote:
>>> 
>>> Hi Jianxun,
>>> 
>>> On 08/03/2016 01:04 PM, Jianxun Zhang wrote:
>>>> Hi Saul, Tom & others,
>>>> 
>>>> This is the V5 submission of RMC work with new enhancements and fixes over
>>>> V4 also with some minor adjustments in rmc README file and commit messages.
>>>> 
>>> 
>>> Although I'm a bit dismayed that we seem to have come full circle and
>>> are back at the EFI_PROVIDER="rmc-systemd-boot" interface, I went ahead
>>> and merged these 10 patches anyway- it doesn't seem we'll be able to
>>> make progress toward fleshing out this feature otherwise.
>> 
>> I agree and also feel we are circling on this matter with what we can have 
>> now.
>> 
>> () multiple switches are logically predictable if no overriding is allowed. 
>> We also need to clarify our thoughts on if we really want to have a single 
>> feature switch in this case.
>> 
>> () What we can do is to seek/improve another interface in OE, not to use 
>> EFI_PROVIDER for non-bootloader RMC functions like db deployment stuff.
>> 
>> 
>>> 
>>> Please file a bug addressing that interface issue, as well as for the
>>> other issues we identified along the way and that remain unaddressed.
>>> 
>> 
>> Yes, I will add this one into bz ticket list I am going to file, just 
>> waiting their merge (I just don’t feel filing bugs for pending patches make 
>> much sense technically.)
>> 
> 
> All merged, so no need to wait now.  Please add me to the cc: list for
> all the bugs you file related to this, thanks.

Tom,
This is the list of tickets I filed today. The first section is what I 
collected during submission. The later part is for other improvement in RMC and 
test case.
I should have added you in CC list of each of them. But if I missed any, feel 
free to add yourself. Please also add comments for anything inaccurately 
reflects our discussion.

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10081
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10083
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10084
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10085

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10086
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10087
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10088
https://bugzilla.yoctoproject.org/show_bug.cgi?id=10089

I appreciate your effort on RMC review and merge, and specially enjoy our good 
discussion in these threads.


> 
>> 
>>> The most important ones in addition being:
>>> 
>>> - rmc should be useful for all yocto-supported platforms, not just the
>>> ones in meta-intel.  Because it only supports Intel platforms at the
>>> moment, and to give it some exposure, it makes sense to have it in
>>> meta-intel at least initially, but it really should be in oe-core.
>>> Adding support for other platforms should also help generalize the code
>>> in the process.  So please file a bug to add support for the other
>>> platforms and move it out of meta-intel.
>>> 
>> 
>> I agree with you to push it to OE, just want to be more precisely for 
>> supported scope even when it is in OE. RMC is based on EFI and SMBIOS so I 
>> should say any platforms with these FW features should be supported 
>> naturally.
>> We have EFI features in OE already, so this won’t be a blocker. But for 
>> other arch not with required FW, I am not sure how much RMC could help.
>> 
> 
> Well, the first step as implemented here requires those things.  But
> surely the general idea of tailoring images based on fingerprints
> generalizes to other platforms.
> 
>> Also sharing my understanding on generating code/file approach in OE, I 
>> think when people don’t have an alternative solution to manage 
>> customizations, they need the approach. But I hope we can rethink it when a 
>> runtime solution
>> is on horizon.
>> 
>> I cannot see why providing variables, with logic behind them, to users could 
>> be better or more flexible than having board-specific files, if the later 
>> way can managed file copies outside of generic stack. 
>> 
>> I don’t mind you or anyone forward this newbie’s opinion to any OE people, 
>> seriously. I do have concern on this OE philosophy.
>> 
>> But I will file a ticket so that we can check in these thoughts and 
>> requirements.
>>

Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)

[Jianxun Zhang]

> On Aug 4, 2016, at 2:26 PM, Tom Zanussi  wrote:
> 
> On 08/04/2016 04:11 PM, Jianxun Zhang wrote:
>> 
>>> On Aug 4, 2016, at 7:31 AM, Tom Zanussi  wrote:
>>> 
>>> On 08/03/2016 07:49 PM, Jianxun Zhang wrote:
>>>> 
>>>>> On Aug 3, 2016, at 4:15 PM, Tom Zanussi  
>>>>> wrote:
>>>>> 
>>>>> Hi Jianxun,
>>>>> 
>>>>> On 08/03/2016 01:04 PM, Jianxun Zhang wrote:
>>>>>> Hi Saul, Tom & others,
>>>>>> 
>>>>>> This is the V5 submission of RMC work with new enhancements and fixes 
>>>>>> over
>>>>>> V4 also with some minor adjustments in rmc README file and commit 
>>>>>> messages.
>>>>>> 
>>>>> 
>>>>> Although I'm a bit dismayed that we seem to have come full circle and
>>>>> are back at the EFI_PROVIDER="rmc-systemd-boot" interface, I went ahead
>>>>> and merged these 10 patches anyway- it doesn't seem we'll be able to
>>>>> make progress toward fleshing out this feature otherwise.
>>>> 
>>>> I agree and also feel we are circling on this matter with what we can have 
>>>> now.
>>>> 
>>>> () multiple switches are logically predictable if no overriding is 
>>>> allowed. We also need to clarify our thoughts on if we really want to have 
>>>> a single feature switch in this case.
>>>> 
>>>> () What we can do is to seek/improve another interface in OE, not to use 
>>>> EFI_PROVIDER for non-bootloader RMC functions like db deployment stuff.
>>>> 
>>>> 
>>>>> 
>>>>> Please file a bug addressing that interface issue, as well as for the
>>>>> other issues we identified along the way and that remain unaddressed.
>>>>> 
>>>> 
>>>> Yes, I will add this one into bz ticket list I am going to file, just 
>>>> waiting their merge (I just don’t feel filing bugs for pending patches 
>>>> make much sense technically.)
>>>> 
>>> 
>>> All merged, so no need to wait now.  Please add me to the cc: list for
>>> all the bugs you file related to this, thanks.
>> 
>> Tom,
>> This is the list of tickets I filed today. The first section is what I 
>> collected during submission. The later part is for other improvement in RMC 
>> and test case.
>> I should have added you in CC list of each of them. But if I missed any, 
>> feel free to add yourself. Please also add comments for anything 
>> inaccurately reflects our discussion.
>> 
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10081
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10083
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10084
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10085
>> 
> 
> Looks ok, but I think there are a couple things missing, mainly the
> interface issue we keep going around in circles on, and there's
> something about detecting errors at build-time, but nothing about runtime.
> 
I think interface issue is captured in 10084. It decouples RMC with 
EFI_PROVIDER. But please feel free to file another bug if I get lost in 
circling.

The installer show deployment information in console. I don’t think bootloader 
should fail or toss warning message when there is no data or db for a board.  
Or are you suggesting anything else? Please feel free to assign me a ticket as 
a following up.

> There are also minor things that were touched on, such as the complete
> copy of the installer from oe-core, and forcing the user to specify each
> part of the path individually to create a file in the installer, etc.
> 
10085 implicitly covers installer's copy topic. There will be no copy or patch 
of installer in meta-intel once RMC is in OE.

I have explained why developers have to specify path for each file and shall 
not delegate this work to RMC (Thread "Re: [meta-intel] [PATCHv3 6/6] rmc: 
document and examples for RMC feature”)

I think you didn’t bother this before just because you don’t care it and assume 
“default” attribute of what copied to a target’s partition are always “right”. 
With the existing OE installer, how does user specify
a FS attribute not default during installation, specifically when rootfs is 
read-only? This should be a generic topic, not RMC-specific.



> Tom
> 
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10086
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10087
>> https://bugzilla.yoctoproject.org/show_bug.cgi?

Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)

[Jianxun Zhang]

> On Aug 4, 2016, at 3:55 PM, Tom Zanussi  wrote:
> 
> On 08/04/2016 05:41 PM, Jianxun Zhang wrote:
>> 
>>> On Aug 4, 2016, at 2:26 PM, Tom Zanussi  wrote:
>>> 
>>> On 08/04/2016 04:11 PM, Jianxun Zhang wrote:
>>>> 
>>>>> On Aug 4, 2016, at 7:31 AM, Tom Zanussi  
>>>>> wrote:
>>>>> 
>>>>> On 08/03/2016 07:49 PM, Jianxun Zhang wrote:
>>>>>> 
>>>>>>> On Aug 3, 2016, at 4:15 PM, Tom Zanussi  
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi Jianxun,
>>>>>>> 
>>>>>>> On 08/03/2016 01:04 PM, Jianxun Zhang wrote:
>>>>>>>> Hi Saul, Tom & others,
>>>>>>>> 
>>>>>>>> This is the V5 submission of RMC work with new enhancements and fixes 
>>>>>>>> over
>>>>>>>> V4 also with some minor adjustments in rmc README file and commit 
>>>>>>>> messages.
>>>>>>>> 
>>>>>>> 
>>>>>>> Although I'm a bit dismayed that we seem to have come full circle and
>>>>>>> are back at the EFI_PROVIDER="rmc-systemd-boot" interface, I went ahead
>>>>>>> and merged these 10 patches anyway- it doesn't seem we'll be able to
>>>>>>> make progress toward fleshing out this feature otherwise.
>>>>>> 
>>>>>> I agree and also feel we are circling on this matter with what we can 
>>>>>> have now.
>>>>>> 
>>>>>> () multiple switches are logically predictable if no overriding is 
>>>>>> allowed. We also need to clarify our thoughts on if we really want to 
>>>>>> have a single feature switch in this case.
>>>>>> 
>>>>>> () What we can do is to seek/improve another interface in OE, not to use 
>>>>>> EFI_PROVIDER for non-bootloader RMC functions like db deployment stuff.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Please file a bug addressing that interface issue, as well as for the
>>>>>>> other issues we identified along the way and that remain unaddressed.
>>>>>>> 
>>>>>> 
>>>>>> Yes, I will add this one into bz ticket list I am going to file, just 
>>>>>> waiting their merge (I just don’t feel filing bugs for pending patches 
>>>>>> make much sense technically.)
>>>>>> 
>>>>> 
>>>>> All merged, so no need to wait now.  Please add me to the cc: list for
>>>>> all the bugs you file related to this, thanks.
>>>> 
>>>> Tom,
>>>> This is the list of tickets I filed today. The first section is what I 
>>>> collected during submission. The later part is for other improvement in 
>>>> RMC and test case.
>>>> I should have added you in CC list of each of them. But if I missed any, 
>>>> feel free to add yourself. Please also add comments for anything 
>>>> inaccurately reflects our discussion.
>>>> 
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10081
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10083
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10084
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10085
>>>> 
>>> 
>>> Looks ok, but I think there are a couple things missing, mainly the
>>> interface issue we keep going around in circles on, and there's
>>> something about detecting errors at build-time, but nothing about runtime.
>>> 
>> I think interface issue is captured in 10084. It decouples RMC with 
>> EFI_PROVIDER. But please feel free to file another bug if I get lost in 
>> circling.
>> 
>> The installer show deployment information in console. I don’t think 
>> bootloader should fail or toss warning message when there is no data or db 
>> for a board.  Or are you suggesting anything else? Please feel free to 
>> assign me a ticket as a following up.
>> 
> 
> You modify the bootloader to call libraries to gather data from the
> board and query the rmc db.  The libraries and the database itself can
> be buggy or corrupt, and cause unintended failures.  How does the user
> differentiate a failure from these causes vs an expected lack of
> configuration?

We start troubleshoot SW

[meta-intel] [PATCH 1/2] rmc: explicitly specify hash style for linker

[Jianxun Zhang]

QA sanity checker in OE fails when an ELF binary has symbol
table without GNU hash.

There is no issue so far because rmc is statically linked
with C libraries and symbol table is stripped out in build.

But once we compile rmc with dynamic linking, the symbol table
in dynamic section stays. Thus it fails QA checker for the
default of hash style is sysv.

To have some peace of mind, we specify "both" for hash style
to linker this time.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-bsp/rmc/rmc.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
index d8e538b..d77ad31 100644
--- a/common/recipes-bsp/rmc/rmc.bb
+++ b/common/recipes-bsp/rmc/rmc.bb
@@ -20,6 +20,8 @@ S = "${WORKDIR}/git"
 
 DEPENDS_class-target = "gnu-efi"
 
+EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
+
 # from gnu-efi, we should align arch-mapping with it.
 def rmc_efi_arch(d):
 import re
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 2/2] rmc: update revision of rmc project

[Jianxun Zhang]

New changes in the upstream rmc project are:

2e38d05 Merge branch 'rmc-dev' (Aug 30 2016)
a1a4a26 Makefile: remove static linking in Linux build
b22169a doc: update README file
29e943d Merge branch 'rmc-dev' (Aug 24 2016)
fc2fb1e rmc: fix allocating buffer issue in read_file() (32 bit)
38b0553 rmc: fix wrong error message
7ee67a0 test: Provide test scripts and sample data

Signed-off-by: Jianxun Zhang 
---
 common/recipes-bsp/rmc/rmc.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
index d77ad31..9b87dd5 100644
--- a/common/recipes-bsp/rmc/rmc.bb
+++ b/common/recipes-bsp/rmc/rmc.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=838c366f69b72c5df05c96dff79b35f2"
 
 SRC_URI = "git://git.yoctoproject.org/rmc"
 
-SRCREV = "9bc0f645729bb41e050395fbfac170fca351b3b8"
+SRCREV = "2e38d056f86c0457f3a5ca7ef848545bbb190e47"
 
 S = "${WORKDIR}/git"
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 0/2] rmc: update revision

[Jianxun Zhang]

The first patch is necessary to build rmc with new revision becauase
the upstream rmc project doesn't force static linking anymore.

Basic test is done with rmc exampled in meta-intel.

Thanks

Jianxun Zhang (2):
  rmc: explicitly specify hash style for linker
  rmc: update revision of rmc project

 common/recipes-bsp/rmc/rmc.bb | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/2] intel-corei7-64: add machine configurations specific to leafhill bsp

[Jianxun Zhang]

I just provide my comment in lines on console stuff from RMC perspective.

Thanks

> On Sep 6, 2016, at 11:21 AM, Cal Sullivan  
> wrote:
> 
> 
> 
> On 09/06/2016 10:43 AM, Saul Wold wrote:
>> On Mon, 2016-09-05 at 14:18 +0800, Rebecca Chang Swee Fun wrote:
>>> We would like to enable new BSP for Intel Atom E3900 SoC based
>>> platforms.
>>> This will help us to consolidate BSP into intel-common and we can use
>>> KERNEL_FEATURES to select target BSP to compile.
>>> 
>>> Leaf Hill uses different serial console port setup. Hence this
I have a questions on the “boards” derived from a SoC "platform". Are we 
expecting all boards based on this SoC will have identical console or any 
settings hardcoded here?
>>> mechanism are in place to enable new bsp with existing machine
>>> configurations file.
>>> 
>>> Leaf Hill BSP also required additional kernel stack protector
>>> settings to compile kernel with security defense enabled.
>>> 
>> Is this for Jethro, Kroghoth, master?
>> 
>> more comments below
>> 
>>> Signed-off-by: Rebecca Chang Swee Fun
>>> 
>>> ---
>>>  conf/machine/intel-corei7-64.conf | 9 ++---
>>>  1 file changed, 6 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/conf/machine/intel-corei7-64.conf b/conf/machine/intel-
>>> corei7-64.conf
>>> index cc16d62..7a5b400 100644
>>> --- a/conf/machine/intel-corei7-64.conf
>>> +++ b/conf/machine/intel-corei7-64.conf
>>> @@ -29,6 +29,9 @@ XSERVER ?= "${XSERVER_X86_BASE} \
>>>  ${XSERVER_X86_VESA} \
>>> "
>>>  -SYSLINUX_OPTS = "serial 0 115200"
>>> -SERIAL_CONSOLE = "115200 ttyS0"
>>> -APPEND += "console=ttyS0,115200 console=tty0"
>>> +SYSLINUX_OPTS = "serial ${@bb.utils.contains('KERNEL_FEATURES',
>>> 'leafhill', '2', '0', d)} 115200"
>>> +SERIAL_CONSOLE = "115200 ${@bb.utils.contains('KERNEL_FEATURES',
>>> 'leafhill', 'ttyS2', 'ttyS0', d)}"
>> Can we not use the SERIAL_CONSOLES = "115200,ttyS2 115200,ttyS0"
>> variable here instead?
> 
> I think doing a switch based on KERNEL_FEATURES doesn't scale well and makes 
> things a lot less readable.

> We can also do this:
> 
> SERIAL_CONSOLES = "115200,ttyS2 115200,ttyS0"
> SERIAL_CONSOLES_CHECK = "ttyS2 ttyS0"
> 
> This should stop getty from trying to enable non-existent serial consoles, 
> stopping the annoying "trying to respawn" warning we would get every five 
> minutes otherwise.
NUC Gen 6 example in rmc dir fixed a similar issue by modifying inittab in 
_installation_ time for a specific board, so you don’t need to specify OE 
variables for a board conf.
> 
> 
>> 
>>> +APPEND += "${@bb.utils.contains('KERNEL_FEATURES', 'leafhill',
>>> 'console=ttyS2,115200n8', 'console=ttyS0,115200', d)} console=tty0"
>>> +APPEND += "${@bb.utils.contains('KERNEL_FEATURES', 'leafhill',
>>> 'reboot=efi kmemleak=off i915.enable_ipc=1', '', d)}"
>> So the console settings I understand, but I think we can set multiple
>> consoles on the command line.
> Yep, multiple consoles in APPEND is fine. We do it in core2 already.

I think it is another twist following the traditional build-time approach, same 
as to put these in a board conf file. If we enable RMC and check in all 
supported later, we won’t need APPEND very much for board-specifc 
differentiations.

But if you do need a different kernel config or compiling flag , that’s another 
story.
>> 
>> Moving forward for 2.2 and beyond, you should start learning about the
>> "Runtime Machine Config" RMC that was recently introduced into meta-
>> intel for 2.2
>> 
>>> +
>>> +KERNEL_EXTRA_ARGS = "${@bb.utils.contains('KERNEL_FEATURES',
>>> 'leafhill', 'EXTRA_CFLAGS="-D_FORTIFY_SOURCE=2 -Wformat -O2 -Wformat-
>>> security"', '', d)}"
>> Do we really need to change the CFLAGS here?  Would the be appropriate
>> for all kernels moving forward?  These seem more like product quality
>> or maybe distro related CFLAGS than BSP generic flags.
>> 
>> We want to keep the difference between a non-intel-core* bsp and the
>> intel-core* bsps to a minimum, this will always guarantee they are
>> different
> Agree here.
> 
> ---
> Cal
>> Sau!
>> 
> 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] IGT: update 1.14 -> 1.15

[Jianxun Zhang]

This change update intel-gpu-tools to 1.15 as a sync-up with
Intel graphic stack 2016 Q2 release.

This change explicitly sets ${PV} in recipe and renames it
after package name only. By doing so we don't need to enforce
a policy to rename recipe every time we do update. Patch
speaks itself.

${PV} and checksums shall be updated together. When either
checksums or ${PV} is forgotten to update, developers will
get a build error as a heads-up. This is because graphic base
in OE fetches source with ${PV}.

Signed-off-by: Jianxun Zhang 
---
Rough test is done by cherry-picking some IGT tools and tests.
I still need to hack piglit to run IGT test as an authentic test
approach, but I will address this with another patch to OE.

 .../intel-gpu-tools/{intel-gpu-tools_1.14.bb => intel-gpu-tools.bb} | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)
 rename common/recipes-graphics/intel-gpu-tools/{intel-gpu-tools_1.14.bb => 
intel-gpu-tools.bb} (88%)

diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb 
b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools.bb
similarity index 88%
rename from common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
rename to common/recipes-graphics/intel-gpu-tools/intel-gpu-tools.bb
index c20ce31..64cc612 100644
--- a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
+++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools.bb
@@ -15,8 +15,10 @@ RDEPENDS_${PN}-tests += "bash"
 
 PACKAGE_BEFORE_PN = "${PN}-benchmarks ${PN}-tests"
 
-SRC_URI[md5sum] = "b09d69526c86174007bea2228e36b2f1"
-SRC_URI[sha256sum] = 
"3596e1d36e9c1203eed5abff5a0f272d573f4eb917b5cee4f029cce5a70a0f0c"
+PV = "1.15"
+
+SRC_URI[md5sum] = "dea5d3a60f93054760d773aaa3a36b1f"
+SRC_URI[sha256sum] = 
"dcf256112d2692aa49ce6c6d17a898f60b3709b98c2f1c4592b23d22371462bd"
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[libunwind] = 
"--with-libunwind,--without-libunwind,libunwind,libunwind"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] IGT: update 1.14 -> 1.15

[Jianxun Zhang]

> On Sep 9, 2016, at 7:34 AM, Saul Wold  wrote:
> 
> On Thu, 2016-09-08 at 17:02 -0700, Jianxun Zhang wrote:
>> 
>> This change update intel-gpu-tools to 1.15 as a sync-up with
>> Intel graphic stack 2016 Q2 release.
>> 
>> This change explicitly sets ${PV} in recipe and renames it
>> after package name only. By doing so we don't need to enforce
>> a policy to rename recipe every time we do update. Patch
>> speaks itself.
>> 
> This is wrong!  
> 
> The whole point of naming the recipe as ${PN}_${PV} is to remove the
> need to update PV in the recipe.
> 
> Yes checksums need to be updated on a regular basis, there are tools
> like devtool that can assist with this.
> 
> The OpenEmbedded standard is for $PN_$PV.bb filename this also assists
> in understand quickly what version a particular recipe is.  There are
> also limited cases where 2 different $PVs are needed for some reasons.
> 
> Please resubmit this as a normal update with $PV contained in the file
> name.
> 
> Please see: https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs
> )_for_Package_Updating
Saul,
I think the drawback of current procedure is it causes git “resets" history on 
recipe since new recipe when a renamed or git mv-ed recipe also have too much 
modifications. I don’t think git really tracks moving or renaming:

This is what I did with wiki procedure:

mkdir gmtest
cd gmtest
git init
echo "file 1" > file
git add .
#/ now we have old recipe:
git commit -s -m "commit 1”
# lets update it, following wiki:
git mv file file_new
git status
# modify renamed new recipe:
echo "file 2" > file_new
git status
git diff
git add .
# git won’t show renaming info because of similarity
git commit -s -m "commit 2”
# git wont’ show commit #1 for old recipe - chopped history:
git log file_new
# git won’t have renaming info in final patch:
git format-patch -M -1
# and you can’t run this with tip at commit #2 for the old
git log file

Thanks

> 
> Thanks 
>Sau!
> 
> 
>> 
>> ${PV} and checksums shall be updated together. When either
>> checksums or ${PV} is forgotten to update, developers will
>> get a build error as a heads-up. This is because graphic base
>> in OE fetches source with ${PV}.
>> 
>> Signed-off-by: Jianxun Zhang 
>> ---
>> Rough test is done by cherry-picking some IGT tools and tests.
>> I still need to hack piglit to run IGT test as an authentic test
>> approach, but I will address this with another patch to OE.
>> 
>>  .../intel-gpu-tools/{intel-gpu-tools_1.14.bb => intel-gpu-tools.bb}
>>> 
>>> 6 --
>>  1 file changed, 4 insertions(+), 2 deletions(-)
>>  rename common/recipes-graphics/intel-gpu-tools/{intel-gpu-
>> tools_1.14.bb => intel-gpu-tools.bb} (88%)
>> 
>> diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools_1.14.bb b/common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools.bb
>> similarity index 88%
>> rename from common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools_1.14.bb
>> rename to common/recipes-graphics/intel-gpu-tools/intel-gpu-tools.bb
>> index c20ce31..64cc612 100644
>> --- a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
>> +++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools.bb
>> @@ -15,8 +15,10 @@ RDEPENDS_${PN}-tests += "bash"
>>  
>>  PACKAGE_BEFORE_PN = "${PN}-benchmarks ${PN}-tests"
>>  
>> -SRC_URI[md5sum] = "b09d69526c86174007bea2228e36b2f1"
>> -SRC_URI[sha256sum] =
>> "3596e1d36e9c1203eed5abff5a0f272d573f4eb917b5cee4f029cce5a70a0f0c"
>> +PV = "1.15"
>> +
>> +SRC_URI[md5sum] = "dea5d3a60f93054760d773aaa3a36b1f"
>> +SRC_URI[sha256sum] =
>> "dcf256112d2692aa49ce6c6d17a898f60b3709b98c2f1c4592b23d22371462bd"
>>  
>>  PACKAGECONFIG ??= ""
>>  PACKAGECONFIG[libunwind] = "--with-libunwind,--without-
>> libunwind,libunwind,libunwind"
>> -- 
>> 2.7.4
>> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] IGT: update 1.14 -> 1.15

[Jianxun Zhang]

On Sep 11, 2016, at 1:17 PM, Paul Eggleton  
wrote:
> 
> Hi Jianxin,
> 
> On Fri, 09 Sep 2016 10:50:50 Jianxun Zhang wrote:
>>> On Sep 9, 2016, at 7:34 AM, Saul Wold  wrote:
>>> On Thu, 2016-09-08 at 17:02 -0700, Jianxun Zhang wrote:
>>>> This change update intel-gpu-tools to 1.15 as a sync-up with
>>>> Intel graphic stack 2016 Q2 release.
>>>> 
>>>> This change explicitly sets ${PV} in recipe and renames it
>>>> after package name only. By doing so we don't need to enforce
>>>> a policy to rename recipe every time we do update. Patch
>>>> speaks itself.
>>> 
>>> This is wrong!
>>> 
>>> The whole point of naming the recipe as ${PN}_${PV} is to remove the
>>> need to update PV in the recipe.
>>> 
>>> Yes checksums need to be updated on a regular basis, there are tools
>>> like devtool that can assist with this.
>>> 
>>> The OpenEmbedded standard is for $PN_$PV.bb filename this also assists
>>> in understand quickly what version a particular recipe is.  There are
>>> also limited cases where 2 different $PVs are needed for some reasons.
>>> 
>>> Please resubmit this as a normal update with $PV contained in the file
>>> name.
>>> 
>>> Please see: https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs
>>> )_for_Package_Updating
>> 
>> Saul,
>> I think the drawback of current procedure is it causes git “resets" history
>> on recipe since new recipe when a renamed or git mv-ed recipe also have too
>> much modifications. I don’t think git really tracks moving or renaming:
> 
> It doesn't reset history. You're right that it doesn't track renames - that's 
> because rename detection is done whenever git looks at a change, not when the 
> change is applied. If you want to see the full history including renames, use 
> the --follow option.
Paul,
I just come back from a vacation and run "git log --follow new_renamed_file" in 
the test project created with procedure in my previous reply. It doesn’t show 
history before renaming the file in that case.
The procedure simulates a routine update (renaming & modifying recipe in a 
single commit) but won’t always give the expected result in git history. I 
think the first half of your comment could be the answer. git doesn’t   track 
rename, so --follow should not have more magic in this case.

> 
> Saul is correct, use of PV in the recipe filename is standard OE practice and 
> we don't want to be deviating from that - besides which I'm not sure we have 
> much to gain by doing so.

If you defined this as a standard in OE universe, no more argument is needed. I 
just want to point out any inconsistent outcome from the standard practice  
which may be out of expectation sometimes, assuming my test is valid.

Last time I followed the policy to use git mv and submit a patch to update a 
short recipe in meta-intel, we had same confusion when Saul didn’t see renaming 
info in patch in review. (I can’t remember which recipe however).

I will submit a V2 back to normal.

Thanks lot!

> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2] IGT: update 1.14 -> 1.15

[Jianxun Zhang]

This change updates intel-gpu-tools to 1.15 which is in Intel
graphic stack 2016 Q2 release.

Signed-off-by: Jianxun Zhang 
---
The V2 renames recipe file name as an OE standard practice.

 .../{intel-gpu-tools_1.14.bb => intel-gpu-tools_1.15.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename common/recipes-graphics/intel-gpu-tools/{intel-gpu-tools_1.14.bb => 
intel-gpu-tools_1.15.bb} (89%)

diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb 
b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.15.bb
similarity index 89%
rename from common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
rename to common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.15.bb
index c20ce31..03fcbc7 100644
--- a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
+++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.15.bb
@@ -15,8 +15,8 @@ RDEPENDS_${PN}-tests += "bash"
 
 PACKAGE_BEFORE_PN = "${PN}-benchmarks ${PN}-tests"
 
-SRC_URI[md5sum] = "b09d69526c86174007bea2228e36b2f1"
-SRC_URI[sha256sum] = 
"3596e1d36e9c1203eed5abff5a0f272d573f4eb917b5cee4f029cce5a70a0f0c"
+SRC_URI[md5sum] = "dea5d3a60f93054760d773aaa3a36b1f"
+SRC_URI[sha256sum] = 
"dcf256112d2692aa49ce6c6d17a898f60b3709b98c2f1c4592b23d22371462bd"
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[libunwind] = 
"--with-libunwind,--without-libunwind,libunwind,libunwind"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH V2] IGT: update 1.14 -> 1.15

[Jianxun Zhang]

Sure, Saul.
I just found Q3 has been released last week. I will roll this in a series for 
Q3.

Thanks

> On Sep 26, 2016, at 3:09 PM, Saul Wold  wrote:
> 
> 
> In the future can you please use the non-abbreviated intel-gpu-tools, I
> hade not really noticed this the first time, I have fixed it locally
> this time.
> 
> Thanks
> Sau!
> 
> On Mon, 2016-09-26 at 14:54 -0700, Jianxun Zhang wrote:
>> This change updates intel-gpu-tools to 1.15 which is in Intel
>> graphic stack 2016 Q2 release.
>> 
>> Signed-off-by: Jianxun Zhang 
>> ---
>> The V2 renames recipe file name as an OE standard practice.
>> 
>>  .../{intel-gpu-tools_1.14.bb => intel-gpu-
>> tools_1.15.bb}  | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>  rename common/recipes-graphics/intel-gpu-tools/{intel-gpu-
>> tools_1.14.bb => intel-gpu-tools_1.15.bb} (89%)
>> 
>> diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools_1.14.bb b/common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools_1.15.bb
>> similarity index 89%
>> rename from common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools_1.14.bb
>> rename to common/recipes-graphics/intel-gpu-tools/intel-gpu-
>> tools_1.15.bb
>> index c20ce31..03fcbc7 100644
>> --- a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
>> +++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.15.bb
>> @@ -15,8 +15,8 @@ RDEPENDS_${PN}-tests += "bash"
>>  
>>  PACKAGE_BEFORE_PN = "${PN}-benchmarks ${PN}-tests"
>>  
>> -SRC_URI[md5sum] = "b09d69526c86174007bea2228e36b2f1"
>> -SRC_URI[sha256sum] =
>> "3596e1d36e9c1203eed5abff5a0f272d573f4eb917b5cee4f029cce5a70a0f0c"
>> +SRC_URI[md5sum] = "dea5d3a60f93054760d773aaa3a36b1f"
>> +SRC_URI[sha256sum] =
>> "dcf256112d2692aa49ce6c6d17a898f60b3709b98c2f1c4592b23d22371462bd"
>>  
>>  PACKAGECONFIG ??= ""
>>  PACKAGECONFIG[libunwind] = "--with-libunwind,--without-
>> libunwind,libunwind,libunwind"
>> -- 
>> 2.7.4
>> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 2/3] libva: update 1.7.0 -> 1.7.2

[Jianxun Zhang]

This change updates libva to 1.7.2 which is in Intel graphic stack
2016 Q3 release.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-multimedia/libva/{libva_1.7.0.bb => libva_1.7.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename common/recipes-multimedia/libva/{libva_1.7.0.bb => libva_1.7.2.bb} (93%)

diff --git a/common/recipes-multimedia/libva/libva_1.7.0.bb 
b/common/recipes-multimedia/libva/libva_1.7.2.bb
similarity index 93%
rename from common/recipes-multimedia/libva/libva_1.7.0.bb
rename to common/recipes-multimedia/libva/libva_1.7.2.bb
index d6eb1ed..d72074d 100644
--- a/common/recipes-multimedia/libva/libva_1.7.0.bb
+++ b/common/recipes-multimedia/libva/libva_1.7.2.bb
@@ -19,8 +19,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=2e48940f94acb0af582e5ef03537800f"
 
 SRC_URI = 
"http://www.freedesktop.org/software/vaapi/releases/libva/${BP}.tar.bz2";
 
-SRC_URI[md5sum] = "7309097b790de8dbc9641ed6393eab9f"
-SRC_URI[sha256sum] = 
"a689bccbcc81a66b458e448377f108c057d3eee44a2e21a23c92c549dc8bc95f"
+SRC_URI[md5sum] = "77d30af5a4bfaec6dddc2bdcbbd92ef5"
+SRC_URI[sha256sum] = 
"5dd61cf16a5648b680e6146a58064e93be11bf4e65a9e4e30f1e9cb8ecfa2c13"
 
 DEPENDS = "libdrm virtual/mesa virtual/libgles1 virtual/libgles2 virtual/egl"
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 0/3] Update to 2016 Q3 Intel graphic release

[Jianxun Zhang]

This series updates several projects in meta-intel to the
versions in Q3 graphic release.

For other updated projects in OE this time, I only see cairo
1.14.6 is behind 1.15.2 in Q3. Kernel version is not included.

Thanks

Jianxun Zhang (3):
  intel-gpu-tools: update 1.14 -> 1.16
  libva: update 1.7.0 -> 1.7.2
  libva-intel-driver: update 1.7.0 -> 1.7.2

 .../{intel-gpu-tools_1.14.bb => intel-gpu-tools_1.16.bb}  | 4 ++--
 .../{libva-intel-driver_1.7.0.bb => libva-intel-driver_1.7.2.bb}  | 4 ++--
 common/recipes-multimedia/libva/{libva_1.7.0.bb => libva_1.7.2.bb}| 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename common/recipes-graphics/intel-gpu-tools/{intel-gpu-tools_1.14.bb => 
intel-gpu-tools_1.16.bb} (89%)
 rename common/recipes-multimedia/libva/{libva-intel-driver_1.7.0.bb => 
libva-intel-driver_1.7.2.bb} (87%)
 rename common/recipes-multimedia/libva/{libva_1.7.0.bb => libva_1.7.2.bb} (93%)

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 1/3] intel-gpu-tools: update 1.14 -> 1.16

[Jianxun Zhang]

This change updates intel-gpu-tools to 1.16 which is in Intel
graphic stack 2016 Q3 release.

Signed-off-by: Jianxun Zhang 
---
 .../{intel-gpu-tools_1.14.bb => intel-gpu-tools_1.16.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename common/recipes-graphics/intel-gpu-tools/{intel-gpu-tools_1.14.bb => 
intel-gpu-tools_1.16.bb} (89%)

diff --git a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb 
b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.16.bb
similarity index 89%
rename from common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
rename to common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.16.bb
index c20ce31..f1f643b 100644
--- a/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb
+++ b/common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.16.bb
@@ -15,8 +15,8 @@ RDEPENDS_${PN}-tests += "bash"
 
 PACKAGE_BEFORE_PN = "${PN}-benchmarks ${PN}-tests"
 
-SRC_URI[md5sum] = "b09d69526c86174007bea2228e36b2f1"
-SRC_URI[sha256sum] = 
"3596e1d36e9c1203eed5abff5a0f272d573f4eb917b5cee4f029cce5a70a0f0c"
+SRC_URI[md5sum] = "95ae60c2c0e56736273edc406f8277c8"
+SRC_URI[sha256sum] = 
"c6be6d8311a939dd7ebb4639a2605bdbe711a4d3c77c8273a83f2050c2723ae1"
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[libunwind] = 
"--with-libunwind,--without-libunwind,libunwind,libunwind"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 3/3] libva-intel-driver: update 1.7.0 -> 1.7.2

[Jianxun Zhang]

This change updates libva-intel-driver to 1.7.2 which is in Intel
graphic stack 2016 Q3 release.

Signed-off-by: Jianxun Zhang 
---
 .../{libva-intel-driver_1.7.0.bb => libva-intel-driver_1.7.2.bb}  | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename common/recipes-multimedia/libva/{libva-intel-driver_1.7.0.bb => 
libva-intel-driver_1.7.2.bb} (87%)

diff --git a/common/recipes-multimedia/libva/libva-intel-driver_1.7.0.bb 
b/common/recipes-multimedia/libva/libva-intel-driver_1.7.2.bb
similarity index 87%
rename from common/recipes-multimedia/libva/libva-intel-driver_1.7.0.bb
rename to common/recipes-multimedia/libva/libva-intel-driver_1.7.2.bb
index 403329b..f82e9d7 100644
--- a/common/recipes-multimedia/libva/libva-intel-driver_1.7.0.bb
+++ b/common/recipes-multimedia/libva/libva-intel-driver_1.7.2.bb
@@ -15,8 +15,8 @@ DEPENDS = "libva libdrm"
 
 SRC_URI = 
"http://www.freedesktop.org/software/vaapi/releases/${BPN}/${BPN}-${PV}.tar.bz2";
 
-SRC_URI[md5sum] = "00619c393e0c9c74b205d9adf69b68db"
-SRC_URI[sha256sum] = 
"9d19d6c789a9a4fbce23c4f0eaf993ba776b512bec4c87982ab17ac841435c0c"
+SRC_URI[md5sum] = "f28ac265f836f7ce881305bd3a282c90"
+SRC_URI[sha256sum] = 
"099e7bf6aa826971ec2caff235babf4da995f754e2ca16a73b258671130e67bc"
 
 inherit autotools pkgconfig
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] purge console settings in core2 and corei7 conf files

[Jianxun Zhang]

These arch-like conf files are actually used as generic
configurations for multiple x86 boards.

Serial console settings are board-specific so there is no
such a perfect setting fitting all of boards.

Developers should use the existing variables in OE to
customize console settings for the type of a board, like
SERIAL_CONSOLES, SERIAL_CONSOLES_CHECK, SYSLINUX_OPTS,
APPEND, etc in a permanent conf file in their BSP layers
or the temporary local.conf in build time.

If they still want to have a single BSP conf file and
image built for multiple targets, they could try RMC
feature with provided board-specific bits as a runtime
solution.

With either of two options available to developers, we
purge these hardcoded default settings.

We don't change quark config this time because of boards
of this family are not so many as the other two.

Signed-off-by: Jianxun Zhang 
---
Saul,
This is the proposal #1 to remove (any) tty in generic x86 conf files. I know 
you could only want to remove ttyS0 but the issue is common on other consoles.

I only tested it on NUC4 which expects no any consoles. I guess people could be 
confused when seeing some issues on boards that do need the removed consoles. 
Well, refer to commit msg to justfy it...

Thanks

 conf/machine/intel-core2-32.conf  | 4 +---
 conf/machine/intel-corei7-64.conf | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/conf/machine/intel-core2-32.conf b/conf/machine/intel-core2-32.conf
index 5f8ee24..2e4df55 100644
--- a/conf/machine/intel-core2-32.conf
+++ b/conf/machine/intel-core2-32.conf
@@ -27,8 +27,6 @@ XSERVER ?= "${XSERVER_X86_BASE} \
 ${XSERVER_X86_VESA} \
"
 
-SYSLINUX_OPTS = "serial 0 115200"
-SERIAL_CONSOLES = "115200;ttyS0 115200;ttyPCH0"
-APPEND += "rootwait console=ttyS0,115200 console=ttyPCH0,115200 console=tty0"
+APPEND += "rootwait"
 
 PACKAGE_INSTALL_append_pn-core-image-minimal-initramfs = " linux-firmware-i915"
diff --git a/conf/machine/intel-corei7-64.conf 
b/conf/machine/intel-corei7-64.conf
index 30d492f..ed85262 100644
--- a/conf/machine/intel-corei7-64.conf
+++ b/conf/machine/intel-corei7-64.conf
@@ -26,8 +26,6 @@ XSERVER ?= "${XSERVER_X86_BASE} \
 ${XSERVER_X86_VESA} \
"
 
-SYSLINUX_OPTS = "serial 0 115200"
-SERIAL_CONSOLE = "115200 ttyS0"
-APPEND += "rootwait console=ttyS0,115200 console=tty0"
+APPEND += "rootwait"
 
 PACKAGE_INSTALL_append_pn-core-image-minimal-initramfs = " linux-firmware-i915"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH][DO NOT MERGE] rmc: Add board data for NUC5i5RYB

[Jianxun Zhang]

A particular intention of this change is to remove the serial
setting in kernel command line that is hardcoded in core2 and
corei7 conf files.

However we cannot use KBOOTPARAM because it is designed as a
fragment appended to hardcoded part at runtime. This is why
we need to create more files in this patch to use cmdline
in bootloader entry files to bypass whatever from the build.

Once we have a clean base (no any preset console setting)
in generic configurations, this change can be dropped.

Signed-off-by: Jianxun Zhang 
---
Saul,
This is proposal #2 to remove a console hardcoded in core* conf files without 
touching them. This change is only for the concerned NUC model. That means 
other boards having same recent ttyS0 issue are not covered.


If prposal #1 is acceptable (in another mail), you don't need this change 
because #1 applies all boards.

Thanks

 common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh   |   2 ++
 common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf|   4 
 common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf |   4 
 common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp| Bin 0 -> 149 bytes
 6 files changed, 14 insertions(+)
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp

diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG
new file mode 100644
index 000..b2fabe8
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG
@@ -0,0 +1,2 @@
+boot.conf
+install.conf
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG
new file mode 100644
index 000..ca5f04b
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG
@@ -0,0 +1,2 @@
+efi_entry_dir:root:disk:770:/boot/loader/entries/
+boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh
new file mode 100644
index 000..6694261
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh
@@ -0,0 +1,2 @@
+# There is no tty device on this board.
+sed -i '/start_getty.\+ttyS.*/d' /tgt_root/etc/inittab
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf
new file mode 100644
index 000..b29fa45
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf
@@ -0,0 +1,4 @@
+title NUC5i5RYB boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot rootwait
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf
new file mode 100644
index 000..0dca3ca
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf
@@ -0,0 +1,4 @@
+title NUC5i5RYB install
+linux /vmlinuz
+initrd /initrd
+options LABEL=install-efi rootwait
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp
new file mode 100644
index 
..57374779069490cf24c17bea740d49c00e5ac9b9
GIT binary patch
literal 149
zcmZQ%Ehx%QDNQbk&r8frWl$gl7?@Bs_=P%~W|{^?Ix(;al%*CGXXfWIc;=O)=4b?I
yDmdpCrD}xuYAR%!>Y5sv8iXo12ZSm(C>ZLQ8Mu2?G1M~@r52|am8GUIps)dnwhttps://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2] rmc: Add board data for NUC5i5RYB

[Jianxun Zhang]

A particular intention of this change is to remove the serial
setting in kernel command line that is hardcoded in core2 and
corei7 conf files.

However we cannot use KBOOTPARAM because it is designed as a
fragment appended to the hardcoded part at runtime. This is
why we need to create more files in this patch to use cmdline
in bootloader entry files to bypass whatever from the build.

Once we have a clean base (no any preset console settings)
in generic configurations, this change can be dropped.

Signed-off-by: Jianxun Zhang 
---
Saul,
This is a V2 only dropped "[DO NOT MERGE]" tag in subject.

 common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh   |   2 ++
 common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf|   4 
 common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf |   4 
 common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp| Bin 0 -> 149 bytes
 6 files changed, 14 insertions(+)
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf
 create mode 100644 common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp

diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG
new file mode 100644
index 000..b2fabe8
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/BOOTENTRY.CONFIG
@@ -0,0 +1,2 @@
+boot.conf
+install.conf
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG
new file mode 100644
index 000..ca5f04b
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/INSTALLER.CONFIG
@@ -0,0 +1,2 @@
+efi_entry_dir:root:disk:770:/boot/loader/entries/
+boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh
new file mode 100644
index 000..6694261
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/POSTINSTALL.sh
@@ -0,0 +1,2 @@
+# There is no tty device on this board.
+sed -i '/start_getty.\+ttyS.*/d' /tgt_root/etc/inittab
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf
new file mode 100644
index 000..b29fa45
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/boot.conf
@@ -0,0 +1,4 @@
+title NUC5i5RYB boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot rootwait
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf
new file mode 100644
index 000..0dca3ca
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/NUC5i5RYB/install.conf
@@ -0,0 +1,4 @@
+title NUC5i5RYB install
+linux /vmlinuz
+initrd /initrd
+options LABEL=install-efi rootwait
diff --git a/common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp 
b/common/recipes-bsp/rmc/boards/NUC5i5RYB/nuc5i5.fp
new file mode 100644
index 
..57374779069490cf24c17bea740d49c00e5ac9b9
GIT binary patch
literal 149
zcmZQ%Ehx%QDNQbk&r8frWl$gl7?@Bs_=P%~W|{^?Ix(;al%*CGXXfWIc;=O)=4b?I
yDmdpCrD}xuYAR%!>Y5sv8iXo12ZSm(C>ZLQ8Mu2?G1M~@r52|am8GUIps)dnwhttps://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 2/2] rmc: Add example for Galileo Gen 2 (Quark)

[Jianxun Zhang]

This is an experimental RMC sample for quark. At runtime, a
boot option with board name will be available for user to
boot the Galileo.

Note: The supported image type is hddimg instead of the direct-
boot image type usually used on quark. Use a USB stick flashed
with the image to boot the Galileo Gen 2 board.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/Galileo2/boot.conf|   4 
 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp  | Bin 0 -> 109 bytes
 3 files changed, 6 insertions(+)
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/boot.conf
 create mode 100755 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp

diff --git a/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG 
b/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
new file mode 100644
index 000..06c5a74
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
@@ -0,0 +1,2 @@
+boot.conf
+
diff --git a/common/recipes-bsp/rmc/boards/Galileo2/boot.conf 
b/common/recipes-bsp/rmc/boards/Galileo2/boot.conf
new file mode 100644
index 000..580ea48
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/Galileo2/boot.conf
@@ -0,0 +1,4 @@
+title Galileo Gen 2 boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot rootwait console=ttyS1,115200
diff --git a/common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp 
b/common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp
new file mode 100755
index 
..fe77d4d181e2ce9d0b6f662d436778d6dde81be3
GIT binary patch
literal 109
zcmZQ%Ehx%QDNQbk&r8frWe5y)4Dx1RLKSpR%*o72&38}DGh$#7C`&CW&dkqa@XRYo
n&Cv+bQ~-*XX6B_T01Zk`EiTS4VyI^*N-a(;DoagaKw$#_u$m+P

literal 0
HcmV?d1

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 0/2] RMC example for quark

[Jianxun Zhang]

Saul,
I am a little surprised to see the first patch is necessary to override 
EFI_PROVIDER in a local.conf.

And maybe we want to mention using hddimg on quark in README with another patch?

Thanks

Jianxun Zhang (2):
  quark: amend EFI Bootloader option
  rmc: Add example for Galileo Gen 2 (Quark)

 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/Galileo2/boot.conf|   4 
 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp  | Bin 0 -> 109 bytes
 conf/machine/intel-quark.conf   |   2 +-
 4 files changed, 7 insertions(+), 1 deletion(-)
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/boot.conf
 create mode 100755 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 1/2] quark: amend EFI Bootloader option

[Jianxun Zhang]

We cannot override the current EFI bootloader selection with
another "EFI_PROVIDER=..." in a local.conf in a build/conf
directory when it is specified by "=" syntax in the current
conf file for quark.

Signed-off-by: Jianxun Zhang 
---
 conf/machine/intel-quark.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index ad67319..c032916 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -18,7 +18,7 @@ MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
 SERIAL_CONSOLE = "115200 ttyS1"
 APPEND += "rootwait console=ttyS1,115200 console=tty0"
 
-EFI_PROVIDER = "systemd-boot"
+EFI_PROVIDER ?= "systemd-boot"
 
 # Ensure that the Lock prefix is omitted for the kernel"
 KERNEL_EXTRA_ARGS = "EXTRA_CFLAGS=-Wa,-momit-lock-prefix=yes"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 1/2] quark: explicitly set boot entry in bootloader

[Jianxun Zhang]

This is to get rid of "install" option when booting quark with
an image in hddimg format. EFI installer doesn't work on quark
at this point.

Signed-off-by: Jianxun Zhang 
---
 conf/machine/intel-quark.conf | 9 +
 1 file changed, 9 insertions(+)

diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index ad67319..fdc9f67 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -20,5 +20,14 @@ APPEND += "rootwait console=ttyS1,115200 console=tty0"
 
 EFI_PROVIDER = "systemd-boot"
 
+# Bypass the default labels which also has "install" option in OE.
+#
+# We don't need to do this when constructing direct-boot image with
+# wic. But EFI installer in hddimg image doesn't work on quark now,
+# so we only provide a live-boot entry in boot menu for images in
+# hddimg format.
+
+LABELS = "boot"
+
 # Ensure that the Lock prefix is omitted for the kernel"
 KERNEL_EXTRA_ARGS = "EXTRA_CFLAGS=-Wa,-momit-lock-prefix=yes"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 2/2] README: Provide information for how to live-boot quark with hddimg

[Jianxun Zhang]

This change adds the procedure to boot quark with images in hddimg
format.

Signed-off-by: Jianxun Zhang 
---
 README | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/README b/README
index 772ac4e..777c66c 100644
--- a/README
+++ b/README
@@ -248,6 +248,17 @@ To create a direct-boot image for USB storage media, 
simply specify
 galileodisk-usb instead of galileodisk-sd in the "wic create ..."
 command, then write the output image to USB storage media and boot it.
 
+Actually, Galileo board can boot off with an image in hddimg format
+from USB drives too. But only live-boot, no installation, is supported
+at this point. An image in hddimg format is generated when you build
+quark BSP. You can follow the procedure in II.b to use dd command to
+prepare your USB drive, then press F7 key as what board prompts when it
+boots. Galileo should show a boot option menu for you to choose the
+UEFI USB boot option for the drive to boot the system. If the board
+already passes this stage and show a grub boot menu, you can press 'c'
+key and then type "quit" in grub shell. The board should come back to
+the UEFI boot menu.
+
 III. Technical Miscellany
 =
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 0/2] quark: live-boot with hddimg

[Jianxun Zhang]

Saul,
This patch series is in parallel with the series of RMC support of quark 
submitted yesterday because this work is not rmc-specific in fact.

But in case you meet conflicts when merging, feel free to let me know.

Jianxun Zhang (2):
  quark: explicitly set boot entry in bootloader
  README: Provide information for how to live-boot quark with hddimg

 README| 11 +++
 conf/machine/intel-quark.conf |  9 +
 2 files changed, 20 insertions(+)

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 3/4] quark: amend EFI Bootloader option

[Jianxun Zhang]

We cannot override the current EFI bootloader selection with
another "EFI_PROVIDER=..." in a local.conf in a build/conf
directory when it is specified by "=" syntax in the current
conf file for quark.

Signed-off-by: Jianxun Zhang 
---
 conf/machine/intel-quark.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index 5ac7011..036bd25 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -18,7 +18,7 @@ MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
 SERIAL_CONSOLE = "115200 ttyS1"
 APPEND += "rootwait console=ttyS1,115200 console=tty0"
 
-EFI_PROVIDER = "systemd-boot"
+EFI_PROVIDER ?= "systemd-boot"
 
 # Bypass the default labels which also has "install" option in OE.
 #
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 0/4] RMC support for quark (hddimg)

[Jianxun Zhang]

Resubmission including the two previous submitted series for hddimg
support on quark and adding RMC example for Galileo. Aware of wks
image has been enabled in meta-intel, I will make RMC support
direct-boot in the next stage.

Jianxun Zhang (4):
  quark: explicitly set boot entry in bootloader
  README: Provide information for how to live-boot quark with hddimg
  quark: amend EFI Bootloader option
  rmc: Add example for Galileo Gen 2 (Quark)

 README  |  11 +++
 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/Galileo2/boot.conf|   4 
 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp  | Bin 0 -> 109 bytes
 conf/machine/intel-quark.conf   |  11 ++-
 documentation/rmc/README|   9 -
 6 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/boot.conf
 create mode 100755 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 2/4] README: Provide information for how to live-boot quark with hddimg

[Jianxun Zhang]

This change adds the procedure to boot quark with images in hddimg
format.

Signed-off-by: Jianxun Zhang 
---
 README | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/README b/README
index 772ac4e..777c66c 100644
--- a/README
+++ b/README
@@ -248,6 +248,17 @@ To create a direct-boot image for USB storage media, 
simply specify
 galileodisk-usb instead of galileodisk-sd in the "wic create ..."
 command, then write the output image to USB storage media and boot it.
 
+Actually, Galileo board can boot off with an image in hddimg format
+from USB drives too. But only live-boot, no installation, is supported
+at this point. An image in hddimg format is generated when you build
+quark BSP. You can follow the procedure in II.b to use dd command to
+prepare your USB drive, then press F7 key as what board prompts when it
+boots. Galileo should show a boot option menu for you to choose the
+UEFI USB boot option for the drive to boot the system. If the board
+already passes this stage and show a grub boot menu, you can press 'c'
+key and then type "quit" in grub shell. The board should come back to
+the UEFI boot menu.
+
 III. Technical Miscellany
 =
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 1/4] quark: explicitly set boot entry in bootloader

[Jianxun Zhang]

This is to get rid of "install" option when booting quark with
an image in hddimg format. EFI installer doesn't work on quark
at this point.

Signed-off-by: Jianxun Zhang 
---
 conf/machine/intel-quark.conf | 9 +
 1 file changed, 9 insertions(+)

diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index 70cb45e..5ac7011 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -20,6 +20,15 @@ APPEND += "rootwait console=ttyS1,115200 console=tty0"
 
 EFI_PROVIDER = "systemd-boot"
 
+# Bypass the default labels which also has "install" option in OE.
+#
+# We don't need to do this when constructing direct-boot image with
+# wic. But EFI installer in hddimg image doesn't work on quark now,
+# so we only provide a live-boot entry in boot menu for images in
+# hddimg format.
+
+LABELS = "boot"
+
 # Ensure that the Lock prefix is omitted for the kernel"
 KERNEL_EXTRA_ARGS = "EXTRA_CFLAGS=-Wa,-momit-lock-prefix=yes"
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 4/4] rmc: Add example for Galileo Gen 2 (Quark)

[Jianxun Zhang]

This is an experimental RMC sample for quark. At runtime, a
boot option with board name will be available for user to
boot the Galileo.

Note: The supported image type is hddimg instead of the direct-
boot image type usually used on quark. Use a USB stick flashed
with the image to boot the Galileo Gen 2 board.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/Galileo2/boot.conf|   4 
 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp  | Bin 0 -> 109 bytes
 documentation/rmc/README|   9 -
 4 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/boot.conf
 create mode 100755 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp

diff --git a/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG 
b/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
new file mode 100644
index 000..06c5a74
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
@@ -0,0 +1,2 @@
+boot.conf
+
diff --git a/common/recipes-bsp/rmc/boards/Galileo2/boot.conf 
b/common/recipes-bsp/rmc/boards/Galileo2/boot.conf
new file mode 100644
index 000..580ea48
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/Galileo2/boot.conf
@@ -0,0 +1,4 @@
+title Galileo Gen 2 boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot rootwait console=ttyS1,115200
diff --git a/common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp 
b/common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp
new file mode 100755
index 
..fe77d4d181e2ce9d0b6f662d436778d6dde81be3
GIT binary patch
literal 109
zcmZQ%Ehx%QDNQbk&r8frWe5y)4Dx1RLKSpR%*o72&38}DGh$#7C`&CW&dkqa@XRYo
n&Cv+bQ~-*XX6B_T01Zk`EiTS4VyI^*N-a(;DoagaKw$#_u$m+P

literal 0
HcmV?d1

diff --git a/documentation/rmc/README b/documentation/rmc/README
index c392eb2..2427ffd 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -275,7 +275,14 @@ common/recipes-bsp/rmc/boards/T100-32bit
 This example is provided for validation on 32 bit X86 architecture. It doesn't
 provide any new function not mentioned in above examples.
 
-
+EXAMPLE 5: RMC for quark
+Galileo Gen 2
+common/recipes-bsp/rmc/boards/Galileo2
+This example doesn't show any feature not covered in the above examples. Note
+RMC only supports hddimg image format so far. Please refer to the section II.c
+in README in meta-intel for how to boot Galileo with images in hddimg format.
+Bootloader should show a board-specific boot option "Galileo Gen 2 boot" when
+the board boots off.
 
 Troubleshooting
 

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2 1/4] quark: explicitly set boot entry in bootloader

[Jianxun Zhang]

This is to get rid of "install" option when booting quark with
an image in hddimg format. EFI installer doesn't work on quark
at this point.

Signed-off-by: Jianxun Zhang 
---
 conf/machine/intel-quark.conf | 9 +
 1 file changed, 9 insertions(+)

diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index 70cb45e..c001302 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -20,6 +20,15 @@ APPEND += "rootwait console=ttyS1,115200 console=tty0"
 
 EFI_PROVIDER = "systemd-boot"
 
+# Bypass the default labels which also has "install" option in OE.
+#
+# We don't need to do this when constructing direct-boot image with
+# wic. But EFI installer in hddimg image doesn't work on quark now,
+# so we only provide a live-boot entry in boot menu for images in
+# hddimg format.
+
+LABELS_LIVE = "boot"
+
 # Ensure that the Lock prefix is omitted for the kernel"
 KERNEL_EXTRA_ARGS = "EXTRA_CFLAGS=-Wa,-momit-lock-prefix=yes"
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2 4/4] rmc: Add example for Galileo Gen 2 (Quark)

[Jianxun Zhang]

This is an experimental RMC sample for quark. At runtime, a
boot option with board name will be available for user to
boot the Galileo.

Note: The supported image type is hddimg instead of the direct-
boot image type usually used on quark. Use a USB stick flashed
with the image to boot the Galileo Gen 2 board.

Signed-off-by: Jianxun Zhang 
---
 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/Galileo2/boot.conf|   4 
 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp  | Bin 0 -> 109 bytes
 documentation/rmc/README|   9 -
 4 files changed, 14 insertions(+), 1 deletion(-)
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/boot.conf
 create mode 100755 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp

diff --git a/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG 
b/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
new file mode 100644
index 000..06c5a74
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
@@ -0,0 +1,2 @@
+boot.conf
+
diff --git a/common/recipes-bsp/rmc/boards/Galileo2/boot.conf 
b/common/recipes-bsp/rmc/boards/Galileo2/boot.conf
new file mode 100644
index 000..580ea48
--- /dev/null
+++ b/common/recipes-bsp/rmc/boards/Galileo2/boot.conf
@@ -0,0 +1,4 @@
+title Galileo Gen 2 boot
+linux /vmlinuz
+initrd /initrd
+options LABEL=boot rootwait console=ttyS1,115200
diff --git a/common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp 
b/common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp
new file mode 100755
index 
..fe77d4d181e2ce9d0b6f662d436778d6dde81be3
GIT binary patch
literal 109
zcmZQ%Ehx%QDNQbk&r8frWe5y)4Dx1RLKSpR%*o72&38}DGh$#7C`&CW&dkqa@XRYo
n&Cv+bQ~-*XX6B_T01Zk`EiTS4VyI^*N-a(;DoagaKw$#_u$m+P

literal 0
HcmV?d1

diff --git a/documentation/rmc/README b/documentation/rmc/README
index c392eb2..2427ffd 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -275,7 +275,14 @@ common/recipes-bsp/rmc/boards/T100-32bit
 This example is provided for validation on 32 bit X86 architecture. It doesn't
 provide any new function not mentioned in above examples.
 
-
+EXAMPLE 5: RMC for quark
+Galileo Gen 2
+common/recipes-bsp/rmc/boards/Galileo2
+This example doesn't show any feature not covered in the above examples. Note
+RMC only supports hddimg image format so far. Please refer to the section II.c
+in README in meta-intel for how to boot Galileo with images in hddimg format.
+Bootloader should show a board-specific boot option "Galileo Gen 2 boot" when
+the board boots off.
 
 Troubleshooting
 

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2 2/4] README: Provide information for how to live-boot quark with hddimg

[Jianxun Zhang]

This change adds the procedure to boot quark with images in hddimg
format.

Signed-off-by: Jianxun Zhang 
---
 README | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/README b/README
index 772ac4e..777c66c 100644
--- a/README
+++ b/README
@@ -248,6 +248,17 @@ To create a direct-boot image for USB storage media, 
simply specify
 galileodisk-usb instead of galileodisk-sd in the "wic create ..."
 command, then write the output image to USB storage media and boot it.
 
+Actually, Galileo board can boot off with an image in hddimg format
+from USB drives too. But only live-boot, no installation, is supported
+at this point. An image in hddimg format is generated when you build
+quark BSP. You can follow the procedure in II.b to use dd command to
+prepare your USB drive, then press F7 key as what board prompts when it
+boots. Galileo should show a boot option menu for you to choose the
+UEFI USB boot option for the drive to boot the system. If the board
+already passes this stage and show a grub boot menu, you can press 'c'
+key and then type "quit" in grub shell. The board should come back to
+the UEFI boot menu.
+
 III. Technical Miscellany
 =
 
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2 0/4] RMC support for quark(hddimg)

[Jianxun Zhang]

This V2 changed to use LABELS_LIVE instead of LABELS which always triggers
a warning message in OE. We should either amend OE document to direct
people to use _LIVE or _VM for LABELS or remove the warning message to just
use LABELS nicely.

Jianxun Zhang (4):
  quark: explicitly set boot entry in bootloader
  README: Provide information for how to live-boot quark with hddimg
  quark: amend EFI Bootloader option
  rmc: Add example for Galileo Gen 2 (Quark)

 README  |  11 +++
 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG |   2 ++
 common/recipes-bsp/rmc/boards/Galileo2/boot.conf|   4 
 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp  | Bin 0 -> 109 bytes
 conf/machine/intel-quark.conf   |  11 ++-
 documentation/rmc/README|   9 -
 6 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/BOOTENTRY.CONFIG
 create mode 100644 common/recipes-bsp/rmc/boards/Galileo2/boot.conf
 create mode 100755 common/recipes-bsp/rmc/boards/Galileo2/gallieo2.fp

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH V2 3/4] quark: amend EFI Bootloader option

[Jianxun Zhang]

We cannot override the current EFI bootloader selection with
another "EFI_PROVIDER=..." in a local.conf in a build/conf
directory when it is specified by "=" syntax in the current
conf file for quark.

Signed-off-by: Jianxun Zhang 
---
 conf/machine/intel-quark.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/intel-quark.conf b/conf/machine/intel-quark.conf
index c001302..b56f050 100644
--- a/conf/machine/intel-quark.conf
+++ b/conf/machine/intel-quark.conf
@@ -18,7 +18,7 @@ MACHINE_EXTRA_RRECOMMENDS += "kernel-modules linux-firmware"
 SERIAL_CONSOLE = "115200 ttyS1"
 APPEND += "rootwait console=ttyS1,115200 console=tty0"
 
-EFI_PROVIDER = "systemd-boot"
+EFI_PROVIDER ?= "systemd-boot"
 
 # Bypass the default labels which also has "install" option in OE.
 #
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] quark: use UUID for rootfs

[Jianxun Zhang]

Port the change http://lists.openembedded.org/pipermail/
openembedded-core/2016-October/127948.html into wks files
in meta-intel.

Note: This patch has not been on OE master branch at this point.

Original commit message:

--
systemd-bootdisk.wks: use PARTUUID

Root device name in systemd-bootdisk.wks is 'sda'. This can cause
images, produced using this wks to refuse booting if real device
name is not 'sda'. For example, when booting MinnowBoard MAX from
MicroSD card the boot process stucks with this message on the boot
console output: Waiting for root device /dev/sda2...
This happens because real device name of MicroSD card on this device
is mmcblk1.

Used --use-uuid option for root partition. This should make
wic to put partition UUID instead of device name into kernel command
line.

[YOCTO #10485]

Signed-off-by: Ed Bartosh 
------

Signed-off-by: Jianxun Zhang 
---
 scripts/lib/wic/canned-wks/galileodisk-sd.wks  | 2 +-
 scripts/lib/wic/canned-wks/galileodisk-usb.wks | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/scripts/lib/wic/canned-wks/galileodisk-sd.wks 
b/scripts/lib/wic/canned-wks/galileodisk-sd.wks
index e03c2f8..6d96af4 100644
--- a/scripts/lib/wic/canned-wks/galileodisk-sd.wks
+++ b/scripts/lib/wic/canned-wks/galileodisk-sd.wks
@@ -4,6 +4,6 @@
 
 part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk 
mmcblk0 --label msdos --active --align 1024
 
-part / --source rootfs --ondisk mmcblk0 --fstype=ext3 --label platform --align 
1024
+part / --source rootfs --ondisk mmcblk0 --fstype=ext3 --label platform --align 
1024 --use-uuid
 
 bootloader  --timeout=0  --append="console=ttyS1,115200n8 
earlycon=uart8250,mmio32,0x9000b000,115200n8 reboot=efi,warm apic=debug rw 
LABEL=boot debugshell=5"
diff --git a/scripts/lib/wic/canned-wks/galileodisk-usb.wks 
b/scripts/lib/wic/canned-wks/galileodisk-usb.wks
index b721c95..d746cc8 100644
--- a/scripts/lib/wic/canned-wks/galileodisk-usb.wks
+++ b/scripts/lib/wic/canned-wks/galileodisk-usb.wks
@@ -4,6 +4,6 @@
 
 part /boot --source bootimg-efi --sourceparams="loader=systemd-boot" --ondisk 
sda --label msdos --active --align 1024
 
-part / --source rootfs --ondisk sda --fstype=ext3 --label platform --align 1024
+part / --source rootfs --ondisk sda --fstype=ext3 --label platform --align 
1024 --use-uuid
 
 bootloader  --timeout=0  --append="rootwait console=ttyS1,115200n8 
earlycon=uart8250,mmio32,0x9000b000,115200n8 reboot=efi,warm apic=debug rw 
LABEL=boot debugshell=5"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] rmc: Limit them to x86 targets

[Jianxun Zhang]

Khem,

I think it is appropriate to have this.

BTW, what RMC is based on actually supports non-x86 arches but meta-intel team 
haven’t verified non-x86 boards.

Thanks lot!

> On Nov 8, 2016, at 8:39 AM, Khem Raj  wrote:
> 
> Makes meta-intel behave well in multi-BSP scene
> 
> Signed-off-by: Khem Raj 
> ---
> common/recipes-bsp/rmc/rmc.bb | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
> index 9b87dd5..aeaf12e 100644
> --- a/common/recipes-bsp/rmc/rmc.bb
> +++ b/common/recipes-bsp/rmc/rmc.bb
> @@ -20,6 +20,8 @@ S = "${WORKDIR}/git"
> 
> DEPENDS_class-target = "gnu-efi"
> 
> +COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
> +
> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
> 
> # from gnu-efi, we should align arch-mapping with it.
> -- 
> 1.9.1
> 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] broxton-m/KBOOTPARAM: Add videofb console back

[Jianxun Zhang]

> On Nov 8, 2016, at 11:24 AM, Saul Wold  wrote:
> 
> This re-enables the video framebuffer for displaying cosole output
> 
> Signed-off-by: Saul Wold 
> ---
> common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM 
> b/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
> index 5ad14b4..99f81d1 100644
> --- a/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
> +++ b/common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM
> @@ -1 +1 @@
> -video=efifb maxcpus=4 noxsave reboot=efi kmemleak=off console=ttyS2,115200
> +video=efifb maxcpus=4 noxsave reboot=efi kmemleak=off console=tty0 
> console=ttyS2,115200

Review +1
Test +1

> -- 
> 2.7.4
> 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] rmc: Fix compiling issue with musl

[Jianxun Zhang]

| src/rmcl/rmcl.c: In function 'query_policy_from_db':
| src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t'
| ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1;
| ^~~~

The musl C lib provides ssize_t but we need to enable it
with a macro.

Signed-off-by: Jianxun Zhang 
---
I feel there could be a better syntax to do it. And We could need to get
an ack from Hernandez, Alejandro who reported this issue and seems still
have (other) compiling errors even with this patch.

I submit this patch based on my thoughts and test out of tiny config.

Tests:
() Specify TCLIBC = "musl" in local.conf in my build dir.
() Build quark
() I can see this issue happens without the fix
() With this patch and do clean builds for quark and corei7-64,
Compiling passes. Boot test passed on RMC targets quark and Broxton-m.

Thanks

 common/recipes-bsp/rmc/rmc.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
index aeaf12e..61a1bdb 100644
--- a/common/recipes-bsp/rmc/rmc.bb
+++ b/common/recipes-bsp/rmc/rmc.bb
@@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
 
 EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
 
+EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"'
+
 # from gnu-efi, we should align arch-mapping with it.
 def rmc_efi_arch(d):
 import re
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH] rmc: Fix compiling issue with musl

[Jianxun Zhang]

Saul,
Please hold on reviewing this patch. I will try another way in rmc to fix it.

Thanks

> On Nov 14, 2016, at 2:38 PM, Jianxun Zhang  
> wrote:
> 
> | src/rmcl/rmcl.c: In function 'query_policy_from_db':
> | src/rmcl/rmcl.c:254:25: error: unknown type name 'ssize_t'
> | ssize_t cmd_name_len = strlen((char *)&rmc_db[policy_idx]) + 1;
> | ^~~~
> 
> The musl C lib provides ssize_t but we need to enable it
> with a macro.
> 
> Signed-off-by: Jianxun Zhang 
> ---
> I feel there could be a better syntax to do it. And We could need to get
> an ack from Hernandez, Alejandro who reported this issue and seems still
> have (other) compiling errors even with this patch.
> 
> I submit this patch based on my thoughts and test out of tiny config.
> 
> Tests:
> () Specify TCLIBC = "musl" in local.conf in my build dir.
> () Build quark
> () I can see this issue happens without the fix
> () With this patch and do clean builds for quark and corei7-64,
> Compiling passes. Boot test passed on RMC targets quark and Broxton-m.
> 
> Thanks
> 
> common/recipes-bsp/rmc/rmc.bb | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
> index aeaf12e..61a1bdb 100644
> --- a/common/recipes-bsp/rmc/rmc.bb
> +++ b/common/recipes-bsp/rmc/rmc.bb
> @@ -24,6 +24,8 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
> 
> EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
> 
> +EXTRA_OEMAKE_append_libc-musl = '" -D__NEED_ssize_t"'
> +
> # from gnu-efi, we should align arch-mapping with it.
> def rmc_efi_arch(d):
> import re
> -- 
> 2.7.4
> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 0/2] RMC: update

[Jianxun Zhang]

This work is to update rmc and other components in meta-intel to reflect
the latest changes happened in the upstream rmc project. Please refer to
the commit messages and annotations for additional information.

Jianxun Zhang (2):
  rmc: integration update
  gnu-efi: removed from meta-intel

 ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 -
 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend  |  3 --
 common/recipes-bsp/rmc/rmc.bb  | 20 ++--
 .../recipes-bsp/systemd-boot/systemd-boot.bbappend |  4 +-
 ...sd-boot-Link-RMC-library-into-bootloader.patch} | 10 ++--
 ...d-board-specific-boot-entries-from-RMC-da.patch | 55 +-
 ...pport-global-kernel-command-line-fragment.patch | 10 ++--
 7 files changed, 38 insertions(+), 96 deletions(-)
 delete mode 100644 
common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
 delete mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
 rename 
common/recipes-bsp/systemd-boot/systemd-boot/{0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
 => 0001-sd-boot-Link-RMC-library-into-bootloader.patch} (70%)

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 2/2] gnu-efi: removed from meta-intel

[Jianxun Zhang]

We once added a patch in gnu-efi for rmc's sake. The latest rmc
gets rid of this dependency on gnu-efi.

The removed patch is still a reasonable change and merged into
the upstream gnu-efi project. It should come with the next update
in the gnu-efi recipe in OE.

At this point, however, we don't see any urgency to keep it in
meta-intel any more.

Signed-off-by: Jianxun Zhang 
---
 ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 --
 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend  |  3 --
 2 files changed, 35 deletions(-)
 delete mode 100644 
common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
 delete 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
deleted file mode 100644
index c86bf08..000
--- 
a/common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-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
deleted file mode 100644
index 1e9cfda..000
--- a/common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/gnu-efi:"
-SRC_URI_append_intel-x86-common = 
"file://0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch"
-PACKAGE_ARCH_intel-x86-common = "${INTEL_COMMON_PACKAGE_ARCH}"
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH 1/2] rmc: integration update

[Jianxun Zhang]

This is a whole package of rmc work in meta-intel to reflect
some major changes in the upstream project:

In rmc.bb recipe, EFI_ARCH, path of EFI header files, and
dependency on gnu-efi are removed with the updated revision.

In systemd-boot, patches to integrate with rmc are re-worked
mainly because of new APIs. Size of patches are smaller than
the previous implementation. Notice we still use multiple APIs
instead of calling an one-step interface multiple times, to get
some potential runtime performance benefit. (rmc tool in user
space is changed to use single API in the upstream project.)

Fixes [YOCTO #10086]
Fixes [YOCTO #10671]

Signed-off-by: Jianxun Zhang 
---
For 10671 I believe I have fixed compiling issue with musl at
my side. Please let me know if the orginal reporter still see
the issue. (Alejandro Hernandez)

Thanks


 common/recipes-bsp/rmc/rmc.bb  | 20 ++--
 .../recipes-bsp/systemd-boot/systemd-boot.bbappend |  4 +-
 ...sd-boot-Link-RMC-library-into-bootloader.patch} | 10 ++--
 ...d-board-specific-boot-entries-from-RMC-da.patch | 55 +-
 ...pport-global-kernel-command-line-fragment.patch | 10 ++--
 5 files changed, 38 insertions(+), 61 deletions(-)
 rename 
common/recipes-bsp/systemd-boot/systemd-boot/{0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
 => 0001-sd-boot-Link-RMC-library-into-bootloader.patch} (70%)

diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
index aeaf12e..41062bf 100644
--- a/common/recipes-bsp/rmc/rmc.bb
+++ b/common/recipes-bsp/rmc/rmc.bb
@@ -14,32 +14,22 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=838c366f69b72c5df05c96dff79b35f2"
 
 SRC_URI = "git://git.yoctoproject.org/rmc"
 
-SRCREV = "2e38d056f86c0457f3a5ca7ef848545bbb190e47"
+SRCREV = "4799cb89b543712390d863a6fc50a58881590fa2"
 
 S = "${WORKDIR}/git"
 
-DEPENDS_class-target = "gnu-efi"
-
 COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
 
-EXTRA_OEMAKE='RMC_CFLAGS="-Wl,--hash-style=both"'
-
-# from gnu-efi, we should align arch-mapping with it.
-def rmc_efi_arch(d):
-import re
-arch = d.getVar("TARGET_ARCH", True)
-if re.match("i[3456789]86", arch):
-return "ia32"
-return arch
+TARGET_CFLAGS +="-Wl,--hash-style=both"
 
 do_compile_class-target() {
oe_runmake
-   oe_runmake RMC_EFI_HEADER_PREFIX=${STAGING_INCDIR}/efi 
RMC_EFI_ARCH="${@rmc_efi_arch(d)}" -f Makefile.efi
+   oe_runmake -f Makefile.efi
 }
 
 do_install() {
-   oe_runmake RMC_EFI_ARCH="${@rmc_efi_arch(d)}" 
RMC_INSTALL_PREFIX=${D}/usr install
-   oe_runmake RMC_EFI_ARCH="${@rmc_efi_arch(d)}" 
RMC_INSTALL_PREFIX=${D}/usr -f Makefile.efi install
+   oe_runmake RMC_INSTALL_PREFIX=${D}/usr install
+   oe_runmake RMC_INSTALL_PREFIX=${D}/usr -f Makefile.efi install
 }
 
 do_install_class-native() {
diff --git a/common/recipes-bsp/systemd-boot/systemd-boot.bbappend 
b/common/recipes-bsp/systemd-boot/systemd-boot.bbappend
index ed31755..2aecc3f 100644
--- a/common/recipes-bsp/systemd-boot/systemd-boot.bbappend
+++ b/common/recipes-bsp/systemd-boot/systemd-boot.bbappend
@@ -2,7 +2,7 @@ DEPENDS_append_intel-x86-common = " rmc"
 
 FILESEXTRAPATHS_prepend := "${THISDIR}/systemd-boot:"
 
-EXTRA_OEMAKE_append_intel-x86-common = ' 
EFI_LDFLAGS="-L${STAGING_DIR_HOST}/usr/lib" 
EFI_CFLAGS="-I${STAGING_INCDIR}/rmc/efi -DRMC_EFI"'
+EXTRA_OEMAKE_append_intel-x86-common = ' 
EFI_LDFLAGS="-L${STAGING_DIR_HOST}/usr/lib" EFI_CFLAGS="-I${STAGING_INCDIR}/rmc 
-DRMC_EFI"'
 
 # Pin systemd revision down for systemd-boot recipe.
 # Patches could not be applied cleanly when systemd in OE is updated,
@@ -15,7 +15,7 @@ EXTRA_OEMAKE_append_intel-x86-common = ' 
EFI_LDFLAGS="-L${STAGING_DIR_HOST}/usr/
 SRCREV_intel-x86-common = "3a74d4fc90cb322a4784a3515bef7118c8f8c5ba"
 
 SRC_URI_append_intel-x86-common = " \
-file://0001-sd-boot-Link-RMC-libraries-into-bootloader.patch \
+file://0001-sd-boot-Link-RMC-library-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 \
 file://0001-efi-boot.c-workaround-for-Joule-BIOS-hang.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-library-into-bootloader.patch
similarity index 70%
rename from 
common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-libraries-into-bootloader.patch
rename to 
common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
index c8867a2..626efce 100644
--- 
a/common/recipes

Re: [meta-intel] [PATCH] rmc: remove stack-protector-strong from CFLAGS

[Jianxun Zhang]

> On Dec 2, 2016, at 2:19 PM, Saul Wold  wrote:
> 
> Since the rmc is used standalone from systemd-boot and does not
> use libc which provides the stack_chk_fail code that causes an
> undefined symbol
> 
> Signed-off-by: Saul Wold 
> ---
> common/recipes-bsp/rmc/rmc.bb | 1 +
> 1 file changed, 1 insertion(+)
> 
> diff --git a/common/recipes-bsp/rmc/rmc.bb b/common/recipes-bsp/rmc/rmc.bb
> index 41062bf..8c89a99 100644
> --- a/common/recipes-bsp/rmc/rmc.bb
> +++ b/common/recipes-bsp/rmc/rmc.bb
> @@ -22,6 +22,7 @@ COMPATIBLE_HOST = "(x86_64.*|i.86.*)-linux*"
> 
> TARGET_CFLAGS +="-Wl,--hash-style=both"
> 
> +SECURITY_CFLAGS_remove_class-target = "-fstack-protector-strong”
Saul,
I believe this will fix the issue with the current OE security setting. There 
could be other similar cases too:
-fstack-protector   -fstack-protector-all   
-fstack-protector-explicit 
gcc (5.4) from my ubuntu. You may want to test/add these this time or put them 
in a watch list...

Thanks


> do_compile_class-target() {
>   oe_runmake
>   oe_runmake -f Makefile.efi
> -- 
> 2.7.4
> 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [yocto][meta-inte][rmc][PATCH v2 1/1] rmc: add support for alternative EFI bootloaders

[Jianxun Zhang]

> On Dec 13, 2016, at 2:56 PM, Todor Minchev  
> wrote:
> 
> RMC was previously configured to work only with the systemd-boot EFI
> bootloader. With this commit we can specify alternative bootloaders by
> setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
> not set systemd-boot will be used by default.
> 
> Signed-off-by: Todor Minchev 
> ---
> Remove references to grub-efi and gummiboot from V1.
> 
> classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} |  5 +++--
> conf/machine/include/meta-intel.inc|  2 +-
> documentation/rmc/README   | 16 +---
> 3 files changed, 17 insertions(+), 6 deletions(-)
> rename classes/{rmc-systemd-boot.bbclass => rmc-boot.bbclass} (73%)
> 
> diff --git a/classes/rmc-systemd-boot.bbclass b/classes/rmc-boot.bbclass
> similarity index 73%
> rename from classes/rmc-systemd-boot.bbclass
> rename to classes/rmc-boot.bbclass
> index ad2cf10..a1f2093 100644
> --- a/classes/rmc-systemd-boot.bbclass
> +++ b/classes/rmc-boot.bbclass
> @@ -1,9 +1,10 @@
> -# rmc-systemd-boot bbclass
> +# rmc-boot bbclass
> # Deploy central RMC database file to ESP
> 
> IMAGE_INSTALL_append = " rmc"
> +RMC_BOOTLOADER ?= "systemd-boot”
Maybe this is what we could have now without bothering OE. It is better than 
the corrent code at the cost of another variable to user. I hope in the future 
we could get rid of  the dependency to EFI_PROVIDER (e.g. bz10084).

Also refer to my comment for the document change at the below.
> 
> -inherit systemd-boot
> +inherit ${RMC_BOOTLOADER}
> 
> do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
> 
> diff --git a/conf/machine/include/meta-intel.inc 
> b/conf/machine/include/meta-intel.inc
> index c7555ce..fd0a792 100644
> --- a/conf/machine/include/meta-intel.inc
> +++ b/conf/machine/include/meta-intel.inc
> @@ -32,7 +32,7 @@ MACHINE_ESSENTIAL_EXTRA_RDEPENDS_append = 
> "${@bb.utils.contains('MACHINE_FEATURE
> # merge the microcode data in the final initrd image.
> INITRD_LIVE_prepend = "${@bb.utils.contains('MACHINE_FEATURES', 
> 'intel-ucode', '${DEPLOY_DIR_IMAGE}/microcode.cpio ', '', d)}"
> 
> -EFI_PROVIDER ?= "rmc-systemd-boot"
> +EFI_PROVIDER ?= "rmc-boot"
> 
> # Add general MACHINEOVERRIDE for meta-intel
> MACHINEOVERRIDES =. "intel-x86-common:"
> diff --git a/documentation/rmc/README b/documentation/rmc/README
> index 2427ffd..dbee6b6 100644
> --- a/documentation/rmc/README
> +++ b/documentation/rmc/README
> @@ -165,14 +165,24 @@ steps still can override results from this hook for 
> boot entries and KBOOTPARAM.
> 
> Enable RMC Feature
> 
> -To Enable RMC feature in build, add the below lines in a conf file:
> +To enable the RMC feature please add the following variables to your 
> local.conf.
> +
> DISTRO_FEATURES_append = " rmc"
> -EFI_PROVIDER = "rmc-systemd-boot"
> +EFI_PROVIDER = "rmc-boot"
> +
> +The default EFI bootloader used with RMC is systemd-boot. To change the 
> default
> +bootloader please overwrite the RMC_BOOTLOADER variable in your local.conf
> 
> Note:
> Image could be still bootable if you only have either of two lines, but RMC
> feature won't be fully functional.
> 
> +To install only the RMC client with the systemd-boot bootloader without
> +including a default RMC database file, add the following lines to your
> +local.conf:
> +
> +EFI_PROVIDER = "systemd-boot"
> +IMAGE_INSTALL_append = " rmc”
I think this use case could confuse for user without much benefit. And actually 
they still can set EFI_PROVIDER to any available efi bootloaders to get this 
effect as long as it is not “rmc-boot”, right?
Maybe we should just say “you won’t get rmc database deployed if you set 
EFI_PROVIDER to any values not rmc-boot."
> 
> 
> 
> Examples
> @@ -190,7 +200,7 @@ EXAMPLE 1: Support a new board type:
> (1) enable the feature and do a build to get a live-boot image by adding these
> lines in conf/local.conf:
> DISTRO_FEATURES_append = " rmc"
> -EFI_PROVIDER = "rmc-systemd-boot"
> +EFI_PROVIDER = "rmc-boot"
> 
> (2) flash the image to a USB stick and boot it on your board
> 
> -- 
> 2.11.0
> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] rmc: Extend usages of RMC_BOARD_DATA_DIRS to specify board data

[Jianxun Zhang]

Use the variable RMC_BOARD_DATA_DIRS, to disable, append to, or
override the default board data in meta-intel with boards' data
provided by users.

Ideally, users should get the updated database in the new built
image after an incremental build.

Examples of RMC database output (db):

RMC_BOARD_DATA_DIRS  = "" (disable db generation)
RMC_BOARD_DATA_DIRS_append = " top_dir" (db of defaults & user's)
RMC_BOARD_DATA_DIRS = "top_dir" (db for user's , no defaults)
RMC_BOARD_DATA_DIRS  = " " (same as "")

Signed-off-by: Jianxun Zhang 
---
 classes/rmc-boot.bbclass |  6 +-
 common/recipes-bsp/rmc/rmc-db.bb |  3 ++-
 documentation/rmc/README | 41 
 3 files changed, 32 insertions(+), 18 deletions(-)

diff --git a/classes/rmc-boot.bbclass b/classes/rmc-boot.bbclass
index a1f2093..37c3e30 100644
--- a/classes/rmc-boot.bbclass
+++ b/classes/rmc-boot.bbclass
@@ -9,5 +9,9 @@ inherit ${RMC_BOOTLOADER}
 do_bootimg[depends] += "${MLPREFIX}rmc-db:do_deploy"
 
 efi_populate_append() {
-install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db ${DEST}/rmc.db
+   if [ -f ${DEPLOY_DIR_IMAGE}/rmc.db ]; then
+   install -m 0400 ${DEPLOY_DIR_IMAGE}/rmc.db ${DEST}/rmc.db
+   else
+   rm -f ${DEST}/rmc.db
+   fi
 }
diff --git a/common/recipes-bsp/rmc/rmc-db.bb b/common/recipes-bsp/rmc/rmc-db.bb
index 14553af..99565fd 100644
--- a/common/recipes-bsp/rmc/rmc-db.bb
+++ b/common/recipes-bsp/rmc/rmc-db.bb
@@ -14,7 +14,7 @@ S = "${WORKDIR}"
 
 inherit rmc-db
 
-RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/boards/"
+RMC_BOARD_DATA_DIRS ?= "${THISDIR}/boards/"
 RMC_DB_DIR = "${WORKDIR}/db"
 
 # Let sstate be aware of change in any added board directories
@@ -41,6 +41,7 @@ do_deploy () {
if [ -f ${RMC_DB_DIR}/rmc.db ]; then
install -m 0400 ${RMC_DB_DIR}/rmc.db ${DEPLOYDIR}
else
+   rm -f ${DEPLOYDIR}/rmc.db
echo "Warning: no RMC central database found, skip deployment."
fi
 }
diff --git a/documentation/rmc/README b/documentation/rmc/README
index dbee6b6..eaa763e 100644
--- a/documentation/rmc/README
+++ b/documentation/rmc/README
@@ -82,15 +82,31 @@ following this example, so that RMC recipes can pick up 
them correctly in build.
   |- ...more files
 
 Note 0:
-To add your boards into RMC feature, simply put this line in your
-rmc-db.bbappend:
+Developers are expected to use variable RMC_BOARD_DATA_DIRS to specify data of
+boards packed into RMC database file generated in a build. The default value of
+the variable in meta-intel specifies a group of boards. They work as examples
+and necessary quirks for these boards to function properly. Developers can
+override, append to the default boards with data of their own boards in the
+database file, or even disable the generation of the database file.
 
-RMC_BOARD_DATA_DIRS_append := " ${THISDIR}/my_top_dir"
+For example, in your local.conf file:
 
-RMC db recipe takes all top directories specified in RMC_BOARD_DATA_DIRS to
-construct and deploy a central RMC database inside image. The bbclass of the
-bare RMC project also provide function for other components to construct their
-own RMC database file. Please refer to rmc-db.bbclass for more information.
+This line adds your boards along with the default boards into RMC database 
file,
+assuming you have a directory named "rmc" which has a subdirectory for each
+board:
+
+RMC_BOARD_DATA_DIRS_append = " /path_of/rmc"
+
+This line directs RMC to pack data of your boards only, without data of the
+default boards in meta-intel:
+
+RMC_BOARD_DATA_DIRS = "/path_of/rmc"
+
+And this line disables database generation:
+
+RMC_BOARD_DATA_DIRS = ""
+
+Please also refer to the "Example 1" in this document.
 
 Subdirectory is not supported in a board's directory.
 
@@ -175,15 +191,8 @@ bootloader please overwrite the RMC_BOOTLOADER variable in 
your local.conf
 
 Note:
 Image could be still bootable if you only have either of two lines, but RMC
-feature won't be fully functional.
-
-To install only the RMC client with the systemd-boot bootloader without
-including a default RMC database file, add the following lines to your
-local.conf:
-
-EFI_PROVIDER = "systemd-boot"
-IMAGE_INSTALL_append = " rmc"
-
+feature could not be fully functional, depending on the availability of the
+database file, installer and the rmc tool.
 
 Examples
 

-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

[meta-intel] [PATCH] systemd-boot: update 230 -> 232

[Jianxun Zhang]

This change updates the locked systemd-boot revision to v232
release which is the current in OE.

Signed-off-by: Jianxun Zhang 
---
Pre-submission RMC test passed on these boards:
Live boot (hddimg)
Nuc gen 6
Broxton-M
Gelileo gen 2 (quark)
T100TA (32 bit)
Minowmax Turbot 32 bit (negtive test, we don't have turbot fingerprint and data)

Installation:
Nuc gen 6

Note:
A patch in systemd-boot to workaround key pressing issue on Broxton-M also 
enables the scrolling in boot loader menu on the old T100TA.
The machine failed to boot after installation but it doesn't seem to be 
RMC-related.

I don't see the new case should be the deal breaker for this update.

Thanks

 common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend 
b/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
index 2aecc3f..12c1e5a 100644
--- a/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
+++ b/common/recipes-bsp/systemd-boot/systemd-boot_%.bbappend
@@ -11,8 +11,8 @@ EXTRA_OEMAKE_append_intel-x86-common = ' 
EFI_LDFLAGS="-L${STAGING_DIR_HOST}/usr/
 # 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_intel-x86-common = "3a74d4fc90cb322a4784a3515bef7118c8f8c5ba"
+# Revision: systemd v232 in OE
+SRCREV_intel-x86-common = "a1e2ef7ec912902d8142e7cb5830cbfb47dba86c"
 
 SRC_URI_append_intel-x86-common = " \
 file://0001-sd-boot-Link-RMC-library-into-bootloader.patch \
-- 
2.7.4

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/2] systemd-boot: use RMC database in EFI stub

[Jianxun Zhang]

I noticed there are several RMC patches in mailing list and should review them 
tomorrow. (Just returned from a vacation)

Refer to my initial comment for Saul’s. Appreciate Mikko going through the 
following up when I was off.


> On Feb 2, 2017, at 12:46 PM, Ylinen, Mikko  wrote:
> 
> Hi,
> 
> On Fri, Jan 27, 2017 at 6:05 PM, Wold, Saul  wrote:
> On Fri, 2017-01-27 at 15:36 +0200, Mikko Ylinen wrote:
> > systemd-boot's EFI stub can be built in an EFI executable
> > with the kernel, cmdline, and initrd.
> >
> > This commit enables the EFI stub code to use the RMC database
> > and appends the board specific cmdline (KBOOTPARAM) to the
> > built-in cmdline.
> >
> If we are going to expose the KBOOTPARAM this way, shouldn't that be
> done inside of RMC proper and a getter type of API to provide
> KBOOTPARAM directly?
Assuming this thoughts is to the upstream RMC project.

I have to stress my opinion. RMC is designed as a _generic_ file-based 
centralized solution so that any software (EFI and user space) could get its 
service within just 1~2 API calls.

KBOOTPARAM and how to parse or use its content is too client-specific. (Even 
the name “KBOOMPARAM” is derived from kernel doc, nothing about RMC).

Packing client-specifc stuff in RMC core could damage the scalability in the 
future. Say, how could we support bootloaders that need different behavior of 
KBOOTPARAM in RMC?

I understand people want to get rid of another copy of this logic, and am 
thinking maybe we should have a new file/API in systemd-boot as the shim (?)

Thanks



> 
> Makes a lot of sense to me. However, until that API is in place, I'd suggest
> we use what I'm proposing for the stub here (that's the same approach used 
> with
> the full bootloader as well).
Just want to point out the a small difference between main bootloader and stub 
at this point. the main is implemented with single-action APIs for a 
potentially better performance when query multiple files. The stub uses 
double-action API to simplify the code because it only read one file so far.
> 
> -- Mikko 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/2] systemd-boot: use RMC database in EFI stub

[Jianxun Zhang]

Reviewed + 1, beside from what in discussion of KBOOTPARAM refactoring.

> On Jan 27, 2017, at 5:36 AM, Mikko Ylinen  wrote:
> 
> systemd-boot's EFI stub can be built in an EFI executable
> with the kernel, cmdline, and initrd.
> 
> This commit enables the EFI stub code to use the RMC database
> and appends the board specific cmdline (KBOOTPARAM) to the
> built-in cmdline.
> 
> Signed-off-by: Mikko Ylinen 
> ---
> ...Link-RMC-library-into-bootloader-and-stub.patch | 39 +++
> ...-sd-boot-Link-RMC-library-into-bootloader.patch | 31 -
> ...-kernel-command-line-fragment-in-EFI-stub.patch | 81 ++
> .../systemd-boot/systemd-boot_%.bbappend   |  3 +-
> 4 files changed, 122 insertions(+), 32 deletions(-)
> create mode 100644 
> common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader-and-stub.patch
> delete mode 100644 
> common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
> create mode 100644 
> common/recipes-bsp/systemd-boot/systemd-boot/0004-sd-boot-Support-global-kernel-command-line-fragment-in-EFI-stub.patch
> 
> diff --git 
> a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader-and-stub.patch
>  
> b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader-and-stub.patch
> new file mode 100644
> index 000..2f248e2
> --- /dev/null
> +++ 
> b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader-and-stub.patch
> @@ -0,0 +1,39 @@
> +From fe1c2fdfe81f2ac2b41fe8543ba07f1911770d26 Mon Sep 17 00:00:00 2001
> +From: Jianxun Zhang 
> +Date: Sat, 21 May 2016 18:52:07 -0700
> +Subject: [PATCH] sd-boot: Link RMC library into bootloader and stub
> +
> +Add RMC library into bootloader binary and stub.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Jianxun Zhang 
> +---
> + Makefile.am | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/Makefile.am b/Makefile.am
> +index 305099ab6..9fb6f9b7b 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 -lrmcefi $(shell $(CC) 
> -print-libgcc-file-name); \
> + nm -D -u $@ | grep ' U ' && exit 1 || :
> + 
> + $(systemd_boot): $(systemd_boot_solib)
> +@@ -2852,7 +2852,7 @@ $(top_builddir)/src/boot/efi/%.o: 
> $(top_srcdir)/src/boot/efi/%.c $(addprefix $(t
> + 
> + $(stub_solib): $(stub_objects)
> + $(AM_V_CCLD)$(LD) $(efi_ldflags) $(stub_objects) \
> +--o $@ -lefi -lgnuefi $(shell $(CC) -print-libgcc-file-name); \
> ++-o $@ -lefi -lgnuefi -lrmcefi $(shell $(CC) 
> -print-libgcc-file-name); \
> + nm -D -u $@ | grep ' U ' && exit 1 || :
> + 
> + $(stub): $(stub_solib)
> +-- 
> +2.11.0
> +
> diff --git 
> a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
>  
> b/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
> deleted file mode 100644
> index 626efce..000
> --- 
> a/common/recipes-bsp/systemd-boot/systemd-boot/0001-sd-boot-Link-RMC-library-into-bootloader.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -From 1ccd031ce97501f8ee63f39e8794437d568115dc 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 library into bootloader
> -
> -Add RMC library 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..df176a5 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 -lrmcefi $(shell $(CC) 
> -print-libgcc-file-name); \
> - nm -D -u $@ | grep ' U ' && exit 1 || :
> - 
> - $(systemd_boot): $(syste

Re: [meta-intel] [PATCH 2/2] rmc: add Minnowboard Turbot board data

[Jianxun Zhang]

Reviewed +1

Thanks!

> On Jan 27, 2017, at 5:36 AM, Mikko Ylinen  wrote:
> 
> To be able to detect a Minnowboard Turbot, its fingerprint
> is needed in the RMC database.
> 
> This initial commit adds the fingerprint and a simple cmdline
> entry (KBOOTPARAM) for the board.
> 
> Signed-off-by: Mikko Ylinen 
> ---
> .../recipes-bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM   |   1 +
> .../rmc/boards/MinnowboardTurbot/minnowboardturbot.fp | Bin 0 -> 154 bytes
> 2 files changed, 1 insertion(+)
> create mode 100644 common/recipes-bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM
> create mode 100644 
> common/recipes-bsp/rmc/boards/MinnowboardTurbot/minnowboardturbot.fp
> 
> diff --git a/common/recipes-bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM 
> b/common/recipes-bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM
> new file mode 100644
> index 000..476b1fb
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/MinnowboardTurbot/KBOOTPARAM
> @@ -0,0 +1 @@
> +console=ttyS0,115200
> diff --git 
> a/common/recipes-bsp/rmc/boards/MinnowboardTurbot/minnowboardturbot.fp 
> b/common/recipes-bsp/rmc/boards/MinnowboardTurbot/minnowboardturbot.fp
> new file mode 100644
> index 
> ..9aa145f35b83cfd08d72b922193ee2072c441b72
> GIT binary patch
> literal 154
> zcmZQ%Ehx%QDNQbk&r8frW$?|+%gZlM%1 z2}v~ri$GawQE_H|9)o9INotNpkfwrTNq(+Ih_9xCb3mwqf~&EGk(q*mgMy)+iJ7}c
> T6+=BkQEG8&QCVsV0}2}eM1L?f
> 
> literal 0
> HcmV?d1
> 
> -- 
> 2.11.0
> 
> -
> Intel Finland Oy
> Registered Address: PL 281, 00181 Helsinki 
> Business Identity Code: 0357606 - 4 
> Domiciled in Helsinki 
> 
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
> 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 1/3] Makefile: add verbosity and debug options to Makefile

[Jianxun Zhang]

Todor,
Please refer to my 2 inline comments.

> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> wrote:
> 
> By default Makefile verbosity is disabled (V=0). Verbosity can be enabled by
> setting the V environment variable to any value not equal to 0 (e.g V=1)
> 
> Example:
> make clean V=1; make V=1
> 
> A debug version of the rmc binary can be built by using the debug
> Makefile target. This will include debug symbols and will disable compiler
> optimizations when compiling rmc.
> 
> Example:
> 
> make debug
> 
> Signed-off-by: Todor Minchev 
> ---
> Makefile | 31 +--
> 1 file changed, 21 insertions(+), 10 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 9ade775..d85d8e9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,5 +1,12 @@
> # Copyright (C) 2016 Jianxun Zhang 
> 
> +V ?= 0
> +ifeq ($(V),0)
> +  VERBOSITY = @
> +else
> +  VERBOSITY =
> +endif
> +
I am thinking maybe we should remove ‘@‘ in rules and use -s option of make (in 
recipe) when we want to mute the output. This should reach the same effect 
without bothering new variables.

We still enable/disable output as a whole anyway.

Let me know if this proposal works for you.

> TOPDIR = $(shell if [ -z "$$PWD" ]; then pwd; else echo "$$PWD"; fi)
> 
> RMC_TOOL_SRC := $(wildcard src/*.c)
> @@ -20,28 +27,32 @@ RMC_INSTALL_HEADER_PATH := 
> $(RMC_INSTALL_PREFIX)/include/rmc/
> 
> ALL_OBJS := $(RMC_TOOL_OBJ) $(RMC_LIB_OBJ)
> 
> +
> RMC_CFLAGS := -Wall -I$(TOPDIR)/inc
> 
> all: rmc
> +debug: RMC_CFLAGS += -DDEBUG -g -O0
> +debug: rmc
I am not sure if this is necessary because we already have CFLAGS. I think you 
can reach the same effect without adding a new debug target:
make CFLAGS='-DDEBUG -g -O0’

also refer to commit e8b48e6 in rmc project.

> 
> $(ALL_OBJS): %.o: %.c
> - @$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> + $(VERBOSITY)$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> 
> librmc: $(RMC_LIB_OBJ)
> - @$(AR) rcs src/lib/$@.a $^
> + $(VERBOSITY)$(AR) rcs src/lib/$@.a $^
> 
> rmc: $(RMC_TOOL_OBJ) librmc
> - @$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc $(RMC_TOOL_OBJ) 
> src/lib/librmc.a -o src/$@
> + $(VERBOSITY)$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc 
> $(RMC_TOOL_OBJ) \
> +  src/lib/librmc.a -o src/$@
> 
> clean:
> - @rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> + $(VERBOSITY)rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> 
> .PHONY: clean rmc librmc
> 
> install:
> - @mkdir -p $(RMC_INSTALL_BIN_PATH)
> - @install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> - @mkdir -p $(RMC_INSTALL_LIB_PATH)
> - @install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> - @mkdir -p $(RMC_INSTALL_HEADER_PATH)
> - @install -m 644 $(RMC_INSTALL_HEADERS) $(RMC_INSTALL_HEADER_PATH)
> + $(VERBOSITY)mkdir -p $(RMC_INSTALL_BIN_PATH)
> + $(VERBOSITY)install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> + $(VERBOSITY)mkdir -p $(RMC_INSTALL_LIB_PATH)
> + $(VERBOSITY)install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> + $(VERBOSITY)mkdir -p $(RMC_INSTALL_HEADER_PATH)
> + $(VERBOSITY)install -m 644 $(RMC_INSTALL_HEADERS) 
> $(RMC_INSTALL_HEADER_PATH)
> -- 
> 2.11.0
> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH 2/3] rmc: Enable reading the contents of an existing fingerprint file

[Jianxun Zhang]

Tudor,
Please refer to my 3 inline comments.

> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> wrote:
> 
> The contents of an existing fingerprint file can be read and output on
> the command line with the following options:
> 
> ./rmc -F -i input_fingerprint_file
Suggest we have a new top option for dumping in parallel with -F to keep usages 
clear and simple for users.

> 
> Signed-off-by: Todor Minchev 
> ---
> src/rmc.c | 121 +++---
> 1 file changed, 76 insertions(+), 45 deletions(-)
> 
> diff --git a/src/rmc.c b/src/rmc.c
> index 062dd36..a051ccf 100644
> --- a/src/rmc.c
> +++ b/src/rmc.c
> @@ -14,33 +14,35 @@
> #include 
> 
> #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
> -"NOTE: Most of usages require root permission (sudo)\n" \
> -"rmc -F [-o output_fingerprint]\n" \
> +"NOTE: Most of usages require root permission (sudo)\n\n" \
> +"rmc -F [-o output_fingerprint] | -i input_fingerprint\n" \
> "rmc -R [-f ] -b  [-o output_record]\n" 
> \
> "rmc -D  [-o output_database]\n" \
> - "rmc -B  -d  -o output_file\n" \
> - "\n" \
> - "-F: generate board rmc fingerprint of board\n" \
> - "-R: generate board rmc record of board with its fingerprint and file 
> blobs.\n" \
> -"-f: fingerprint file to be packed in record, rmc will create a 
> fingerprint for board and use it internally to\n" \
> -"generate record if -f is missed.\n" \
> -"-b: files to be packed in record\n" \
> - "-G: generate rmc database file with records specified in record file 
> list\n" \
> - "-B: get a flie blob with specified name associated to the board rmc is 
> running on\n" \
> - "-d: database file to be queried\n" \
> - "-o: path and name of output file of a specific command\n" \
> - "\n" \
> -"Examples (Steps in an order to add board support into rmc):\n" \
> -"generate board fingerprint:\n" \
> -"rmc -F\n\n" \
> -"generate a rmc record for the board with two file blobs, output to:\n" \
> -"a specified file:\n" \
> -"rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> -"generate a rmc database file with records from 3 different boards:\n" \
> -"rmc -D board1_record board2_record board3_record\n\n" \
> -"query a file blob named audio.conf associated to the board rmc is 
> running on in database my_rmc.db and output\n" \
> -"to /tmp/new_audio.conf:\n" \
> -"rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> +"rmc -B  -d  -o output_file\n\n" \
> +  "-F: manage fingerprint file\n" \
> +"\t-o output_file: store RMC fingerprint of current board in 
> output_file\n" \
> +"\t-i input_file: print RMC fingerprint stored in input_file\n\n" \
> +  "-R: generate board rmc record of board with its fingerprint and file 
> blobs.\n" \
> +"\t-f intput_file : input fingerprint file to be packed in record\n\n" \
> +"\tNOTE: RMC will create a fingerprint for the board and use it to\n" \
> +"\tgenerate record if an input fingerprint file is not provided.\n\n" \
> +"\t-b: files to be packed in record\n\n" \
> +  "-G: generate rmc database file with records specified in record file 
> list\n\n" \
> +  "-B: get a file blob with specified name associated to the board rmc is\n" 
> \
> +  "running on\n" \
> +"\t-d: database file to be queried\n" \
> +"\t-o: path and name of output file of a specific command\n\n" \
> +"Examples (Steps in an order to add board support into rmc):\n\n" \
> +"1. Generate board fingerprint:\n" \
> +"\t./rmc -F\n\n” \
Why do we force the rmc in current dir here? rmc can be installed to a system 
path like other programs.

> +"2. Generate a rmc record for the board with two file blobs and save 
> it\n" \
> +"to a specified file:\n" \
> +"\t./rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> +"3. Generate a rmc database file with records from 3 different 
> boards:\n" \
> +"\t./rmc -D board1_record board2_record board3_record\n\n" \
> +"4. Query a file blob named audio.conf associated to the board rmc is\n" 
> \
> +"running on in database my_rmc.db and output to /tmp/new_audio.conf:\n" \
> +"\t./rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> 
> 
> #define RMC_OPT_CAP_F   (1 << 0)
> @@ -51,6 +53,7 @@
> #define RMC_OPT_O   (1 << 5)
> #define RMC_OPT_B   (1 << 6)
> #define RMC_OPT_D   (1 << 7)
> +#define RMC_OPT_I   (1 << 8)
> 
> static void usage () {
> fprintf(stdout, USAGE);
> @@ -78,7 +81,7 @@ static void dump_fingerprint(rmc_fingerprint_t *fp) {
> static int write_fingerprint_file(const char* pathname, rmc_fingerprint_t 
> *fp) {
> int i;
> int first = 0;
> -
> +/* TODO - do we need to open/close file multiple times to write each 
> field */
> for (i = 0; i < RMC_FINGER_NUM; i++) {
> if (write_file(pathname, &fp->rmc_fingers[i].type, 
> sizeof(fp->rmc_fingers[i].type)

Re: [meta-intel] [PATCH 3/3] rmc: add database extraction functionality

[Jianxun Zhang]

Todor,
Nice change overall. I haven’t run any test and just share multiple (11) inline 
comments for this patch.

This should be the last one in the series. Please let me know if I missed any 
other RMC patches for review.

I plan to run rmc internal test once we have an updated patch set. We could 
need to add a new test case for the dumping feature in the future.

You can refer to the README in rmc project for the pipeline of merging.

Thanks!

> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
> wrote:
> 
> The contents of an existing database file can be extracted in the
> current working directory with the -E option. The top level of the
> directory tree is rmc_db_dump and all files corresponding to
> a given record will be saved in a separate sub-directory. The sub-directory
> name of each record is the signature corresponding to the fingerprint for
> that record.
> 
> Example:
> ./src/rmc -E -d rmc.db
> 
> Successfully extracted rmc.db
> 
> Signed-off-by: Todor Minchev 
> ---
> inc/rmc_api.h |  9 ++
> src/lib/api.c | 85 +--
> src/lib/common/rmcl.c |  3 +-
> src/rmc.c | 44 +++---
> 4 files changed, 126 insertions(+), 15 deletions(-)
> 
> diff --git a/inc/rmc_api.h b/inc/rmc_api.h
> index a484389..ce26220 100644
> --- a/inc/rmc_api.h
> +++ b/inc/rmc_api.h
> @@ -74,6 +74,15 @@ extern int rmc_query_file_by_fp(rmc_fingerprint_t *fp, 
> char *db_pathname, char *
>  */
> extern int rmc_gimme_file(char* db_pathname, char *file_name, rmc_file_t 
> *file);
> 
> +
> +/* extract the contents of a database file and store the files corresponding 
> to
> + * each record in a separate directory. The name of each directory is the 
> signature
> + * of the fingerpring for that record
> + * (in) db_pathname: The path and file name of a RMC database file generated 
> by RMC tool
> + * return: 0 on success, non-zero on failure.
> + */
> +int dump_db(char *db_pathname) ;
> +
Please move this into section 1.3, somewhere after next line. It doesn’t belong 
to section 1.2 “double-action API”

> /* 1.3 - Helper APIs */
> 
> /* Free allocated data referred in a fingerprint
> diff --git a/src/lib/api.c b/src/lib/api.c
> index 0adb390..aca8d99 100644
> --- a/src/lib/api.c
> +++ b/src/lib/api.c
> @@ -3,6 +3,7 @@
>  * RMC API implementation for Linux user space
>  */
> 
> +#define _GNU_SOURCE
> #include 
> #include 
> #include 
> @@ -14,8 +15,11 @@
> #include 
> #include 
> 
> -#define EFI_SYSTAB_PATH "/sys/firmware/efi/systab"
> -#define SYSTAB_LEN 4096 /* assume 4kb is enough...*/
> +#define EFI_SYSTAB_PATH  "/sys/firmware/efi/systab"
> +#define SYSTAB_LEN   4096 /* assume 4kb is enough...*/
> +#define DB_DUMP_DIR  "./rmc_db_dump"  /* directory to store db data dump 
> */
> +
> +extern const rmc_uint8_t rmc_db_signature[RMC_DB_SIG_LEN];
We could have a new small helper API like is_rmcdb(db_blob) in RMCL to hold 
checker logic at line 357 in this file, so that we can get rid of this line and 
make the checker reusable. (So far I feel the checker should work in both EFI 
and Linux contexts.)

We could even update checker API without bothering its callers in the future. 
Let me know if it makes sense...

> 
> int read_file(const char *pathname, char **data, rmc_size_t* len) {
> int fd = -1;
> @@ -325,3 +329,80 @@ int rmc_gimme_file(char* db_pathname, char *file_name, 
> rmc_file_t *file) {
> 
> return ret;
> }
> +
> +/*
> + * Dump contents of database file
> + * (in) rmc_db - input database file to extract
rmc_db VS db_pathname. I think we can remove the comment here, it is already in 
the header file.
> + */
> +int dump_db(char *db_pathname) {
> +rmc_meta_header_t meta_header;
> +rmc_db_header_t *db_header = NULL;
> +rmc_record_header_t record_header;
> +rmc_uint64_t record_idx = 0;   /* offset of each reacord in db*/
> +rmc_uint64_t meta_idx = 0; /* offset of each meta in a record */
> +rmc_uint64_t file_idx = 0; /* offset of file in a meta */
> +rmc_file_t file;
> +char *out_dir = NULL, *out_name = NULL;
> +rmc_size_t db_len = 0;
> +rmc_uint8_t *rmc_db = NULL;
> +struct stat s = {0};
> +
> +if (read_file(db_pathname, (char **)&rmc_db, &db_len)) {
> +fprintf(stderr, "Failed to read database file\n\n");
> +return 1;
> +}
> +
> +db_header = (rmc_db_header_t *)rmc_db;
> +
> +/* sanity check of db */
> +if (strncmp((const char *)db_header->signature,
> +(const char *)rmc_db_signature, RMC_DB_SIG_LEN))
> +return 1;
> +
> +/* create the top level directory */
> +if (stat(DB_DUMP_DIR, &s) == -1) {
> +if(mkdir(DB_DUMP_DIR, 0755)) {
> +fprintf(stderr, "Failed to create %s directory\n\n", out_name);
I think we should not go any further when we cannot create the top dir.
> +}
> +}
> +
> +/* query the meta. idx: start of record */
> +record_idx = sizeof(rmc_db_he

Re: [meta-intel] [PATCH 2/3] rmc: Enable reading the contents of an existing fingerprint file

[Jianxun Zhang]

> On Feb 6, 2017, at 2:28 PM, Todor Minchev  
> wrote:
> 
> On Mon, 2017-02-06 at 12:01 -0800, Jianxun Zhang wrote:
>> Tudor,
>> Please refer to my 3 inline comments.
>> 
>>> On Feb 2, 2017, at 2:37 PM, Todor Minchev  
>>> wrote:
>>> 
>>> The contents of an existing fingerprint file can be read and output on
>>> the command line with the following options:
>>> 
>>> ./rmc -F -i input_fingerprint_file
>> Suggest we have a new top option for dumping in parallel with -F to keep 
>> usages clear and simple for users.
> 
> We can use -E to extract both the database and the fingerprint?
> 
> rmc -E -d rmc.db
> rmc -E -f rmc.fingerprint
good idea.
> 
>>> 
>>> Signed-off-by: Todor Minchev 
>>> ---
>>> src/rmc.c | 121 
>>> +++---
>>> 1 file changed, 76 insertions(+), 45 deletions(-)
>>> 
>>> diff --git a/src/rmc.c b/src/rmc.c
>>> index 062dd36..a051ccf 100644
>>> --- a/src/rmc.c
>>> +++ b/src/rmc.c
>>> @@ -14,33 +14,35 @@
>>> #include 
>>> 
>>> #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
>>> -"NOTE: Most of usages require root permission (sudo)\n" \
>>> -"rmc -F [-o output_fingerprint]\n" \
>>> +"NOTE: Most of usages require root permission (sudo)\n\n" \
>>> +"rmc -F [-o output_fingerprint] | -i input_fingerprint\n" \
>>>"rmc -R [-f ] -b  [-o 
>>> output_record]\n" \
>>>"rmc -D  [-o output_database]\n" \
>>> -   "rmc -B  -d  -o output_file\n" \
>>> -   "\n" \
>>> -   "-F: generate board rmc fingerprint of board\n" \
>>> -   "-R: generate board rmc record of board with its fingerprint and file 
>>> blobs.\n" \
>>> -"-f: fingerprint file to be packed in record, rmc will create a 
>>> fingerprint for board and use it internally to\n" \
>>> -"generate record if -f is missed.\n" \
>>> -"-b: files to be packed in record\n" \
>>> -   "-G: generate rmc database file with records specified in record file 
>>> list\n" \
>>> -   "-B: get a flie blob with specified name associated to the board rmc is 
>>> running on\n" \
>>> -   "-d: database file to be queried\n" \
>>> -   "-o: path and name of output file of a specific command\n" \
>>> -   "\n" \
>>> -"Examples (Steps in an order to add board support into rmc):\n" \
>>> -"generate board fingerprint:\n" \
>>> -"rmc -F\n\n" \
>>> -"generate a rmc record for the board with two file blobs, output 
>>> to:\n" \
>>> -"a specified file:\n" \
>>> -"rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
>>> -"generate a rmc database file with records from 3 different boards:\n" 
>>> \
>>> -"rmc -D board1_record board2_record board3_record\n\n" \
>>> -"query a file blob named audio.conf associated to the board rmc is 
>>> running on in database my_rmc.db and output\n" \
>>> -"to /tmp/new_audio.conf:\n" \
>>> -"rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
>>> +"rmc -B  -d  -o output_file\n\n" 
>>> \
>>> +  "-F: manage fingerprint file\n" \
>>> +"\t-o output_file: store RMC fingerprint of current board in 
>>> output_file\n" \
>>> +"\t-i input_file: print RMC fingerprint stored in input_file\n\n" \
>>> +  "-R: generate board rmc record of board with its fingerprint and file 
>>> blobs.\n" \
>>> +"\t-f intput_file : input fingerprint file to be packed in record\n\n" 
>>> \
>>> +"\tNOTE: RMC will create a fingerprint for the board and use it to\n" \
>>> +"\tgenerate record if an input fingerprint file is not provided.\n\n" \
>>> +"\t-b: files to be packed in record\n\n" \
>>> +  "-G: generate rmc database file with records specified in record file 
>>> list\n\n" \
>>> +  "-B: get a file blob with specified name associated to the board rmc 
>>> is\n" \
>>> +  "running on\n" \
>>> +"\t-d: database file t

Re: [meta-intel] [PATCH v2 1/5] Makefile: disable silent mode in Makefiles

[Jianxun Zhang]

Review +1,
Thanks to address my comment

> On Feb 9, 2017, at 11:17 AM, Todor Minchev  
> wrote:
> 
> By default make will output the commands that are executed for each
> target. Silent mode can be enabled with the '-s' option.
> 
> Example:
> make -s
> 
> Signed-off-by: Todor Minchev 
> ---
> Makefile | 21 +++--
> Makefile.efi | 10 +-
> 2 files changed, 16 insertions(+), 15 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 9ade775..c58047a 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -25,23 +25,24 @@ RMC_CFLAGS := -Wall -I$(TOPDIR)/inc
> all: rmc
> 
> $(ALL_OBJS): %.o: %.c
> - @$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> + $(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> 
> librmc: $(RMC_LIB_OBJ)
> - @$(AR) rcs src/lib/$@.a $^
> + $(AR) rcs src/lib/$@.a $^
> 
> rmc: $(RMC_TOOL_OBJ) librmc
> - @$(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc $(RMC_TOOL_OBJ) 
> src/lib/librmc.a -o src/$@
> + $(CC) $(CFLAGS) $(RMC_CFLAGS) -Lsrc/lib/ -lrmc $(RMC_TOOL_OBJ) \
> +  src/lib/librmc.a -o src/$@
> 
> clean:
> - @rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> + rm -f $(ALL_OBJS) src/rmc src/lib/librmc.a
> 
> .PHONY: clean rmc librmc
> 
> install:
> - @mkdir -p $(RMC_INSTALL_BIN_PATH)
> - @install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> - @mkdir -p $(RMC_INSTALL_LIB_PATH)
> - @install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> - @mkdir -p $(RMC_INSTALL_HEADER_PATH)
> - @install -m 644 $(RMC_INSTALL_HEADERS) $(RMC_INSTALL_HEADER_PATH)
> + mkdir -p $(RMC_INSTALL_BIN_PATH)
> + install -m 755 src/rmc $(RMC_INSTALL_BIN_PATH)
> + mkdir -p $(RMC_INSTALL_LIB_PATH)
> + install -m 644 src/lib/librmc.a $(RMC_INSTALL_LIB_PATH)
> + mkdir -p $(RMC_INSTALL_HEADER_PATH)
> + install -m 644 $(RMC_INSTALL_HEADERS) $(RMC_INSTALL_HEADER_PATH)
> diff --git a/Makefile.efi b/Makefile.efi
> index 3bd417d..66081d7 100644
> --- a/Makefile.efi
> +++ b/Makefile.efi
> @@ -18,16 +18,16 @@ RMC_CFLAGS := -DRMC_EFI -Wall -I$(TOPDIR)/inc -fpic 
> -nostdinc -nostdlib  -fno-bu
> all: librmcefi
> 
> $(RMC_LIB_OBJ): %.efi.o: %.c
> - @$(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> + $(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> 
> librmcefi: $(RMC_LIB_OBJ)
> - @$(AR) rcs src/lib/$@.a $^
> + $(AR) rcs src/lib/$@.a $^
> 
> clean:
> - @rm -f $(RMC_LIB_OBJ) src/lib/librmcefi.a
> + rm -f $(RMC_LIB_OBJ) src/lib/librmcefi.a
> 
> .PHONY: clean librmcefi
> 
> install:
> - @mkdir -p $(RMC_INSTALL_LIB_PATH)
> - @install -m 644 $(RMC_INSTALL_LIBS) $(RMC_INSTALL_LIB_PATH)
> + mkdir -p $(RMC_INSTALL_LIB_PATH)
> + install -m 644 $(RMC_INSTALL_LIBS) $(RMC_INSTALL_LIB_PATH)
> -- 
> 2.11.1
> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH v2 2/5] Makefile: add debug target

[Jianxun Zhang]

> On Feb 9, 2017, at 11:17 AM, Todor Minchev  
> wrote:
> 
> A debug version of the rmc binary can be built by using the debug
> Makefile target. This will include debug symbols and will disable
> compiler optimizations.
> 
> Example:
> 
> make debug
> 
> Signed-off-by: Todor Minchev 
> ---
> Makefile | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/Makefile b/Makefile
> index c58047a..fdd936f 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -23,6 +23,8 @@ ALL_OBJS := $(RMC_TOOL_OBJ) $(RMC_LIB_OBJ)
> RMC_CFLAGS := -Wall -I$(TOPDIR)/inc
> 
> all: rmc
> +debug: RMC_CFLAGS += -DDEBUG -g -O0
> +debug: rmc
> 
I missed your feedback of V1, just recap it here also with my comment:

- "Yup, the above will have the same effect as 'make debug'.
I thought that 'make debug' might be a convenient way to build a debug
binary? Do you think it makes sense to keep this extra target for
convenience since it doesn't affect the other usages of make?"

You could have to come back to CFLAGS when the a hard coded debug flags is not 
enough.

And, why pass -DDEBUG in RMC_CFLAGS when invoking gcc to compile rmc? I don’t 
see this macro DEBUG in the current rmc code.

Thanks
> $(ALL_OBJS): %.o: %.c
>   $(CC) -c $(CFLAGS) $(RMC_CFLAGS) $< -o $@
> -- 
> 2.11.1
> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH v2 3/5] rmc: Enable reading the contents of an existing fingerprint file

[Jianxun Zhang]

> On Feb 9, 2017, at 11:17 AM, Todor Minchev  
> wrote:
> 
> The contents of an existing fingerprint file can be read and output on
> the command line with the following options:
> 
> rmc -E -f input_fingerprint_file
> 
> Signed-off-by: Todor Minchev 
> ---
> src/rmc.c | 98 ++-
> 1 file changed, 65 insertions(+), 33 deletions(-)
> 
> diff --git a/src/rmc.c b/src/rmc.c
> index 062dd36..f3a2a5e 100644
> --- a/src/rmc.c
> +++ b/src/rmc.c
> @@ -14,43 +14,47 @@
> #include 
> 
> #define USAGE "RMC (Runtime Machine configuration) Tool\n" \
> -"NOTE: Most of usages require root permission (sudo)\n" \
> +"NOTE: Most of usages require root permission (sudo)\n\n" \
> "rmc -F [-o output_fingerprint]\n" \
> "rmc -R [-f ] -b  [-o output_record]\n" 
> \
> "rmc -D  [-o output_database]\n" \
> - "rmc -B  -d  -o output_file\n" \
> - "\n" \
> - "-F: generate board rmc fingerprint of board\n" \
> - "-R: generate board rmc record of board with its fingerprint and file 
> blobs.\n" \
> -"-f: fingerprint file to be packed in record, rmc will create a 
> fingerprint for board and use it internally to\n" \
> -"generate record if -f is missed.\n" \
> -"-b: files to be packed in record\n" \
> - "-G: generate rmc database file with records specified in record file 
> list\n" \
> - "-B: get a flie blob with specified name associated to the board rmc is 
> running on\n" \
> - "-d: database file to be queried\n" \
> - "-o: path and name of output file of a specific command\n" \
> - "\n" \
> -"Examples (Steps in an order to add board support into rmc):\n" \
> -"generate board fingerprint:\n" \
> -"rmc -F\n\n" \
> -"generate a rmc record for the board with two file blobs, output to:\n" \
> -"a specified file:\n" \
> -"rmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> -"generate a rmc database file with records from 3 different boards:\n" \
> -"rmc -D board1_record board2_record board3_record\n\n" \
> -"query a file blob named audio.conf associated to the board rmc is 
> running on in database my_rmc.db and output\n" \
> -"to /tmp/new_audio.conf:\n" \
> -"rmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> +"rmc -B  -d  -o output_file\n\n" \
> +  "-F: manage fingerprint file\n" \
> +"\t-o output_file: store RMC fingerprint of current board in 
> output_file\n" \
> +  "-R: generate board rmc record of board with its fingerprint and file 
> blobs.\n" \
> +"\t-f intput_file : input fingerprint file to be packed in record\n\n" \
> +"\tNOTE: RMC will create a fingerprint for the board and use it to\n" \
> +"\tgenerate record if an input fingerprint file is not provided.\n\n" \
> +"\t-b: files to be packed in record\n\n" \
> +  "-G: generate rmc database file with records specified in record file 
> list\n\n" \
> +  "-B: get a file blob with specified name associated to the board rmc is\n" 
> \
> +  "running on\n" \
> +"\t-d: database file to be queried\n" \
> +"\t-o: path and name of output file of a specific command\n\n" \
> +  "-E: Extract data from fingerprint file and print it to terminal\n" \
> +"\t-f: fingerprint file to extract\n\n" \
> +"Examples (Steps in an order to add board support into rmc):\n\n" \
> +"1. Generate board fingerprint:\n" \
> +"\trmc -F\n\n" \
> +"2. Generate a rmc record for the board with two file blobs and save 
> it\n" \
> +"to a specified file:\n" \
> +"\trmc -R -f fingerprint -b file_1 file_2 -o my_board.record\n\n" \
> +"3. Generate a rmc database file with records from 3 different 
> boards:\n" \
> +"\trmc -D board1_record board2_record board3_record\n\n" \
> +"4. Query a file blob named audio.conf associated to the board rmc is\n" 
> \
> +"running on in database my_rmc.db and output to /tmp/new_audio.conf:\n" \
> +"\trmc -B audio.conf -d my_rmc.db -o /tmp/new_audio.conf\n\n"
> 
> 
> #define RMC_OPT_CAP_F   (1 << 0)
> #define RMC_OPT_CAP_R   (1 << 1)
> #define RMC_OPT_CAP_D   (1 << 2)
> #define RMC_OPT_CAP_B   (1 << 3)
> -#define RMC_OPT_F   (1 << 4)
> -#define RMC_OPT_O   (1 << 5)
> -#define RMC_OPT_B   (1 << 6)
> -#define RMC_OPT_D   (1 << 7)
> +#define RMC_OPT_CAP_E   (1 << 4)
> +#define RMC_OPT_F   (1 << 5)
> +#define RMC_OPT_O   (1 << 6)
> +#define RMC_OPT_B   (1 << 7)
> +#define RMC_OPT_D   (1 << 8)
> 
> static void usage () {
> fprintf(stdout, USAGE);
> @@ -78,7 +82,7 @@ static void dump_fingerprint(rmc_fingerprint_t *fp) {
> static int write_fingerprint_file(const char* pathname, rmc_fingerprint_t 
> *fp) {
> int i;
> int first = 0;
> -
> +/* TODO - do we need to open/close file multiple times to write each 
> field */
> for (i = 0; i < RMC_FINGER_NUM; i++) {
> if (write_file(pathname, &fp->rmc_fingers[i].type, 
> sizeof(fp->rmc_fingers[i].type), first))
>  

Re: [meta-intel] [PATCH v2 4/5] rmc: remove unnecessary return variable

[Jianxun Zhang]

Nice. Review +1

> On Feb 9, 2017, at 11:17 AM, Todor Minchev  
> wrote:
> 
> Signed-off-by: Todor Minchev 
> ---
> src/rmc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/src/rmc.c b/src/rmc.c
> index f3a2a5e..b5c7847 100644
> --- a/src/rmc.c
> +++ b/src/rmc.c
> @@ -218,7 +218,6 @@ read_fp_done:
> static rmc_file_t *read_policy_file(char *pathname, int type) {
> rmc_file_t *tmp = NULL;
> rmc_size_t policy_len = 0;
> -int ret;
> char *path_token;
> 
> if ((tmp = calloc(1, sizeof(rmc_file_t))) == NULL) {
> @@ -230,8 +229,7 @@ static rmc_file_t *read_policy_file(char *pathname, int 
> type) {
> tmp->next = NULL;
> 
> if (type == RMC_GENERIC_FILE) {
> -ret = read_file(pathname, (char **)&tmp->blob, &policy_len);
> -if (ret) {
> +if (read_file(pathname, (char **)&tmp->blob, &policy_len)) {
> fprintf(stderr, "Failed to read file %s\n\n", pathname);
> free(tmp);
> return NULL;
> -- 
> 2.11.1
> 

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel

Re: [meta-intel] [PATCH v2 5/5] rmc: add database extraction functionality

[Jianxun Zhang]

Todor,
Appreciate the V2 series. I have only one real concern on using system() in 
this patch and the whole series. The other comments are more for corner cases 
which have less impact.

I could miss some of your feedbacks in V1 threads. Sorry for not to point out 
things earlier before the V2.

Thanks

> On Feb 9, 2017, at 11:17 AM, Todor Minchev  
> wrote:
> 
> The contents of an existing database file can be extracted with the -E option.
> By default the top level of the directory tree is rmc_db_dump, an alternative
> path can be specified with the -o option. The file blobs corresponding
> to a given record will be saved in a separate sub-directory. The sub-directory
> name of each record is the signature corresponding to the fingerprint for that
> record with all non-alphanumeric characters stripped.
> 
> Example:
> ./src/rmc -E -d rmc.db -o output/directory/
> 
> Successfully extracted rmc.db
> 
> Signed-off-by: Todor Minchev 
> ---
> inc/rmc_api.h |   9 +
> inc/rmcl.h|   7 
> src/lib/api.c | 106 +-
> src/lib/common/rmcl.c |  17 +++-
> src/rmc.c |  30 +-
> 5 files changed, 157 insertions(+), 12 deletions(-)
> 
> diff --git a/inc/rmc_api.h b/inc/rmc_api.h
> index a484389..2f8c978 100644
> --- a/inc/rmc_api.h
> +++ b/inc/rmc_api.h
> @@ -109,6 +109,15 @@ extern int read_file(const char *pathname, char **data, 
> rmc_size_t* len);
>  */
> int write_file(const char *pathname, void *data, rmc_size_t len, int append);
> 
> +/* extract the contents of a database file and store the files corresponding 
> to
> + * each record in a separate directory. The name of each directory is the 
> signature
> + * of the fingerpring for that record with all non-alphanumeric characters 
> stripped
> + * (in) db_pathname: The path and file name of a RMC database file generated 
> by RMC tool
> + * (in) output_path: A directory path to extract the database to
> + * return: 0 on success, non-zero on failure.
> + */
> +int dump_db(char *db_pathname, char *output_path) ;
> +
> #else
> /* 2 - API for UEFI context */
> 
> diff --git a/inc/rmcl.h b/inc/rmcl.h
> index 5bbad42..471ebfe 100644
> --- a/inc/rmcl.h
> +++ b/inc/rmcl.h
> @@ -164,4 +164,11 @@ extern int rmcl_generate_db(rmc_record_file_t 
> *record_files, rmc_uint8_t **rmc_d
>  */
> extern int query_policy_from_db(rmc_fingerprint_t *fingerprint, rmc_uint8_t 
> *rmc_db, rmc_uint8_t type, char *blob_name, rmc_file_t *policy);
> 
> +/*
> + * Check if db_blob has a valid rmc database signature
> + *
> + * return 0 if db_blob has a valid signature or non-zero otherwise
> + */
> +int is_rmcdb(rmc_uint8_t *db_blob);
> +
> #endif /* INC_RMCL_H_ */
> diff --git a/src/lib/api.c b/src/lib/api.c
> index 0adb390..56746a4 100644
> --- a/src/lib/api.c
> +++ b/src/lib/api.c
> @@ -3,6 +3,7 @@
>  * RMC API implementation for Linux user space
>  */
> 
> +#define _GNU_SOURCE
> #include 
> #include 
> #include 
> @@ -10,12 +11,15 @@
> #include 
> #include 
> #include 
> +#include 
> +#include 
> 
> #include 
> #include 
> 
> -#define EFI_SYSTAB_PATH "/sys/firmware/efi/systab"
> -#define SYSTAB_LEN 4096 /* assume 4kb is enough...*/
> +#define EFI_SYSTAB_PATH  "/sys/firmware/efi/systab"
> +#define SYSTAB_LEN   4096 /* assume 4kb is enough...*/
> +#define DB_DUMP_DIR  "./rmc_db_dump"  /* directory to store db data dump 
> */
> 
> int read_file(const char *pathname, char **data, rmc_size_t* len) {
> int fd = -1;
> @@ -325,3 +329,101 @@ int rmc_gimme_file(char* db_pathname, char *file_name, 
> rmc_file_t *file) {
> 
> return ret;
> }
> +
> +void remove_non_alphanum(char *in) {
> +char c;
> +unsigned long i = 0, j = 0;
> +
> +while ((c = in[i++]) != '\0'){
> +if (isalnum(c))
> +in[j++] = c;
I think this will work in the almost all the real cases. A corner case, though 
very rare, is two fingerprints differ each other _only_ by non alphnum 
characters. The dumps of two different fingerprints will be wrongly in the same 
dir as a result. (We can’t dictate what FW engineers put into bios)

Maybe in the future we could use ASCII code of hex values of a signature which 
is a field with a fixed length as dir name?

> +}
> +in[j] = '\0';
> +}
> +
> +int dump_db(char *db_pathname, char *output_path) {
> +rmc_meta_header_t meta_header;
> +rmc_db_header_t *db_header = NULL;
> +rmc_record_header_t record_header;
> +rmc_uint64_t record_idx = 0;   /* offset of each reacord in db*/
> +rmc_uint64_t meta_idx = 0; /* offset of each meta in a record */
> +rmc_uint64_t file_idx = 0; /* offset of file in a meta */
> +rmc_file_t file;
> +char *out_dir = NULL, *out_name = NULL, *cmd = NULL, *tmp_dir_name = 
> NULL;
> +rmc_size_t db_len = 0;
> +rmc_uint8_t *rmc_db = NULL;
> +DIR *tmp_dir = NULL;
> +
> +if (read_file(db_pathname, (char **)&rmc_db, &db_len)) {
> +fprintf(stder

Re: [meta-intel] [PATCH 2/2] rmc-db: LICENSE is straight MIT so just use common-license/MIT

[Jianxun Zhang]

Review +1

Thanks, Saul. I hesitated when deciding which MIT copy is for MIT, but my 
decision was poor…



> On Feb 28, 2017, at 1:12 PM, Saul Wold  wrote:
> 
> The OE-Core LICENSE is mostly MIT, but should not be used as a checksum
> file for a purely MIT licensed package.
> 
> Signed-off-by: Saul Wold 
> ---
> common/recipes-bsp/rmc/rmc-db.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/common/recipes-bsp/rmc/rmc-db.bb 
> b/common/recipes-bsp/rmc/rmc-db.bb
> index 99565fd..f24ed11 100644
> --- a/common/recipes-bsp/rmc/rmc-db.bb
> +++ b/common/recipes-bsp/rmc/rmc-db.bb
> @@ -8,7 +8,7 @@ information."
> 
> LICENSE = "MIT"
> 
> -LIC_FILES_CHKSUM = 
> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690"
> +LIC_FILES_CHKSUM = 
> "file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
> 
> S = "${WORKDIR}"
> 
> -- 
> 2.7.4
> 
> -- 
> ___
> meta-intel mailing list
> meta-intel@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-intel

-- 
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel