Re: [meta-intel] [PATCH 0/1] Update dpdk v16.04 to v16.07
On 09/06/2016 10:24 PM, Rahul Kumar Gupta wrote:
> Dear Maintainer(s),
>
> This patch will update dpdk recipe from v16.04 to v16.07.
>
> It will also rename and modify two patches since mk/rte.app.mk and
> mk/rte.sdkinstall.mk has modified in this dpdk version so these patches
> don't apply cleanly on top of it.
> Add one patch which will fix the compilation by making directory dependent
> to other and by adding lib path in LIBDIRS.
> dpdk-pmdinfogen should not be the part of image since it is host specific
> binary.
>
> The image have been tested on Grantley-Broadwell using
> intel-corei7-64 BSP.
>
> Please merge in master if these looks ok.
Merged. Thanks,
Tom
>
> Thanks
>
> Rahul Kumar Gupta (1):
> meta-isg: dpdk: Update v16.04 -> v16.07
>
> meta-isg/common/recipes-extended/dpdk/dpdk.inc | 6 ++-
> ...7-add-sysroot-option-within-app-makefile.patch} | 25 +--
> ...dk-16.07-dpdk-fix-for-parellel-make-issue.patch | 42 +
> ...-dpdk-fix-installation-warning-and-issue.patch} | 52
> +++---
> .../dpdk/{dpdk_16.04.bb => dpdk_16.07.bb} | 4 +-
> 5 files changed, 85 insertions(+), 44 deletions(-)
> rename
> meta-isg/common/recipes-extended/dpdk/dpdk/{dpdk-16.04-add-sysroot-option-within-app-makefile.patch
> => dpdk-16.07-add-sysroot-option-within-app-makefile.patch} (43%)
> create mode 100644
> meta-isg/common/recipes-extended/dpdk/dpdk/dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch
> rename
> meta-isg/common/recipes-extended/dpdk/dpdk/{dpdk-16.04-dpdk-fix-installation-warning-and-issue.patch
> => dpdk-16.07-dpdk-fix-installation-warning-and-issue.patch} (61%)
> rename meta-isg/common/recipes-extended/dpdk/{dpdk_16.04.bb =>
> dpdk_16.07.bb} (74%)
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] linux-yocto SRCREV update 9/1
Merged, thanks. Tom On 09/01/2016 06:46 PM, California Sullivan wrote: > > Hi Tom, > > This week's update fixes the architecture mismatch for quark MACHINEs > for 4.4, the architecture mismatch for quark and core2 for 4.1, the > configuration warnings with the new kernel tools for core2 and corei7, > and updates the 4.1 kernel to v4.1.30. > > No new errors or warning were revealed in my normal smoke testing, and > as usual the patches are also available at my branch here: > > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for intel-quark fix > linux-yocto/4.1: Update SRCREVs for v4.1.30 and fix config for new > tools > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++-- > 6 files changed, 15 insertions(+), 15 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] rmc: update revision
On 08/30/2016 04:03 PM, Jianxun Zhang wrote: > 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(-) > Merged, thanks. Tom -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] meta-isg: Update MAINTAINER file
On 08/26/2016 01:28 AM, chun.weng@intel.com wrote: > From: Ong Chun Weng > > Hi, > > This patch is to remove the retired BSP maintainer name > and contact from the maintainer list in MAINTAINER file. > This change is targeted for upcoming YP 2.2, please help > to merge into meta-intel master branch. > > Removed the maintainer for: > a.HASWELL-WC (previous commit:99fa5a9466158e4847d7d1efd64ca1e0e002d495) > b.VALLEYISLAND (previous commit: 20c6a8ab096c01a26f6cbac93ffe0d2004619061) > > Please review and provide feedback. Thanks. > > Best Reagrds, > Chun Weng > > > Ong Chun Weng (1): > meta-isg: Update the MAINTAINERS file for retired BSP layers > > meta-isg/MAINTAINERS | 12 ++-- > 1 file changed, 2 insertions(+), 10 deletions(-) > Merged, thanks. Tom -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] BSP Layer Retirement
On 08/24/2016 01:58 AM, chun.weng@intel.com wrote: > From: Ong Chun Weng > > Hi, > > This patchset is to retire the meta-haswell-wc and meta-vallyisland > BSP layer in the meta-intel master branch. These changes are > targeted for the upcoming Yocto Project 2.2. > > The sato image have been tested on Walnut Canyon platform using > intel-corei7-64. I have tested the following sanity tests: > 1. OS Loader - USB and SATA Boot > 2. USB and SATA - read and write > 3. Ethernet > 4. HD Audio > 5. Display - VGA, Display Port, and HDMI > 6. Power Management - S0 and S5 system state > > Please help to review and provide your feedback. > Merged into meta-intel/master. It seems you missed the corresponding updates to MAINTAINERS for this though - please send an additional patch cleaning that up too. Thanks, Tom > Thanks. > > Best Regards, > Chun Weng > > Ong Chun Weng (2): > meta-isg: meta-valleyisland: BSP layer retirement > meta-isg: meta-haswell-wc: BSP layer retirement > > meta-isg/meta-haswell-wc/COPYING.MIT | 17 -- > meta-isg/meta-haswell-wc/README| 172 --- > meta-isg/meta-haswell-wc/README.sources| 17 -- > meta-isg/meta-haswell-wc/conf/layer.conf | 12 -- > .../meta-haswell-wc/conf/machine/haswell-wc.conf | 29 --- > .../formfactor/formfactor/haswell-wc/machconfig| 3 - > .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 1 - > meta-isg/meta-valleyisland/COPYING.MIT | 17 -- > meta-isg/meta-valleyisland/README | 234 > - > meta-isg/meta-valleyisland/README.sources | 18 -- > meta-isg/meta-valleyisland/conf/layer.conf | 14 -- > .../conf/machine/valleyisland-32.conf | 25 --- > .../conf/machine/valleyisland-64.conf | 26 --- > .../formfactor/valleyisland-32/machconfig | 3 - > .../formfactor/valleyisland-64/machconfig | 3 - > .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 1 - > 16 files changed, 592 deletions(-) > delete mode 100644 meta-isg/meta-haswell-wc/COPYING.MIT > delete mode 100644 meta-isg/meta-haswell-wc/README > delete mode 100644 meta-isg/meta-haswell-wc/README.sources > delete mode 100644 meta-isg/meta-haswell-wc/conf/layer.conf > delete mode 100644 meta-isg/meta-haswell-wc/conf/machine/haswell-wc.conf > delete mode 100644 > meta-isg/meta-haswell-wc/recipes-bsp/formfactor/formfactor/haswell-wc/machconfig > delete mode 100644 > meta-isg/meta-haswell-wc/recipes-bsp/formfactor/formfactor_0.0.bbappend > delete mode 100644 meta-isg/meta-valleyisland/COPYING.MIT > delete mode 100644 meta-isg/meta-valleyisland/README > delete mode 100644 meta-isg/meta-valleyisland/README.sources > delete mode 100644 meta-isg/meta-valleyisland/conf/layer.conf > delete mode 100644 > meta-isg/meta-valleyisland/conf/machine/valleyisland-32.conf > delete mode 100644 > meta-isg/meta-valleyisland/conf/machine/valleyisland-64.conf > delete mode 100644 > meta-isg/meta-valleyisland/recipes-bsp/formfactor/formfactor/valleyisland-32/machconfig > delete mode 100644 > meta-isg/meta-valleyisland/recipes-bsp/formfactor/formfactor/valleyisland-64/machconfig > delete mode 100644 > meta-isg/meta-valleyisland/recipes-bsp/formfactor/formfactor_0.0.bbappend > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/1] SRCREV update 8/24
On 08/24/2016 04:48 PM, California Sullivan wrote: > This is a rather large update. We bring in 4.4.16, 4.4.17, and 4.4.18 > stable patches. The patches needed for preempt-rt were brought in as > well, so that also finally got bumped. > > This update is very late because the 4.4.16 merge had i915 conflicts > that needed resolved, and the kernel tools were updated at the same > time. Due to the kernel tools update revealing some configuration > issues the cache needed several changes. Further changes need to be > made still, but with this set we at least get clean builds with > intel-corei7-64 and intel-core2-32 on the 4.4.18 kernel. > > There is one new error in this update: > [1.169900] amd_nb: Cannot enumerate AMD northbridges > > This was introduced by the following patch: > d9c5952 x86/amd_nb: Fix boot crash on non-AMD systems > > This is irrelevant to us, and really just highlights more configuration > options we should turn off in the future. > > As usual, this patch is also available at: > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test Merged, thanks. Tom > > California Sullivan (1): > linux-yocto/4.4: Bump to 4.4.18 and update cache for tool changes > > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 6 +++--- > 3 files changed, 9 insertions(+), 9 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] lunix-yocto SRCREV update August 5
On 08/05/2016 06:38 PM, California Sullivan wrote: > Hi Tom, > > Smaller SRCREV update this time, with just a few mei backports and > minor configuration changes in 4.4, and just one configuration change > in 4.1. There would be a major update to the preempt-rt kernel, but > the standard/preempt-rt/intel/base branch is missing a major patch, > causing warnings on build and failure to boot if I try and bring in > that update, so I'm holding off for now. It will be fixed by next > week's SRCREV update. > > Besides that issue, no new errors or warnings were noted on the NUC6 > (64 bit) or MinnowBoard Turbot (32 and 64 bit) in my smoke testing. > > As usual, these patches are also available at: > > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > Merged into master, Thanks, Tom > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for more mei backports > linux-yocto/4.1: Update meta SRCREVs to disable legacy PTYS > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++-- > 6 files changed, 10 insertions(+), 10 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)
On 08/04/2016 08:42 PM, Jianxun Zhang wrote: > >> 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 >>> a
Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)
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? Tom >> 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 e
Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)
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. 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. 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?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 t
Re: [meta-intel] [PATCHv5 06/10] rmc: document and examples for RMC feature
On 08/04/2016 01:30 PM, Jianxun Zhang wrote: > >> 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: [] >>>>> + >>>>> + >>>>> + >>>>> +Enable RMC Feature >>>>> + >>>>> +To Enable RMC feature in build, add the below lines in a conf file: >>>>> +DISTRO_FEATURES_append = " rmc" >>>>> +EFI_PROVIDER = "rmc-systemd-boot" >>>>> + >>>>> +Note: >>>>> +Image could be still bootable if you only have either of two lines, but >>>>> RMC >>>>> +feature won't be fully functional. >>>>> + >>>> >>>> In what way? Please explain. What do you mean by it 'could still be >>>> bootable'. Under what conditions? And please explain what it means >>>> that the 'RMC feature won't be fully functional'. Which parts will be >>>> functional and which parts won’t? >>>> >>> I will amend this in README, but it is a bit complex now. >>> >>> Now we have 2 switches, so we have to cover 2^2 = 4 possibilities. I tested >>> these but think it is too overwhelming to user if we have lengthy sections >>> to explain result from each of them. >>> >>> Actually, the more we say in this section here, the more possibly users >>> gonna say “hey, man, why don’t just tell us how to fully enable/disable >>> this thing?!”. >>> >> >> The other option is to just fix it, so that there are only two options, >> as it should be. But I guess it won't happen overnight, so needs to be >> documented as long as this situation exists. >> > > Just kindly remind you the installer. The current design in OE ties up > installer and bootloader. If we apply the idea of discussion on bootloader to > installer case and you want RMC image not to “override” original installer, > we get 2^3 = 8… I think we gonna either have a single distro feature which > you disapprove or break functions into a component basis in README. Any cases > in the middle ground is asking trouble. > > I think I should do something to redesign these parts in OE if people accept > my thoughts. > By two options, I just meant: if you set DISTRO_FEATURES_append = " rmc" (or whatever the right switch ends up being), the bootloader/installer/whatever enables the rmc functionality built in to it. If " rmc" is not set, or if " rmc" is set but those components don't have rmc support, it doesn't (i.e. as if the original unmodified functionality was specified). Tom >> Tom >> >>> I will file a bug to amend README to make it shorter, within 150 lines >>> somehow. I believe we will have more talk on this topic. >>> >>>> Thanks, >>>> >>>> Tom >>>> >>>>> + >>>>> + >>>>> +Examples >>>>> + >>>>> +We checked in configuration data in common/recipes-bsp/rmc/boards/ for >>>>> several >>>>> +boards, to help users to understand the RMC feature. These examples are >>>>> also for >>>>> +validation. For any example you find not working as what this section >>>>> depicts, >>>>> +it should be treated as a bug to be fixed. >>>>> + >>>>> +To test this feature with examples, enable it and build an image first, >>>>> then >>>>> +boot the built image on supported boards. Examples are always built in >>>>> when the >>>>> +feature is enabled, except for the EXAMPLE 1. >>>>> + >>>>> +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" >>>>> + >>>>> +(2) flash the image to a USB stick and boot it on your board >>>>> + >>>>> +(3) in super user mode, run "rmc -F -o my_b
Re: [meta-intel] [PATCHv5 06/10] rmc: document and examples for RMC feature
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
>>> 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/
Re: [meta-intel] [PATCH 0/2] Fix build with zlib-qat and openssl-qat
On 08/03/2016 02:59 AM, Rahul Kumar Gupta wrote: > Dear Maintainer(s), > > These patches will fix the unpack and patch error causes due to incremental > builds of zlib-qat v0.4.7-002 and openssl-qat v0.4.9-009. These packages > needs a patch present in a zip file that is unpacked and applied on top of > zlib and openssl respectively. > > So the work around is to split do_patch into two - one to unpack the qat patch > and apply it on openssl and zlib respectively. And, other to apply the patches > added in SRC_URI. > > The image have been tested on Grantley-Broadwell using intel-corei7-64 BSP. > Getting build errors: Build Configuration: BB_VERSION= "1.31.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "x86_64-poky-linux" MACHINE = "intel-corei7-64" DISTRO= "poky" DISTRO_VERSION= "2.1+snapshot-20160804" TUNE_FEATURES = "m64 corei7" TARGET_FPU= "" meta meta-poky meta-yocto-bsp= "master9:a56fb90dc3805494eeaf04c60538425e8d52efc5" meta-intel meta-isg = "master13:3fdd6fdae1df3223d4d748dbcf609c27a79b8f9d" Initialising tasks: 100% |##| Time: 0:00:02 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: openssl-qat-0.4.9-009-r0 do_patch: Function failed: opensslqat_do_patch (log file is located at /usr/local/dev/yocto/master-cur/build/tmp/work/intel_corei7_64-poky-linux/openssl-qat/0.4.9-009-r0/temp/log.do_patch.25068) ERROR: Logfile of failure stored in: /usr/local/dev/yocto/master-cur/build/tmp/work/intel_corei7_64-poky-linux/openssl-qat/0.4.9-009-r0/temp/log.do_patch.25068 Log data follows: | DEBUG: Executing python function do_patch | DEBUG: Executing shell function opensslqat_do_patch | No patch removed | Applying patch /usr/local/dev/yocto/master-cur/build/tmp/work/intel_corei7_64-poky-linux/openssl-qat/0.4.9-009-r0/git/debian/patches/openssl-1.0.1async-qat.patch | patching file Configure | Hunk #1 FAILED at 716. | Hunk #2 succeeded at 1150 with fuzz 2 (offset -223 lines). | Hunk #3 FAILED at 1617. | Hunk #4 FAILED at 1632. | 3 out of 4 hunks FAILED -- rejects in file Configure | patching file apps/Makefile | Hunk #1 FAILED at 32. | 1 out of 1 hunk FAILED -- rejects in file apps/Makefile | patching file apps/openssl.c | Hunk #1 FAILED at 134. | Hunk #2 FAILED at 280. | 2 out of 2 hunks FAILED -- rejects in file apps/openssl.c | patching file apps/s_server.c | Hunk #1 FAILED at 196. | Hunk #2 FAILED at 612. | Hunk #3 FAILED at 1015. | Hunk #4 FAILED at 1380. | Hunk #5 FAILED at 1419. | 5 out of 5 hunks FAILED -- rejects in file apps/s_server.c | patching file apps/speed.c | Hunk #1 FAILED at 110. | Hunk #2 FAILED at 364. | Hunk #3 FAILED at 533. | Hunk #4 FAILED at 854. | Hunk #5 FAILED at 1000. | Hunk #6 succeeded at 1071 with fuzz 1 (offset 54 lines). | Hunk #7 FAILED at 1476. | Hunk #8 succeeded at 1563 with fuzz 2 (offset 75 lines). | Hunk #9 succeeded at 1581 with fuzz 2 (offset 79 lines). | Hunk #10 FAILED at 1514. | Hunk #11 FAILED at 1525. | Hunk #12 FAILED at 2290. | Hunk #13 FAILED at 2303. | Hunk #14 FAILED at 2338. | Hunk #15 FAILED at 2350. | Hunk #16 FAILED at 2371. | Hunk #17 FAILED at 2397. | Hunk #18 FAILED at 2404. | Hunk #19 FAILED at 2464. | Hunk #20 FAILED at 2492. | 17 out of 20 hunks FAILED -- rejects in file apps/speed.c | patching file crypto/engine/eng_all.c | Hunk #1 succeeded at 115 with fuzz 2 (offset 3 lines). | Hunk #2 succeeded at 132 with fuzz 2 (offset 6 lines). | patching file crypto/engine/engine.h | Hunk #1 FAILED at 405. | 1 out of 1 hunk FAILED -- rejects in file crypto/engine/engine.h | patching file crypto/opensslv.h | Hunk #1 FAILED at 31. | 1 out of 1 hunk FAILED -- rejects in file crypto/opensslv.h | patching file engines/Makefile | Hunk #1 FAILED at 10. | Hunk #2 FAILED at 139. | 2 out of 2 hunks FAILED -- rejects in file engines/Makefile | The next patch would create the file engines/qat_engine/Makefile, | which already exists! Applying it anyway. | patching file engines/qat_engine/Makefile | Hunk #1 FAILED at 1. | 1 out of 1 hunk FAILED -- rejects in file engines/qat_engine/Makefile | The next patch would create the file engines/qat_engine/e_qat.c, | which already exists! Applying it anyway. | patching file engines/qat_engine/e_qat.c | Hunk #1 FAILED at 1. | 1 out of 1 hunk FAILED -- rejects in file engines/qat_engine/e_qat.c | The next patch would create the file engines/qat_engine/e_qat.ec, | which already exists! Applying it anyway. | patching file engines/qat_engine/e_qat.ec | Hunk #1 FAILED at 1. | 1 out of 1 hunk FAILED -- rejects in file engines/qat_engine/e_qat.ec | The next patch would create the file engines/qat_engine/e_qat.h, | which already exists! Applying it anyway. | patching file engines/qat_engine/e_qat.h | Hunk #1 FAILED at 1. | 1 out of 1 hunk FAILED -- rejects in file engines/qat_engine/e_qat.h | The next patch would create the file engines/qat_engine/
Re: [meta-intel] [PATCHv5 06/10] rmc: document and examples for RMC feature
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/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> new file mode 100644
> index 000..cb01ced
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> @@ -0,0 +1 @@
> +boot.conf
> diff --git a/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
> b/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
> new file mode 100644
> index 000..6e789cd
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/minnowmax/boot.conf
> @@ -0,0 +1,4 @@
> +title Minnow Max boot
> +linux /vmlinuz
> +initrd /initrd
> +options LABEL=boot console=ttyS0,115200n8
> diff --git a/common/recipes-bsp/rmc/boards/minnowmax/minnowmax.f
Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)
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. > >> 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. > > >> - 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. > Sorry, failing silently even if that maps to something legal isn't useful. > 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 > >> 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-
Re: [meta-intel] [PATCHv5 00/10] Runtime Machine Configuration (RMC)
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. Please file a bug addressing that interface issue, as well as for the other issues we identified along the way and that remain unaddressed. 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. - 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. 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.fp| Bin 0 -> 116 bytes > common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + > .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + > common/recipes-bsp/rmc/boards/broxton-m/KBOOTPARAM | 1 + > common/recipes-bsp/rmc/boards/broxton-m/bm.fp | Bin 0 -> 83 bytes > .../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 + > .../recipes-bsp/rmc/boards/nucgen6/POSTINSTALL.sh | 7 + > common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + > common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + > common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + > common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes > common/recipes-bsp/rmc/rmc-db.bb | 48 +++ > common/recipes-bsp/rmc/rmc.bb | 46 +++ > .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ > ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ > ...d-board-specific-boot-entries-from-RMC-da.patch | 263 +++ > ...pport-global-kernel-command-line-fragment.patch | 66 > .../initrdscripts/files/init-install-efi.sh| 339 > .../initramfs-live-install-efi_%.bbappend | 1 + > conf/layer.conf| 10 + > documentation/rmc/README | 356 > + > 34 files changed, 1370 insertions(+) > create mode 100644 classes/rmc-db.bbclass > create mode 100644 classes/rmc-systemd-boot.bbclass > create mode 100644 > common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch > create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp > create mode 100644 common/recipes-bsp/r
Re: [meta-intel] [PATCHv5 0/1] Runtime Machine Configuration (RMC)
Hi Jianxun, On 08/02/2016 08:59 PM, Jianxun Zhang wrote: > Hi Saul, Tom & others, > > This is the V5 submission of RMC work which squashed top commit of V4.5, also > with some minor adjustments in rmc README file and commit messages. > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=jxzhang/rmc-submission-V5 > > (167a258f637d62420f203832bb746af958221f81) > > Thanks lot! > Are you asking to have this merged? If so, you need to post any patch you want merged to the list, not as a URL. Thanks, Tom -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] SRCREV update July 28
On 07/28/2016 08:48 PM, California Sullivan wrote: > Hi Tom, > > This week's SRCREV update for 4.4 fixes some compilation issues in > several drivers we are currently not building, but others might. The > failures started when we brought in the drm forklift, but I missed them > because I didn't think to do allyesconfig/allmodconfig builds at the > time. We also bring in updates to the MEI and RPMB features. > > The 4.1 update is a bit smaller, just bringing in a few small fixes for > USB and swap, and I2C support for Denverton. > > In smoke testing I did hit a strange issue with mei_txe on the 4.1 > kernel with a 64 bit MinnowBoard Turbot, but I don't think that has > anything to do with this update. There were no mei changes in the 4.1 > kernel, and after unplugging power and USB then replugging them in, the > error no longer occured. Many reboots later and I was still unable to > reproduce the error. > > No other new errors or warnings were seen. > > As usual, this update is also available at: > > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > Merged, thanks, Tom > Thanks, > Cal Sullivan > > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for compilation fixes, mei and rpmb > backports > linux-yocto/4.1: Update SRCREVs to latest > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++-- > 6 files changed, 10 insertions(+), 10 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] quark: wks updates
On 07/26/2016 05:26 PM, Jianxun Zhang wrote:
> This patch series updates quark for its bootloader and wks files.
>
> () The old gummiboot will be replaced with systemdboot in OE. (I am the
> guy driving it). I think what we have enabled on systemd-boot is good
> enough to switch quark's bootloader, so this change is an early move in
> meta-intel.
>
> () I got kernel panic due to missing rootfs when booting Galileo Gen 2 with
> a direct-boot image on USB stick. I don't think the existing wks file can
> support it, wondering why people haven't complain this. A new wks to boot
> USB stick is added in 2nd patch.
>
Merged.
Thanks,
Tom
> Jianxun Zhang (2):
> quark: switch gummiboot to systemd-boot
> quark: Support direct-boot image for USB storage media
>
> README | 22
> +-
> conf/machine/intel-quark.conf | 2 +-
> .../{mkgalileodisk.wks => galileodisk-sd.wks} | 6 +++---
> scripts/lib/wic/canned-wks/galileodisk-usb.wks | 9 +
> 4 files changed, 26 insertions(+), 13 deletions(-)
> rename scripts/lib/wic/canned-wks/{mkgalileodisk.wks => galileodisk-sd.wks}
> (56%)
> create mode 100644 scripts/lib/wic/canned-wks/galileodisk-usb.wks
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 2/2 v2] linux-yocto*: remove mei from KERNEL_FEATURES
On 07/20/2016 05:32 PM, Saul Wold wrote:
> As it's already part of the intel-common-drivers in yocto-kernel-cache
>
> Signed-off-by: Saul Wold
> ---
> v2: this patch seems to have gotten lost in the shuffle, no real change, just
> rebase
Merged.
Thanks,
Tom
>
> common/recipes-kernel/linux/linux-yocto-dev.bbappend | 2 --
> common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 1 -
> common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 1 -
> 3 files changed, 4 deletions(-)
>
> diff --git a/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> b/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> index 9a1b5d0..3b1382c 100644
> --- a/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto-dev.bbappend
> @@ -1,7 +1,5 @@
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> -KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
> -
> COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
> KMACHINE_core2-32-intel-common = "intel-core2-32"
> KERNEL_FEATURES_append_core2-32-intel-common =
> "${KERNEL_FEATURES_INTEL_COMMON}"
> diff --git a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
> b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
> index 7cf821b..e74639c 100644
> --- a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
> @@ -5,7 +5,6 @@ SRCREV_META_INTEL_COMMON =
> "cab4fec4b7ab0efae0f44c1ec1836c035a9b78fe"
> SRCREV_MACHINE_INTEL_COMMON = "47821fe3846ba2f9cddebbf2a6fe60d364be1999"
>
> KBRANCH_INTEL_COMMON = "standard/intel/base"
> -KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
>
> LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
> COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
> diff --git a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> index 3711d73..7cb99b8 100644
> --- a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> +++ b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
> @@ -5,7 +5,6 @@ SRCREV_META_INTEL_COMMON =
> "4800a400d5ace1d4332ee18b01ac1c680e454457"
> SRCREV_MACHINE_INTEL_COMMON = "f67e69b33e63209737571d2e71ac84b2ecdf3cfc"
>
> KBRANCH_INTEL_COMMON = "standard/intel/base"
> -KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
>
> LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
> COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [master][PATCH 0/2] Fix build for GNU_HASH QA issue
Hi Rahul, I'm getting errors and warnings for both of these - see below: On 07/27/2016 12:58 AM, Rahul Kumar Gupta wrote: > Dear Maintainer(s), > > These changes will fix do_package_qa errors in qat16 v2.6.0-65 and zlib-qat > v0.4.7-002 by adding LDFLAGS to TARGET_CC_ARCH. > > LDFLAGS is not used by the each Makefile so instead of adding this in > Makefiles, passed LDFLAGS with TARGET_CC_ARCH. To ensure that the LDFLAGS > variable is being passed to the linker command. > > These QA errors are due to the default linker hash style is set to sysv > in gcc-cross.inc in poky now. So We need to explicitly set the hash style > to gnu in our LDFLAGS. > > The image have been tested on Grantley-Broadwell using intel-corei7-64 BSP. > > Please merge in master if these looks ok. > > Thanks > > Rahul Kumar Gupta (2): > meta-isg: qat16: fix for GNU_HASH QA issue > meta-isg: zlib-qat: fix for GNU_HASH QA error > > meta-isg/common/recipes-extended/qat/qat16.inc | 1 + > meta-isg/common/recipes-extended/zlib-qat/zlib-qat_0.4.7-002.bb | 1 + > 2 files changed, 2 insertions(+) > For qat16, I get QA warnings: Build Configuration: BB_VERSION= "1.31.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "x86_64-poky-linux" MACHINE = "intel-corei7-64" DISTRO= "poky" DISTRO_VERSION= "2.1+snapshot-20160727" TUNE_FEATURES = "m64 corei7" TARGET_FPU= "" meta meta-poky meta-yocto-bsp= "master8:039f47ad197a9a53109c9f3deadd9c35e62c056d" meta-intel meta-isg = "master11:f8944487ab5db4618664b818173947ad08b1e9ce" Initialising tasks: 100% |###| Time: 0:00:01 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-dc-stateless-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/dc_stateless_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-cipher-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/cipher_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-gcm-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/gcm_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-ssl-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/ssl_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-prime-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/prime_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /qat16-app/usr/bin/cpa_sample_code is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-sym-dp-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/sym_dp_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-drbg-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/drbg_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-ipsec-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/ipsec_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-nrbg-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/nrbg_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-dh-sample/lib/modules/4.4.15-yocto-standard/kernel/drivers/dh_sample.ko is owned by uid 1000, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] WARNING: qat16-2.6.0-65-r0 do_package_qa: QA Issue: qat16: /kernel-module-algchaining-sample/lib/modules/4.4.15-yocto-standard/kernel/drive
Re: [meta-intel] [PATCHv4 0/6] Add Runtime Machine Configuration (RMC)
On 07/25/2016 02:03 PM, Tom Zanussi wrote:
> Hi Jianxun,
>
> On 07/22/2016 06:30 PM, Jianxun Zhang wrote:
>> V4 includes these changes and fixes since V3:
>>
>> () Explicitly set ${S} to get rid of a qa warning
>>
>> () systemd-boot: Skip reading conf files on disk if any RMC entry is
>> loaded, so that user only see RMC entreis on a supported board. This doesn't
>> affect boards not supported by RMC, conf file on ESP will be loaded.
>>
>> () update installer to the latest OE version and with a fix for a bug:
>> RMC entries could be overwritten when they have same file names of default
>> entries.
>>
>> () Misc. changes in RMC readme for new behavior and fix of wrong info of
>> creating dir in INSTALLER.CONFIG
>>
>
> Looks good as far as the boot menu changes, thanks.
>
> Unfortunately, the previous behavior where changes to the config files
> aren't being picked up seems to be back i.e. if I change e.g. BOOTPARAM
> to have a different loglevel, or add a new entry to BOOTENTRY.CONFIG and
> rebuild the image, I don't see my changes in the new image.
>
Never mind, my bad - my bblayers was pointing to an old layer. It seems
to work fine when rebuilding now.
Tom
> Tom
>
>
>> Open items NOT addressed in V4. They are either still in discussion or in
>> fix plan.
>>
>> () hooks for checker at build time
>>
>> () APPEND of cmdline
>>
>> () grab input files in SRC_URI (? Paul E)
>>
>> () Pursuing to upstream to OE so we don't need to carry patches and copies.
>>
>> () Don't override EFI_PROVIDER when RMC distro feature is enabled.
>>
>> () Anything from previous series I missed here.
>>
>> Jianxun Zhang (6):
>> rmc: Add Runtime Machine Configuration (RMC) project
>> gnu-efi: Add GUID for SMBIOS 3 entry point structure
>> systemd-boot: load board-specific entry and kernel cmdline
>> EFI installer: deploy board-specific data and kernel cmdline
>> rmc: add recipe and bbclass for RMC feature
>> rmc: document and examples for RMC feature
>>
>> classes/rmc-db.bbclass | 92 ++
>> classes/rmc-systemd-boot.bbclass | 12 +
>> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++
>> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 +
>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 +
>> .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes
>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 +
>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 +
>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 +
>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 +
>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes
>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 +
>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 +
>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes
>> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 +
>> .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 +
>> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 +
>> common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 +
>> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 +
>> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 +
>> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes
>> common/recipes-bsp/rmc/rmc-db.bb | 48 +++
>> common/recipes-bsp/rmc/rmc.bb | 46 +++
>> .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++
>> ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++
>> ...d-board-specific-boot-entries-from-RMC-da.patch | 263
>> ...pport-global-kernel-command-line-fragment.patch | 66
>> .../initrdscripts/files/init-install-efi.sh| 326
>>
>> .../initramfs-live-install-efi_%.bbappend | 1 +
>> conf/layer.conf| 16 +
>> documentation/rmc/README | 342
>> +
>> 31 files changed, 1341 insertions(+)
>> create mode 100644 classes/rmc-db.bbclass
>> create mode 100644 classes/rmc-systemd-boot.bbclass
>> create mode 100644
>> common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
>> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
>> create mode 100644 common/recipes-bsp/rmc/bo
Re: [meta-intel] [PATCHv4 0/6] Add Runtime Machine Configuration (RMC)
Hi Jianxun,
On 07/22/2016 06:30 PM, Jianxun Zhang wrote:
> V4 includes these changes and fixes since V3:
>
> () Explicitly set ${S} to get rid of a qa warning
>
> () systemd-boot: Skip reading conf files on disk if any RMC entry is
> loaded, so that user only see RMC entreis on a supported board. This doesn't
> affect boards not supported by RMC, conf file on ESP will be loaded.
>
> () update installer to the latest OE version and with a fix for a bug:
> RMC entries could be overwritten when they have same file names of default
> entries.
>
> () Misc. changes in RMC readme for new behavior and fix of wrong info of
> creating dir in INSTALLER.CONFIG
>
Looks good as far as the boot menu changes, thanks.
Unfortunately, the previous behavior where changes to the config files
aren't being picked up seems to be back i.e. if I change e.g. BOOTPARAM
to have a different loglevel, or add a new entry to BOOTENTRY.CONFIG and
rebuild the image, I don't see my changes in the new image.
Tom
> Open items NOT addressed in V4. They are either still in discussion or in
> fix plan.
>
> () hooks for checker at build time
>
> () APPEND of cmdline
>
> () grab input files in SRC_URI (? Paul E)
>
> () Pursuing to upstream to OE so we don't need to carry patches and copies.
>
> () Don't override EFI_PROVIDER when RMC distro feature is enabled.
>
> () Anything from previous series I missed here.
>
> Jianxun Zhang (6):
> rmc: Add Runtime Machine Configuration (RMC) project
> gnu-efi: Add GUID for SMBIOS 3 entry point structure
> systemd-boot: load board-specific entry and kernel cmdline
> EFI installer: deploy board-specific data and kernel cmdline
> rmc: add recipe and bbclass for RMC feature
> rmc: document and examples for RMC feature
>
> classes/rmc-db.bbclass | 92 ++
> classes/rmc-systemd-boot.bbclass | 12 +
> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++
> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 +
> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 +
> .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes
> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 +
> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 +
> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 +
> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 +
> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes
> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 +
> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 +
> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes
> .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 +
> .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 +
> common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 +
> common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 +
> common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 +
> common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 +
> common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes
> common/recipes-bsp/rmc/rmc-db.bb | 48 +++
> common/recipes-bsp/rmc/rmc.bb | 46 +++
> .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++
> ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++
> ...d-board-specific-boot-entries-from-RMC-da.patch | 263
> ...pport-global-kernel-command-line-fragment.patch | 66
> .../initrdscripts/files/init-install-efi.sh| 326
> .../initramfs-live-install-efi_%.bbappend | 1 +
> conf/layer.conf| 16 +
> documentation/rmc/README | 342
> +
> 31 files changed, 1341 insertions(+)
> create mode 100644 classes/rmc-db.bbclass
> create mode 100644 classes/rmc-systemd-boot.bbclass
> create mode 100644
> common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch
> create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend
> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
> create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf
> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf
> create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp
> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG
> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf
> create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp
> create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG
> create mode
Re: [meta-intel] [PATCH 0/1] gstreamer-vaapi: Update to upstream version 1.8.2
On 07/22/2016 06:16 PM, Scott D Phillips wrote: > gstreamer got updated from 1.6.x to 1.8.x back in May: > >> e9c85d5 gstreamer1.0: upgrade to version 1.8.1 > > With the 1.8.x series gstreamer-vaapi got integrated into the > maintainership of the greater GStreamer project. The old 0.7.0 > pre-upstream version of gstreamer-vaapi has never been verified > against 1.8.x so we need to update here. > > Also it's worth noting that the old github-homed version of > gstreamer-vaapi strove to support multiple release versions of > GStreamer. This is no longer the case with the upstreamed > gstreamer-vaapi, so we need to try to coordinate updates in > gstreamer and gstreamer-vaapi to not get any funky regressions. > > This update (vs 0.7.0) is known to be tested with new platforms > APL and KBL as well as contain bug fixes for SKL. It is also known > to correct a playback issue with VP9 on all platforms. > Merged. Thanks, Tom > Scott D Phillips (1): > gstreamer-vaapi: Update to upstream version 1.8.2 > > .../gstreamer/gstreamer-vaapi-1.0_0.7.0.bb | 8 -- > .../gstreamer/gstreamer-vaapi-1.0_1.8.2.bb | 6 + > .../gstreamer/gstreamer-vaapi.inc | 4 +-- > ...5-Fix-offset-calculation-in-codec_data-pa.patch | 31 > -- > 4 files changed, 7 insertions(+), 42 deletions(-) > delete mode 100644 > common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_0.7.0.bb > create mode 100644 > common/recipes-multimedia/gstreamer/gstreamer-vaapi-1.0_1.8.2.bb > delete mode 100644 > common/recipes-multimedia/gstreamer/gstreamer-vaapi/0001-decoder-h265-Fix-offset-calculation-in-codec_data-pa.patch > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] linux-yocto SRCREV update July 22
On 07/22/2016 07:36 PM, California Sullivan wrote: > Hi Tom, > > Here's the weekly update. This time we grab stable updates for both the > 4.4 and 4.1 kernels, as well as a slurry of backports and fixes for > Broxton and Apollo Lake. No new errors or warnings were seen in the > usual smoke tests on NUC6 or MinnowBoard Turbot (32 and 64 bit). > Merged. Thanks, Tom > These patches are also available for pulling at: > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for v4.4.15 and more Broxton backports > linux-yocto/4.1: Update SRCREVs for v4.1.28 and more BXT/APL backports > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 6 +++--- > 6 files changed, 18 insertions(+), 18 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [master][PATCH 0/3] Fix build and simplify installation
On 10/20/2047 09:58 PM, Rahul Kumar Gupta wrote: > Dear Maintainer(s), > > These changes will > Fix the compilation errors in dpdk v16.04 with shared libraries, > Add --hash-style as LD flags to avoid QA error and > Simplify the do_install by using the makefile. > > This will add two patches to dpdk recipe. One for fixing installation other > is for ensuring that the CFLAGS are passed to LD when compiling rte libs > as shared. > > The image have been tested on Grantley-Broadwell using intel-corei7-64 BSP. > > Please merge in master if these looks ok. > Merged. Thanks, Tom > Thanks > > Rahul Kumar Gupta (3): > meta-isg: dpdk: fix for GNU_HASH QA issue > meta-isg: dpdk: simplify do_install > meta-isg: dpdk: fix compilation with dynamic libs > > meta-isg/common/recipes-extended/dpdk/dpdk.inc | 51 +- > ...04-dpdk-fix-compilation-with-dynamic-libs.patch | 30 > ...4-dpdk-fix-installation-warning-and-issue.patch | 79 > ++ > 3 files changed, 126 insertions(+), 34 deletions(-) > create mode 100644 > meta-isg/common/recipes-extended/dpdk/dpdk/dpdk-16.04-dpdk-fix-compilation-with-dynamic-libs.patch > create mode 100644 > meta-isg/common/recipes-extended/dpdk/dpdk/dpdk-16.04-dpdk-fix-installation-warning-and-issue.patch > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/22/2016 12:17 PM, Jianxun Zhang wrote: > >> On Jul 22, 2016, at 9:45 AM, Tom Zanussi wrote: >> >> On 07/22/2016 12:12 AM, Jianxun Zhang wrote: >>> >>>> On Jul 21, 2016, at 8:13 PM, Tom Zanussi >>>> wrote: >>>> >>>> On 07/21/2016 08:05 PM, Jianxun Zhang wrote: >>>>> >>>>>> On Jul 21, 2016, at 2:50 PM, Tom Zanussi >>>>>> wrote: >>>>>> >>>>>> On 07/21/2016 04:35 PM, Jianxun Zhang wrote: >>>>>>> >>>>>>>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi >>>>>>>> wrote: >>>>>>>> >>>>>>>> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >>>>>>>>> >>>>>>>>>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Hi Jianxun, >>>>>>>>>> >>>>>>>>>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>>>>>>>>>> V3 addresses feedbacks for V2, also includes other fixes: >>>>>>>>>>> >>>>>>>>>>> () Explicitly tell user overriding is a temporary solution in README >>>>>>>>>>> >>>>>>>>>>> () Move back two readme files back to top dir >>>>>>>>>>> >>>>>>>>>>> () Move RMC README to /documentation/rmc/ >>>>>>>>>>> >>>>>>>>>>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>>>>>>>>>> >>>>>>>>>>> () patches have been squashed >>>>>>>>>>> >>>>>>>>>>> () Now any new change of files in a board dir can be effective with >>>>>>>>>>> a rebuild. >>>>>>>>>>> >>>>>>>>>>> () removing tmp dir in build won't cause build issue. (it is >>>>>>>>>>> uncesesary either) >>>>>>>>>>> >>>>>>>>>>> () amend commit messages >>>>>>>>>>> >>>>>>>>>>> () amend installation logic in database recipe >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> It seems to be working in general and I see updates when I change, >>>>>>>>>> but I >>>>>>>>>> seem to be getting extra boot menu items I didn't ask for. >>>>>>>>>> >>>>>>>>>> I have a BOOTENTRY.CONFIG with just this: >>>>>>>>>> >>>>>>>>>> boot.conf >>>>>>>>>> >>>>>>>>>> and in boot.conf: >>>>>>>>>> >>>>>>>>>> title NextUnitofComputing Gen3 boot >>>>>>>>>> linux /vmlinuz >>>>>>>>>> initrd /initrd >>>>>>>>>> options LABEL=mybootlabel >>>>>>>>>> >>>>>>>>>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also >>>>>>>>>> see >>>>>>>>>> two entries before it: >>>>>>>>>> >>>>>>>>>> boot >>>>>>>>>> install >>>>>>>>>> >>>>>>>>>> I would expect to see only what I have in my configuration. Or am I >>>>>>>>>> doing something wrong? >>>>>>>>>> >>>>>>>>> Tom, >>>>>>>>> No, you don’t do anything wrong. It is designed that way. Any boot >>>>>>>>> entry you pack in RMC are addition to the two default entries “boot” >>>>>>>>> and “install” which are built from OE. There are different routes to >>>>>>>>> add entries. >>>>>>>>> >>>>>>>>> OE allows user to bring their own boot entries in build >>>>>>>>> (GUMMIBOOT_ENTRIES), so we should not override these. >>>>>>>>
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/22/2016 12:12 AM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 8:13 PM, Tom Zanussi wrote: >> >> On 07/21/2016 08:05 PM, Jianxun Zhang wrote: >>> >>>> On Jul 21, 2016, at 2:50 PM, Tom Zanussi >>>> wrote: >>>> >>>> On 07/21/2016 04:35 PM, Jianxun Zhang wrote: >>>>> >>>>>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi >>>>>> wrote: >>>>>> >>>>>> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >>>>>>> >>>>>>>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Jianxun, >>>>>>>> >>>>>>>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>>>>>>>> V3 addresses feedbacks for V2, also includes other fixes: >>>>>>>>> >>>>>>>>> () Explicitly tell user overriding is a temporary solution in README >>>>>>>>> >>>>>>>>> () Move back two readme files back to top dir >>>>>>>>> >>>>>>>>> () Move RMC README to /documentation/rmc/ >>>>>>>>> >>>>>>>>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>>>>>>>> >>>>>>>>> () patches have been squashed >>>>>>>>> >>>>>>>>> () Now any new change of files in a board dir can be effective with a >>>>>>>>> rebuild. >>>>>>>>> >>>>>>>>> () removing tmp dir in build won't cause build issue. (it is >>>>>>>>> uncesesary either) >>>>>>>>> >>>>>>>>> () amend commit messages >>>>>>>>> >>>>>>>>> () amend installation logic in database recipe >>>>>>>>> >>>>>>>> >>>>>>>> It seems to be working in general and I see updates when I change, but >>>>>>>> I >>>>>>>> seem to be getting extra boot menu items I didn't ask for. >>>>>>>> >>>>>>>> I have a BOOTENTRY.CONFIG with just this: >>>>>>>> >>>>>>>> boot.conf >>>>>>>> >>>>>>>> and in boot.conf: >>>>>>>> >>>>>>>> title NextUnitofComputing Gen3 boot >>>>>>>> linux /vmlinuz >>>>>>>> initrd /initrd >>>>>>>> options LABEL=mybootlabel >>>>>>>> >>>>>>>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >>>>>>>> two entries before it: >>>>>>>> >>>>>>>> boot >>>>>>>> install >>>>>>>> >>>>>>>> I would expect to see only what I have in my configuration. Or am I >>>>>>>> doing something wrong? >>>>>>>> >>>>>>> Tom, >>>>>>> No, you don’t do anything wrong. It is designed that way. Any boot >>>>>>> entry you pack in RMC are addition to the two default entries “boot” >>>>>>> and “install” which are built from OE. There are different routes to >>>>>>> add entries. >>>>>>> >>>>>>> OE allows user to bring their own boot entries in build >>>>>>> (GUMMIBOOT_ENTRIES), so we should not override these. >>>>>>> >>>>>>> However, we cannot assume which entry should be replaced/overridden at >>>>>>> runtime too because what you see in boot menu is title filed which >>>>>>> could be anything from user. >>>>>>> >>>>>>> User could be confused when he realize there are two boot or install >>>>>>> options, but he can quickly change titles in conf file to differentiate. >>>>>>> >>>>>> >>>>>> Yes, I certainly was confused to see two boot entries. Even if I rename >>>>>> them like you suggest, how do I rename them to avoid confusion for the >>>>>> user i.e. which boot do I use, and if
Re: [meta-intel] [PATCH] intel-microcode: Update to the 20160714 version
Merged into master.
Thanks,
Tom
On 07/21/2016 11:54 AM, christopher.w.cl...@gmail.com wrote:
> From: Christopher Clark
>
> Dates changed in Licence file required CHKSUM update
>
> From the OpenXT Project ( http://openxt.org )
> refs: OXT-668
>
> Signed-off-by: Christopher Clark
> ---
> .../{intel-microcode_20151106.bb => intel-microcode_20160714.bb} | 8
>
> 1 file changed, 4 insertions(+), 4 deletions(-)
> rename common/recipes-core/microcode/{intel-microcode_20151106.bb =>
> intel-microcode_20160714.bb} (87%)
>
> diff --git a/common/recipes-core/microcode/intel-microcode_20151106.bb
> b/common/recipes-core/microcode/intel-microcode_20160714.bb
> similarity index 87%
> rename from common/recipes-core/microcode/intel-microcode_20151106.bb
> rename to common/recipes-core/microcode/intel-microcode_20160714.bb
> index f168b7d..e5047ea 100644
> --- a/common/recipes-core/microcode/intel-microcode_20151106.bb
> +++ b/common/recipes-core/microcode/intel-microcode_20160714.bb
> @@ -11,11 +11,11 @@ DESCRIPTION = "The microcode data file contains the
> latest microcode\
> if the file is placed in the /etc/firmware directory of the Linux system."
>
> LICENSE = "Intel-Microcode-License"
> -LIC_FILES_CHKSUM =
> "file://microcode.dat;md5=0c9b76c8fa021400a15b3fd71a71977b"
> +LIC_FILES_CHKSUM =
> "file://microcode.dat;md5=d8c57b35388b4b9f970f5377fcdfc486"
>
> -SRC_URI = "http://downloadmirror.intel.com/25512/eng/microcode-${PV}.tgz";
> -SRC_URI[md5sum] = "288dc721fb39d71457ef2f5a49161f57"
> -SRC_URI[sha256sum] =
> "096e39489eef67666be652e81fa372a06b74f39ea3d565dc0287242c668717e7"
> +SRC_URI = "http://downloadmirror.intel.com/26156/eng/microcode-${PV}.tgz";
> +SRC_URI[md5sum] = "84e4c0530dc38fd7b804daf894b1bdf9"
> +SRC_URI[sha256sum] =
> "f3a9c6fc93275bf1febc26f7c397ac93ed5f109e47fb52932f6dbd5cfdbc840e"
>
> DEPENDS = "iucode-tool-native"
> S = "${WORKDIR}"
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 08:05 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 2:50 PM, Tom Zanussi wrote: >> >> On 07/21/2016 04:35 PM, Jianxun Zhang wrote: >>> >>>> On Jul 21, 2016, at 1:07 PM, Tom Zanussi >>>> wrote: >>>> >>>> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >>>>> >>>>>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >>>>>> wrote: >>>>>> >>>>>> Hi Jianxun, >>>>>> >>>>>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>>>>>> V3 addresses feedbacks for V2, also includes other fixes: >>>>>>> >>>>>>> () Explicitly tell user overriding is a temporary solution in README >>>>>>> >>>>>>> () Move back two readme files back to top dir >>>>>>> >>>>>>> () Move RMC README to /documentation/rmc/ >>>>>>> >>>>>>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>>>>>> >>>>>>> () patches have been squashed >>>>>>> >>>>>>> () Now any new change of files in a board dir can be effective with a >>>>>>> rebuild. >>>>>>> >>>>>>> () removing tmp dir in build won't cause build issue. (it is uncesesary >>>>>>> either) >>>>>>> >>>>>>> () amend commit messages >>>>>>> >>>>>>> () amend installation logic in database recipe >>>>>>> >>>>>> >>>>>> It seems to be working in general and I see updates when I change, but I >>>>>> seem to be getting extra boot menu items I didn't ask for. >>>>>> >>>>>> I have a BOOTENTRY.CONFIG with just this: >>>>>> >>>>>> boot.conf >>>>>> >>>>>> and in boot.conf: >>>>>> >>>>>> title NextUnitofComputing Gen3 boot >>>>>> linux /vmlinuz >>>>>> initrd /initrd >>>>>> options LABEL=mybootlabel >>>>>> >>>>>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >>>>>> two entries before it: >>>>>> >>>>>> boot >>>>>> install >>>>>> >>>>>> I would expect to see only what I have in my configuration. Or am I >>>>>> doing something wrong? >>>>>> >>>>> Tom, >>>>> No, you don’t do anything wrong. It is designed that way. Any boot entry >>>>> you pack in RMC are addition to the two default entries “boot” and >>>>> “install” which are built from OE. There are different routes to add >>>>> entries. >>>>> >>>>> OE allows user to bring their own boot entries in build >>>>> (GUMMIBOOT_ENTRIES), so we should not override these. >>>>> >>>>> However, we cannot assume which entry should be replaced/overridden at >>>>> runtime too because what you see in boot menu is title filed which could >>>>> be anything from user. >>>>> >>>>> User could be confused when he realize there are two boot or install >>>>> options, but he can quickly change titles in conf file to differentiate. >>>>> >>>> >>>> Yes, I certainly was confused to see two boot entries. Even if I rename >>>> them like you suggest, how do I rename them to avoid confusion for the >>>> user i.e. which boot do I use, and if I'm supposed to ignore the other >>>> one, why is it there? >>> I think we shouldn’t enforce any naming policy here at this point. This is >>> out of RMC control. Will user complain for confusion caused be another >>> “boot” from a conf file added via the existing GUMMIBOOT_ENTRIES? >>> >> >> You're the one suggesting renaming some to avoid confusing the user >> (because apparently we can't get rid of the two boot entries we didn't >> specify in rmc), nobody mentioned a naming policy. > Sorry if I miss your point. What we are discussing is (a) if titles could be > confusing, or (b) if you have multiple boot entries to boot a board. For the > naming aspect (a), it is totally up to developer or users. For the later case
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
On 07/21/2016 06:33 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 4:14 PM, Tom Zanussi wrote: >> >> On 07/21/2016 06:02 PM, Jianxun Zhang wrote: >>> >>>> On Jul 21, 2016, at 3:41 PM, Tom Zanussi >>>> wrote: >>>> >>>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>>>> Provide a README for RMC feature. Also check in fingerprints and >>>>> configuration data for several boards as examples for users. >>>>> They can be used for validation too. >>>>> >>>>> Signed-off-by: Jianxun Zhang >>>> >>>> [...] >>>> >>>>> + >>>>> +Note 3: >>>>> +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific >>>>> to the >>>>> +board, then tries to fetch each file specified in this config file, and >>>>> then >>>>> +deploy the file onto target with its permissions, UID, GID and other >>>>> attributes >>>>> +also specified in this config file if file for the board can be >>>>> retrieved from >>>>> +RMC database. The format of this file is (# is for comment line) >>>>> + >>>>> +# name:uid:gid:mode:path_on_target >>>>> +# to create a directory, add a “/” at the end of path_on_target: >>>>> +audio_policy:0:0:600:/etc/audio/ >>>>> +audio_def_policy:0:0:600:/etc/audio/audio_policy >>>>> + >>>>> +The first line tells RMC installer to create a directory “audio” in >>>>> /etc. If any >>>>> +parent directory doesn’t exist, installer will create it. The above >>>>> example >>>>> +creates /etc/audio directory first, then fetch a file named >>>>> “audio_def_policy” >>>>> +from RMC database for the board, then copy it to /etc/audio/ with a new >>>>> name >>>>> +“audio_policy”. >>>>> + >>>> >>>> This example explicitly creates the /etc/audio directory first, then the >>>> audio_policy file inside. It seems you're doing this here just as an >>>> example, but when I tried without creating the /etc/audio directory >>>> first, it failed… >>> Great catch! The correct information is in commit msg of installer patch, >>> but not updated in README. :-( >>> Will fix this. >>> >> >> So, the fix is to make the code match "If any parent directory doesn’t >> exist, installer will create it". Seems like that's the right fix.. > Nope. Developer must explicitly direct installer to create dir for new file > first. This is because only developer knows FS attributes for dir to be > created. Code is right but readme is wrong. > Seems like they should be created with default attributes, which they can of course override by doing it directly - it's very tedious for the user to manually create each directory otherwise. Tom > >> new directory first if destination of a file is in that directory >> by adding a '/' at the end of a line. > > >> If a rule in config file is to create a directory, installer >> creates it accordingly. Developer must direct installer to create >> new directory first if destination of a file is in that directory >> by adding a '/' at the end of a line. > > > >> >> Tom >> >>>> >>>> Tom >>>> >>>>> +If this config file is not provided, only default entries “boot” and >>>>> “install” >>>>> +from OE are in boot menu. The name of this config file is what installer >>>>> looks >>>>> +up first, so it must be “INSTALLER.CONFIG”. >>>>> + >>>>> + > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 4/6] EFI installer: deploy board-specific data and kernel cmdline
On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
> Extend the existing init-install-efi.sh in OE to call RMC tool
> so that it can deploy file blobs and a global kernel cmdline
> fragment associated to the type of current running board.
>
> At first, it tries to retrieve a special configuration file
> INSTALLER.CONFIG associated to the board from RMC database file
> on ESP.
>
> If the config file is fetched successfully, installer parses
> configuration file to know which file blobs should be deployed
> from database to target, also with other necessary information
> like FS attributes of deployed file.
>
> If a rule in config file is to create a directory, installer
> creates it accordingly. Developer must direct installer to create
> new directory first if destination of a file is in that directory
> by adding a '/' at the end of a line.
>
> The below is an example of INSTALLER.CONFIG. It directs installer to
> deploy a boot entry boot.conf to EFI partition, create a
> directory /etc/mylib/ on target's rootfs, and deploy a config
> file mylib.conf in the created directory. The first several lines
> started with '#' are comment.
>
> efi_entry_dir:root:disk:770:/boot/loader/entries/
> boot.conf:root:disk:770:/boot/loader/entries/rmcboot.conf
> mylibdir:root:root:770:/tgt_root/etc/mylib/
> mylib.conf:root:root:660:/tgt_root/etc/mylib/mylib.conf
>
> When installer cannot get config file for the type of running board,
> it skips any board-specific deployment. If a command fails for a file,
> installer simply move to the next file.
>
> After all the boot entries are deployed, installer seeks a config file
> KBOOTPARAM from RMC database file. In success, it appends the content
> of KBOOTPARAM to the end of kernel command line of every deployed
> entry. KBOOTPARAM works as a global kernel command line fragment
> specific to the type of running board.
>
> The installer is a copy of EFI installer script in OE meta:
> ./recipes-core/initrdscripts/files/init-install-efi.sh
> (1f2a01b02e9e175cad4cf05b3ff7430bba232eb6)
>
It seems like this is the wrong way to go - to have another copy of the
same exact file, which is quite large, somewhere else in the system.
Besides the obvious duplication, what happens when bugs are found in one
- is this going to track all patches to the original?
I suppose that since having rmc in meta-intel is just a stopover to
oe-core, it's a temporary situation, but even still, it would be nice if
it would be possible to make and submit changes to the original (I guess
when rmc is in oe-core, it will need them anyway) and use them from rmc
in meta-intel..
Tom
> Signed-off-by: Jianxun Zhang
> ---
> .../initrdscripts/files/init-install-efi.sh| 315
> +
> .../initramfs-live-install-efi_%.bbappend | 1 +
> 2 files changed, 316 insertions(+)
> create mode 100644
> common/recipes-core/initrdscripts/files/init-install-efi.sh
> create mode 100644
> common/recipes-core/initrdscripts/initramfs-live-install-efi_%.bbappend
>
> diff --git a/common/recipes-core/initrdscripts/files/init-install-efi.sh
> b/common/recipes-core/initrdscripts/files/init-install-efi.sh
> new file mode 100644
> index 000..ec685d3
> --- /dev/null
> +++ b/common/recipes-core/initrdscripts/files/init-install-efi.sh
> @@ -0,0 +1,315 @@
> +#!/bin/sh -e
> +#
> +# Copyright (c) 2016, Intel Corporation.
> +# All rights reserved.
> +#
> +# install.sh [device_name] [rootfs_name]
> +#
> +# This file is a copy of file with same name in OE:
> +# meta/recipes-core/initrdscripts/files/. We modify
> +# it for RMC feature to deploy file blobs from RMC
> +# database file to target.
> +
> +PATH=/sbin:/bin:/usr/sbin:/usr/bin
> +
> +# We need 20 Mb for the boot partition
> +boot_size=20
> +
> +# 5% for swap
> +swap_ratio=5
> +
> +# Get a list of hard drives
> +hdnamelist=""
> +live_dev_name=`cat /proc/mounts | grep ${1%/} | awk '{print $1}'`
> +live_dev_name=${live_dev_name#\/dev/}
> +# Only strip the digit identifier if the device is not an mmc
> +case $live_dev_name in
> +mmcblk*)
> +;;
> +*)
> +live_dev_name=${live_dev_name%%[0-9]*}
> +;;
> +esac
> +
> +echo "Searching for hard drives ..."
> +
> +for device in `ls /sys/block/`; do
> +case $device in
> +loop*)
> +# skip loop device
> +;;
> +sr*)
> +# skip CDROM device
> +;;
> +ram*)
> +# skip ram device
> +;;
> +*)
> +# skip the device LiveOS is on
> +# Add valid hard drive name to the list
> +case $device in
> +$live_dev_name*)
> +# skip the device we are running from
> +;;
> +*)
> +hdnamelist="$hdnamelist $device"
> +;;
> +esac
> +;;
> +esac
> +done
> +
> +if [ -z "${hdnamelist}" ]; then
> +echo "You need another device (besides the live devic
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
On 07/21/2016 06:02 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 3:41 PM, Tom Zanussi wrote: >> >> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>> Provide a README for RMC feature. Also check in fingerprints and >>> configuration data for several boards as examples for users. >>> They can be used for validation too. >>> >>> Signed-off-by: Jianxun Zhang >> >> [...] >> >>> + >>> +Note 3: >>> +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to >>> the >>> +board, then tries to fetch each file specified in this config file, and >>> then >>> +deploy the file onto target with its permissions, UID, GID and other >>> attributes >>> +also specified in this config file if file for the board can be retrieved >>> from >>> +RMC database. The format of this file is (# is for comment line) >>> + >>> +# name:uid:gid:mode:path_on_target >>> +# to create a directory, add a “/” at the end of path_on_target: >>> +audio_policy:0:0:600:/etc/audio/ >>> +audio_def_policy:0:0:600:/etc/audio/audio_policy >>> + >>> +The first line tells RMC installer to create a directory “audio” in /etc. >>> If any >>> +parent directory doesn’t exist, installer will create it. The above example >>> +creates /etc/audio directory first, then fetch a file named >>> “audio_def_policy” >>> +from RMC database for the board, then copy it to /etc/audio/ with a new >>> name >>> +“audio_policy”. >>> + >> >> This example explicitly creates the /etc/audio directory first, then the >> audio_policy file inside. It seems you're doing this here just as an >> example, but when I tried without creating the /etc/audio directory >> first, it failed… > Great catch! The correct information is in commit msg of installer patch, but > not updated in README. :-( > Will fix this. > So, the fix is to make the code match "If any parent directory doesn’t exist, installer will create it". Seems like that's the right fix.. Tom >> >> Tom >> >>> +If this config file is not provided, only default entries “boot” and >>> “install” >>> +from OE are in boot menu. The name of this config file is what installer >>> looks >>> +up first, so it must be “INSTALLER.CONFIG”. >>> + >>> + >> > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 6/6] rmc: document and examples for RMC feature
On 07/21/2016 03:37 AM, Jianxun Zhang wrote: > Provide a README for RMC feature. Also check in fingerprints and > configuration data for several boards as examples for users. > They can be used for validation too. > > Signed-off-by: Jianxun Zhang [...] > + > +Note 3: > +At runtime, RMC installer tries to fetch INSTALLER.CONFIG file specific to > the > +board, then tries to fetch each file specified in this config file, and then > +deploy the file onto target with its permissions, UID, GID and other > attributes > +also specified in this config file if file for the board can be retrieved > from > +RMC database. The format of this file is (# is for comment line) > + > +# name:uid:gid:mode:path_on_target > +# to create a directory, add a “/” at the end of path_on_target: > +audio_policy:0:0:600:/etc/audio/ > +audio_def_policy:0:0:600:/etc/audio/audio_policy > + > +The first line tells RMC installer to create a directory “audio” in /etc. If > any > +parent directory doesn’t exist, installer will create it. The above example > +creates /etc/audio directory first, then fetch a file named > “audio_def_policy” > +from RMC database for the board, then copy it to /etc/audio/ with a new name > +“audio_policy”. > + This example explicitly creates the /etc/audio directory first, then the audio_policy file inside. It seems you're doing this here just as an example, but when I tried without creating the /etc/audio directory first, it failed... Tom > +If this config file is not provided, only default entries “boot” and > “install” > +from OE are in boot menu. The name of this config file is what installer > looks > +up first, so it must be “INSTALLER.CONFIG”. > + > + -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv3 1/6] rmc: Add Runtime Machine Configuration (RMC) project
On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
> RMC recipe fetch RMC project and build it more than once in
> build time:
>
> RMC tool is built for host architecture (native). The tool for
> host is used to generate RMC database in build time.
>
> RMC tool is also built for target architecture, so that scripts
> in user space can call RMC tool on a running target. Developers
> can also boot a target and run rmc tool to obtain fingerprint
> for a new board type.
>
> RMC libraries are compiled for both of UEFI context and user
> space. They are always linked in RMC tool and can be linked
> into an EFI bootloader. The recipes don't install libraries
> for target's user space until we have a new client needs it.
>
> The rmc-db.bbclass provides functions to generate rmc database
> file for other software components to reuse.
>
> We absorb a patch from Tom Zanussi to update source location with
> the public link. We could put this change in another commit, but
> leaving the replaced internal link in this commit could cause
> trouble when people bisect the project but don't have access to
> the internal location:
> --
> rmc: Update to use public repo
>
> The repo the rmc recipe was pointing to was private - it's now public
> Signed-off-by: Tom Zanussi
>
> common/recipes-bsp/rmc/rmc.inc | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/common/recipes-bsp/rmc/rmc.inc b/common/recipes-bsp/rmc/rmc.inc
> index c046e2e..bdf930d 100644
> --- a/common/recipes-bsp/rmc/rmc.inc
> +++ b/common/recipes-bsp/rmc/rmc.inc
> @@ -15,7 +15,7 @@ LICENSE = "MIT"
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=bcdd376d27b26bde6afadd67aa3c8b07"
>
> -SRC_URI = "git://g...@git.yoctoproject.org/rmc;protocol=ssh"
> +SRC_URI = "git://git.yoctoproject.org/rmc"
> ...
> --
>
> Signed-off-by: Jianxun Zhang
> ---
> classes/rmc-db.bbclass| 92
> +++
> common/recipes-bsp/rmc/rmc.bb | 46 ++
> 2 files changed, 138 insertions(+)
> create mode 100644 classes/rmc-db.bbclass
> create mode 100644 common/recipes-bsp/rmc/rmc.bb
>
> diff --git a/classes/rmc-db.bbclass b/classes/rmc-db.bbclass
> new file mode 100644
> index 000..0fb4c27
> --- /dev/null
> +++ b/classes/rmc-db.bbclass
> @@ -0,0 +1,92 @@
> +# RMC database bbclass
> +# provide functions to generate RMC database file on build host (native)
> +
> +DEPENDS += "rmc-native"
> +
> +# rmc_generate_db()
> +# $1: a list of directories. Each directory holds directories for a group of
> +# boards.
> +# $2: path_name of rmc generates database file and records
> +#
> +# WARNING: content of directory of database file will be removed.
> +#
> +# Each board directory shall contain a fingerprint file (*.fp) at least, with
> +# optional file blob(s) associated to the type of board. If a board directory
> +# has no file blob, no record is created for that board.
> +#
> +# An example of two directories each of which contains two boards for RMC:
> +# (All file and directory names are for illustration purpose.)
> +#
> +# dir_1/
> +# board_1/
> +# board_1_fingerprint.fp
> +# file_1.blob
> +# board_2/
> +# board_2.fp
> +# dir_2/
> +# board_3/
> +# b3.fp
> +# file_1.blob
> +# file_2.conf
> +# board_4/
> +# board_foo.fp
> +# mylib.config
> +#
I was easily able to accidentally create nonsense configuration and
nothing told me it was wrong.
For example, in my BOOTENTRY.CONFIG I mistyped a filename that didn't exist:
doesntexistboot.conf
It would seem that would be something the user would definitely be
interested in knowing (along with any other errors in .conf files
themselves), especially since there doesn't seem to be any way on the
target to tell what the source of the problem is.
It seems you should be able to detect that when generating the db file
on the host at least.
Basically there doesn't seem to be any way to determine the cause of
problems other than inspection, which is going to cause lots of
complaints from users.
Tom
> +# To generate a RMC database "rmc.db" with data of all (actually 3) of
> boards in
> +# a directory "deploy_dir":
> +#
> +# rmc_generate_db "dir_1 dir_2" "deploy_dir/rmc.db"
> +#
> +# The board_2 will be skipped. No record or any data for it is packed in
> +# generated database because it only contains a fingerprint file.
> +#
> +
> +rmc_generate_db () {
> + RMC_BOARD_DIRS=$1
> +
>
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 04:35 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 1:07 PM, Tom Zanussi wrote: >> >> On 07/21/2016 02:22 PM, Jianxun Zhang wrote: >>> >>>> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >>>> wrote: >>>> >>>> Hi Jianxun, >>>> >>>> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>>>> V3 addresses feedbacks for V2, also includes other fixes: >>>>> >>>>> () Explicitly tell user overriding is a temporary solution in README >>>>> >>>>> () Move back two readme files back to top dir >>>>> >>>>> () Move RMC README to /documentation/rmc/ >>>>> >>>>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>>>> >>>>> () patches have been squashed >>>>> >>>>> () Now any new change of files in a board dir can be effective with a >>>>> rebuild. >>>>> >>>>> () removing tmp dir in build won't cause build issue. (it is uncesesary >>>>> either) >>>>> >>>>> () amend commit messages >>>>> >>>>> () amend installation logic in database recipe >>>>> >>>> >>>> It seems to be working in general and I see updates when I change, but I >>>> seem to be getting extra boot menu items I didn't ask for. >>>> >>>> I have a BOOTENTRY.CONFIG with just this: >>>> >>>> boot.conf >>>> >>>> and in boot.conf: >>>> >>>> title NextUnitofComputing Gen3 boot >>>> linux /vmlinuz >>>> initrd /initrd >>>> options LABEL=mybootlabel >>>> >>>> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >>>> two entries before it: >>>> >>>> boot >>>> install >>>> >>>> I would expect to see only what I have in my configuration. Or am I >>>> doing something wrong? >>>> >>> Tom, >>> No, you don’t do anything wrong. It is designed that way. Any boot entry >>> you pack in RMC are addition to the two default entries “boot” and >>> “install” which are built from OE. There are different routes to add >>> entries. >>> >>> OE allows user to bring their own boot entries in build >>> (GUMMIBOOT_ENTRIES), so we should not override these. >>> >>> However, we cannot assume which entry should be replaced/overridden at >>> runtime too because what you see in boot menu is title filed which could be >>> anything from user. >>> >>> User could be confused when he realize there are two boot or install >>> options, but he can quickly change titles in conf file to differentiate. >>> >> >> Yes, I certainly was confused to see two boot entries. Even if I rename >> them like you suggest, how do I rename them to avoid confusion for the >> user i.e. which boot do I use, and if I'm supposed to ignore the other >> one, why is it there? > I think we shouldn’t enforce any naming policy here at this point. This is > out of RMC control. Will user complain for confusion caused be another “boot” > from a conf file added via the existing GUMMIBOOT_ENTRIES? > You're the one suggesting renaming some to avoid confusing the user (because apparently we can't get rid of the two boot entries we didn't specify in rmc), nobody mentioned a naming policy. > I am not suggesting user to “ignore” other boot entries. I should say RMC > just provides another source of boot entries. It is totally up to user for > how to provide an entry, what should be in that entry, and eventually which > entry to boot system. > Multiple sources of boot entries is just confusing. > If we overrides any entries, I guess we will miss corner cases when people > still want to boot a supported target with default settings... > So how can we not make the corner cases drive the default of what most users would expect? i.e. make the default be that the user only sees the menu entries specified via rmc? with a fallback for the corner case users to see the other entries? >> >> To me it seems reasonable to assume that an rmc user would expect rmc >> menu management to be owned by rmc and not be surprised by other options >> from the base bootloader. Or to say it a different way, what's the use >> case for an rmc user to want to manage menu items in two separate >> places, the
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 02:22 PM, Jianxun Zhang wrote: > >> On Jul 21, 2016, at 11:37 AM, Tom Zanussi >> wrote: >> >> Hi Jianxun, >> >> On 07/21/2016 03:37 AM, Jianxun Zhang wrote: >>> V3 addresses feedbacks for V2, also includes other fixes: >>> >>> () Explicitly tell user overriding is a temporary solution in README >>> >>> () Move back two readme files back to top dir >>> >>> () Move RMC README to /documentation/rmc/ >>> >>> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README >>> >>> () patches have been squashed >>> >>> () Now any new change of files in a board dir can be effective with a >>> rebuild. >>> >>> () removing tmp dir in build won't cause build issue. (it is uncesesary >>> either) >>> >>> () amend commit messages >>> >>> () amend installation logic in database recipe >>> >> >> It seems to be working in general and I see updates when I change, but I >> seem to be getting extra boot menu items I didn't ask for. >> >> I have a BOOTENTRY.CONFIG with just this: >> >> boot.conf >> >> and in boot.conf: >> >> title NextUnitofComputing Gen3 boot >> linux /vmlinuz >> initrd /initrd >> options LABEL=mybootlabel >> >> I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see >> two entries before it: >> >> boot >> install >> >> I would expect to see only what I have in my configuration. Or am I >> doing something wrong? >> > Tom, > No, you don’t do anything wrong. It is designed that way. Any boot entry you > pack in RMC are addition to the two default entries “boot” and “install” > which are built from OE. There are different routes to add entries. > > OE allows user to bring their own boot entries in build (GUMMIBOOT_ENTRIES), > so we should not override these. > > However, we cannot assume which entry should be replaced/overridden at > runtime too because what you see in boot menu is title filed which could be > anything from user. > > User could be confused when he realize there are two boot or install options, > but he can quickly change titles in conf file to differentiate. > Yes, I certainly was confused to see two boot entries. Even if I rename them like you suggest, how do I rename them to avoid confusion for the user i.e. which boot do I use, and if I'm supposed to ignore the other one, why is it there? To me it seems reasonable to assume that an rmc user would expect rmc menu management to be owned by rmc and not be surprised by other options from the base bootloader. Or to say it a different way, what's the use case for an rmc user to want to manage menu items in two separate places, the base bootloader and rmc? > An expectation is installer. RMC deployment is always effective no matter > which install option is selected so that RMC deployment on a supported board > is guaranteed. > I can see cases where an 'install' menu item isn't wanted or needed, like for example on an already-installed system. Tom > Thanks > >> Tom >> >> >>> Jianxun Zhang (6): >>> rmc: Add Runtime Machine Configuration (RMC) project >>> gnu-efi: Add GUID for SMBIOS 3 entry point structure >>> systemd-boot: load board-specific entry and kernel cmdline >>> EFI installer: deploy board-specific data and kernel cmdline >>> rmc: add recipe and bbclass for RMC feature >>> rmc: document and examples for RMC feature >>> >>> classes/rmc-db.bbclass | 92 ++ >>> classes/rmc-systemd-boot.bbclass | 12 + >>> ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ >>> common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + >>> .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + >>> .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes >>> common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + >>> .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + >>> .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + >>> common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + >>> .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes >>> .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + >>> .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + >>> .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes >>> .../rmc/boards/nucgen6/BOOTENT
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
Hi Jianxun, On 07/21/2016 03:37 AM, Jianxun Zhang wrote: > V3 addresses feedbacks for V2, also includes other fixes: > > () Explicitly tell user overriding is a temporary solution in README > > () Move back two readme files back to top dir > > () Move RMC README to /documentation/rmc/ > > () Replace wrong EFI_PROVIDER info with Distro feature in RMC README > > () patches have been squashed > > () Now any new change of files in a board dir can be effective with a rebuild. > > () removing tmp dir in build won't cause build issue. (it is uncesesary > either) > > () amend commit messages > > () amend installation logic in database recipe > It seems to be working in general and I see updates when I change, but I seem to be getting extra boot menu items I didn't ask for. I have a BOOTENTRY.CONFIG with just this: boot.conf and in boot.conf: title NextUnitofComputing Gen3 boot linux /vmlinuz initrd /initrd options LABEL=mybootlabel I do see that 'NextUnitofComputing Gen3 boot" menu item, but I also see two entries before it: boot install I would expect to see only what I have in my configuration. Or am I doing something wrong? Tom > Jianxun Zhang (6): > rmc: Add Runtime Machine Configuration (RMC) project > gnu-efi: Add GUID for SMBIOS 3 entry point structure > systemd-boot: load board-specific entry and kernel cmdline > EFI installer: deploy board-specific data and kernel cmdline > rmc: add recipe and bbclass for RMC feature > rmc: document and examples for RMC feature > > classes/rmc-db.bbclass | 92 ++ > classes/rmc-systemd-boot.bbclass | 12 + > ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 32 ++ > common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + > .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + > .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes > common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + > .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + > .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + > common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + > .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes > .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + > .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + > .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes > .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + > .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + > common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + > common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + > common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + > common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + > common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes > common/recipes-bsp/rmc/rmc-db.bb | 46 +++ > common/recipes-bsp/rmc/rmc.bb | 46 +++ > .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ > ...d-boot-Link-RMC-libraries-into-bootloader.patch | 31 ++ > ...d-board-specific-boot-entries-from-RMC-da.patch | 241 +++ > ...pport-global-kernel-command-line-fragment.patch | 66 > .../initrdscripts/files/init-install-efi.sh| 315 +++ > .../initramfs-live-install-efi_%.bbappend | 1 + > conf/layer.conf| 16 + > documentation/rmc/README | 337 > + > 31 files changed, 1301 insertions(+) > create mode 100644 classes/rmc-db.bbclass > create mode 100644 classes/rmc-systemd-boot.bbclass > create mode 100644 > common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch > create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/minnowmaxB3.fp > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/INSTALLER.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM > create mode 100644 common/recipes-bsp/rmc/boards/nucgen6/boot.conf > create mode 100644 common/recipes-bsp/rmc
Re: [meta-intel] [PATCHv3 0/6] Runtime Machine Configuration (RMC)
On 07/21/2016 03:37 AM, Jianxun Zhang wrote:
> V3 addresses feedbacks for V2, also includes other fixes:
>
> () Explicitly tell user overriding is a temporary solution in README
>
> () Move back two readme files back to top dir
>
> () Move RMC README to /documentation/rmc/
>
> () Replace wrong EFI_PROVIDER info with Distro feature in RMC README
>
> () patches have been squashed
>
> () Now any new change of files in a board dir can be effective with a rebuild.
>
> () removing tmp dir in build won't cause build issue. (it is uncesesary
> either)
>
> () amend commit messages
>
> () amend installation logic in database recipe
>
Just noting things as I see them. Seeing this warning builing v3:
WARNING: rmc-db-1.0-r0 do_unpack: rmc-db: the directory ${WORKDIR}/${BP}
(/usr/local/dev/yocto/rmc-test-v3/build/tmp/work/corei7-64-poky-linux/rmc-db/1.0-r0/rmc-db-1.0)
pointed to by the S variable doesn't exist - please set S within the
recipe to point to where the source has been unpacked to
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv2 7/7] rmc: Use DISTRO_FEATURES as feature switch
On 07/19/2016 01:53 PM, Jianxun Zhang wrote:
>
>> On Jul 19, 2016, at 11:07 AM, Tom Zanussi
>> wrote:
>>
>> On 07/18/2016 08:00 PM, Jianxun Zhang wrote:
>>> From: Saul Wold
>>>
>>> This refactoring is based on Saul Wold's initial attempt
>>> to have a more appropriate switch than using EFI_PROVIDER,
>>> to capture the whole RMC feature.
>>>
>>> Now put DISTRO_FEATURES_append = " rmc" in a conf file to
>>> enable RMC feature.
>>>
>>> RMC patches in systemd-boot, gnu-efi and EFI installer are
>>> not effective in build unless the feature is enabled.
>>>
>>> Signed-off-by: Jianxun Zhang
>>> ---
>>> conf/layer.conf | 16
>>> documentation/README.rmc | 5 -
>>> 2 files changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/conf/layer.conf b/conf/layer.conf
>>> index d8e5000..8e22186 100644
>>> --- a/conf/layer.conf
>>> +++ b/conf/layer.conf
>>> @@ -15,3 +15,19 @@ LICENSE_PATH += "${LAYERDIR}/common/custom-licenses"
>>> # This should only be incremented on significant changes that will
>>> # cause compatibility issues with other layers
>>> LAYERVERSION_intel = "3"
>>> +
>>> +
>>> +# Exclude RMC patches unless RMC Feature is eanbled
>>> +RMC_BBMASK :=
>>> "${LAYERDIR}/common/recipes-bsp/systemd-boot/systemd-boot.*\.bbappend \
>>> +
>>> ${LAYERDIR}/common/recipes-core/initrdscripts/initramfs-live-install-efi.*\.bbappend
>>> \
>>> + ${LAYERDIR}/common/recipes-bsp/gnu-efi/gnu-efi.*\.bbappend"
>>> +
>>> +BBMASK += "${RMC_BBMASK}"
>>> +
>>> +BBMASK_remove = "${@bb.utils.contains('DISTRO_FEATURES', 'rmc',
>>> '${RMC_BBMASK}', '', d)}"
>>> +
>>> +# Override EFI_PROVIDER when RMC Feature is enabled
>>> +
>>> +EFI_PROVIDER_rmc_bootloader = "rmc-systemd-boot"
>>> +
>>> +OVERRIDES_append = ":${@bb.utils.contains('DISTRO_FEATURES', 'rmc',
>>> 'rmc_bootloader', '', d)}"
>>> diff --git a/documentation/README.rmc b/documentation/README.rmc
>>> index eb31d22..d00b5ef 100644
>>> --- a/documentation/README.rmc
>>> +++ b/documentation/README.rmc
>>> @@ -153,7 +153,10 @@ up first, so it must be “INSTALLER.CONFIG”.
>>> Enable RMC Feature
>>>
>>> To Enable RMC feature in build, add the below line in a conf file:
>>> -EFI_PROVIDER="rmc-systemd-boot"
>>> +DISTRO_FEATURES_append = " rmc"
>>> +
>>> +Note: To ensure its whole functionality, RMC Feature overrides any
>>> bootloader
>>> +selected in EFI_PROVIDER with its own bootloader.
>>>
>>
>> It's ok to do this for a first implementation, but it needs to be made
>> very clear to the user that this isn't how it's supposed to work and is
>> just a temporary state of affairs. i.e. the RMC feature isn't meant ot
>> override a bootloader, just augment it despite what the initial
>> implementation does.
>>
>
> Tom,
> Installer and bootloader are key parts in RMC feature. The point to group
> pieces together with a distro switch is to treat them as a whole. That means
> we do want RMC to override any settings if we care the functionality of this
> feature. Otherwise, we lose the point to have a feature switch.
>
> But what’s to be improved is RMC should provide user a way to specify a
> RMC-supported bootloader once we add 2nd or more bootloaders with RMC
> support. This won’t change our argument on overriding however, regard to a
> single or a set of supported bootloader to replace others.
>
From a user's perspective, it seems simple - if I want to use
systemd-boot, I just say
EFI_PROVIDER = "systemd-boot"
If I specify that I want to use the rmc support with that, I add
DISTRO_FEATURES_append = " rmc" according to your latest scheme, in
order to do that.
If I don't add the rmc DISTRO_FEATURES_append, I just get the same
bootloader but no rmc support.
If I specify
EFI_PROVIDER = "grub-efi"
and
DISTRO_FEATURES_append = " rmc"
I'd expect rmc support to be added, if the bootloader supports it. If
not, no harm done, I just get the bootloader as I always have.
That would be the same no matter how many bootlo
Re: [meta-intel] [PATCHv2 7/7] rmc: Use DISTRO_FEATURES as feature switch
On 07/18/2016 08:00 PM, Jianxun Zhang wrote:
> From: Saul Wold
>
> This refactoring is based on Saul Wold's initial attempt
> to have a more appropriate switch than using EFI_PROVIDER,
> to capture the whole RMC feature.
>
> Now put DISTRO_FEATURES_append = " rmc" in a conf file to
> enable RMC feature.
>
> RMC patches in systemd-boot, gnu-efi and EFI installer are
> not effective in build unless the feature is enabled.
>
> Signed-off-by: Jianxun Zhang
> ---
> conf/layer.conf | 16
> documentation/README.rmc | 5 -
> 2 files changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/conf/layer.conf b/conf/layer.conf
> index d8e5000..8e22186 100644
> --- a/conf/layer.conf
> +++ b/conf/layer.conf
> @@ -15,3 +15,19 @@ LICENSE_PATH += "${LAYERDIR}/common/custom-licenses"
> # This should only be incremented on significant changes that will
> # cause compatibility issues with other layers
> LAYERVERSION_intel = "3"
> +
> +
> +# Exclude RMC patches unless RMC Feature is eanbled
> +RMC_BBMASK :=
> "${LAYERDIR}/common/recipes-bsp/systemd-boot/systemd-boot.*\.bbappend \
> +
> ${LAYERDIR}/common/recipes-core/initrdscripts/initramfs-live-install-efi.*\.bbappend
> \
> + ${LAYERDIR}/common/recipes-bsp/gnu-efi/gnu-efi.*\.bbappend"
> +
> +BBMASK += "${RMC_BBMASK}"
> +
> +BBMASK_remove = "${@bb.utils.contains('DISTRO_FEATURES', 'rmc',
> '${RMC_BBMASK}', '', d)}"
> +
> +# Override EFI_PROVIDER when RMC Feature is enabled
> +
> +EFI_PROVIDER_rmc_bootloader = "rmc-systemd-boot"
> +
> +OVERRIDES_append = ":${@bb.utils.contains('DISTRO_FEATURES', 'rmc',
> 'rmc_bootloader', '', d)}"
> diff --git a/documentation/README.rmc b/documentation/README.rmc
> index eb31d22..d00b5ef 100644
> --- a/documentation/README.rmc
> +++ b/documentation/README.rmc
> @@ -153,7 +153,10 @@ up first, so it must be “INSTALLER.CONFIG”.
> Enable RMC Feature
>
>
> To Enable RMC feature in build, add the below line in a conf file:
> -EFI_PROVIDER="rmc-systemd-boot"
> +DISTRO_FEATURES_append = " rmc"
> +
> +Note: To ensure its whole functionality, RMC Feature overrides any bootloader
> +selected in EFI_PROVIDER with its own bootloader.
>
It's ok to do this for a first implementation, but it needs to be made
very clear to the user that this isn't how it's supposed to work and is
just a temporary state of affairs. i.e. the RMC feature isn't meant ot
override a bootloader, just augment it despite what the initial
implementation does.
Thanks,
Tom
>
>
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCHv2 6/7] rmc: document and examples for RMC feature
Hi Jianxun,
Just a couple quick comments, still reviewing but wanted to get these
noted...
On 07/18/2016 08:00 PM, Jianxun Zhang wrote:
> Provide a README.rmc for RMC feature in a new directory
> "documentation", also move other README files in top directory
> there.
>
> 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
> README => documentation/README | 0
> documentation/README.rmc | 332
> +
> README.sources => documentation/README.sources | 0
> 20 files changed, 376 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
> rename README => documentation/README (100%)
> create mode 100644 documentation/README.rmc
> rename README.sources => documentation/README.sources (100%)
>
> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
> b/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
> new file mode 100644
> index 000..b2fabe8
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG
> @@ -0,0 +1,2 @@
> +boot.conf
> +install.conf
> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
> b/common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp
> new file mode 100644
> index
> ..86ecea7344bfc744f7f9d57f3f1810d6f7ba0db1
> GIT binary patch
> literal 116
> zcmZQ%Ehx%QDNQbk&r8frWe71eFbHvEV8SZOB2boERGgWg$KaV)lA5Ctq^aOolAo&)
> p;;X6P91yAyWo&L@px~fjsAp{K?oq{1&rp1_02dA-n(p
>
> literal 0
> HcmV?d1
>
> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
> b/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
> new file mode 100644
> index 000..f1578e0
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/T100-32bit/boot.conf
> @@ -0,0 +1,4 @@
> +title T100T(32bit) boot
> +linux /vmlinuz
> +initrd /initrd
> +options LABEL=boot loglevel=8
> diff --git a/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
> b/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
> new file mode 100644
> index 000..67e7eb1
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/T100-32bit/install.conf
> @@ -0,0 +1,4 @@
> +title T100T(32bit) install
> +linux /vmlinuz
> +initrd /initrd
> +options LABEL=install-efi
> diff --git a/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> new file mode 100644
> index 000..cb01ced
> --- /dev/null
> +++ b/common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG
> @@ -0,0 +1 @@
> +boot.conf
> diff
Re: [meta-intel] [PATCH 0/2] linux-yocto SRCREV update July 14
On 07/14/2016 06:26 PM, California Sullivan wrote: > Hi Tom, > > This week's SRCREV update is pretty large. For linux-yocto 4.4, we > forklift the entire i915 driver from the Linux 4.7 kernel into our > kernel as well as bring in a point release from stable. For linux-yocto > 4.1 we bring in a point release and a couple more Broxton patches. > > In smoke testing I found no new errors or warnings. Since the drm > backport is complete I also ran the piglit test suite on MinnowBoard > and NUC6. Both completed sucessfully, which is great since previously > the NUC6 would encounter a graphics bug and hang the system. > Nice! Also boot-tested core-image-sato on my NUC 3 with both kernels here and saw no problems... Thanks, Tom > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for v4.4.14 and drm forklift > linux-yocto/4.1: Update SRCREVs for v4.1.27 and Broxton fixes > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 6 +++--- > 6 files changed, 18 insertions(+), 18 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 6/6] rmc: document and examples for rmc distro feature
On 07/14/2016 12:07 PM, Saul Wold wrote: > On Thu, 2016-07-14 at 08:05 -0500, Tom Zanussi wrote: >> On 07/14/2016 01:34 AM, Jianxun Zhang wrote: >>> >>> >>>> >>>> On Jul 13, 2016, at 3:43 PM, Tom Zanussi >>> .com> wrote: >>>> >>>> On 07/13/2016 04:21 PM, Jianxun Zhang wrote: >>>>> >>>>> >>>> [...] >>>> >>>>> >>>>>> >>>>>>> >>>>>>> + >>>>>>> + >>>>>>> +Enable >>>>>>> + >>>>>>> >>>>>>> +To Enable RMC distro feature in build, add the below line >>>>>>> in a conf file: >>>>>>> +EFI_PROVIDER="rmc-distro" >>>>>>> + >>>>>> Is rmc-distro actually meant to be an EFI provider? I know >>>>>> you only >>>>>> support systemd-boot for now, but assuming there was also >>>>>> support in >>>>>> grub-efi for rmc, how would the user specify that? >>>>> Tom, >>>>> BTW, I proposed to change it to “rmc-boot” in another reply to >>>>> Saul. I think we should have a better switch later. Technically >>>>> developer can modify any software to use RMC project, so yours >>>>> is a valid point. But for this “rmc image” feature, locking >>>>> down to a bootloader greatly simplifies the maintenance. I >>>>> actually did a shopping among existing EFI bootloaders in YP >>>>> and go with systemd-boot... >>>>> >>>> Well, you're calling it an image feature, and it does seem like >>>> it's a >>>> feature you're adding to an image, but EFI_PROVIDER="rmc-boot" >>>> doesn't >>>> capture that. I'm not saying this is the way to do it - I hope >>>> some >>>> build system expert could suggest an appropriate way to do this, >>>> but I'd >>>> expect that if I wanted to add support for RMC to an image, I'd >>>> do >>>> something more like: >>>> >>>> IMAGE_FEATURES += "rmc" >>>> >>>> EFI_PROVIDER="systemd-boot" or EFI_PROVIDER="grub-efi" >>>> >>>> That also simplifies the naming… >>> Tom, >>> () As what I proposed, “rmc” is for rmc project. We should split >>> the new project with this image feature. The later one modified >>> bootloader and installer to call rmc project to have an end-to-end >>> solution. It is the first (combo) user case of RMC. rmc project’s >>> recipe and bbclass is intended to be reused by other software in >>> the future. >>> >>> () If user specify another bootloader “grub-efi” but don’t have RMC >>> change in it, this setup actually breaks image feature. RMC DB is >>> installed via an EFI bootloader bbclass. This is the only interface >>> I found to deploy a file to ESP without changing OE - inherit from >>> systemd-boot bbclass or override it. >>> >>> () BTW, I think inherit from systemd-boot is better than reuse >>> “EFI_PROVIDER=systemd-boot” since people may want to have systemd- >>> boot without rmc image feature. That means we will have a rmc- >>> boot.bbclass inheriting systemd-boot... >>> > A better clearer name here would be rmc-systemd-boot.bbclass that way > when we get grub-efi working with an rmc-grub-efi.bbclass or switch to > the IMAGE_FEATURES. > Right, and these names illustrate the fact that it should be treated as an attribute and that the approach is unscalable. >>> I know EFI_PROVIDER=rmc-boot is strange as a switch of whole image >>> feature. Do we have some ways to use IMAGE_FEATURE and still >>> enforce only using bootloader we suppport? >>> >>> Not an expert at these points. I will work on other feedbacks first >>> and let’s go back to this based on new series. >>> >> Right, I'm not an expert either on these points of wrt build system >> implementation - let's just agree at a high level first. >> > I am probably the closed expert right now, and yes, ultimately having > this as an IMAGE_FEATURE would be great, but we are not there yet. > > I also verified how bbclass overriding/extending works. > >> To me, it behaves like an attribute which w
Re: [meta-intel] [PATCH 6/6] rmc: document and examples for rmc distro feature
On 07/14/2016 01:34 AM, Jianxun Zhang wrote: > >> On Jul 13, 2016, at 3:43 PM, Tom Zanussi wrote: >> >> On 07/13/2016 04:21 PM, Jianxun Zhang wrote: >>> >> >> [...] >> >>>>> + >>>>> + >>>>> +Enable >>>>> + >>>>> +To Enable RMC distro feature in build, add the below line in a conf file: >>>>> +EFI_PROVIDER="rmc-distro" >>>>> + >>>> >>>> Is rmc-distro actually meant to be an EFI provider? I know you only >>>> support systemd-boot for now, but assuming there was also support in >>>> grub-efi for rmc, how would the user specify that? >>> Tom, >>> BTW, I proposed to change it to “rmc-boot” in another reply to Saul. I >>> think we should have a better switch later. Technically developer can >>> modify any software to use RMC project, so yours is a valid point. But for >>> this “rmc image” feature, locking down to a bootloader greatly simplifies >>> the maintenance. I actually did a shopping among existing EFI bootloaders >>> in YP and go with systemd-boot... >>> >> >> Well, you're calling it an image feature, and it does seem like it's a >> feature you're adding to an image, but EFI_PROVIDER="rmc-boot" doesn't >> capture that. I'm not saying this is the way to do it - I hope some >> build system expert could suggest an appropriate way to do this, but I'd >> expect that if I wanted to add support for RMC to an image, I'd do >> something more like: >> >> IMAGE_FEATURES += "rmc" >> >> EFI_PROVIDER="systemd-boot" or EFI_PROVIDER="grub-efi" >> >> That also simplifies the naming… > Tom, > () As what I proposed, “rmc” is for rmc project. We should split the new > project with this image feature. The later one modified bootloader and > installer to call rmc project to have an end-to-end solution. It is the > first (combo) user case of RMC. rmc project’s recipe and bbclass is intended > to be reused by other software in the future. > > () If user specify another bootloader “grub-efi” but don’t have RMC change in > it, this setup actually breaks image feature. RMC DB is installed via an EFI > bootloader bbclass. This is the only interface I found to deploy a file to > ESP without changing OE - inherit from systemd-boot bbclass or override it. > > () BTW, I think inherit from systemd-boot is better than reuse > “EFI_PROVIDER=systemd-boot” since people may want to have systemd-boot > without rmc image feature. That means we will have a rmc-boot.bbclass > inheriting systemd-boot... > > I know EFI_PROVIDER=rmc-boot is strange as a switch of whole image feature. > Do we have some ways to use IMAGE_FEATURE and still enforce only using > bootloader we suppport? > > Not an expert at these points. I will work on other feedbacks first and > let’s go back to this based on new series. > Right, I'm not an expert either on these points of wrt build system implementation - let's just agree at a high level first. To me, it behaves like an attribute which when set modifies something to give it that attribute if it applies, but doesn't break it if it doesn't apply. So the user should be able to specify the bootloader of choice like as they do now, and if the 'rmc' attribute is set, it's built with rmc support, and if not, it isn't. And if the user sets the 'rmc' attribute for a bootloader that can't support rmc, it's just ignored (and warned about) but doesn't break anything. If we can agree on that, then we can work on looking at the most appropriate build system interface to use. As for the name, it doesn't matter what the rmc project is called - the attribute name used by the build system can refer to it any way it wants. Actually, it would be good to give it a more descriptive name than an acronym like 'rmc', but I can't think of anything at the moment... Tom >> >> Also, although you may have shopped around for the best EFI bootloader, >> it may not be the best one tomorrow or for someone else. >> >> So I think we need to get this right for supporting multiple >> EFI_PROVIDERS. This is an externally visible interface and if we go >> with a hack to start with, we'll break anyone using it in the future >> when we have to change it - better to start with something extensible.. >> >> >>> Copy my proposal here: >>> Saul, >>> I think it i
Re: [meta-intel] [PATCH 6/6] rmc: document and examples for rmc distro feature
On 07/13/2016 04:21 PM, Jianxun Zhang wrote: > [...] >>> + >>> + >>> +Enable >>> + >>> +To Enable RMC distro feature in build, add the below line in a conf file: >>> +EFI_PROVIDER="rmc-distro" >>> + >> >> Is rmc-distro actually meant to be an EFI provider? I know you only >> support systemd-boot for now, but assuming there was also support in >> grub-efi for rmc, how would the user specify that? > Tom, > BTW, I proposed to change it to “rmc-boot” in another reply to Saul. I think > we should have a better switch later. Technically developer can modify any > software to use RMC project, so yours is a valid point. But for this “rmc > image” feature, locking down to a bootloader greatly simplifies the > maintenance. I actually did a shopping among existing EFI bootloaders in YP > and go with systemd-boot... > Well, you're calling it an image feature, and it does seem like it's a feature you're adding to an image, but EFI_PROVIDER="rmc-boot" doesn't capture that. I'm not saying this is the way to do it - I hope some build system expert could suggest an appropriate way to do this, but I'd expect that if I wanted to add support for RMC to an image, I'd do something more like: IMAGE_FEATURES += "rmc" EFI_PROVIDER="systemd-boot" or EFI_PROVIDER="grub-efi" That also simplifies the naming... Also, although you may have shopped around for the best EFI bootloader, it may not be the best one tomorrow or for someone else. So I think we need to get this right for supporting multiple EFI_PROVIDERS. This is an externally visible interface and if we go with a hack to start with, we'll break anyone using it in the future when we have to change it - better to start with something extensible.. > Copy my proposal here: > Saul, > I think it is a good idea because what it does is generate a centralized ‘db’ > inside rmc project build path. > I propose these to address all feedbacks on naming in V2: > () rmc.bb -> rmc.bb (no change, it is for bare rmc project) > () rmc-distro.bb -> rmc-db.bb (as you suggested) > () rmc-native.bb -> (merged into rmc.bb, I will try it) > () rmc-native.bbclass -> rmc-db.bbclass (it uses native tool to make db) > () rmc-distro.bbclass-> rmc-boot.bbclass. > user sets EFI_PROVIDER=rmc-boot to enable rmc image feature. This is the only > odd ball in my proposal, but it may not be totally absurd. It inherits > systemd-boot anyway. Later we could use MACHINE_FEATURE or DISTRO_FEATURE to > enable “rmc-image” feature to replace an EFI bootloader-like name to enable > the whole thing. Assume the word “image” is okay here. :-) > > >> [...] >>> + >>> +If no any board-specific configuration becomes effective on your board but >>> it >>> +works on other boards of same product, you can run rmc tool to obtain >>> +fingerprint file on your board and compare it with fingerprint of a working >>> +board. It is possible they have different firmware versions and unluckily, >>> some >>> +information for fingerprint changes between two versions. You can update >>> BIOS >>> +on every board to the same BIOS version if it is feasible. Otherwise you >>> have >>> +to treat them as two different type of boards. We could extend rmc design >>> to >>> +allow multiple fingerprints in a board directory as a workaround. >>> + >> >> Would it be possible to do some kind of fingerprint wildcarding in >> addition/instead? > This case shouldn’t happen quite often for launched products because board in > product won’t be changed on user’s hands. I think wild card approach could > cause ambiguity hard to debug when RMC load data wrongly for a board type. > > My plan is to support multiple fingerprints for a single type of board later. > > Sometimes FW engineers do things out of our control and expectation. >> OK, but it seems strange to have two identical boards that have nothing but trivial firmware differences treated as separate types by the system. Tom -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 6/6] rmc: document and examples for rmc distro feature
Hi Jianxun, Overall this looks like a good start, some specific comments inline. There also seems to be some documentation in the recipes themselves that would be good to have in this document. The recipes refer to this file for 'more information' and there is more information here, but there's also useful background information and descriptions of how things are meant to work together in the recipes that isn't here. For the most part, the documentation in the recipes that doesn't specifically talk about the recipe details should be a subset of what's here, I think. On 07/12/2016 12:59 PM, Jianxun Zhang wrote: > Provide a README.rmc.distro for rmc-distro. > > 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 > --- > README.rmc.distro | 261 > + > .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + > .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes > common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + > .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + > .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + > common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + > .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes > .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + > .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + > .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes > .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + > .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + > common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + > common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + > common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + > common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + > common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes > common/recipes-bsp/rmc/rmc-distro.bb | 2 +- > 19 files changed, 306 insertions(+), 1 deletion(-) > create mode 100644 README.rmc.distro > 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 > > diff --git a/README.rmc.distro b/README.rmc.distro > new file mode 100644 > index 000..f32d856 > --- /dev/null > +++ b/README.rmc.distro > @@ -0,0 +1,261 @@ > +RMC Disro > + > +Table of Contents > + > +Introduction > +Usage > +Enable > +Examples > +Troubleshooting > + > + > + > +Introduction: > + > +RMC Distro feature fills functionality gaps between a build for a generic > +machine like intel-corei7-64 and boards which require board-specific quirks > and > +configurations. These special customizations cannot be covered by > conventional > +auto-detection features based on probing a hardware module because they > happen > +at a board or a product level. For example: > + - tty console to be specified for a type of board in kernel cmdline > + - default audio configuration > + - network configuration > + - UI layout > + - requirement to software driven by a mechanical design > + - or static configuration bits for a physical bus that doesn't support to > + identify devices or their presence at runtime > + > +An image with the feature has ability to configure supported boards with data > +associated only to a type of board to get full functionality of the target at > +runtime, yet still with a single image. > + > +The effect is identical as what a conventional image customized for a type of > +board (depending on the way to deploy image). >
Re: [meta-intel] [PATCH 0/6] Runtime Machine Configuration and Distro
On 07/12/2016 06:06 PM, Saul Wold wrote: > On Tue, 2016-07-12 at 10:59 -0700, Jianxun Zhang wrote: >> This patch seriese introduces new RMC project and RMC distro that's >> developped based on RMC. >> >> The test is done on several boards, including boards checked in >> examples. (poky:6bb3069; meta-intel: 9bb4622) >> >> Some people may have checked implementation before, but I have done >> a lot refactoring since this week. Now RMC project and RMC distro >> are splitted and bbclasses are provided for reuse in other clients. >> These should be the biggest change you didn't see in old code. >> >> The last patch in the series adds examples and a new document >> README.rmc.distro in meta-intel. I think it could make original >> README too lengthy if we put everyting in README, but let me know >> if a single readme is still preferred. >> > I strongly urge you not to use the word "distro" here or in the recipe > name. > >> README.rmc.distro is designed to be the interfce to new users (and >> myself). Information of RMC project can be obtained from rmc >> recipes, bbclass and RMC project's README. I should have left traces >> to these information in code. >> >> Known issues: >> RMC tool crashes on a NUC gen 4 but doesn't on another sample. Other >> boards work as expected (nuc gen 6, minnowmax, T100,). >> >> Default "install" boot option could be seen although RMC distro >> always has its own installer effective. This could confuse users when >> both of install and "RMC install" options show up on the board. >> >> >> Jianxun Zhang (6): >> rmc: Add Runtime Machine Configuration (RMC) project >> gnu-efi: Add GUID for SMBIOS 3 entry point structure >> systemd-boot: load board-specific entry and kernel cmdline >> EFI installer: deploy board-specific data and kernel cmdline >> rmc: add recipe and bbclass for feature "rmc distro" >> rmc: document and examples for rmc distro feature >> >> README.rmc.distro | 261 >> + > Let's not have the README.rmc.distro in the top level, maybe we need to > have a documentation directory and we can move this file there. > That would make sense, if it looks like we're going to have more stand-alone documentation - do you foresee that? I guess I don't have a problem with a separate README like this because meta-intel is supposedly just a temporary stopover for this since it's ultimately destined for oe-core. Where would this go in oe-core? Tom -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/6] Runtime Machine Configuration and Distro
On 07/12/2016 12:59 PM, Jianxun Zhang wrote: > This patch seriese introduces new RMC project and RMC distro that's > developped based on RMC. > > The test is done on several boards, including boards checked in > examples. (poky:6bb3069; meta-intel: 9bb4622) > > Some people may have checked implementation before, but I have done > a lot refactoring since this week. Now RMC project and RMC distro > are splitted and bbclasses are provided for reuse in other clients. > These should be the biggest change you didn't see in old code. > > The last patch in the series adds examples and a new document > README.rmc.distro in meta-intel. I think it could make original > README too lengthy if we put everyting in README, but let me know > if a single readme is still preferred. > > README.rmc.distro is designed to be the interfce to new users (and > myself). Information of RMC project can be obtained from rmc > recipes, bbclass and RMC project's README. I should have left traces > to these information in code. > > Known issues: > RMC tool crashes on a NUC gen 4 but doesn't on another sample. Other > boards work as expected (nuc gen 6, minnowmax, T100,). > It also segfaults on my NUC gen 3. I think this needs to be fixed before we can pull it in. Tom > Default "install" boot option could be seen although RMC distro > always has its own installer effective. This could confuse users when > both of install and "RMC install" options show up on the board. > > > Jianxun Zhang (6): > rmc: Add Runtime Machine Configuration (RMC) project > gnu-efi: Add GUID for SMBIOS 3 entry point structure > systemd-boot: load board-specific entry and kernel cmdline > EFI installer: deploy board-specific data and kernel cmdline > rmc: add recipe and bbclass for feature "rmc distro" > rmc: document and examples for rmc distro feature > > README.rmc.distro | 261 + > classes/rmc-distro.bbclass | 49 > classes/rmc-native.bbclass | 92 ++ > ...d-GUID-for-SMBIOS-3-entry-point-structure.patch | 30 ++ > common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend | 2 + > .../rmc/boards/T100-32bit/BOOTENTRY.CONFIG | 2 + > .../rmc/boards/T100-32bit/T100-32bit.fp| Bin 0 -> 116 bytes > common/recipes-bsp/rmc/boards/T100-32bit/boot.conf | 4 + > .../recipes-bsp/rmc/boards/T100-32bit/install.conf | 4 + > .../rmc/boards/minnowmax/BOOTENTRY.CONFIG | 1 + > common/recipes-bsp/rmc/boards/minnowmax/boot.conf | 4 + > .../recipes-bsp/rmc/boards/minnowmax/minnowmax.fp | Bin 0 -> 143 bytes > .../rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG| 1 + > .../recipes-bsp/rmc/boards/minnowmaxB3/boot.conf | 4 + > .../rmc/boards/minnowmaxB3/minnowmaxB3.fp | Bin 0 -> 148 bytes > .../rmc/boards/nucgen6/BOOTENTRY.CONFIG| 2 + > .../rmc/boards/nucgen6/INSTALLER.CONFIG| 6 + > common/recipes-bsp/rmc/boards/nucgen6/KBOOTPARAM | 1 + > common/recipes-bsp/rmc/boards/nucgen6/boot.conf| 4 + > common/recipes-bsp/rmc/boards/nucgen6/install.conf | 4 + > common/recipes-bsp/rmc/boards/nucgen6/mylib.conf | 7 + > common/recipes-bsp/rmc/boards/nucgen6/nuc6.fp | Bin 0 -> 149 bytes > common/recipes-bsp/rmc/rmc-distro.bb | 28 ++ > common/recipes-bsp/rmc/rmc-native.bb | 7 + > common/recipes-bsp/rmc/rmc.bb | 21 ++ > common/recipes-bsp/rmc/rmc.inc | 22 ++ > .../recipes-bsp/systemd-boot/systemd-boot.bbappend | 20 ++ > ...d-boot-Link-RMC-libraries-into-bootloader.patch | 29 ++ > ...d-board-specific-boot-entries-from-RMC-da.patch | 239 > ...pport-global-kernel-command-line-fragment.patch | 64 + > .../initrdscripts/files/init-install-efi.sh| 315 > + > .../initramfs-live-install-efi_%.bbappend | 1 + > 32 files changed, 1224 insertions(+) > create mode 100644 README.rmc.distro > create mode 100644 classes/rmc-distro.bbclass > create mode 100644 classes/rmc-native.bbclass > create mode 100644 > common/recipes-bsp/gnu-efi/gnu-efi/0001-Add-GUID-for-SMBIOS-3-entry-point-structure.patch > create mode 100644 common/recipes-bsp/gnu-efi/gnu-efi_%.bbappend > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/T100-32bit.fp > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/T100-32bit/install.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/boot.conf > create mode 100644 common/recipes-bsp/rmc/boards/minnowmax/minnowmax.fp > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/BOOTENTRY.CONFIG > create mode 100644 common/recipes-bsp/rmc/boards/minnowmaxB3/
Re: [meta-intel] [PATCH 0/6] Runtime Machine Configuration and Distro
On 07/12/2016 02:36 PM, Tom Zanussi wrote: > Hi Jianxun, > > I'm just starting to look at this - it's a lot and will take awhile, but > first thing right off is that I'm having a problem building: > Also got this at the end: WARNING: core-image-minimal-1.0-r0 do_image_complete: The license listed MIT was not in the licenses collected for recipe rmc-distro Here's a patch that fixes the build error: [PATCH] rmc: Update to use public repo The repo the rmc recipe was pointing to was private - it's now public so remove the ssh protocol from the SRC_URI. Signed-off-by: Tom Zanussi --- common/recipes-bsp/rmc/rmc.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/recipes-bsp/rmc/rmc.inc b/common/recipes-bsp/rmc/rmc.inc index c046e2e..bdf930d 100644 --- a/common/recipes-bsp/rmc/rmc.inc +++ b/common/recipes-bsp/rmc/rmc.inc @@ -15,7 +15,7 @@ LICENSE = "MIT" LIC_FILES_CHKSUM = "file://COPYING;md5=bcdd376d27b26bde6afadd67aa3c8b07" -SRC_URI = "git://g...@git.yoctoproject.org/rmc;protocol=ssh" +SRC_URI = "git://git.yoctoproject.org/rmc" SRCREV = "f10c018fbaa19072c7281726e1457c73a409e1d1" -- 2.5.0 > $ bitbake core-image-minimal > Loading cache: 100% > |###| > Time: 0:00:00 > Loaded 1324 entries from dependency cache. > Parsing recipes: 100% > |#| > Time: 0:00:00 > Parsing of 884 .bb files complete (883 cached, 1 parsed). 1324 targets, > 51 skipped, 0 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > > Build Configuration: > BB_VERSION= "1.31.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "Ubuntu-15.10" > TARGET_SYS= "x86_64-poky-linux" > MACHINE = "intel-corei7-64" > DISTRO= "poky" > DISTRO_VERSION= "2.1+snapshot-20160712" > TUNE_FEATURES = "m64 corei7" > TARGET_FPU= "" > meta > meta-poky > meta-yocto-bsp= "master0:6bb3069eeff76373041f8da08418386fe5ef5897" > meta-intel= "master0:9f40e8e6bc783d013229e38ce14909cc4d30263a" > > Initialising tasks: 100% > |##| > Time: 0:00:05 > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > WARNING: rmc-1.0-r0 do_fetch: Failed to fetch URL > git://g...@git.yoctoproject.org/rmc;protocol=ssh, attempting MIRRORS if > available > ERROR: rmc-1.0-r0 do_fetch: Fetcher failure: Fetch command failed with > exit code 128, output: > Cloning into bare repository > '/usr/local/dev/yocto/downloads/git2/git.yoctoproject.org.rmc'... > Permission denied (publickey). > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. > > ERROR: rmc-1.0-r0 do_fetch: Function failed: Fetcher failure for URL: > 'git://g...@git.yoctoproject.org/rmc;protocol=ssh'. Unable to fetch URL > from any source. > ERROR: Logfile of failure stored in: > /usr/local/dev/yocto/rmc-test/build/tmp/work/corei7-64-poky-linux/rmc/1.0-r0/temp/log.do_fetch.1274 > ERROR: Task > /usr/local/dev/yocto/rmc-test/meta-intel/common/recipes-bsp/rmc/rmc.bb:do_fetch > (/usr/local/dev/yocto/rmc-test/meta-intel/common/recipes-bsp/rmc/rmc.bb:do_fetch) > failed with exit code '1' > NOTE: Tasks Summary: Attempted 509 tasks of which 0 didn't need to be > rerun and 1 failed. > > Summary: 1 task failed: > > /usr/local/dev/yocto/rmc-test/meta-intel/common/recipes-bsp/rmc/rmc.bb:do_fetch > Summary: There was 1 WARNING message shown. > Summary: There were 2 ERROR messages shown, returning a non-zero exit code. > > On 07/12/2016 12:59 PM, Jianxun Zhang wrote: >> This patch seriese introduces new RMC project and RMC distro that's >> developped based on RMC. >> >> The test is done on several boards, including boards checked in >> examples. (poky:6bb3069; meta-intel: 9bb4622) >> > > So it seems that in order for me to test this, I need to do the build as > above, run the rmc tool on the target, get the fingerprint, and then > create a new layer with that new fingerprint in the correct directory > structure, rebuild, etc. > > I see that you have a bunch of examples, but I don't see the example > layer you mention in the README. It would make it much easier to test > if you didn't force the user to go through all that just to try it out. > Can you provide an example layer, maybe including all the boards in
Re: [meta-intel] [PATCH 0/6] Runtime Machine Configuration and Distro
Hi Jianxun, I'm just starting to look at this - it's a lot and will take awhile, but first thing right off is that I'm having a problem building: $ bitbake core-image-minimal Loading cache: 100% |###| Time: 0:00:00 Loaded 1324 entries from dependency cache. Parsing recipes: 100% |#| Time: 0:00:00 Parsing of 884 .bb files complete (883 cached, 1 parsed). 1324 targets, 51 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.31.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-15.10" TARGET_SYS= "x86_64-poky-linux" MACHINE = "intel-corei7-64" DISTRO= "poky" DISTRO_VERSION= "2.1+snapshot-20160712" TUNE_FEATURES = "m64 corei7" TARGET_FPU= "" meta meta-poky meta-yocto-bsp= "master0:6bb3069eeff76373041f8da08418386fe5ef5897" meta-intel= "master0:9f40e8e6bc783d013229e38ce14909cc4d30263a" Initialising tasks: 100% |##| Time: 0:00:05 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: rmc-1.0-r0 do_fetch: Failed to fetch URL git://g...@git.yoctoproject.org/rmc;protocol=ssh, attempting MIRRORS if available ERROR: rmc-1.0-r0 do_fetch: Fetcher failure: Fetch command failed with exit code 128, output: Cloning into bare repository '/usr/local/dev/yocto/downloads/git2/git.yoctoproject.org.rmc'... Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. ERROR: rmc-1.0-r0 do_fetch: Function failed: Fetcher failure for URL: 'git://g...@git.yoctoproject.org/rmc;protocol=ssh'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /usr/local/dev/yocto/rmc-test/build/tmp/work/corei7-64-poky-linux/rmc/1.0-r0/temp/log.do_fetch.1274 ERROR: Task /usr/local/dev/yocto/rmc-test/meta-intel/common/recipes-bsp/rmc/rmc.bb:do_fetch (/usr/local/dev/yocto/rmc-test/meta-intel/common/recipes-bsp/rmc/rmc.bb:do_fetch) failed with exit code '1' NOTE: Tasks Summary: Attempted 509 tasks of which 0 didn't need to be rerun and 1 failed. Summary: 1 task failed: /usr/local/dev/yocto/rmc-test/meta-intel/common/recipes-bsp/rmc/rmc.bb:do_fetch Summary: There was 1 WARNING message shown. Summary: There were 2 ERROR messages shown, returning a non-zero exit code. On 07/12/2016 12:59 PM, Jianxun Zhang wrote: > This patch seriese introduces new RMC project and RMC distro that's > developped based on RMC. > > The test is done on several boards, including boards checked in > examples. (poky:6bb3069; meta-intel: 9bb4622) > So it seems that in order for me to test this, I need to do the build as above, run the rmc tool on the target, get the fingerprint, and then create a new layer with that new fingerprint in the correct directory structure, rebuild, etc. I see that you have a bunch of examples, but I don't see the example layer you mention in the README. It would make it much easier to test if you didn't force the user to go through all that just to try it out. Can you provide an example layer, maybe including all the boards in the examples, as you mention in the README? Thanks, Tom > Some people may have checked implementation before, but I have done > a lot refactoring since this week. Now RMC project and RMC distro > are splitted and bbclasses are provided for reuse in other clients. > These should be the biggest change you didn't see in old code. > > The last patch in the series adds examples and a new document > README.rmc.distro in meta-intel. I think it could make original > README too lengthy if we put everyting in README, but let me know > if a single readme is still preferred. > > README.rmc.distro is designed to be the interfce to new users (and > myself). Information of RMC project can be obtained from rmc > recipes, bbclass and RMC project's README. I should have left traces > to these information in code. > > Known issues: > RMC tool crashes on a NUC gen 4 but doesn't on another sample. Other > boards work as expected (nuc gen 6, minnowmax, T100,). > > Default "install" boot option could be seen although RMC distro > always has its own installer effective. This could confuse users when > both of install and "RMC install" options show up on the board. > > > Jianxun Zhang (6): > rmc: Add Runtime Machine Configuration (RMC) project > gnu-efi: Add GUID for SMBIOS 3 entry point structure > systemd-boot: load board-specific entry and kernel cmdline > EFI installer: deploy board-specific data and kernel cmdline > rmc: add recipe and bbclass for feature "rmc distro" > rmc: document and examples for rmc distro feature > > README.rmc.distro | 261 + > classes/rmc-distro.bbclass
Re: [meta-intel] [PATCH 0/2] SRCREV update July 7
On 07/07/2016 08:50 PM, California Sullivan wrote: > Hi Tom, > > This set of SRCREV updates brings in more items for Broxton and Apollo > Lake support. > > No new errors or warnings when using poky krogoth. Poky master HEAD has > a segfault in matchbox-panel but that appears to be unrelated to this > update. > Yeah, it is unrelated - I built and booted intel-corei7-64 with these kernel changes but useing an older poky commit, and didn't see the segfault in matchbox-panel. For reference, here's the commit I used. commit 5c11e365e19357f721c49d076971567e7b64b61b Author: Ross Burton Date: Tue Jun 21 15:33:11 2016 +0100 lib/oeqa: add Galculator to SDK and runtime tests Merged, thanks, Tom > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for more Broxton fixes and features > linux-yocto/4.1: Update SRCREVs for better Apollo Lake support > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++-- > 6 files changed, 12 insertions(+), 12 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH v2] thermald: Add thermal daemon utility
Merged, thanks.
Tom
On 07/07/2016 03:38 AM, Yong Li wrote:
> This user space thermal daemon utility is used for thermal management
>
> Signed-off-by: Yong Li
> ---
> common/recipes-bsp/thermald/thermald_1.5.3.bb | 27
> +++
> 1 file changed, 27 insertions(+)
> create mode 100644 common/recipes-bsp/thermald/thermald_1.5.3.bb
>
> diff --git a/common/recipes-bsp/thermald/thermald_1.5.3.bb
> b/common/recipes-bsp/thermald/thermald_1.5.3.bb
> new file mode 100644
> index 000..cb2b07e
> --- /dev/null
> +++ b/common/recipes-bsp/thermald/thermald_1.5.3.bb
> @@ -0,0 +1,27 @@
> +SUMMARY = "Linux thermal daemon"
> +
> +DESCRIPTION = "Thermal Daemon is a Linux daemon used to prevent the \
> +overheating of platforms. This daemon monitors temperature and applies \
> +compensation using available cooling methods."
> +
> +HOMEPAGE = "https://github.com/01org/thermal_daemon";
> +
> +DEPENDS = "dbus dbus-glib libxml2 glib-2.0"
> +DEPENDS +=
> "${@bb.utils.contains('DISTRO_FEATURES','systemd','systemd','',d)}"
> +
> +LICENSE = "GPL-2.0"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=ea8831610e926e2e469075b52bf08848"
> +
> +SRC_URI = "https://github.com/01org/thermal_daemon/archive/v${PV}.tar.gz";
> +SRC_URI[md5sum] = "66402236ed3c86a798029cb4d5313817"
> +SRC_URI[sha256sum] =
> "e20b450ef27a5b5e45474c831663c8f5ecd14c82ace5a4b1e06c442e0a23b53e"
> +
> +S = "${WORKDIR}/thermal_daemon-${PV}"
> +
> +inherit pkgconfig autotools systemd
> +
> +FILES_${PN} += "${datadir}/dbus-1/system-services/*.service"
> +
> +SYSTEMD_SERVICE_${PN} = "thermald.service"
> +
> +COMPATIBLE_HOST = '(i.86|x86_64).*-linux'
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [master][PATCH 0/1] Fix DPDK build error with GCC 6
On 10/03/2047 02:14 PM, Rahul Kumar Gupta wrote: > Dear Maintainer(s), > > This change is to fix the misleading indentation warning/error in the > DPDK 16.04 with GCC version 6. This is the warning teated as error since > yocto is using -Wall and -Werror. > > A new warning -Wmisleading-indentation was added to -Wall in GCC version 6, > warning about places where the indentation of the code might mislead a human > reader about the control flow. > > The image have been tested on Grantley-Broadwell using intel-corei7-64 BSP. > > Please merge in master if these looks ok. > Merged, thanks. Tom > Thanks, > > Rahul Kumar Gupta (1): > meta-isg: dpdk : Fix for misleading indentation error > > meta-isg/common/recipes-extended/dpdk/dpdk.inc | 1 + > ...6.04-Fix-for-misleading-indentation-error.patch | 56 > ++ > 2 files changed, 57 insertions(+) > create mode 100644 > meta-isg/common/recipes-extended/dpdk/dpdk/dpdk-16.04-Fix-for-misleading-indentation-error.patch > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] Weekly SRCREV update
Merged into master, thanks. Tom On 06/28/2016 09:53 PM, California Sullivan wrote: > Hi Tom, > > Here's the almost-weekly SRCREV update. Was a bit late on this one due > to other focuses and few 4.4 changes. On the other hand, a huge number > backports for Broxton/Apollo Lake were brought into 4.1. In my smoke > testing I didn't find any new issues on MinnowBoard Turbot or NUC6 with > either kernel. > > As usual these changes are also available at: > > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs for latest features and BXT backports > linux-yocto/4.1: Update SRCREVs for lots of BXT/APL backports > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++-- > 6 files changed, 12 insertions(+), 12 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH V2 1/1] lms7: Add patch to fix gcc6 C++ whitespace
Merged into master, thanks.
Tom
On 06/28/2016 05:04 PM, Jianxun Zhang wrote:
> This change is ported from the fix on lms8 for
> the same issue:
>
> commit 6dc3746443523a02f72bf5142cfbe3a800d32f4a
> Author: Saul Wold
> Date: Mon May 16 10:01:49 2016 -0700
>
> lms8: Add patch to fix gcc6 C++ whitespace
>
> This adds a patch to lms8 to fix an error cause by the newer
> C++11 standard being enabled in GCC6 that requires additional
> whitespace around User-Defined literals.
>
> [YOCTO #9640]
>
> Signed-off-by: Saul Wold
> Signed-off-by: Tom Zanussi
>
> Fixes [YOCTO #9785]
>
> Signed-off-by: Jianxun Zhang
> ---
> () Update commit msg to address Tom's feedback
> () Original patch has been tested by running "lms7 --version"
>
> Thanks
>
> common/recipes-bsp/amt/lms7_7.1.20.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/common/recipes-bsp/amt/lms7_7.1.20.bb
> b/common/recipes-bsp/amt/lms7_7.1.20.bb
> index 7ed84fc..87de86b 100644
> --- a/common/recipes-bsp/amt/lms7_7.1.20.bb
> +++ b/common/recipes-bsp/amt/lms7_7.1.20.bb
> @@ -10,7 +10,9 @@ BPN="lms"
> PV_SUB = "25"
> SRC_URI =
> "http://software.intel.com/sites/default/files/m/4/e/a/9/b/37962-${BPN}_${PV}.${PV_SUB}.zip
> \
> file://atnetworktool-printf-fix.patch \
> - file://readlink-declaration.patch"
> + file://readlink-declaration.patch \
> +
> file://0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-error.patch \
> + "
>
> LOCALSRC = "file://${WORKDIR}/outputdir/${BPN}-${PV}-${PV_SUB}.tar.gz"
>
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] lms7: Fix compiling error with GCC 6
On 06/28/2016 12:55 PM, Jianxun Zhang wrote:
> This change is ported from 6dc37464 which fixes lms8.
Please then include the subject and commit text from the other commit so
the user knows what it does by looking at this commit.
Thanks,
Tom
>
> Fixes [YOCTO #9785]
>
> Signed-off-by: Jianxun Zhang
> ---
> Note: Very limited test was done before submission. Only compiling
> against lms7 is tested. Let me know if any more test is expected.
>
> Thanks
>
> common/recipes-bsp/amt/lms7_7.1.20.bb | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/common/recipes-bsp/amt/lms7_7.1.20.bb
> b/common/recipes-bsp/amt/lms7_7.1.20.bb
> index 7ed84fc..87de86b 100644
> --- a/common/recipes-bsp/amt/lms7_7.1.20.bb
> +++ b/common/recipes-bsp/amt/lms7_7.1.20.bb
> @@ -10,7 +10,9 @@ BPN="lms"
> PV_SUB = "25"
> SRC_URI =
> "http://software.intel.com/sites/default/files/m/4/e/a/9/b/37962-${BPN}_${PV}.${PV_SUB}.zip
> \
> file://atnetworktool-printf-fix.patch \
> - file://readlink-declaration.patch"
> + file://readlink-declaration.patch \
> +
> file://0001-Protocol.cpp-Add-whitespace-for-gcc6-compile-error.patch \
> + "
>
> LOCALSRC = "file://${WORKDIR}/outputdir/${BPN}-${PV}-${PV_SUB}.tar.gz"
>
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 1/1] linux-yocto-tiny/4.1: Fix SRCREV override
The SRCREV overrides for tiny were malformed - fix them so they
actually make sense and take effect.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index 78817a3..c73cc21 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -2,8 +2,8 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-SRCREV_meta_nlp-32-intel-common = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
-SRCREV_machine_nlp-32-intel-common = "fb0153332a1fdd0518f9055ece1c53f3a99973f5"
+SRCREV_meta_i586-nlp-32-intel-common =
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_i586-nlp-32-intel-common =
"fb0153332a1fdd0518f9055ece1c53f3a99973f5"
KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 0/1][jethro] Fix linux-yocto-tiny/4.1 SRCREVS
While updating to standard/intel/tiny, I wondered why my changes didn't 'take' and tracked it down to a problem with incomplete SRCREV overrides, which this fixes. The following changes since commit 0513c36afcd955bcb24600ef60f412bc821064b8: linux-yocto-tiny: Fix broken SRCREV specifications (2016-06-24 09:55:20 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib tzanussi/jethro-tiny-srcrev-fix http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/jethro-tiny-srcrev-fix Tom Zanussi (1): linux-yocto-tiny/4.1: Fix SRCREV override common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 5/5] linux-yocto-tiny: Fix broken SRCREV specifications
linux-yocto-tiny uses hyphens rather than underscores between SRCREV
and the machine or meta specification, preventing it from actually
taking effect. Fix it by changing the hyphens to underscores.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index 1d53f56..78817a3 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -2,8 +2,8 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-SRCREV_meta-nlp-32-intel-common = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
-SRCREV_machine-nlp-32-intel-common = "fb0153332a1fdd0518f9055ece1c53f3a99973f5"
+SRCREV_meta_nlp-32-intel-common = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_nlp-32-intel-common = "fb0153332a1fdd0518f9055ece1c53f3a99973f5"
KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 3/5] linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base
The dedicated standard tiny branch for Intel platforms has been
renamed to standard/tiny/intel/base - update the 4.1 tiny kernel
recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index aed3e6e..1d53f56 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -1,9 +1,9 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.18"
+#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-SRCREV_meta-nlp-32-intel-common = "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine-nlp-32-intel-common = "ec18b0b3bd6befd416078e81d775dab37b3f9124"
-KBRANCH_i586-nlp-32-intel-common = "standard/tiny/common-pc"
+SRCREV_meta-nlp-32-intel-common = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine-nlp-32-intel-common = "fb0153332a1fdd0518f9055ece1c53f3a99973f5"
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 0/5][jethro] Use */intel/base branches
This patchset updates krogoth to use the */intel/base branches - these have been soaking in master without problem and have been build- and boot-tested with core2-32, so should be safe to move into jethro now. There is one kernel_configcheck warning for GPIO_GENERIC from the new broxton.cfg fragment, but that isn't anything new - the same problem exists in krogoth and master but no warning is displayed for those releases. In order to provide more timely support for Intel platforms, this patchset makes use of a set of dedicated */intel branches being created for linux-yocto 4.1 kernels. These branches and the corresponding kernel metadata branches provide a place to add Intel-specific features and updates which aren't yet upstream or may never go upstream but nevertheless are useful for various users. This patchset also fixes a couple bugs related to the use of linux-yocto-tiny in meta-intel. The following changes since commit 2397181e99d3155c7a00e1756cec92b568d9a9eb: meta-valleyisland: Update machine SRCREVs to latest commit (2016-05-06 09:14:03 -0700) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib tzanussi/standard-intel-base-updates-jethro http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/standard-intel-base-updates-jethro Tom Zanussi (5): linux-yocto/4.1: Switch to standard/intel/base linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base intel-common-pkgarch: Set common PACKAGE_ARCH for linux-yocto-tiny linux-yocto-tiny: Fix broken SRCREV specifications .../linux/linux-yocto-rt_4.1.bbappend | 24 +++--- .../linux/linux-yocto-tiny_4.1.bbappend| 8 .../recipes-kernel/linux/linux-yocto_4.1.bbappend | 24 +++--- conf/machine/include/intel-common-pkgarch.inc | 1 + 4 files changed, 29 insertions(+), 28 deletions(-) -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 2/5] linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base
The dedicated standard rt branch for Intel platforms has been renamed
to standard/preempt-rt/intel/base - update the 4.1 rt kernel recipe
accordingly.
Signed-off-by: Tom Zanussi
---
.../linux/linux-yocto-rt_4.1.bbappend | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
index c3709cd..7d81fe7 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
@@ -1,25 +1,25 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-LINUX_VERSION_core2-32-intel-common = "4.1.18"
+LINUX_VERSION_core2-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
-SRCREV_meta_core2-32-intel-common = "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine_core2-32-intel-common =
"2a4c22b03d434f7695e607b6ad30f77671985a6d"
+SRCREV_meta_core2-32-intel-common = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_core2-32-intel-common =
"fb58cd4f92e8b7dfbb7f62af9f01518dbb792041"
KMACHINE_core2-32-intel-common = "intel-core2-32"
-KBRANCH_core2-32-intel-common = "standard/preempt-rt/base"
+KBRANCH_core2-32-intel-common = "standard/preempt-rt/intel/base"
KERNEL_FEATURES_append_core2-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
-LINUX_VERSION_corei7-64-intel-common = "4.1.18"
+LINUX_VERSION_corei7-64-intel-common = "4.1.26"
COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
-SRCREV_meta_corei7-64-intel-common = "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine_corei7-64-intel-common =
"2a4c22b03d434f7695e607b6ad30f77671985a6d"
+SRCREV_meta_corei7-64-intel-common = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_corei7-64-intel-common =
"fb58cd4f92e8b7dfbb7f62af9f01518dbb792041"
KMACHINE_corei7-64-intel-common = "intel-corei7-64"
-KBRANCH_corei7-64-intel-common = "standard/preempt-rt/base"
+KBRANCH_corei7-64-intel-common = "standard/preempt-rt/intel/base"
KERNEL_FEATURES_append_corei7-64-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
-LINUX_VERSION_i586-nlp-32-intel-common = "4.1.18"
+LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-SRCREV_meta_i586-nlp-32-intel-common =
"b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine_i586-nlp-32-intel-common =
"2a4c22b03d434f7695e607b6ad30f77671985a6d"
+SRCREV_meta_i586-nlp-32-intel-common =
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_i586-nlp-32-intel-common =
"fb58cd4f92e8b7dfbb7f62af9f01518dbb792041"
KMACHINE_i586-nlp-32-intel-common = "intel-corei7-64"
-KBRANCH_i586-nlp-32-intel-common = "standard/preempt-rt/base"
+KBRANCH_i586-nlp-32-intel-common = "standard/preempt-rt/intel/base"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 1/5] linux-yocto/4.1: Switch to standard/intel/base
The dedicated standard branch for Intel platforms has been renamed to
standard/intel/base - update the 4.1 kernel recipe accordingly.
Signed-off-by: Tom Zanussi
---
.../recipes-kernel/linux/linux-yocto_4.1.bbappend | 24 +++---
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
index b9736b3..c87a7e2 100644
--- a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
@@ -2,29 +2,29 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
-LINUX_VERSION_core2-32-intel-common = "4.1.18"
+LINUX_VERSION_core2-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
KMACHINE_core2-32-intel-common = "intel-core2-32"
-KBRANCH_core2-32-intel-common = "standard/base"
-SRCREV_meta_core2-32-intel-common ?= "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine_core2-32-intel-common ?=
"ec18b0b3bd6befd416078e81d775dab37b3f9124"
+KBRANCH_core2-32-intel-common = "standard/intel/base"
+SRCREV_meta_core2-32-intel-common ?= "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_core2-32-intel-common ?=
"9195020e5747fba069c19996fab079931584a7fb"
KERNEL_FEATURES_append_core2-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
-LINUX_VERSION_corei7-64-intel-common = "4.1.18"
+LINUX_VERSION_corei7-64-intel-common = "4.1.26"
COMPATIBLE_MACHINE_corei7-64-intel-common = "${MACHINE}"
KMACHINE_corei7-64-intel-common = "intel-corei7-64"
-KBRANCH_corei7-64-intel-common = "standard/base"
-SRCREV_meta_corei7-64-intel-common ?=
"b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine_corei7-64-intel-common ?=
"ec18b0b3bd6befd416078e81d775dab37b3f9124"
+KBRANCH_corei7-64-intel-common = "standard/intel/base"
+SRCREV_meta_corei7-64-intel-common ?=
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_corei7-64-intel-common ?=
"9195020e5747fba069c19996fab079931584a7fb"
KERNEL_FEATURES_append_corei7-64-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
# Quark / X1000 BSP Info
-LINUX_VERSION_i586-nlp-32-intel-common = "4.1.18"
+LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
-KBRANCH_i586-nlp-32-intel-common = "standard/base"
-SRCREV_meta_i586-nlp-32-intel-common ?=
"b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine_i586-nlp-32-intel-common ?=
"ec18b0b3bd6befd416078e81d775dab37b3f9124"
+KBRANCH_i586-nlp-32-intel-common = "standard/intel/base"
+SRCREV_meta_i586-nlp-32-intel-common ?=
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_i586-nlp-32-intel-common ?=
"9195020e5747fba069c19996fab079931584a7fb"
KERNEL_FEATURES_append_i586-nlp-32-intel-common = ""
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 4/5] intel-common-pkgarch: Set common PACKAGE_ARCH for linux-yocto-tiny
The linux-yocto-tiny metadata assumes the common PACKAGE_ARCH but
without this is actually machine-specific and broken.
Signed-off-by: Tom Zanussi
---
conf/machine/include/intel-common-pkgarch.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/intel-common-pkgarch.inc
b/conf/machine/include/intel-common-pkgarch.inc
index 66aac12..9de15b2 100644
--- a/conf/machine/include/intel-common-pkgarch.inc
+++ b/conf/machine/include/intel-common-pkgarch.inc
@@ -1,6 +1,7 @@
INTEL_COMMON_PACKAGE_ARCH ?= "${TUNE_PKGARCH}-intel-common"
PACKAGE_ARCH_pn-linux-yocto = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_ARCH_pn-linux-yocto-rt = "${INTEL_COMMON_PACKAGE_ARCH}"
+PACKAGE_ARCH_pn-linux-yocto-tiny = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_ARCH_pn-linux-yocto-dev = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_ARCH_pn-intel-microcode = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_EXTRA_ARCHS_append += "${INTEL_COMMON_PACKAGE_ARCH}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] linux-firmware: remove firmware that is now in OE-Core
Merged, thanks. Tom On 06/23/2016 10:38 PM, Saul Wold wrote: > Remove the recipe since we now include the iwlwifi-8000C-19 version > in the OE-Core recipe, so removes having to carry around an additional > firmware blob. > > Related with OE-Core rev: 8b3d3ac84f787bf4ecccdcbcb97f2dac56acd45c > > [YOCTO #9771] > > Signed-off-by: Saul Wold > --- > .../linux-firmware/iwlwifi-8000C-19.ucode | Bin 2382972 -> 0 > bytes > .../linux-firmware/linux-firmware_git.bbappend| 8 > 2 files changed, 8 deletions(-) > delete mode 100644 > common/recipes-kernel/linux-firmware/linux-firmware/iwlwifi-8000C-19.ucode > delete mode 100644 > common/recipes-kernel/linux-firmware/linux-firmware_git.bbappend > > diff --git > a/common/recipes-kernel/linux-firmware/linux-firmware/iwlwifi-8000C-19.ucode > b/common/recipes-kernel/linux-firmware/linux-firmware/iwlwifi-8000C-19.ucode > deleted file mode 100644 > index > 230f957ac0ca0d5d968af8ca2008b6552a85d772.. > GIT binary patch > literal 0 > HcmV?d1 > > literal 2382972 [snip] -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH V4 1/1] formfactor: detect USB HID keyboard and touch screen
Merged, thanks.
Tom
On 06/23/2016 07:05 PM, Jianxun Zhang wrote:
> The new machconfig probes USB keyboard and touch screen, and
> then sets HAVE_* variables according to detection.
>
> Detectable devices:
> USB HID keyboards (Generic Desktop)
> USB HID touch screens (Digitizer)
>
> Note:
> The intention is to have a way to provide initial formfactor
> settings in a boot procedure. That means supported keyboard
> and touch screen must be connected before machconfig runs.
> Any new connection or disconnection won't be detected until
> machconfig is executed again.
>
> Limitation:
> There could be some USB HID devices presents more than one
> usage in a single descriptor. We will add support once such
> device emerges.
>
> Some platforms may have _virtual_ devices provided by BIOS.
> It will cause false detection when they are presented as
> types we supported. We can add black list logic when it
> becomes a big concern.
>
> Fixes [YOCTO #9205]
>
> Signed-off-by: Jianxun Zhang
> ---
> Just get a hand on this patch. V4 checks the existing of usbhid-command first.
>
> Same test done on NUC 6 and X220 as before.
>
> Let me know if this address feedbacks to previous versions.
>
> .../recipes-bsp/formfactor/formfactor/machconfig | 39
> ++
> .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 1 +
> 2 files changed, 40 insertions(+)
> create mode 100644 common/recipes-bsp/formfactor/formfactor/machconfig
> create mode 100644 common/recipes-bsp/formfactor/formfactor_0.0.bbappend
>
> diff --git a/common/recipes-bsp/formfactor/formfactor/machconfig
> b/common/recipes-bsp/formfactor/formfactor/machconfig
> new file mode 100644
> index 000..b5222b8
> --- /dev/null
> +++ b/common/recipes-bsp/formfactor/formfactor/machconfig
> @@ -0,0 +1,39 @@
> +# Note: super user permission is required to run usbhid-dump
> +# successfully.
> +
> +# HEX keys are according to USB HID spec and USB HID usage table
> +# We could add more keys as needed in the future.
> +
> +# It may not be very accurate. Here we only look for first two lines
> +# of a descriptor section. Example:
> +#
> +# 001:003:000:DESCRIPTOR 1460501386.337809
> +# 05 01 09 02 A1 01 09 01 A1 00 05 09 19 01 29 03
> +# 15 00 25 01 95 03 75 01 81 02 .. .. .. .. .. ..
> +# .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
> +#
> +# By doing so we elimiate false matches when HEX keys are in the lines
> +# in the middle of whole descriptor section.
> +
> +if type usbhid-dump &>/dev/null; then
> +if USBHID_DUMP_OUTPUT=$(usbhid-dump -e descriptor 2>/dev/null|grep -A1
> DESCRIPTOR); then
> +# checker for generic USB HID keyboard
> +USBHID_KBD_CMD="grep -E '^ 05 01 09 06'"
> +
> +# checker for touch screen
> +USBHID_TS_CMD="grep -E '^ 05 0D 09 04'"
> +
> +if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_TS_CMD &>/dev/null; then
> +HAVE_TOUCHSCREEN=1
> +fi
> +
> +if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_KBD_CMD &>/dev/null; then
> +HAVE_KEYBOARD=1
> +else
> +# config script in OE will set HAVE_KEYBOARD=1
> +# if we don't set any value. We have to explicitly
> +# tell it when keyboard is not detected.
> +HAVE_KEYBOARD=0
> +fi
> +fi
> +fi
> diff --git a/common/recipes-bsp/formfactor/formfactor_0.0.bbappend
> b/common/recipes-bsp/formfactor/formfactor_0.0.bbappend
> new file mode 100644
> index 000..72d991c
> --- /dev/null
> +++ b/common/recipes-bsp/formfactor/formfactor_0.0.bbappend
> @@ -0,0 +1 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 8/8] linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base
The dedicated standard rt branch for Intel platforms has been renamed
to standard/preempt-rt/intel/base - update the 4.4 rt kernel recipe
accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index e6bd200..d80eb20 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -1,10 +1,10 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-LINUX_VERSION_INTEL_COMMON = "4.4.3"
-SRCREV_META_INTEL_COMMON ?= "9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
-SRCREV_MACHINE_INTEL_COMMON ?= "fcabc089b516e760d00a066893f9772d1535785c"
+LINUX_VERSION_INTEL_COMMON = "4.4.14"
+SRCREV_META_INTEL_COMMON ?= "870134f4bfa6208d6e5339e065486be3b6e693a5"
+SRCREV_MACHINE_INTEL_COMMON ?= "3f35359cf66659e5a27dc1a5f32f33d730649415"
-KBRANCH_INTEL_COMMON = "standard/preempt-rt/base"
+KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 5/8] linux-yocto-tiny: Fix broken SRCREV specifications
linux-yocto-tiny uses hyphens rather than underscores between SRCREV
and the machine or meta specification, preventing it from actually
taking effect. Fix it by changing the hyphens to underscores.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 4 ++--
common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index 81241e0..bae84bd 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
-SRCREV_meta-i586-nlp-32-intel-common =
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
-SRCREV_machine-i586-nlp-32-intel-common =
"fb0153332a1fdd0518f9055ece1c53f3a99973f5"
+SRCREV_meta_i586-nlp-32-intel-common =
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine_i586-nlp-32-intel-common =
"fb0153332a1fdd0518f9055ece1c53f3a99973f5"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
index e1c2c92..af9d739 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
@@ -1,8 +1,8 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
#LINUX_VERSION_i586-nlp-32-intel-common = "4.4.3"
-SRCREV_meta-i586-nlp-32-intel-common =
"9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
-SRCREV_machine-i586-nlp-32-intel-common =
"076cc85486fda808582bd1e77400a5c49dea3e2e"
+SRCREV_meta_i586-nlp-32-intel-common =
"9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
+SRCREV_machine_i586-nlp-32-intel-common =
"076cc85486fda808582bd1e77400a5c49dea3e2e"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
KBRANCH_i586-nlp-32-intel-common = "standard/tiny/common-pc"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 0/8][krogoth] Use */intel/base branches
This patchset updates krogoth to use the */intel/base branches - these have been soaking in master without problem and have been build- and boot-tested with corei7-64, so should be safe to move into krogoth now. In order to provide more timely support for Intel platforms, this patchset makes use of a set of dedicated */intel branches being created for linux-yocto 4.1 and 4.4 kernels. These branches and the corresponding kernel metadata branches provide a place to add Intel-specific features and updates which aren't yet upstream or may never go upstream but nevertheless are useful for various users. This patchset also fixes a couple bugs related to the use of linux-yocto-tiny in meta-intel. The following changes since commit 58b8e0f2e6c4f6566983baf4bc980a86592398ad: linux-yocto-rt/4.4: Update KBRANCH (2016-06-03 16:58:47 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib tzanussi/standard-intel-base-updates-krogoth http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/standard-intel-base-updates-krogoth Tom Zanussi (8): linux-yocto/4.1: Switch to standard/intel/base linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base intel-common-pkgarch: Set common PACKAGE_ARCH for linux-yocto-tiny linux-yocto-tiny: Fix broken SRCREV specifications linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base linux-yocto/4.4: Switch to standard/intel/base linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 8 common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 8 common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 8 common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 9 + common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 8 common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 8 conf/machine/include/intel-common-pkgarch.inc | 1 + 7 files changed, 26 insertions(+), 24 deletions(-) -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 7/8] linux-yocto/4.4: Switch to standard/intel/base
The dedicated standard branch for Intel platforms has been renamed to
standard/intel/base - update the 4.4 kernel recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
index f908e5b..94d1a24 100644
--- a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
@@ -1,10 +1,10 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-LINUX_VERSION_INTEL_COMMON = "4.4.3"
-SRCREV_META_INTEL_COMMON = "9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
-SRCREV_MACHINE_INTEL_COMMON = "076cc85486fda808582bd1e77400a5c49dea3e2e"
+LINUX_VERSION_INTEL_COMMON = "4.4.14"
+SRCREV_META_INTEL_COMMON = "870134f4bfa6208d6e5339e065486be3b6e693a5"
+SRCREV_MACHINE_INTEL_COMMON = "13852755ecbf491848afbe40e66fc152bc70915b"
-KBRANCH_INTEL_COMMON = "standard/base"
+KBRANCH_INTEL_COMMON = "standard/intel/base"
KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 6/8] linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base
The dedicated standard tiny branch for Intel platforms has been
renamed to standard/tiny/intel/base - update the 4.4 tiny kernel
recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
index af9d739..7fd00bf 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
@@ -1,10 +1,11 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-#LINUX_VERSION_i586-nlp-32-intel-common = "4.4.3"
-SRCREV_meta_i586-nlp-32-intel-common =
"9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
-SRCREV_machine_i586-nlp-32-intel-common =
"076cc85486fda808582bd1e77400a5c49dea3e2e"
+#LINUX_VERSION_i586-nlp-32-intel-common = "4.4.13"
+SRCREV_meta_i586-nlp-32-intel-common =
"870134f4bfa6208d6e5339e065486be3b6e693a5"
+SRCREV_machine_i586-nlp-32-intel-common =
"13852755ecbf491848afbe40e66fc152bc70915b"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-KBRANCH_i586-nlp-32-intel-common = "standard/tiny/common-pc"
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
+
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 4/8] intel-common-pkgarch: Set common PACKAGE_ARCH for linux-yocto-tiny
The linux-yocto-tiny metadata assumes the common PACKAGE_ARCH but
without this is actually machine-specific and broken.
Signed-off-by: Tom Zanussi
---
conf/machine/include/intel-common-pkgarch.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/conf/machine/include/intel-common-pkgarch.inc
b/conf/machine/include/intel-common-pkgarch.inc
index 66aac12..9de15b2 100644
--- a/conf/machine/include/intel-common-pkgarch.inc
+++ b/conf/machine/include/intel-common-pkgarch.inc
@@ -1,6 +1,7 @@
INTEL_COMMON_PACKAGE_ARCH ?= "${TUNE_PKGARCH}-intel-common"
PACKAGE_ARCH_pn-linux-yocto = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_ARCH_pn-linux-yocto-rt = "${INTEL_COMMON_PACKAGE_ARCH}"
+PACKAGE_ARCH_pn-linux-yocto-tiny = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_ARCH_pn-linux-yocto-dev = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_ARCH_pn-intel-microcode = "${INTEL_COMMON_PACKAGE_ARCH}"
PACKAGE_EXTRA_ARCHS_append += "${INTEL_COMMON_PACKAGE_ARCH}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 2/8] linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base
The dedicated standard rt branch for Intel platforms has been renamed
to standard/preempt-rt/intel/base - update the 4.1 rt kernel recipe
accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
index 8e7854f..f4f3194 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
@@ -1,10 +1,10 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-LINUX_VERSION_INTEL_COMMON = "4.1.18"
-SRCREV_META_INTEL_COMMON ?= "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_MACHINE_INTEL_COMMON ?= "28d8cfdbcb18a6eef202099cca66430fd3b6eae0"
+LINUX_VERSION_INTEL_COMMON = "4.1.26"
+SRCREV_META_INTEL_COMMON ?= "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_MACHINE_INTEL_COMMON ?= "fb58cd4f92e8b7dfbb7f62af9f01518dbb792041"
-KBRANCH_INTEL_COMMON = "standard/preempt-rt/base"
+KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 3/8] linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base
The dedicated standard tiny branch for Intel platforms has been
renamed to standard/tiny/intel/base - update the 4.1 tiny kernel
recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index 73208cb..81241e0 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -1,10 +1,10 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.18"
-SRCREV_meta-i586-nlp-32-intel-common =
"b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_machine-i586-nlp-32-intel-common =
"91f62d4a0a31919d9b2ccdaf881130f99b61fc5e"
+#LINUX_VERSION_i586-nlp-32-intel-common = "4.1.26"
+SRCREV_meta-i586-nlp-32-intel-common =
"20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_machine-i586-nlp-32-intel-common =
"fb0153332a1fdd0518f9055ece1c53f3a99973f5"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-KBRANCH_i586-nlp-32-intel-common = "standard/tiny/common-pc"
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 1/8] linux-yocto/4.1: Switch to standard/intel/base
The dedicated standard branch for Intel platforms has been renamed to
standard/intel/base - update the 4.1 kernel recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
index 459ce84..31b3998 100644
--- a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
@@ -1,10 +1,10 @@
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
-LINUX_VERSION_INTEL_COMMON = "4.1.18"
-SRCREV_META_INTEL_COMMON = "b9023d4c8fbbb854c26f158a079a5f54dd61964d"
-SRCREV_MACHINE_INTEL_COMMON = "91f62d4a0a31919d9b2ccdaf881130f99b61fc5e"
+LINUX_VERSION_INTEL_COMMON = "4.1.26"
+SRCREV_META_INTEL_COMMON = "20edcbf4e42dd4cef7213a0ce2a4481d8d296f5d"
+SRCREV_MACHINE_INTEL_COMMON = "9195020e5747fba069c19996fab079931584a7fb"
-KBRANCH_INTEL_COMMON = "standard/base"
+KBRANCH_INTEL_COMMON = "standard/intel/base"
KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] SRCREV update for linux-yocto recipes
Merged, thanks, Cal. Tom On 06/16/2016 05:02 PM, California Sullivan wrote: > Hi Tom, > > Here's another SRCREV update. In 4.4 we just grab some stable updates. > In 4.1 we get stable updates and several backports for BXT/APL support. > > In my smoke tests I found no new errors or warnings. > > As usual this update is also available at: > > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Bump SRCREVs from Linux 4.4.12 to 4.4.13 > linux-yocto/4.1: Bump SRCREVs to Linux 4.1.26 and add BXT/APL > backports > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 6 +++--- > 6 files changed, 18 insertions(+), 18 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] va-intel: set S to WORKDIR
Merged into meta-intel/master, thanks.
Tom
On 06/14/2016 02:21 PM, Ross Burton wrote:
> This package doesn't have a traditional tarball so the default S of PV-PN
> isn't
> valid, set it to $WORKDIR to silence the sanity check.
>
> Signed-off-by: Ross Burton
> ---
> common/recipes-multimedia/libva/va-intel.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/common/recipes-multimedia/libva/va-intel.bb
> b/common/recipes-multimedia/libva/va-intel.bb
> index 0c90148..95e50a1 100644
> --- a/common/recipes-multimedia/libva/va-intel.bb
> +++ b/common/recipes-multimedia/libva/va-intel.bb
> @@ -3,6 +3,8 @@ LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/LICENSE;md5=4d92cd373abda3937c2bc47fbc49d690 \
>
> file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
>
> +S = "${WORKDIR}"
> +
> PR = "r1"
>
> def map_valibs(d):
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH] formfactor: detect USB HID keyboard and touch screen
Hi Jianxun,
On 06/07/2016 06:46 PM, Jianxun Zhang wrote:
> The new machconfig probes USB keyboard and touch screen, and
> then sets HAVE_* variables according to detection.
>
> Detectable devices:
> USB HID keyboards (Generic Desktop)
> USB HID touch screens (Digitizer)
>
> Note:
> The intention is to have a way to provide initial formfactor
> settings in a boot procedure. That means supported keyboard
> and touch screen must be connected before machconfig runs.
> Any new connection or disconnection won't be detected until
> machconfig is executed again.
>
> Limitation:
> There could be some USB HID devices presents more than one
> usage in a single descriptor. We will add support once such
> device emerges.
>
> Some platforms may have _virtual_ devices provided by BIOS.
> It will cause false detection when they are presented as
> types we supported. We can add black list logic when it
> becomes a big concern.
>
> Fixes [YOCTO #9205]
>
> Signed-off-by: Jianxun Zhang
> ---
> .../recipes-bsp/formfactor/formfactor/machconfig | 37
> ++
> .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 1 +
> 2 files changed, 38 insertions(+)
> create mode 100644 common/recipes-bsp/formfactor/formfactor/machconfig
> create mode 100644 common/recipes-bsp/formfactor/formfactor_0.0.bbappend
>
> diff --git a/common/recipes-bsp/formfactor/formfactor/machconfig
> b/common/recipes-bsp/formfactor/formfactor/machconfig
> new file mode 100644
> index 000..17d4978
> --- /dev/null
> +++ b/common/recipes-bsp/formfactor/formfactor/machconfig
> @@ -0,0 +1,37 @@
> +# Note: super user permission is required to run usbhid-dump
> +# successfully.
> +
> +# HEX keys are according to USB HID spec and USB HID usage table
> +# We could add more keys as needed in the future.
> +
> +# checker for generic USB HID keyboard
> +USBHID_KBD_CMD="grep -E '^ 05 01 09 06'"
> +
> +# checker for touch screen
> +USBHID_TS_CMD="grep -E '^ 05 0D 09 04'"
> +
> +# It may not be very accurate. Here we only look for first two lines
> +# of a descriptor section. Example:
> +#
> +# 001:003:000:DESCRIPTOR 1460501386.337809
> +# 05 01 09 02 A1 01 09 01 A1 00 05 09 19 01 29 03
> +# 15 00 25 01 95 03 75 01 81 02 .. .. .. .. .. ..
> +# .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..
> +#
> +# By doing so we elimiate false matches when HEX keys are in the lines
> +# in the middle of whole descriptor section.
> +
> +USBHID_DUMP_OUTPUT=$(usbhid-dump -e descriptor|grep -A1 DESCRIPTOR)
> +
> +if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_TS_CMD &>/dev/null; then
> +HAVE_TOUCHSCREEN=1
> +fi
> +
> +if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_KBD_CMD &>/dev/null; then
> +HAVE_KEYBOARD=1
> +else
> +# config script in OE will set HAVE_KEYBOARD=1
> +# if we don't set any value. We have to explicitly
> +# tell it when keyboard is not detected.
> +HAVE_KEYBOARD=0
> +fi
What if usbhid-dump doesn't exist? In that case, not detecting a
keyboard doesn't mean there isn't one.
I think Saul suggested you check for usbhid-dump first and then exit
having touched nothing that would deviate from the defaults.
Tom
> diff --git a/common/recipes-bsp/formfactor/formfactor_0.0.bbappend
> b/common/recipes-bsp/formfactor/formfactor_0.0.bbappend
> new file mode 100644
> index 000..72d991c
> --- /dev/null
> +++ b/common/recipes-bsp/formfactor/formfactor_0.0.bbappend
> @@ -0,0 +1 @@
> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [master] [krogoth] [PATCH] Fix QA issue on intel-gpu-tools
Hi Rebecca,
On 06/07/2016 01:19 AM, Chang, Rebecca Swee Fun wrote:
> Hi all,
>
> Any comments on this patch?
>
Can you please send detailed info on how to reproduce this build? I
can't see the QA error you mention in either krogoth or master.
In fact, I don't see a packages-split/intel-gpu-tools-benchmarks/usr/lib
directory at all, not to mention a .debug directory there.
Thanks,
Tom
> Regards,
> Rebecca
>
> -Original Message-
> From: meta-intel-boun...@yoctoproject.org
> [mailto:meta-intel-boun...@yoctoproject.org] On Behalf Of Rebecca Chang Swee
> Fun
> Sent: Monday, May 30, 2016 3:41 PM
> To: meta-intel@yoctoproject.org
> Cc: california.sulli...@intel.com; Wold, Saul
> Subject: [meta-intel] [master] [krogoth] [PATCH] Fix QA issue on
> intel-gpu-tools
>
> Hi,
>
> I have encountered bitbake QA issue error when compiling IGT v1.14 into image.
>
> I have it fixed by declaring that .debug goes to ${PN}-dbg package.
>
> ...
> ERROR: QA Issue: non debug package contains .debug directory:
> intel-gpu-tools-benchmarks path
> work/corei7-64-poky-linux/intel-gpu-tools/1.14-r0/packages-split/intel-gpu-tools-benchmarks/usr/lib/intel-gpu-tools/intel-gpu-tools/benchmarks/.debug/gem_mmap
> [debug-files]
> ERROR: QA run found fatal errors. Please consider fixing them.
> ERROR: Function failed: do_package_qa
> ...
>
> Please review whether this fix is proper and feedback for rework if
> necessary. Else, please merge this fix for master and krogoth branch.
>
> Thank you very much.
>
> Regards,
> Rebecca
>
> Rebecca Chang Swee Fun (1):
> intel-gpu-tools_1.14: fix bitbake QA issue on debug-files
>
> common/recipes-graphics/intel-gpu-tools/intel-gpu-tools_1.14.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> --
> 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 0/1] SRCREV update
On 06/07/2016 03:38 PM, California Sullivan wrote: > Hi Tom, > > Here's another SRCREV update. This time we bring in a stable update > and backport some mmc patches that fix issues we're seeing on Broxton > boards. > Merged, thanks. Tom > As usual, the update is also available at: > > git://git.yoctoproject.org/meta-intel-contrib -b clsulliv/master-test > > > Thanks, > Cal Sullivan > > California Sullivan (1): > linux-yocto/4.4: Update SRCREVs to pull in 4.4.12 stable and mmc > backports > > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 6 +++--- > 3 files changed, 9 insertions(+), 9 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/6] Use */intel/base branches
On 06/03/2016 09:11 AM, Tom Zanussi wrote: > The previous standard/intel patchset moved the kernels to > /*standard/intel, but this prevents things like 'rebase' branches from > being branched off of those. */standard/intel/base allows for that > and is more consistent with the standard linux-yocto branching scheme, > so these move things again, this time to use the /base branches. > Merged. > https://lists.yoctoproject.org/pipermail/meta-intel/2016-May/003909.html > > The following changes since commit 9bce6bdccf8ed3d3ae1cc2ae6f1f43c864a4ac34: > > linux-yocto/4.1: Bump SRCREVs to Linux 4.1.24 (2016-05-27 17:35:23 -0500) > > are available in the git repository at: > > git://git.yoctoproject.org/meta-intel-contrib > tzanussi/standard-intel-base-updates > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/standard-intel-base-updates > > Tom Zanussi (6): > linux-yocto/4.4: Switch to standard/intel/base > linux-yocto/4.1: Switch to standard/intel/base > linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base > linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base > linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base > linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 2 +- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 2 +- > 6 files changed, 7 insertions(+), 7 deletions(-) > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/6] Use */intel/base branches
On 06/03/2016 11:06 AM, Bruce Ashfield wrote: > On 2016-06-03 12:04 PM, Tom Zanussi wrote: >> On 06/03/2016 11:00 AM, Bruce Ashfield wrote: >>> On 2016-06-03 10:11 AM, Tom Zanussi wrote: >>>> The previous standard/intel patchset moved the kernels to >>>> /*standard/intel, but this prevents things like 'rebase' branches from >>>> being branched off of those. */standard/intel/base allows for that >>>> and is more consistent with the standard linux-yocto branching scheme, >>>> so these move things again, this time to use the /base branches. >>> >>> And I can confirm that the branches have been renamed in the repos. >>> Let me know if there are any issues. >>> >> >> Thanks Bruce. Did you miss tiny? > > Yep. Fixed now. > Great, thanks! Tom > Bruce > >> >> Tom >> >>> Bruce >>> >>>> >>>> >>>> https://lists.yoctoproject.org/pipermail/meta-intel/2016-May/003909.html >>>> >>>> >>>> The following changes since commit >>>> 9bce6bdccf8ed3d3ae1cc2ae6f1f43c864a4ac34: >>>> >>>> linux-yocto/4.1: Bump SRCREVs to Linux 4.1.24 (2016-05-27 17:35:23 >>>> -0500) >>>> >>>> are available in the git repository at: >>>> >>>> git://git.yoctoproject.org/meta-intel-contrib >>>> tzanussi/standard-intel-base-updates >>>> >>>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/standard-intel-base-updates >>>> >>>> >>>> >>>> Tom Zanussi (6): >>>> linux-yocto/4.4: Switch to standard/intel/base >>>> linux-yocto/4.1: Switch to standard/intel/base >>>> linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base >>>> linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base >>>> linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base >>>> linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base >>>> >>>>common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- >>>>common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +- >>>>common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 2 +- >>>>common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 2 +- >>>>common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 2 +- >>>>common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 2 +- >>>>6 files changed, 7 insertions(+), 7 deletions(-) >>>> >>> >> > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/6] Use */intel/base branches
On 06/03/2016 11:00 AM, Bruce Ashfield wrote: > On 2016-06-03 10:11 AM, Tom Zanussi wrote: >> The previous standard/intel patchset moved the kernels to >> /*standard/intel, but this prevents things like 'rebase' branches from >> being branched off of those. */standard/intel/base allows for that >> and is more consistent with the standard linux-yocto branching scheme, >> so these move things again, this time to use the /base branches. > > And I can confirm that the branches have been renamed in the repos. > Let me know if there are any issues. > Thanks Bruce. Did you miss tiny? Tom > Bruce > >> >> >> https://lists.yoctoproject.org/pipermail/meta-intel/2016-May/003909.html >> >> The following changes since commit >> 9bce6bdccf8ed3d3ae1cc2ae6f1f43c864a4ac34: >> >>linux-yocto/4.1: Bump SRCREVs to Linux 4.1.24 (2016-05-27 17:35:23 >> -0500) >> >> are available in the git repository at: >> >>git://git.yoctoproject.org/meta-intel-contrib >> tzanussi/standard-intel-base-updates >> >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/standard-intel-base-updates >> >> >> Tom Zanussi (6): >>linux-yocto/4.4: Switch to standard/intel/base >>linux-yocto/4.1: Switch to standard/intel/base >>linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base >>linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base >>linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base >>linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base >> >> common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- >> common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +- >> common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 2 +- >> common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 2 +- >> common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 2 +- >> common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 2 +- >> 6 files changed, 7 insertions(+), 7 deletions(-) >> > -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 2/6] linux-yocto/4.1: Switch to standard/intel/base
The dedicated standard branch for Intel platforms has been renamed to
standard/intel/base - update the 4.1 kernel recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
index 2e98ff7..7ea655e 100644
--- a/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_4.1.bbappend
@@ -4,7 +4,7 @@ LINUX_VERSION_INTEL_COMMON = "4.1.24"
SRCREV_META_INTEL_COMMON = "4b4199bd24f206d459061bb0a920d009429d5ed3"
SRCREV_MACHINE_INTEL_COMMON = "403eda4633e9037fb715d0d1e8ae847b2bd0651a"
-KBRANCH_INTEL_COMMON = "standard/intel"
+KBRANCH_INTEL_COMMON = "standard/intel/base"
KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 6/6] linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base
The dedicated standard tiny branch for Intel platforms has been
renamed to standard/tiny/intel/base - update the 4.1 tiny kernel
recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index 2d3d574..3b3d39c 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -5,6 +5,6 @@ SRCREV_meta_i586-nlp-32-intel-common =
"4b4199bd24f206d459061bb0a920d009429d5ed3
SRCREV_machine_i586-nlp-32-intel-common =
"403eda4633e9037fb715d0d1e8ae847b2bd0651a"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel"
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 3/6] linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base
The dedicated standard rt branch for Intel platforms has been renamed
to standard/preempt-rt/intel/base - update the 4.4 rt kernel recipe
accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index 2685ad5..d0344f6 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -4,7 +4,7 @@ LINUX_VERSION_INTEL_COMMON = "4.4.11"
SRCREV_META_INTEL_COMMON ?= "3a5f494784591e01f0ae7ab748e8190582c16e8c"
SRCREV_MACHINE_INTEL_COMMON ?= "3bdc347cc2087a0217e3acddccda5bb775cd570b"
-KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel"
+KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 5/6] linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base
The dedicated standard tiny branch for Intel platforms has been
renamed to standard/tiny/intel/base - update the 4.4 tiny kernel
recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
index 177281f..4b64ffa 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend
@@ -5,6 +5,6 @@ SRCREV_meta_i586-nlp-32-intel-common =
"3a5f494784591e01f0ae7ab748e8190582c16e8c
SRCREV_machine_i586-nlp-32-intel-common =
"53e84104c5e68eb468823dd0d262a64623d01a55"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel"
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel/base"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 1/6] linux-yocto/4.4: Switch to standard/intel/base
The dedicated standard branch for Intel platforms has been renamed to
standard/intel/base - update the 4.4 kernel recipe accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
index 2f53439..cfe556b 100644
--- a/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto_4.4.bbappend
@@ -4,7 +4,7 @@ LINUX_VERSION_INTEL_COMMON = "4.4.11"
SRCREV_META_INTEL_COMMON = "3a5f494784591e01f0ae7ab748e8190582c16e8c"
SRCREV_MACHINE_INTEL_COMMON = "53e84104c5e68eb468823dd0d262a64623d01a55"
-KBRANCH_INTEL_COMMON = "standard/intel"
+KBRANCH_INTEL_COMMON = "standard/intel/base"
KERNEL_FEATURES_INTEL_COMMON += "features/amt/mei/mei.scc"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 4/6] linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base
The dedicated standard rt branch for Intel platforms has been renamed
to standard/preempt-rt/intel/base - update the 4.1 rt kernel recipe
accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
index f53b206..d9e67b9 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend
@@ -2,9 +2,9 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
LINUX_VERSION_INTEL_COMMON = "4.1.24"
SRCREV_META_INTEL_COMMON ?= "4b4199bd24f206d459061bb0a920d009429d5ed3"
-SRCREV_MACHINE_INTEL_COMMON ?= "07e7cdbe501e762f73e778fb5507c9a6c7ac5669"
+SRCREV_MACHINE_INTEL_COMMON ?= "e22280e8c2905d96c7cc5917df202b6ed904d042"
-KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel"
+KBRANCH_INTEL_COMMON = "standard/preempt-rt/intel/base"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 0/6] Use */intel/base branches
The previous standard/intel patchset moved the kernels to /*standard/intel, but this prevents things like 'rebase' branches from being branched off of those. */standard/intel/base allows for that and is more consistent with the standard linux-yocto branching scheme, so these move things again, this time to use the /base branches. https://lists.yoctoproject.org/pipermail/meta-intel/2016-May/003909.html The following changes since commit 9bce6bdccf8ed3d3ae1cc2ae6f1f43c864a4ac34: linux-yocto/4.1: Bump SRCREVs to Linux 4.1.24 (2016-05-27 17:35:23 -0500) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib tzanussi/standard-intel-base-updates http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/standard-intel-base-updates Tom Zanussi (6): linux-yocto/4.4: Switch to standard/intel/base linux-yocto/4.1: Switch to standard/intel/base linux-yocto-rt/4.4: Switch to standard/preempt-rt/intel/base linux-yocto-rt/4.1: Switch to standard/preempt-rt/intel/base linux-yocto-tiny/4.4: Switch to standard/tiny/intel/base linux-yocto-tiny/4.1: Switch to standard/tiny/intel/base common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 4 ++-- common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +- common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 2 +- common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 2 +- common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 2 +- common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 2 +- 6 files changed, 7 insertions(+), 7 deletions(-) -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 0/1][krogoth] Update KBRANCH for linux-yocto-rt_4.4
In order to enable branch creation based off of standard/preempt-rt in the 4.4 kernel, standard/preeempt-rt/base was created, which meant standard/preempt-rt had to be removed. This patch updates the 4.4 linux-yocto-rt recipe to point to the new branch (4.1 and previous versions already had standard/preempt-rt/base and therefore don't need updates - only 4.4 is affected). The following changes since commit 91ffb8144c11c391ea3f62ce2a59a49e0f1cb01c: linux-yocto/4.4: Update SRCREVs for Broxton enablement (2016-05-04 13:14:48 -0700) are available in the git repository at: git://git.yoctoproject.org/meta-intel-contrib tzanussi/preempt-rt-kbranch-update-krogoth http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-contrib/log/?h=tzanussi/preempt-rt-kbranch-update-krogoth Tom Zanussi (1): linux-yocto-rt/4.4: Update KBRANCH common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 1/1][krogoth] linux-yocto-rt/4.4: Update KBRANCH
standard/preempt-rt was replaced by standard/preempt-rt/base in
linux-yocto-4.4.git, so KBRANCH needs to be updated accordingly.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
index 92205a6..e6bd200 100644
--- a/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend
@@ -4,7 +4,7 @@ LINUX_VERSION_INTEL_COMMON = "4.4.3"
SRCREV_META_INTEL_COMMON ?= "9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
SRCREV_MACHINE_INTEL_COMMON ?= "fcabc089b516e760d00a066893f9772d1535785c"
-KBRANCH_INTEL_COMMON = "standard/preempt-rt"
+KBRANCH_INTEL_COMMON = "standard/preempt-rt/base"
LINUX_VERSION_core2-32-intel-common = "${LINUX_VERSION_INTEL_COMMON}"
COMPATIBLE_MACHINE_core2-32-intel-common = "${MACHINE}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
Re: [meta-intel] [PATCH 0/2] Yet another SRCREV update
On 05/27/2016 07:52 PM, California Sullivan wrote: > Hi Tom, > > Two SRCREV updates for master are available at: > > git://git.yoctoproject.org/meta-intel-contrib clsulliv/master-test > > Thanks, > Cal Sullivan > > California Sullivan (2): > linux-yocto/4.4: Update SRCREVs to bring in Broxton related backports > linux-yocto/4.1: Bump SRCREVs to Linux 4.1.24 > > common/recipes-kernel/linux/linux-yocto-rt_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-rt_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto-tiny_4.4.bbappend | 4 ++-- > common/recipes-kernel/linux/linux-yocto_4.1.bbappend | 6 +++--- > common/recipes-kernel/linux/linux-yocto_4.4.bbappend | 4 ++-- > 6 files changed, 15 insertions(+), 15 deletions(-) > Merged into meta-intel/master, thanks. Tom -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 0/4] Use */intel branches in genericX86 BSPs
In order to provide more timely support for Intel platforms, this patchset switches the genericX86 BSPs over to using a set of dedicated */intel branches created for linux-yocto 4.1 and 4.4 kernels. These branches and the corresponding kernel metadata branches provide a place to add Intel-specific features and updates which aren't yet upstream or may never go upstream but nevertheless are useful for various users. In order to have all Intel-related BSPs derive from a common source, the genericX86 BSPs (in addition to the meta-intel BSPs) are being switched over to these branches - there should be no loss in functionality by doing so. The following changes since commit 28433319ad8299aa23b1fcfdddbe100b29e86517: bitbake: toaster: tests browser Add test for creating a project (2016-05-11 11:32:58 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib tzanussi/intel-branches http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/intel-branches Tom Zanussi (4): meta-yocto-bsp: Switch linux-yocto 4.4 genericx86* BSPs to standard/intel meta-yocto-bsp: Switch linux-yocto 4.1 genericx86* BSPs to standard/intel linux-yocto/4.1: Make standard/intel branches available linux-yocto/4.4: Make standard/intel branches available meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend | 8 meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend | 8 meta/recipes-kernel/linux/linux-yocto_4.1.bb | 2 +- meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-) -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 7/8] linux-yocto-tiny/4.1: Switch to standard/tiny/intel
We now have a dedicated standard/tiny/intel branch for Intel
platforms, so have the the 4.1 tiny kernel recipe make use of it.
Signed-off-by: Tom Zanussi
---
common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
index d21a562..e4bb1fe 100644
--- a/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
+++ b/common/recipes-kernel/linux/linux-yocto-tiny_4.1.bbappend
@@ -5,6 +5,6 @@ SRCREV_meta-i586-nlp-32-intel-common =
"e8c492e96f39fbee71520dbee0227dd6a87b9a59
SRCREV_machine-i586-nlp-32-intel-common =
"d03753ddb28a1141e550a67c99ac95789a424fc5"
COMPATIBLE_MACHINE_i586-nlp-32-intel-common = "${MACHINE}"
-KBRANCH_i586-nlp-32-intel-common = "standard/tiny/common-pc"
+KBRANCH_i586-nlp-32-intel-common = "standard/tiny/intel"
KMACHINE_i586-nlp-32-intel-common = "intel-quark"
KERNEL_FEATURES_append_i586-nlp-32-intel-common =
"${KERNEL_FEATURES_INTEL_COMMON}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 4/4] linux-yocto/4.4: Make standard/intel branches available
meta-yocto-bsp BSPs inherit SRCREV_meta - update it to include some
new branches for the BSPs there.
Signed-off-by: Tom Zanussi
---
meta/recipes-kernel/linux/linux-yocto_4.4.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
index b74903e..502e491 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.4.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?=
"b18090556c1d1b449233cd555c27a04d38272d6d"
SRCREV_machine_qemux86-64 ?= "b18090556c1d1b449233cd555c27a04d38272d6d"
SRCREV_machine_qemumips64 ?= "3a1c6d7576908a2dd21746b1d4ab4f43b83cd824"
SRCREV_machine ?= "b18090556c1d1b449233cd555c27a04d38272d6d"
-SRCREV_meta ?= "9ab4787fe2aea2ae0fcc31a5e067eaba19ef64c8"
+SRCREV_meta ?= "8f2a3ab2cd6f941052655e175f6e283e2880e562"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.4.git;name=machine;branch=${KBRANCH};
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.4;destsuffix=${KMETA}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 3/4] linux-yocto/4.1: Make standard/intel branches available
meta-yocto-bsp BSPs inherit SRCREV_meta - update it to include some
new branches for the BSPs there.
Signed-off-by: Tom Zanussi
---
meta/recipes-kernel/linux/linux-yocto_4.1.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
index 5d6bd3d..801a2c0 100644
--- a/meta/recipes-kernel/linux/linux-yocto_4.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_4.1.bb
@@ -19,7 +19,7 @@ SRCREV_machine_qemux86 ?=
"d03753ddb28a1141e550a67c99ac95789a424fc5"
SRCREV_machine_qemux86-64 ?= "d03753ddb28a1141e550a67c99ac95789a424fc5"
SRCREV_machine_qemumips64 ?= "351bc6968f63ea6f27cbd7f1678ddc53a9168fd1"
SRCREV_machine ?= "d03753ddb28a1141e550a67c99ac95789a424fc5"
-SRCREV_meta ?= "2bdebd11f1a0bc00071ec1467289a7feb5418dde"
+SRCREV_meta ?= "0b74ce56549e915237c35965e13aa3c034236180"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto-4.1.git;name=machine;branch=${KBRANCH};
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-4.1;destsuffix=${KMETA}"
--
1.9.3
--
___
meta-intel mailing list
meta-intel@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 1/4] meta-yocto-bsp: Switch linux-yocto 4.4 genericx86* BSPs to standard/intel
There is now a dedicated standard/intel branch for Intel platforms, so have the genericx86* BSPs use it. Signed-off-by: Tom Zanussi --- meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend index e31b0c8..cb3d1aa 100644 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.4.bbappend @@ -1,5 +1,5 @@ -KBRANCH_genericx86 = "standard/base" -KBRANCH_genericx86-64 = "standard/base" +KBRANCH_genericx86 = "standard/intel" +KBRANCH_genericx86-64 = "standard/intel" KMACHINE_genericx86 ?= "common-pc" KMACHINE_genericx86-64 ?= "common-pc-64" @@ -7,8 +7,8 @@ KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_beaglebone = "standard/beaglebone" KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" -SRCREV_machine_genericx86?= "3d2455f9da30f923c6bd69014fad4cc4ea738be6" -SRCREV_machine_genericx86-64 ?= "3d2455f9da30f923c6bd69014fad4cc4ea738be6" +SRCREV_machine_genericx86?= "578ff2a88676d20439dbf3877768370d06a22d8f" +SRCREV_machine_genericx86-64 ?= "578ff2a88676d20439dbf3877768370d06a22d8f" SRCREV_machine_edgerouter ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2" SRCREV_machine_beaglebone ?= "ff4c4ef15b51f45b9106d71bf1f62fe7c02e63c2" SRCREV_machine_mpc8315e-rdb ?= "df00877ef9387b38b9601c82db57de2a1b23ce53" -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
[meta-intel] [PATCH 2/4] meta-yocto-bsp: Switch linux-yocto 4.1 genericx86* BSPs to standard/intel
There is now a dedicated standard/intel branch for Intel platforms, so have the genericx86* BSPs use it. Signed-off-by: Tom Zanussi --- meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend index b20a18b..6029693 100644 --- a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend +++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto_4.1.bbappend @@ -1,5 +1,5 @@ -KBRANCH_genericx86 = "standard/base" -KBRANCH_genericx86-64 = "standard/base" +KBRANCH_genericx86 = "standard/intel" +KBRANCH_genericx86-64 = "standard/intel" KBRANCH_edgerouter = "standard/edgerouter" KBRANCH_beaglebone = "standard/beaglebone" KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" @@ -7,8 +7,8 @@ KBRANCH_mpc8315e-rdb = "standard/fsl-mpc8315e-rdb" KMACHINE_genericx86 ?= "common-pc" KMACHINE_genericx86-64 ?= "common-pc-64" -SRCREV_machine_genericx86?= "304caa9480f19875e717faf3cad8cb7ecd758733" -SRCREV_machine_genericx86-64 ?= "304caa9480f19875e717faf3cad8cb7ecd758733" +SRCREV_machine_genericx86?= "d03753ddb28a1141e550a67c99ac95789a424fc5" +SRCREV_machine_genericx86-64 ?= "d03753ddb28a1141e550a67c99ac95789a424fc5" SRCREV_machine_edgerouter ?= "79a31b9d23db126f8a6be3eb88fd683056a213f1" SRCREV_machine_beaglebone ?= "efb6ffb2ca96a364f916c9890ad023fc595e0e6e" SRCREV_machine_mpc8315e-rdb ?= "79a31b9d23db126f8a6be3eb88fd683056a213f1" -- 1.9.3 -- ___ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel
