On 3/13/14, 6:53, "Bruce Ashfield" <bruce.ashfi...@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 -- _______________________________________________ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel