[meta-intel] New valleyisland support

[Darren Hart]

On 3/17/14, 15:39, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:

>On 2014-03-17, 6:31 PM, Darren Hart wrote:
>> 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=stand
>>>>>ar
>>>>> 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.
>
>:) guilty!
>
>>
>> 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?
>
>It is supposed to be the latter, and Tom has been seeing issues, but I
>can't reproduce the failure here. The AUTOREV overwrite is triggered in
>anonymous python, all that I can think is that it isn't running early
>enough.

Could we then use clearly bogus values?

WILL_BE_REPLACED_WITH_AUTOREV

Or, if we will trip over the broken commit checking in kernel.bbclass,
maybe just:

EBAD00000000000000000000

Until we fix it to use the cat-file mechanism....

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