[meta-intel] New valleyisland support

[Darren Hart]

On 3/13/14, 6:53, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:

>On 14-03-13 09:43 AM, Tom Zanussi wrote:
>> On Thu, 2014-03-13 at 06:40 +0000, Keskinarkaus, Teemu wrote:
>>> Hi,
>>>
>>> Okay, here is a little background and some new issues I've encountered.
>>>
>>> We have been using Yocto 1.5.1 earlier to create image for our HWs.
>>>Now the new HW uses E38xx so I started testing the new Yocto/meta-intel
>>>- branches to get (better) support for it.
>>>
>>> Since the current ValleyIsland support for meta-intel was for Dylan -
>>>branch of Yocto and also because I wasn't able to create image with
>>>working Intel HD Graphics driver I started looking for newer versions.
>>>Graphics worked with VESA-driver, but not with actual Intel HD Graphics
>>>driver.  Also the kernel was quite old being 3.8.13.
>>>
>>> I did some digging and noticed that dvhart/bsp-ng had support for the
>>>intel-corei7 so that's why I ended up there. I never intended to use it
>>>other than testing if I can create working image that has working Intel
>>>HD Graphics for Valleyisland.  Then I tried latest poky/meta-intel
>>>combination since dvhart/bsp-ng was merged there.
>>>
>>> When trying to create core-image-sato using the intel-corei7-64 bsp I
>>>ended up with this:
>>>
>>> ERROR: Fetcher failure: Unable to find revision
>>>29594404d7fe73cd80eaa4ee8c43dcc53970c60e in branch meta even from
>>>upstream
>>> ERROR: Function failed: Fetcher failure for URL:
>>>'git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch=standar
>>>d/base,meta;name=machine,meta'. Unable to fetch URL from any source.
>>> ERROR: Logfile of failure stored in:
>>>/opt/build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto-dev/3.
>>>14++gitAUTOINC+29594404d7_29594404d7-r0/temp/log.do_fetch.25380
>>> ERROR: Task 73 
>>>(/opt/poky/../poky/meta/recipes-kernel/linux/linux-yocto-dev.bb,
>>>do_fetch) failed with exit code '1'
>>>
>>> I'm not sure if that is a Yocto - bug, Meta-intel bug or my bug.
>>>
>>
>> I ran into this too and got around it by the hack below.  Not sure why
>> it's not working, how it's actually supposed to work or if there's
>> something we need to be doing in meta-intel layers, adding Bruce..
>
>ok, this is report #2 of this. I'm firing up some tests here to see
>if I can reproduce it.
>
>You shouldn't need your mod to make it work .. so I'll dig out what
>is happening.
>
>Bruce
>
>>
>> diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb
>>b/meta/recipes-kernel/linux/linux-
>> index 5e09720..917714d 100644
>> --- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
>> +++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
>> @@ -28,8 +28,8 @@ SRC_URI =
>>"git://git.pokylinux.org/linux-yocto-dev.git;nocheckout=1;branch
>>   # linux-yocto-dev is the preferred provider, they will be overridden
>>to
>>   # AUTOREV in following anonymous python routine and resolved when the
>>   # variables are finalized.
>> -SRCREV_machine ?= "29594404d7fe73cd80eaa4ee8c43dcc53970c60e"
>> -SRCREV_meta ?= "29594404d7fe73cd80eaa4ee8c43dcc53970c60e"


Well that is obviously wrong, machine and meta can't possibly be the same
commit ID. Bad dvhart... Oh wait... This is oe-core/poky. Bad Zedd.

These should be:

$ git rev-parse origin/standard/base
c4ee7a071d120118c4a5472222f7fb93b9c6f3b5

$ git rev-parse origin/meta
cdf9fb795b8e848cd3ddf3c5e0d98905fac27685


Bruce, is this already queued or do you want me to prep a patch? Or... Are
these the bogus ones that are meant to trigger failure .... Is the AUTOREV
mechanism for linux-yocto-dev just not working?

>> +SRCREV_machine ?= "${AUTOREV}"
>> +SRCREV_meta ?= "${AUTOREV}"

FYI, you can do this in local.conf and avoid modifying the recipe sources
(I prefer this method):

SRCREV_meta_pn-linux-yocto-dev="${AUTOREV}"
SRCREV_machine_pn-linux-yocto-dev="${AUTOREV}"



>>
>>   python () {
>>       if d.getVar("PREFERRED_PROVIDER_virtual/kernel", True) !=
>>"linux-yocto-dev":
>>
>>
>>> Good to hear that linut-rt - support was not dropped, but merely just
>>>changed.
>>>
>>> Btw. Is it intentional that in intel-corei7-64.conf the
>>>PREFERRED_PROVIDER_virtual/kernel is set using = and not ?= which makes
>>>it impossible to override it from later scripts? Or am I doing
>>>something wrong again? I had to comment out that line to be able to use
>>>my own kernel version on later tests.


This is also my mistake. It should also be ?=. It was at = during
development and I forgot to update it to ?= before pushing to meta-intel.
Thank you for catching that.


-- 
Darren Hart
Yocto Project - Linux Kernel
Intel Open Source Technology Center