Re: [yocto] [PATCH 1/4] emgd-driver-bin: upgrade from 1.10 to 1.14

[Kamble, Nitin A]

> -Original Message-
> From: Zanussi, Tom
> Sent: Tuesday, July 31, 2012 1:13 AM
> To: Kamble, Nitin A
> Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com
> Subject: Re: [PATCH 1/4] emgd-driver-bin: upgrade from 1.10 to 1.14
> 
> On Sun, 2012-07-29 at 07:00 -0700, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > 1.14 is the latest released driver for emgd. This change is tested on
> > crownbay machine.
> >
> > Add runtime dependency to libxcb-dri2
> >
> 
> Hi Nitin,
> 
> When building, I'm seeing this:
> 
> NOTE: Resolving any missing task queue dependencies
> NOTE: multiple providers are available for runtime libxcb-dri2 (libxcb-
> nativesdk, libxcb)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match libxcb-dri2
> 
> Tom

This is issue with the libxcb recipe. I have sent a fix for that to oecore 
mailing list.

Nitin

> 
> > Otherwise the libxcb-dri2.so is not getting installed, and video
> > acceleration of emgd does not work. It is dynamic dependency of
> > emgd_drv_video.so
> >
> > put files in gstreamer-0.10/.debug directory to the debug package.
> > It avoids debug files packaging warnings.
> >
> > add downloadfilename param to SRC_URI
> >
> > As the url does not have the filename of the tarball, specify it here
> > so that updated wget bitbake fetcher can save the downloaded file
> > accordingly.
> > BTW now EDC has also published another download URL on our request:
> >
> http://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_14_GOLD_244
> 3.tgz
> >
> > And update emgd driver version in the README.
> >
> > Signed-off-by: Nitin A Kamble 
> > ---
> >  ...-driver-bin_1.10.bb => emgd-driver-bin_1.14.bb} |   17 +---
> -
> >  meta-crownbay/README   |8 
> >  2 files changed, 13 insertions(+), 12 deletions(-)  rename
> > common/recipes-graphics/xorg-xserver/{emgd-driver-bin_1.10.bb =>
> > emgd-driver-bin_1.14.bb} (88%)
> >
> > diff --git
> > a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
> > b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
> > similarity index 88%
> > rename from
> > common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
> > rename to common/recipes-graphics/xorg-xserver/emgd-driver-
> bin_1.14.bb
> > index 5779e5d..b1ba1b8 100644
> > --- a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
> > +++ b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
> > @@ -1,9 +1,9 @@
> > -SUMMARY = "EMGD 1.10 xserver binaries"
> > -DESCRIPTION = "EMGD 1.10 includes some userspace binaries that use
> > non-free \
> > +SUMMARY = "EMGD 1.14 xserver binaries"
> > +DESCRIPTION = "EMGD 1.14 includes some userspace binaries that use
> > +non-free \
> >  licensing, which are now available via a non-click-through
> > downloadable \  tarball, and is what this recipe now uses.  Since it
> > is a non-free license, \ -this recipe is marked as
> > 'License_emgd-driver-bin_1.10' and you need to add \ -to
> > LICENSE_FLAGS_WHITELIST += \"License_emgd-driver-bin_1.10\" to your \
> > +this recipe is marked as 'License_emgd-driver-bin_1.14' and you need
> > +to add \ to LICENSE_FLAGS_WHITELIST +=
> > +\"License_emgd-driver-bin_1.14\" to your \
> >  local.conf in order to enable it in a build."
> >  LICENSE = "Intel-binary-only"
> >  LICENSE_FLAGS = "license_${PN}_${PV}"
> > @@ -16,17 +16,18 @@ EMGD_VIDEO_PLUGIN_DIR =
> "../common/video_plugin"
> >  LIC_FILES_CHKSUM =
> "file://${WORKDIR}/${EMGD_LIC_DIR}/License.txt;md5=b54f01caaf8483b3cb
> 60c0c40f2bf22d"
> >
> >  DEPENDS = "rpm-native xz-native"
> > +RDEPENDS = "libxcb-dri2"
> >
> > -SRC_URI =
> "https://edc.intel.com/App_Shared/Downloads/LIN_EMGD_1_10_RC_2209.
> tgz"
> > +SRC_URI =
> "https://edc.intel.com/Download.aspx?id=6190;downloadfilename=LIN_IEM
> GD_1_14_GOLD_2443.tgz"
> >
> > -SRC_URI[md5sum] = "e4a38d9efa0b086ae21b68145c4db4e9"
> > -SRC_URI[sha256sum] =
> "acea5f0f93a31553553428623c007d7ed0c604cf715fd87dfe075751da4be548"
> > +SRC_URI[md5sum] = "733a7f237ffce21238ce2c9956df4fd6"
> > +SRC_URI[sha256sum] =
> "bcdc333b5edbda7c746a83ef821ded4a0ca55ead30980e4e3680cdb6469f45a2"
> >
> >  # These are closed binaries generated elsewhere so don't check
> > ldflags  INSANE_SKIP_${PN} = "ldflags"
> >
> >  FILES_${PN} += "${libdir}/dri ${libdir}/gstreamer-0.10
> ${libdir}/xorg/modules/drivers"
> > -FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug
> ${libdir}/dri/.debug"
> > +FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug
> ${libdir}/dri/.debug ${libdir}/gstreamer-0.10/.debug"
> >
> >  S = "${WORKDIR}/${EMGD_RPM_DIR}"
> >
> > diff --git a/meta-crownbay/README b/meta-crownbay/README index
> > b56c79a..2521432 100644
> > --- a/meta-crownbay/README
> > +++ b/meta-crownbay/README
> > @@ -6,7 +6,7 @@ The Crown Bay platform consists of the Intel Atom Z6xx
> > processor,  plus the Intel EG20T Platform Controller Hub (Tunnel Creek +
> Topcliff).
> >
> >  It also supports the E6xx embedded on-chip graphics via the 

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Paul Eggleton]

On Monday 30 July 2012 23:52:18 Elvis Dowson wrote:
> On Jul 30, 2012, at 9:18 PM, Paul Eggleton wrote:
> > FYI, we do do this already for most significant changes, and it was done
> > for this one. The trouble with this specific issue is, if you happened to
> > build a normal image prior to building meta-toolchain or indeed any other
> > user of do_populate_sdk, the error will not occur because
> > rpmresolve-native would already have been built; hence why this was
> > missed.
> 
> Ah, I see. I normally alway build meta-toolchain, so that I get the cross
> compiler built first, before trying to build core-image-minimal.

I'm guessing you already know this, but you can just build core-image-minimal 
without building meta-toolchain and the cross compiler will be built 
automatically (and since meta-toolchain builds a bunch of other things it will 
take less time overall). Of course, you may actually need the output of meta-
toolchain, in which case you're getting something for the extra build time; 
but in that case it still does not matter which order you build them in.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] INSANE_SKIP

[Bodke, Kishore K]

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Dallas Clement
>Sent: Friday, July 20, 2012 3:07 PM
>To: yocto@yoctoproject.org
>Subject: [yocto] INSANE_SKIP
>
>Is there a way to skip a QA check for more than one package or all packages?
>
>I'd like to avoid having to add a INSANE_SKIP_${PN} += "ldflags" for
>every package that fails due to ERROR: QA Issue: No GNU_HASH in the
>elf binary.
>
>There are gobs of python and perl packages failing with this error
>when I try to build a distro.

Try exporting the below line before compiling with this works I guess.
export LD="${LD} --hash-style=gnu" 

-Kishore.

>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] denzil kernel build issues

[Frans Meulenbroeks]

2012/7/30 Bruce Ashfield 

> On 12-07-30 10:20 AM, Frans Meulenbroeks wrote:
>
>> Hi Bruce,
>>
>> Thanks for your support.
>> See below
>>
>> 2012/7/30 Bruce Ashfield > >
>>
>>
>> On Mon, Jul 30, 2012 at 7:33 AM, Frans Meulenbroeks
>> > > >>
>>
>> wrote:
>>  > Dear all,
>>  >
>>  > I finally managed to find time to pick up porting my project to
>> denzil and
>>  > did encounter two issues that I wanted to report back:
>>  >
>>  > First is that I could not find what the preferred way was to
>> disable a
>>  > kernel option in my bsp.
>>  > (the option concerned is CONFIG_PM).
>>  > Of course I can sed it out in do_configure but I'd hoped it could
>> be simpler
>>  > (I have tried:
>>  > CONFIG_PM=n
>>  > in my config snippet)
>>
>> Putting:
>>
>> # CONFIG_PM is not set
>>
>> in your configuration fragment will turn off an option, the BSP
>> guide has a
>> "# CONFIG_SMP is not set" as an example for this.
>>
>>
>> i thought it would and I have had this in my config too, but still it
>> get switched on. Guess there is something else in my config that sets
>> this.
>> Will dive into this.
>>
>>
>>  >
>>  > Secondly a patch of mine does not seem to apply properly the
>> first time, but
>>  > it does apply a second time.
>>  > This suggests a race between do_kernel_checkout and do_patch
>>
>> There shouldn't be any race .. if this doesn't work:
>>
>> addtask kernel_checkout before do_patch after do_unpack
>>
>> Then there are some serious problems with bitbake's task scheduling.
>>
>> If you didn't do a clean between the two runs, the second is
>> attempting to continue
>> the patching and you still aren't getting what you want.
>>
>>
>> I did not do a clean inbetween. I figured patch would reattempt to patch
>> and, since the file is there it would continue.
>>
>> The addtask line is there in one of the bitbake files.
>>
>> The odd thing is that the exact same thing builds fine under 3.0.
>> Actually I was trying to move from 3.0 to 3.2 while stumbling on this.
>>
>>
>>
>> Without seeing what you've ported, or a work in progress I can't say
>> exactly
>> what is wrong, but your meta data is somehow wrong or completely
>> missing.
>> Have you set any meta or BSP SRCREVs explicitly ?
>>
>>
>> I have put my work-in-progress in:
>>
>> https://www.dropbox.com/s/**h58h6pq5b0f4u2s/patchproblem.**tar.gzvi
>>
>> you might want to edit conf/layer.conf as it has hardcoded paths.
>> If I go to meta-syrcxx/conf/machine/**syrcxx.conf and set the preferred
>> kernel version to 3.0 things build fine.
>> Then I did set to 3.2 and it fails.
>> Note that apart from a PR bump the files
>> meta-syrcxx/recipes-kernel/**linux/linux-yocto_3.2.bbappend
>> meta-syrcxx/recipes-kernel/**linux/linux-yocto_3.0.bbappend
>> are identical (and I am just using files; so the same patches apply.
>>
>
> You've got a couple of minor problems in the files. dmaengine is
> incorrectly referenced for 3.2. I've attached a fix for that. The
> other items are just warnings..
>
> I have fixes to make that bad configuration reference a hard error,
> with a message during do_patch that high lights the problem .. for
> master. But in denzil, what you got is what I'd expect.
>
> Your max7311.patch also needs to be refreshed for 3.2, since it won't
> apply as is.
>
> After the failure, I refreshed it as follows:
>
>
>  > bitbake -c devshell linux-yocto
>
> # in dev-shell:
>
>  # already fixed in master, but denzil requires this:
>  > export GUILT_BASE=meta
>  > guilt next
> links/files/max7311.patch
>  > guilt push -f
>  # resolve conflict in drivers/gpio/Makefile
>  > git add drivers/gpio/Makefile drivers/gpio/max7311.c
> include/linux/max7311_gpio.h
>  > git clean -f
> Removing drivers/gpio/Makefile.rej
>  > git tag standard/default/syrcxx_top
>  > guilt refresh
> Patch links/files/max7311.patch refreshed
>
>  > cp meta/patches/standard/default/**syrcxx/links/files/max7311.**patch
> $your_layer_location/meta-**syrcxx/recipes-kernel/linux/**files
>
>  > guilt push -a
> Applying patch..links/files/axonbus-**remote.patch
> Patch applied.
> Applying patch..links/files/axonbus-**local.patch
> Patch applied.
> Applying patch..links/files/axon-**display.patch
> Patch applied.
> Applying patch..links/files/axon-**keyboard.patch
> Patch applied.
> Applying patch..links/files/axon-hwmon.**patch
> Patch applied.
>
>  # the series is now clean.
>
> I then cleaned linux-yocto and restarted, it configures and builds
> after that (and eventually gets a build error, but that looks like an
> issue with the code on the 3.2 kernel .. and is for someone else to
> fix :)
>
> As for the CONFIG_PM, it's a Kconfig "feature" that is causing you
> pain. You can't directly "access" (enable/disable

[yocto] creating SD card for booting Yocto image on Pandaboard

[Jim Abernathy]

I have not seem a procedure documented for creating an SD card with the 
Yocto image that works in a Pandaboard Rev A2.


I have created a core-image-minimal and core-image-sato successfully. I 
followed the basic procedures on pandaboard wiki to format the SD card.  
After formating the card, I can insert it into an Ubuntu 12.04 system 
and the /media/boot and /media/rootfs devices are mounted 
automatically.  Using the files in tmp/deploy/images, I copy the files 
as below:


cp MLO-pandaboard-2012.12  /media/boot/MLO
cp u-boot-pandaboard-2011.12-r8.img  /media/boot/u-boot.img
cp uImage-3.1.0-r0-pandaboard-201207300170622.bin /media/boot/uImage

tar -xjf core-image-minimal-pandaboard.tar.bz2 -C /media/rootfs/

Am I missing a step? It starts booting the kernel, but that's is, no 
more output on the console.


Jim A

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] denzil kernel build issues

[Bruce Ashfield]

On 12-07-30 10:20 AM, Frans Meulenbroeks wrote:

Hi Bruce,

Thanks for your support.
See below

2012/7/30 Bruce Ashfield mailto:bruce.ashfi...@gmail.com>>

On Mon, Jul 30, 2012 at 7:33 AM, Frans Meulenbroeks
mailto:fransmeulenbro...@gmail.com>>
wrote:
 > Dear all,
 >
 > I finally managed to find time to pick up porting my project to
denzil and
 > did encounter two issues that I wanted to report back:
 >
 > First is that I could not find what the preferred way was to
disable a
 > kernel option in my bsp.
 > (the option concerned is CONFIG_PM).
 > Of course I can sed it out in do_configure but I'd hoped it could
be simpler
 > (I have tried:
 > CONFIG_PM=n
 > in my config snippet)

Putting:

# CONFIG_PM is not set

in your configuration fragment will turn off an option, the BSP
guide has a
"# CONFIG_SMP is not set" as an example for this.


i thought it would and I have had this in my config too, but still it
get switched on. Guess there is something else in my config that sets this.
Will dive into this.


 >
 > Secondly a patch of mine does not seem to apply properly the
first time, but
 > it does apply a second time.
 > This suggests a race between do_kernel_checkout and do_patch

There shouldn't be any race .. if this doesn't work:

addtask kernel_checkout before do_patch after do_unpack

Then there are some serious problems with bitbake's task scheduling.

If you didn't do a clean between the two runs, the second is
attempting to continue
the patching and you still aren't getting what you want.


I did not do a clean inbetween. I figured patch would reattempt to patch
and, since the file is there it would continue.

The addtask line is there in one of the bitbake files.

The odd thing is that the exact same thing builds fine under 3.0.
Actually I was trying to move from 3.0 to 3.2 while stumbling on this.



Without seeing what you've ported, or a work in progress I can't say
exactly
what is wrong, but your meta data is somehow wrong or completely
missing.
Have you set any meta or BSP SRCREVs explicitly ?


I have put my work-in-progress in:

https://www.dropbox.com/s/h58h6pq5b0f4u2s/patchproblem.tar.gz vi

you might want to edit conf/layer.conf as it has hardcoded paths.
If I go to meta-syrcxx/conf/machine/syrcxx.conf and set the preferred
kernel version to 3.0 things build fine.
Then I did set to 3.2 and it fails.
Note that apart from a PR bump the files
meta-syrcxx/recipes-kernel/linux/linux-yocto_3.2.bbappend
meta-syrcxx/recipes-kernel/linux/linux-yocto_3.0.bbappend
are identical (and I am just using files; so the same patches apply.


You've got a couple of minor problems in the files. dmaengine is
incorrectly referenced for 3.2. I've attached a fix for that. The
other items are just warnings..

I have fixes to make that bad configuration reference a hard error,
with a message during do_patch that high lights the problem .. for
master. But in denzil, what you got is what I'd expect.

Your max7311.patch also needs to be refreshed for 3.2, since it won't
apply as is.

After the failure, I refreshed it as follows:


 > bitbake -c devshell linux-yocto

# in dev-shell:

 # already fixed in master, but denzil requires this:
 > export GUILT_BASE=meta
 > guilt next
links/files/max7311.patch
 > guilt push -f
 # resolve conflict in drivers/gpio/Makefile
 > git add drivers/gpio/Makefile drivers/gpio/max7311.c 
include/linux/max7311_gpio.h

 > git clean -f
Removing drivers/gpio/Makefile.rej
 > git tag standard/default/syrcxx_top
 > guilt refresh
Patch links/files/max7311.patch refreshed

 > cp meta/patches/standard/default/syrcxx/links/files/max7311.patch 
$your_layer_location/meta-syrcxx/recipes-kernel/linux/files


 > guilt push -a
Applying patch..links/files/axonbus-remote.patch
Patch applied.
Applying patch..links/files/axonbus-local.patch
Patch applied.
Applying patch..links/files/axon-display.patch
Patch applied.
Applying patch..links/files/axon-keyboard.patch
Patch applied.
Applying patch..links/files/axon-hwmon.patch
Patch applied.

 # the series is now clean.

I then cleaned linux-yocto and restarted, it configures and builds
after that (and eventually gets a build error, but that looks like an
issue with the code on the 3.2 kernel .. and is for someone else to
fix :)

As for the CONFIG_PM, it's a Kconfig "feature" that is causing you
pain. You can't directly "access" (enable/disable) and option that
doesn't have help text, since the help text makes it "user visible"
and hence a configuration knob. (Don't blame me, I don't condone this,
but it is what it is). In this case you need to blast one of the 
dependencies

to disable it. I turned off CONFIG_SUSPEND to get CONFIG_PM out of
my final.config.

I inlined my three changes here, the last one is the patch refresh
for drivers/Kconfig, so it's not all that useful :)

Cheers,

Bruce

[yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, July 31, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada)

[Liu, Song]

Agenda:

* Opens collection - 5 min (Song)
* Yocto 1.3 status  - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status
* SWAT team rotation: Nitin -> Beth
* Opens - 10 min
* Team sharing - 20 min


-Original Appointment-


We encourage people attending the meeting to logon the Yocto IRC chancel during 
the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto
IRC Tutorial: http://www.irchelp.org/irchelp/irctutorial.html 

Conference details
Conference name: 
Yocto Technical Team
Conference date/start time: 
Tue Jun 26, 2012 at 10:00 AM Central Daylight Time
Participants: 
30
Duration: 
60 minutes
Participant passcode: 
76994298
Dial-in number: 
1.972.995.
US Toll Free number: 
1.877.561.6828
BlackBerry users, click this link to join your conference as a participant:
1.972.995.x76994298#
 
Depending on where you are dialing from, either your BlackBerry will pause and 
enter the passcode automatically or you will be prompted to click again to dial 
the passcode.

Local and Global Access Numbers 


Country
Dial-in number
Australia: 
1800 636 843
Czech Republic: 
242 430 350
China (Beijing): 
>From office dial 8-995 or 8784277
Beijing Out of Office dial 5878 4277
China (Shanghai): 
>From office dial 8-995 or 3073322
Shanghai Out of Office dial 2307 3322
China (Shenzen): 
>From office dial 8-995 or 6007877
Shenzen Out of Office dial 2600 7877
China (Other Cities): 
>From IP phone dial 8-995
Other cities - Non IP phone dial 021-23073322
Denmark: 
8060 1400
Finland: 
09 41333477
France: 
0497 275888
Germany: 
08161 803232
Holland: 
030 2417490
India: 
BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 
861 212 (Toll Free) From TI Campus use 8995 Others use 2509 9555 (Landline 
within Bangalore) or
80 2509 9555 (Outside Bangalore)
Israel: 
09 790 6715
Italy: 
039 69061234 (039 is local city code not country code)
Japan: 
>From TI Campus use 8 995 
Outside TI use 03 4331 3777
Malaysia: 
>From IP phone dial 2643799
>From Kuala Lumpur dial 4264 3799
Outside Kuala Lumpur dial (03)4264 3799
Norway: 
2 295 8744
Philippines: 
>From Baguio City use 4471177
>From Metro Manila area use 8702477
Singapore: 
>From IP phone dial 3894777
Outside TI use 6389 4777
South Korea: 
>From IP phone dial 5606998
>From Seoul dial 5606998
Outside Seoul dial (02)5606998
Sweden: 
08 58755577
Taiwan: 
>From IP phone dial 1363
>From Taipei dial 2241 1363
Outside Taipei dial (02)2241 1363
Turkey: 
Landline Only dial 0811 288 0001
then enter 877 633 1123
UK: 
01604 663003
US: 
972 995  or 1877 561 6828

Recurring conferences
First scheduled conference: 
Tue Jun 26, 2012
Recurrence frequency: 
Weekly - Every 1 week(s) on Tuesday
Recurrence ends: 
End on Fri Jun 21, 2013, 10:40 AM CDT



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] denzil kernel build issues

[Frans Meulenbroeks]

2012/7/30 Bruce Ashfield 

> On 12-07-30 10:20 AM, Frans Meulenbroeks wrote:
>
>> Hi Bruce,
>>
>> Thanks for your support.
>> See below
>>
>> 2012/7/30 Bruce Ashfield > >
>>
>>
>> On Mon, Jul 30, 2012 at 7:33 AM, Frans Meulenbroeks
>> > > >>
>>
>> wrote:
>>  > Dear all,
>>  >
>>  > I finally managed to find time to pick up porting my project to
>> denzil and
>>  > did encounter two issues that I wanted to report back:
>>  >
>>  > First is that I could not find what the preferred way was to
>> disable a
>>  > kernel option in my bsp.
>>  > (the option concerned is CONFIG_PM).
>>  > Of course I can sed it out in do_configure but I'd hoped it could
>> be simpler
>>  > (I have tried:
>>  > CONFIG_PM=n
>>  > in my config snippet)
>>
>> Putting:
>>
>> # CONFIG_PM is not set
>>
>> in your configuration fragment will turn off an option, the BSP
>> guide has a
>> "# CONFIG_SMP is not set" as an example for this.
>>
>>
>> i thought it would and I have had this in my config too, but still it
>> get switched on. Guess there is something else in my config that sets
>> this.
>> Will dive into this.
>>
>>
>>  >
>>  > Secondly a patch of mine does not seem to apply properly the
>> first time, but
>>  > it does apply a second time.
>>  > This suggests a race between do_kernel_checkout and do_patch
>>
>> There shouldn't be any race .. if this doesn't work:
>>
>> addtask kernel_checkout before do_patch after do_unpack
>>
>> Then there are some serious problems with bitbake's task scheduling.
>>
>> If you didn't do a clean between the two runs, the second is
>> attempting to continue
>> the patching and you still aren't getting what you want.
>>
>>
>> I did not do a clean inbetween. I figured patch would reattempt to patch
>> and, since the file is there it would continue.
>>
>> The addtask line is there in one of the bitbake files.
>>
>> The odd thing is that the exact same thing builds fine under 3.0.
>> Actually I was trying to move from 3.0 to 3.2 while stumbling on this.
>>
>>
>>
>> Without seeing what you've ported, or a work in progress I can't say
>> exactly
>> what is wrong, but your meta data is somehow wrong or completely
>> missing.
>> Have you set any meta or BSP SRCREVs explicitly ?
>>
>>
>> I have put my work-in-progress in:
>>
>> https://www.dropbox.com/s/**h58h6pq5b0f4u2s/patchproblem.**tar.gzvi
>>
>> you might want to edit conf/layer.conf as it has hardcoded paths.
>> If I go to meta-syrcxx/conf/machine/**syrcxx.conf and set the preferred
>> kernel version to 3.0 things build fine.
>> Then I did set to 3.2 and it fails.
>>
>
> I'll give this a try, sounds like a typical patch/meta issue, so I should
> see it quickly.


Thanks a lot. The file that it wants to patch is there. I can imagine a
patch fault as I am just bringing this over from 3.0 but would have
expected a different message.

>
>
>  Note that apart from a PR bump the files
>> meta-syrcxx/recipes-kernel/**linux/linux-yocto_3.2.bbappend
>> meta-syrcxx/recipes-kernel/**linux/linux-yocto_3.0.bbappend
>> are identical (and I am just using files; so the same patches apply.
>>
>> BTW our board is a powerpc 8313e based board (modeled after mpc8313e-rds)
>>
>> One other thing I noticed; do_install seems to take quite some time; not
>> sure why this is (haven't investigated).
>>
>
> hmm. normally that means some sort of rpm issue (or maybe you are
> using ipk), but it can take a significant time.
>

I'm using rpm afaik (didn't change it)
if ipk is faster I can move over (we do not want to use updates, we always
only ship complete images as we then can test what the customer gets)
my host is ubuntu 10.04 if that matters (yeah, I know, it is old, company
preferred etc)

Best regards, Frans

>
> Cheers,
>
> Bruce
>
>
>> Best regards, Frans
>>
>>
>> Cheers,
>>
>> Bruce
>>
>>  >
>>  > Below is a log that illustrates this and demonstrates that things
>> are ok the
>>  > 2nd time.
>>  > (btw I am also a little bit concerned on the command not found
>> messages).
>>  > And of course any sugguestion for a fix is greatly appreciated.
>>  >
>>  > Best regards, Frans
>>  >
>>  > frans@frans-desktop:~/poky-**denzil-7.0-build$ bitbake
>> virtual/kernel
>>  > Parsing recipes: 100%
>>  >
>> |#**##**
>> ##**#|
>>  > Time: 00:00:30
>>  > Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105
>> targets, 35
>>  > skipped, 0 masked, 0 errors.
>>  >
>>  > OE Build Configuration:
>>  > BB_VERSION = "1.15.1"
>>  > TARGET_ARCH = "powerpc"
>>  > TARGET_OS = "linux-uclibc"
>>   

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Elvis Dowson]

Hi Paul,

On Jul 30, 2012, at 9:18 PM, Paul Eggleton wrote:

> FYI, we do do this already for most significant changes, and it was done for 
> this one. The trouble with this specific issue is, if you happened to build a 
> normal image prior to building meta-toolchain or indeed any other user of 
> do_populate_sdk, the error will not occur because rpmresolve-native would 
> already have been built; hence why this was missed.

Ah, I see. I normally alway build meta-toolchain, so that I get the cross 
compiler
built first, before trying to build core-image-minimal.

Best regards,

Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 1/4] emgd-driver-bin: upgrade from 1.10 to 1.14

[Tom Zanussi]

On Sun, 2012-07-29 at 07:00 -0700, nitin.a.kam...@intel.com wrote:
> From: Nitin A Kamble 
> 
> 1.14 is the latest released driver for emgd. This change is tested on
> crownbay machine.
> 
> Add runtime dependency to libxcb-dri2
> 

Hi Nitin,

When building, I'm seeing this:

NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for runtime libxcb-dri2
(libxcb-nativesdk, libxcb)
NOTE: consider defining a PREFERRED_PROVIDER entry to match libxcb-dri2

Tom

> Otherwise the libxcb-dri2.so is not getting installed, and video
> acceleration of emgd does not work. It is dynamic dependency of
> emgd_drv_video.so
> 
> put files in gstreamer-0.10/.debug directory to the debug package.
> It avoids debug files packaging warnings.
> 
> add downloadfilename param to SRC_URI
> 
> As the url does not have the filename of the tarball, specify it here
> so that updated wget bitbake fetcher can save the downloaded file
> accordingly.
> BTW now EDC has also published another download URL on our request:
> http://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_14_GOLD_2443.tgz
> 
> And update emgd driver version in the README.
> 
> Signed-off-by: Nitin A Kamble 
> ---
>  ...-driver-bin_1.10.bb => emgd-driver-bin_1.14.bb} |   17 +
>  meta-crownbay/README   |8 
>  2 files changed, 13 insertions(+), 12 deletions(-)
>  rename common/recipes-graphics/xorg-xserver/{emgd-driver-bin_1.10.bb => 
> emgd-driver-bin_1.14.bb} (88%)
> 
> diff --git a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb 
> b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
> similarity index 88%
> rename from common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
> rename to common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
> index 5779e5d..b1ba1b8 100644
> --- a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
> +++ b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
> @@ -1,9 +1,9 @@
> -SUMMARY = "EMGD 1.10 xserver binaries"
> -DESCRIPTION = "EMGD 1.10 includes some userspace binaries that use non-free \
> +SUMMARY = "EMGD 1.14 xserver binaries"
> +DESCRIPTION = "EMGD 1.14 includes some userspace binaries that use non-free \
>  licensing, which are now available via a non-click-through downloadable \
>  tarball, and is what this recipe now uses.  Since it is a non-free license, \
> -this recipe is marked as 'License_emgd-driver-bin_1.10' and you need to add \
> -to LICENSE_FLAGS_WHITELIST += \"License_emgd-driver-bin_1.10\" to your \
> +this recipe is marked as 'License_emgd-driver-bin_1.14' and you need to add \
> +to LICENSE_FLAGS_WHITELIST += \"License_emgd-driver-bin_1.14\" to your \
>  local.conf in order to enable it in a build."
>  LICENSE = "Intel-binary-only"
>  LICENSE_FLAGS = "license_${PN}_${PV}"
> @@ -16,17 +16,18 @@ EMGD_VIDEO_PLUGIN_DIR = "../common/video_plugin"
>  LIC_FILES_CHKSUM = 
> "file://${WORKDIR}/${EMGD_LIC_DIR}/License.txt;md5=b54f01caaf8483b3cb60c0c40f2bf22d"
>  
>  DEPENDS = "rpm-native xz-native"
> +RDEPENDS = "libxcb-dri2"
>  
> -SRC_URI = 
> "https://edc.intel.com/App_Shared/Downloads/LIN_EMGD_1_10_RC_2209.tgz";
> +SRC_URI = 
> "https://edc.intel.com/Download.aspx?id=6190;downloadfilename=LIN_IEMGD_1_14_GOLD_2443.tgz";
>  
> -SRC_URI[md5sum] = "e4a38d9efa0b086ae21b68145c4db4e9"
> -SRC_URI[sha256sum] = 
> "acea5f0f93a31553553428623c007d7ed0c604cf715fd87dfe075751da4be548"
> +SRC_URI[md5sum] = "733a7f237ffce21238ce2c9956df4fd6"
> +SRC_URI[sha256sum] = 
> "bcdc333b5edbda7c746a83ef821ded4a0ca55ead30980e4e3680cdb6469f45a2"
>  
>  # These are closed binaries generated elsewhere so don't check ldflags
>  INSANE_SKIP_${PN} = "ldflags"
>  
>  FILES_${PN} += "${libdir}/dri ${libdir}/gstreamer-0.10 
> ${libdir}/xorg/modules/drivers"
> -FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug 
> ${libdir}/dri/.debug"
> +FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug 
> ${libdir}/dri/.debug ${libdir}/gstreamer-0.10/.debug"
>  
>  S = "${WORKDIR}/${EMGD_RPM_DIR}"
>  
> diff --git a/meta-crownbay/README b/meta-crownbay/README
> index b56c79a..2521432 100644
> --- a/meta-crownbay/README
> +++ b/meta-crownbay/README
> @@ -6,7 +6,7 @@ The Crown Bay platform consists of the Intel Atom Z6xx 
> processor,
>  plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff).
>  
>  It also supports the E6xx embedded on-chip graphics via the Intel
> -Embedded Media and Graphics Driver (EMGD) 1.10 Driver.
> +Embedded Media and Graphics Driver (EMGD) 1.14 Driver.
>  
> 
>  Dependencies
> @@ -63,7 +63,7 @@ common metadata shared between BSPs) e.g.:
>  The meta-crownbay layer contains support for two different machine
>  configurations. These configurations are identical except for the fact
>  that the one prefixed with 'crownbay' makes use of the
> -Intel-proprietary EMGD 1.10 graphics driver, while the one prefixed
> +Intel-proprietary EMGD 1.14 graphics driver, while the one prefixed

Re: [yocto] build error pandaboard on master

[Gary Thomas]

On 2012-07-30 12:49, Jim Abernathy wrote:

On 07/30/2012 01:16 PM, Gary Thomas wrote:

On 2012-07-30 11:09, Jim Abernathy wrote:

On 07/30/2012 12:57 PM, Gary Thomas wrote:

On 2012-07-30 10:50, Jim Abernathy wrote:

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for cloud9 into 
local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: 
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"


BBMASK by itself didn't solve my particular problem. I'll try the other 
suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a BBMASK
statement somewhere and this one is being ignored because of the ?= assignment.


So I started with a clean build again. This time I only added the BBMASK 
statement you suggested.  I got the following error:

ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out 
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Or don't include those layers - meta-systemd isn't needed by your yocto build.


Thanks, that makes more sense now.  I removed the layer meta-systemd from 
bblayers.conf and used the

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

statement in local.conf to solves the problem.

What is really causing the problem?  Without it dependencies on meta-systemd 
are there, but the mask removes that??  Why can you remove a dependency?


The dependency on systemd comes from this recipe: 
meta-ti/recipes-misc/payload/bonescript.bb
The BBMASK is making bitbake ignore that recipe (you don't need it), hence no 
dependency.


I got core-image-minimal built without errors, Thanks, now I need to ask some 
questions about booting that image.  I'm assuming that I can follow the 
instructions on pandaboard.org
for creating the SD card format and just copy the deploy/image/ u-boot, MLO, 
uImage, and rootfs to the right places and boot the sdcard in the pandaboard. 
Anyway, that's what I
tried.  I'm connected to the panadboard via serial port and the U-Boot works 
and the uImage seems to be found, but I don't get a login console on the serial 
port:

U-Boot SPL 2011.12-dirty (Jul 30 2012 - 13:44:03)
Texas Instruments OMAP4430 ES2.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.12-dirty (Jul 30 2012 - 13:44:03)

CPU  : OMAP4430 ES2.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0
Using default environment

In:serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
reading uImage

4176404 bytes read
Booting from mmc0 ...
## Booting kernel from Legacy Image at 8200 ...
Image Name:   Linux-3.1.0
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:4176340 Bytes = 4 MiB
Load Address: 80008000
Entry Point:  80008000
Verifying Check

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 01:16 PM, Gary Thomas wrote:

On 2012-07-30 11:09, Jim Abernathy wrote:

On 07/30/2012 12:57 PM, Gary Thomas wrote:

On 2012-07-30 10:50, Jim Abernathy wrote:

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:
I'm on master branch trying to build core-image-minimal for 
the machine "pandaboard". Besides the basics, I put in a 
license statement for cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time 
build/conf/bblayers.conf

# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could 
not inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= 
"master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = 
"master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = 
"master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"


ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

BBMASK by itself didn't solve my particular problem. I'll try 
the other suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake 
from

trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have 
a BBMASK
statement somewhere and this one is being ignored because of the 
?= assignment.


So I started with a clean build again. This time I only added the 
BBMASK statement you suggested.  I got the following error:


ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend 

/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend 


ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out 
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Or don't include those layers - meta-systemd isn't needed by your 
yocto build.


Thanks, that makes more sense now.  I removed the layer meta-systemd 
from bblayers.conf and used the


BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

statement in local.conf to solves the problem.

What is really causing the problem?  Without it dependencies on 
meta-systemd are there, but the mask removes that??  Why can you 
remove a dependency?


The dependency on systemd comes from this recipe: 
meta-ti/recipes-misc/payload/bonescript.bb
The BBMASK is making bitbake ignore that recipe (you don't need it), 
hence no dependency.


I got core-image-minimal built without errors, Thanks, now I need to ask 
some questions about booting that image.  I'm assuming that I can follow 
the instructions on pandaboard.org for creating the SD card format and 
just copy the deploy/image/ u-boot, MLO, uImage, and rootfs to the right 
places and boot the sdcard in the pandaboard. Anyway, that's what I 
tried.  I'm connected to the panadboard via serial port and the U-Boot 
works and the uImage seems to be found, but I don't get a login console 
on the serial port:


U-Boot SPL 2011.12-dirty (Jul 30 2012 - 13:44:03)
Texas Instruments OMAP4430 ES2.1
OMAP SD/MMC: 0
reading u-boot.img
reading u-boot.img


U-Boot 2011.12-dirty (Jul 30 2012 - 13:44:03)

CPU  : OMAP4430 ES2.1
Board: OMAP4 Panda
I2C:   ready
DRAM:  1 GiB
MMC:   OMAP SD/MMC: 0
Using default environment

In:serial
Out:   serial
Err:   serial
Hit any key to stop autoboot:  0
reading boot.scr

** Unable to read "boot.scr" from mmc 0:1 **
reading uImage

4176404 bytes read
Booting from mmc0 ...
## Booting kernel from Legacy Image at 8200 ...
   Image Name:   Linux-3.1.0
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4176340 Bytes = 4 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
   Loading Kernel Image ... OK
OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Usb-serial device support

[Leon Woestenberg]

Giovanni,

On Mon, Jul 30, 2012 at 10:48 AM, Giovanni Foiani  wrote:

> I built a distribution for iMX53 QSB with kernel 2.6.35-3 and I need
> support for USB-serial devices.
> When I plug the usb-serial converter I get this error..
>
> *usb wakeup is here
>
>   *
> *otg host Remote wakeup
>
>*
> *usb 1-1: new full speed USB device using fsl-ehci and address 3
>
> *
> *usb 1-1: device v067b p2303 is not supported *
>
> I tried to recompile linux-imx kernel adding support for USB-serial
> devices, I run:
>
>- bibake linux-imx -c menuconfig
>- added support for usb-serial devices in menuconfig
>- bitbake -f -c compile linux-imx
>- bitbake linux-imx
>
> ..but it didn't work..
>
> Any suggestions?
>
> Did you see the install and deploy steps being performed? There are some
versions of OE/Yocto where those steps are not depended upon, even if you
ran -c compile -f.

For example, on Denzil, I have to run the compile, install and deploy steps
forcefully.

Regards,

Leon.

> Giovanni
> --
>
> Dott. Ing. Giovanni Foiani
>
> Cell:+39-349-3577515
> Phone:+39-0532-97-4106
> mail:giovanni.foi...@unife.it
> CenTec - Corso Guercino, 47 - 44042 Cento (FE)
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] denzil kernel build issues

[Bruce Ashfield]

On 12-07-30 10:20 AM, Frans Meulenbroeks wrote:

Hi Bruce,

Thanks for your support.
See below

2012/7/30 Bruce Ashfield mailto:bruce.ashfi...@gmail.com>>

On Mon, Jul 30, 2012 at 7:33 AM, Frans Meulenbroeks
mailto:fransmeulenbro...@gmail.com>>
wrote:
 > Dear all,
 >
 > I finally managed to find time to pick up porting my project to
denzil and
 > did encounter two issues that I wanted to report back:
 >
 > First is that I could not find what the preferred way was to
disable a
 > kernel option in my bsp.
 > (the option concerned is CONFIG_PM).
 > Of course I can sed it out in do_configure but I'd hoped it could
be simpler
 > (I have tried:
 > CONFIG_PM=n
 > in my config snippet)

Putting:

# CONFIG_PM is not set

in your configuration fragment will turn off an option, the BSP
guide has a
"# CONFIG_SMP is not set" as an example for this.


i thought it would and I have had this in my config too, but still it
get switched on. Guess there is something else in my config that sets this.
Will dive into this.


 >
 > Secondly a patch of mine does not seem to apply properly the
first time, but
 > it does apply a second time.
 > This suggests a race between do_kernel_checkout and do_patch

There shouldn't be any race .. if this doesn't work:

addtask kernel_checkout before do_patch after do_unpack

Then there are some serious problems with bitbake's task scheduling.

If you didn't do a clean between the two runs, the second is
attempting to continue
the patching and you still aren't getting what you want.


I did not do a clean inbetween. I figured patch would reattempt to patch
and, since the file is there it would continue.

The addtask line is there in one of the bitbake files.

The odd thing is that the exact same thing builds fine under 3.0.
Actually I was trying to move from 3.0 to 3.2 while stumbling on this.



Without seeing what you've ported, or a work in progress I can't say
exactly
what is wrong, but your meta data is somehow wrong or completely
missing.
Have you set any meta or BSP SRCREVs explicitly ?


I have put my work-in-progress in:

https://www.dropbox.com/s/h58h6pq5b0f4u2s/patchproblem.tar.gz vi

you might want to edit conf/layer.conf as it has hardcoded paths.
If I go to meta-syrcxx/conf/machine/syrcxx.conf and set the preferred
kernel version to 3.0 things build fine.
Then I did set to 3.2 and it fails.


I'll give this a try, sounds like a typical patch/meta issue, so I should
see it quickly.


Note that apart from a PR bump the files
meta-syrcxx/recipes-kernel/linux/linux-yocto_3.2.bbappend
meta-syrcxx/recipes-kernel/linux/linux-yocto_3.0.bbappend
are identical (and I am just using files; so the same patches apply.

BTW our board is a powerpc 8313e based board (modeled after mpc8313e-rds)

One other thing I noticed; do_install seems to take quite some time; not
sure why this is (haven't investigated).


hmm. normally that means some sort of rpm issue (or maybe you are
using ipk), but it can take a significant time.

Cheers,

Bruce



Best regards, Frans


Cheers,

Bruce

 >
 > Below is a log that illustrates this and demonstrates that things
are ok the
 > 2nd time.
 > (btw I am also a little bit concerned on the command not found
messages).
 > And of course any sugguestion for a fix is greatly appreciated.
 >
 > Best regards, Frans
 >
 > frans@frans-desktop:~/poky-denzil-7.0-build$ bitbake virtual/kernel
 > Parsing recipes: 100%
 >

|##|
 > Time: 00:00:30
 > Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105
targets, 35
 > skipped, 0 masked, 0 errors.
 >
 > OE Build Configuration:
 > BB_VERSION = "1.15.1"
 > TARGET_ARCH = "powerpc"
 > TARGET_OS = "linux-uclibc"
 > MACHINE = "syrcxx"
 > DISTRO = "poky"
 > DISTRO_VERSION = "1.2"
 > TUNE_FEATURES = "m32 fpu-hard ppce300c3"
 > TARGET_FPU = ""
 > meta
 > meta-yocto
 > meta-syrcxx = ":"
 >
 > NOTE: Resolving any missing task queue dependencies
 > NOTE: Preparing runqueue
 > NOTE: Executing SetScene Tasks
 > NOTE: Executing RunQueue Tasks
 > NOTE: Running task 162 of 664 (ID: 6,
 >
/home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb
,
 > do_fetch)
 > NOTE: package
 >

linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
 > task do_fetch: Started
 > NOTE: package
 >

linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
 > task do_fetch: Succeeded
 > NOTE: Running task 644 of 664 (ID: 2,
 >
  

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Paul Eggleton]

On Monday 30 July 2012 21:08:54 Elvis Dowson wrote:
> Hi Paul,
> 
> On Jul 30, 2012, at 8:58 PM, Paul Eggleton wrote:
> > This is my fault - I'll put together a patch right now. As a workaround
> > you
> > can "bitbake rpmresolve-native" first and you won't get the error anymore.
> 
> Thanks for the workaround! It worked.
> 
> It would be good if all changes to the master were run through an automated
> build test on an internal git repository, prior to being pushed out to the
> public git repository. This way, you would be able to ensure that breaks in
> the build do not get propagated to all users.

FYI, we do do this already for most significant changes, and it was done for 
this one. The trouble with this specific issue is, if you happened to build a 
normal image prior to building meta-toolchain or indeed any other user of 
do_populate_sdk, the error will not occur because rpmresolve-native would 
already have been built; hence why this was missed.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Gary Thomas]

On 2012-07-30 11:09, Jim Abernathy wrote:

On 07/30/2012 12:57 PM, Gary Thomas wrote:

On 2012-07-30 10:50, Jim Abernathy wrote:

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for cloud9 into 
local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: 
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"


BBMASK by itself didn't solve my particular problem. I'll try the other 
suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a BBMASK
statement somewhere and this one is being ignored because of the ?= assignment.


So I started with a clean build again. This time I only added the BBMASK 
statement you suggested.  I got the following error:

ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out 
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Or don't include those layers - meta-systemd isn't needed by your yocto build.


Thanks, that makes more sense now.  I removed the layer meta-systemd from 
bblayers.conf and used the

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

statement in local.conf to solves the problem.

What is really causing the problem?  Without it dependencies on meta-systemd 
are there, but the mask removes that??  Why can you remove a dependency?


The dependency on systemd comes from this recipe: 
meta-ti/recipes-misc/payload/bonescript.bb
The BBMASK is making bitbake ignore that recipe (you don't need it), hence no 
dependency.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 12:57 PM, Gary Thomas wrote:

On 2012-07-30 10:50, Jim Abernathy wrote:

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:
I'm on master branch trying to build core-image-minimal for the 
machine "pandaboard". Besides the basics, I put in a license 
statement for cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time 
build/conf/bblayers.conf

# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could 
not inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= 
"master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = 
"master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = 
"master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"


ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

BBMASK by itself didn't solve my particular problem. I'll try the 
other suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a 
BBMASK
statement somewhere and this one is being ignored because of the ?= 
assignment.


So I started with a clean build again. This time I only added the 
BBMASK statement you suggested.  I got the following error:


ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend 

/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend 


ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out 
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Or don't include those layers - meta-systemd isn't needed by your 
yocto build.


Thanks, that makes more sense now.  I removed the layer meta-systemd 
from bblayers.conf and used the


BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

statement in local.conf to solves the problem.

What is really causing the problem?  Without it dependencies on 
meta-systemd are there, but the mask removes that??  Why can you remove 
a dependency?


Jim A



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Elvis Dowson]

Hi Paul,

On Jul 30, 2012, at 8:58 PM, Paul Eggleton wrote:
> 
> This is my fault - I'll put together a patch right now. As a workaround you 
> can "bitbake rpmresolve-native" first and you won't get the error anymore.

Thanks for the workaround! It worked.

It would be good if all changes to the master were run through an automated 
build test on an internal git repository, prior to being pushed out to the 
public git repository. This way, you would be able to ensure that breaks in the 
build do not get propagated to all users.

FYI, I refresh my yocto repos every two weeks and always perform a clean build, 
after deleting my tmp and sstate-cache folders. 

It take around 2 hours to build meta-toolchain, and another hour to build 
core-image-minimal, on my machine configuration, which is a MacBook Pro 15", 
8GB RAM, 2.3GHz Core i7, running Ubuntu 12.04 LTS 64-bit using VMware Fusion 
5.0.0 with 8 CPU core configured, and 4GB RAM allocated to the VM.

I usually have the following layers setup for each build

BBLAYERS ?= " \
  /tool/yocto/poky/meta \
  /tool/yocto/poky/meta-yocto \
  /tool/yocto/meta-openembedded/meta-oe \
  /tool/yocto/meta-xilinx \
  "

Best regards,

Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Paul Eggleton]

On Monday 30 July 2012 20:55:50 Elvis Dowson wrote:
> Hi Martin,
> 
> On Jul 30, 2012, at 8:48 PM, Martin Jansa wrote:
> > Attach log.do_populate_sdk.25279
> 
> Here is the log
> 
> DEBUG: Executing python function do_populate_sdk
> DEBUG: Executing shell function populate_sdk_image
> Generating solve db for /tool/yocto/poky/build/tmp/deploy/rpm/ppc440...
>total:   1  0.00 MB 15.378123 secs
>fingerprint:  7383  0.071586 MB  0.795094 secs
>install:  2461  0.00 MB  3.924927 secs
>digest:   4922 17.539986 MB  0.071979 secs
>signature:4922  0.00 MB  5.635336 secs
>dbadd:2461  0.00 MB  3.867947 secs
>dbget:   24358  0.00 MB  0.044111 secs
>dbput:2461 11.232764 MB  2.458966 secs
>readhdr: 24611 22.422706 MB  2.833783 secs
>hdrload: 15847 48.317258 MB  0.063320 secs
>hdrget: 451910  0.00 MB  0.314565 secs
> Generating solve db for
> /tool/yocto/poky/build/tmp/deploy/rpm/x86_64-nativesdk... total:   
>1  0.00 MB  4.420427 secs
>fingerprint:  1698  0.056604 MB  0.353290 secs
>install:   566  0.00 MB  1.192211 secs
>digest:   1132  9.261982 MB  0.035940 secs
>signature:1132  0.00 MB  1.325190 secs
>dbadd: 566  0.00 MB  1.176382 secs
>dbget:   21453  0.00 MB  0.022157 secs
>dbput: 566  5.223256 MB  0.825451 secs
>readhdr:  5661 10.385022 MB  0.950751 secs
>hdrload:  3049 16.903506 MB  0.013520 secs
>hdrget: 107862  0.00 MB  0.088460 secs
> Processing task-core-standalone-sdk-target-dbg...
> Processing task-core-standalone-sdk-target...
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/meta-toolchain-1.0-r7/temp
> /run.populate_sdk_image.25279: line 675: rpmresolve: command not found
> DEBUG: Python function do_populate_sdk finished
> ERROR: Function failed: populate_sdk_image (see
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/meta-toolchain-1.0-r7/tem
> p/log.do_populate_sdk.25279 for further information)

This is my fault - I'll put together a patch right now. As a workaround you 
can "bitbake rpmresolve-native" first and you won't get the error anymore.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Gary Thomas]

On 2012-07-30 10:50, Jim Abernathy wrote:

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for cloud9 into 
local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: 
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"


BBMASK by itself didn't solve my particular problem.  I'll try the other 
suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a BBMASK
statement somewhere and this one is being ignored because of the ?= assignment.


So I started with a clean build again. This time I only added the BBMASK 
statement you suggested.  I got the following error:

ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out 
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Or don't include those layers - meta-systemd isn't needed by your yocto build.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Elvis Dowson]

Hi Martin,

On Jul 30, 2012, at 8:48 PM, Martin Jansa wrote:

> Attach log.do_populate_sdk.25279

Here is the log

DEBUG: Executing python function do_populate_sdk
DEBUG: Executing shell function populate_sdk_image
Generating solve db for /tool/yocto/poky/build/tmp/deploy/rpm/ppc440...
   total:   1  0.00 MB 15.378123 secs
   fingerprint:  7383  0.071586 MB  0.795094 secs
   install:  2461  0.00 MB  3.924927 secs
   digest:   4922 17.539986 MB  0.071979 secs
   signature:4922  0.00 MB  5.635336 secs
   dbadd:2461  0.00 MB  3.867947 secs
   dbget:   24358  0.00 MB  0.044111 secs
   dbput:2461 11.232764 MB  2.458966 secs
   readhdr: 24611 22.422706 MB  2.833783 secs
   hdrload: 15847 48.317258 MB  0.063320 secs
   hdrget: 451910  0.00 MB  0.314565 secs
Generating solve db for 
/tool/yocto/poky/build/tmp/deploy/rpm/x86_64-nativesdk...
   total:   1  0.00 MB  4.420427 secs
   fingerprint:  1698  0.056604 MB  0.353290 secs
   install:   566  0.00 MB  1.192211 secs
   digest:   1132  9.261982 MB  0.035940 secs
   signature:1132  0.00 MB  1.325190 secs
   dbadd: 566  0.00 MB  1.176382 secs
   dbget:   21453  0.00 MB  0.022157 secs
   dbput: 566  5.223256 MB  0.825451 secs
   readhdr:  5661 10.385022 MB  0.950751 secs
   hdrload:  3049 16.903506 MB  0.013520 secs
   hdrget: 107862  0.00 MB  0.088460 secs
Processing task-core-standalone-sdk-target-dbg...
Processing task-core-standalone-sdk-target...
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/meta-toolchain-1.0-r7/temp/run.populate_sdk_image.25279:
 line 675: rpmresolve: command not found
DEBUG: Python function do_populate_sdk finished
ERROR: Function failed: populate_sdk_image (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.25279
 for further information)

Best regards,

Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:
I'm on master branch trying to build core-image-minimal for the 
machine "pandaboard". Besides the basics, I put in a license 
statement for cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not 
inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= 
"master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = 
"master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = 
"master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"


ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

BBMASK by itself didn't solve my particular problem.  I'll try the 
other suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a 
BBMASK
statement somewhere and this one is being ignored because of the ?= 
assignment.


So I started with a clean build again. This time I only added the BBMASK 
statement you suggested.  I got the following error:


ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
ERROR: Command execution failed: Exited with 1

I'm guessing the BBMASK needs to call out 
meta-openembedded/meta-systemd/meta-gnome and meta-efl?


Jim A

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Martin Jansa]

On Mon, Jul 30, 2012 at 08:43:33PM +0400, Elvis Dowson wrote:
> Hi,
>   I just updated my yocto repositories and ran into the following error:
> 
> | ERROR: Function failed: populate_sdk_image (see 
> /tool/yocto/poky/build/tmp/work/ppc440-poky-linux/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.25279
>  for further information)
> NOTE: package meta-toolchain-1.0-r7: task do_populate_sdk: Failed
> ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, 
> do_populate_sdk) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 1878 tasks of which 236 didn't need to be 
> rerun and 1 failed.
> ERROR: An uncaught exception occured in runqueue, please see the failure 
> below:
> 
> Summary: 1 task failed:
>   /tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk
> Summary: There were 3 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> 
> Is there a fix for this? 

Attach log.do_populate_sdk.25279

Cheers,

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk) failed with exit code '1'

[Elvis Dowson]

Hi,
  I just updated my yocto repositories and ran into the following error:

| ERROR: Function failed: populate_sdk_image (see 
/tool/yocto/poky/build/tmp/work/ppc440-poky-linux/meta-toolchain-1.0-r7/temp/log.do_populate_sdk.25279
 for further information)
NOTE: package meta-toolchain-1.0-r7: task do_populate_sdk: Failed
ERROR: Task 7 (/tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, 
do_populate_sdk) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1878 tasks of which 236 didn't need to be rerun 
and 1 failed.
ERROR: An uncaught exception occured in runqueue, please see the failure below:

Summary: 1 task failed:
  /tool/yocto/poky/meta/recipes-core/meta/meta-toolchain.bb, do_populate_sdk
Summary: There were 3 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

Is there a fix for this? 

Elvis Dowson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit

[Tom Zanussi]

On Mon, 2012-07-30 at 08:28 -0700, Darren Hart wrote:
> 
> On 07/30/2012 02:50 AM, Kamble, Nitin A wrote:
> > 
> > 
> >> -Original Message- From: Darren Hart
> >> [mailto:dvh...@linux.intel.com] Sent: Saturday, July 28, 2012 3:27
> >> AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org;
> >> bruce.ashfi...@windriver.com; Zanussi, Tom Subject: Re: [yocto]
> >> [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on
> >> the corwnbay kit
> >> 
> >> 
> >> 
> >> On 07/26/2012 10:31 PM, Kamble, Nitin A wrote:
> >> On 07/23/2012 03:06 AM, nitin.a.kam...@intel.com wrote:
> >>> From: Nitin A Kamble 
> >>> 
> >>> The kit has Auo 800x600 LCD screen. Configuring Xorg for
> >>> it.
> >> 
> >> I presume the crownbay has additional display options? how
> >> does this impact those?
> >> 
> > This change sets the resolution of the screen to 800x600. And
> > this is applicable to LCD screen on the kit as well as
> > external monitor. I will add a note about it in the log.
>  
>  I presume that without this change it was able to detect the 
>  appropriate resolution of the connected monitor, but not of the
>  LCD?
>  
>  If so, this change effectively breaks that autodetection and
>  forces everything to the 800x600 display which is arguably
>  very low-resolution by today's standards. Why should this be
>  the default? When you refer to "the kit", what exactly are you
>  referring to?
>  
>  Also, is this a discussion you have already had with Tom? I
>  don't want to contradict what he has said regarding this BSP.
> >>> 
> >>> 
> >>> EMGD driver on crownbay gives few resolutions as options. By
> >>> default it tries to set 1366x768 resolution for both LCD and
> >>> external monitor. The Crownbay kit is a suitcase kind of box,
> >>> which has builtin LCD screen of resolution 800x600. This LCD
> >>> screen shows only 800x600 of the default 1366x768 area. So The
> >>> LCD is not able to show all the screen, and IMO it is a
> >>> functional issue.
> >>> 
> >>> For my Dell 1704FPTi monitor which has 1280x1024 native
> >>> resolution; When connected to the crownbay,  X cannot find a
> >>> working mode for this monitor. But if I set 800x600 in the
> >>> xorg.conf as this commit does, then both LCD & external monitor
> >>> can show the X screen without any issues.
> >> 
> >> This seems like a bug to me. The driver should be able to probe the
> >> display and use the optimal resolution without it being specified
> >> in the Xorg.conf. So far as I know we don't specify resolution in
> >> any of the meta-intel BSPs:
> >> 
> >> dvhart@envy:~/source/poky/layers/meta-intel [denzil] $ find .
> >> -name xorg.conf | xargs grep -i Modes
> >> 
> >> So while I agree the kit screen should work out of the box, the
> >> fact that even your dell lcd monitor doesn't work is cause for
> >> concern. Is there anything in the Xorg log that indicates why it
> >> isn't able to get the EDID data?
> >> 
> >> -- Darren
> >> 
> > 
> > In the xorg log I do not see any useful EDID information. Either
> > these displays do not support EDID, or the EDID support in the EMGD
> > driver is not working well with these devices. And the EMGD driver is
> > closed source. So we can't fix it. So IMO keeping the resolution to
> > 800x600 is the best possible solution for crownbay BSP.
> 
> Tom,
> 
> I've never booted a crownbay machine. What has your experience been with
> the displays on this board?
> 

I've never had any problems with X autodetecting the correct resolution
for either the LVDS or DVI output.  I actually had the unit Nitin has
now, but the first thing I did with that was unhook the dinky little
built-in panel and hook up a normal-sized LVDS screen that I could stand
up separately for testing.

In any case, I don't think it makes sense to hard-code a resolution for
a particular unusual screen in the default BSP - I'd suggest opening a
bug to find out why this screen can't be auto-detected if it's
important...

Tom 


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit

[Darren Hart]

On 07/30/2012 02:50 AM, Kamble, Nitin A wrote:
> 
> 
>> -Original Message- From: Darren Hart
>> [mailto:dvh...@linux.intel.com] Sent: Saturday, July 28, 2012 3:27
>> AM To: Kamble, Nitin A Cc: yocto@yoctoproject.org;
>> bruce.ashfi...@windriver.com; Zanussi, Tom Subject: Re: [yocto]
>> [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on
>> the corwnbay kit
>> 
>> 
>> 
>> On 07/26/2012 10:31 PM, Kamble, Nitin A wrote:
>> On 07/23/2012 03:06 AM, nitin.a.kam...@intel.com wrote:
>>> From: Nitin A Kamble 
>>> 
>>> The kit has Auo 800x600 LCD screen. Configuring Xorg for
>>> it.
>> 
>> I presume the crownbay has additional display options? how
>> does this impact those?
>> 
> This change sets the resolution of the screen to 800x600. And
> this is applicable to LCD screen on the kit as well as
> external monitor. I will add a note about it in the log.
 
 I presume that without this change it was able to detect the 
 appropriate resolution of the connected monitor, but not of the
 LCD?
 
 If so, this change effectively breaks that autodetection and
 forces everything to the 800x600 display which is arguably
 very low-resolution by today's standards. Why should this be
 the default? When you refer to "the kit", what exactly are you
 referring to?
 
 Also, is this a discussion you have already had with Tom? I
 don't want to contradict what he has said regarding this BSP.
>>> 
>>> 
>>> EMGD driver on crownbay gives few resolutions as options. By
>>> default it tries to set 1366x768 resolution for both LCD and
>>> external monitor. The Crownbay kit is a suitcase kind of box,
>>> which has builtin LCD screen of resolution 800x600. This LCD
>>> screen shows only 800x600 of the default 1366x768 area. So The
>>> LCD is not able to show all the screen, and IMO it is a
>>> functional issue.
>>> 
>>> For my Dell 1704FPTi monitor which has 1280x1024 native
>>> resolution; When connected to the crownbay,  X cannot find a
>>> working mode for this monitor. But if I set 800x600 in the
>>> xorg.conf as this commit does, then both LCD & external monitor
>>> can show the X screen without any issues.
>> 
>> This seems like a bug to me. The driver should be able to probe the
>> display and use the optimal resolution without it being specified
>> in the Xorg.conf. So far as I know we don't specify resolution in
>> any of the meta-intel BSPs:
>> 
>> dvhart@envy:~/source/poky/layers/meta-intel [denzil] $ find .
>> -name xorg.conf | xargs grep -i Modes
>> 
>> So while I agree the kit screen should work out of the box, the
>> fact that even your dell lcd monitor doesn't work is cause for
>> concern. Is there anything in the Xorg log that indicates why it
>> isn't able to get the EDID data?
>> 
>> -- Darren
>> 
> 
> In the xorg log I do not see any useful EDID information. Either
> these displays do not support EDID, or the EDID support in the EMGD
> driver is not working well with these devices. And the EMGD driver is
> closed source. So we can't fix it. So IMO keeping the resolution to
> 800x600 is the best possible solution for crownbay BSP.

Tom,

I've never booted a crownbay machine. What has your experience been with
the displays on this board?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] kernel.bbclass: Iff exists, copy bounds.h for external module building.

[Leon Woestenberg]

Hello Bruce, Scott,

On Mon, Jul 30, 2012 at 5:09 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 12-07-30 11:07 AM, Bruce Ashfield wrote:
>
>> On 12-07-28 09:45 AM, Leon Woestenberg wrote:
>>
>>> From: Leon Woestenberg>
>>>
>>>
> Aha. And now I see that Scott G was copied. If this was for 1.2.x of yocto,
> that needs to be clearly in the subject .. otherwise it is just
> confusing.
>
>
Correct, my intention was for Denzil. Agreed, the full fix should be first
proposed for HEAD, and I should first fix my GIT script foo setup. This
went wrong in several ways.

Regards,

Leon.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Delete unused hob images

[Giovanni Foiani]

Ok, thanks

Giovanni
--

Dott. Ing. Giovanni Foiani

Cell:+39-349-3577515
Phone:+39-0532-97-4106
mail:giovanni.foi...@unife.it
CenTec - Corso Guercino, 47 - 44042 Cento (FE)



On Mon, Jul 30, 2012 at 4:42 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Monday 30 July 2012 15:18:37 Giovanni Foiani wrote:
> > I read this section in Poky Reference manual:
> >
> > *A.2.13. build/tmp/deploy/images/*
> > *
> > *
> > *This directory receives complete filesystem images. If you want to flash
> > the resulting image from a build onto a device, look here for the image.*
> > *
> > *
> > *Note, you should not remove any files from this directory by hand in an
> > attempt to rebuild an image. If you want to clean out the cache, re-run
> the
> > build using the following BitBake command: *
> > * $ bitbake -c cleanall *
> >
> > I built many images using hob and in my *build/tmp/deploy/images/ *folder
> > there are a lot of rootfs images (like
> > hob-image-imx53qsb-.rootfs.ext3 etc..) and I want to remove
> the
> > unused ones to free some space..
> >
> > I tried tp run:
> >
> > *bitbake -c cleanall * hob-image-imx53qsb-
> >
> > but I got:
> > ERROR: Nothing PROVIDES 'hob-image-imx53qsb-'
>
> I'm not sure where this came from originally, but it is not correct. I'll
> talk
> to Scott R about fixing this part of the manual.
>
> > Can I safely remove these files by hand?
>
> The hob-image-*, yes. In fact any actual image files in deploy/images are
> OK to
> delete (excluding *zImage*, *uImage*, etc. - those are kernels). All the
> warnings are trying to prevent is people deleting the entire contents of
> deploy/images and then wondering why the kernel, bootloader etc. that get
> produced as part of the process of building an image but are not part of
> the
> image itself aren't re-created when they build the image again afterwards.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] kernel.bbclass: Iff exists, copy bounds.h for external module building.

[Bruce Ashfield]

On 12-07-30 11:07 AM, Bruce Ashfield wrote:

On 12-07-28 09:45 AM, Leon Woestenberg wrote:

From: Leon Woestenberg



Aha. And now I see that Scott G was copied. If this was for 1.2.x of yocto,
that needs to be clearly in the subject .. otherwise it is just
confusing.

My comment still stands that if this is needed for denzil, it should
be the same fixes we have in master, and not something different.

Cheers,

Bruce


Signed-off-by: Leon Woestenberg
---
meta/classes/kernel.bbclass | 6 ++
1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c21ab96..bd3e335 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -183,6 +183,12 @@ kernel_do_install() {
cp arch/powerpc/lib/crtsavres.o $kerneldir/arch/powerpc/lib/crtsavres.o
fi

+ # make -C $kerneldir _mrproper_scripts deleted this file, but we
need it for
+ # building external modules like compat-wireless.
+ if [ -f include/generated/bounds.h ]; then
+ cp include/generated/bounds.h $kerneldir/include/generated/bounds.h
+ fi


This change is definitely safer using and older kernel that doesn't have a
generated bounds.h .. but your tree is out of date. This should be on
top of:

commit 9247550642a536f83c6c711ce4bd340e5e5606b7
Author: Denis Carikli 
Date: Fri Jul 20 16:22:22 2012 -0700

kernel.bbclass: fix external module building

Without that fix we have the following while compiling compat-wireless.
include/linux/mmzone.h:18:30: fatal error: generated/bounds.h: No such
file or directory

Note that the compat-wireless recipe will be added in another commit.

make -C $kerneldir _mrproper_scripts deleted this file along with
other things so we resurrect it with this patch.

(From OE-Core rev: 2d114fd0cdf7486f18e53f2bf41c4f559e4b4a8d)

Signed-off-by: Denis 'GNUtoo' Carikli 
Signed-off-by: Koen Kooi 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie 


Cheers,

Bruce


+
# Remove the following binaries which cause strip errors
# during do_package for cross-compiled platforms
bin_files="arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] kernel.bbclass: Iff exists, copy bounds.h for external module building.

[Bruce Ashfield]

On 12-07-28 09:45 AM, Leon Woestenberg wrote:

From: Leon Woestenberg

Signed-off-by: Leon Woestenberg
---
  meta/classes/kernel.bbclass |6 ++
  1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c21ab96..bd3e335 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -183,6 +183,12 @@ kernel_do_install() {
cp arch/powerpc/lib/crtsavres.o 
$kerneldir/arch/powerpc/lib/crtsavres.o
fi

+   # make -C $kerneldir _mrproper_scripts deleted this file, but we need 
it for
+   # building external modules like compat-wireless.
+   if [ -f include/generated/bounds.h ]; then
+   cp include/generated/bounds.h 
$kerneldir/include/generated/bounds.h
+   fi


This change is definitely safer using and older kernel that doesn't have a
generated bounds.h .. but your tree is out of date. This should be on
top of:

commit 9247550642a536f83c6c711ce4bd340e5e5606b7
Author: Denis Carikli 
Date:   Fri Jul 20 16:22:22 2012 -0700

kernel.bbclass: fix external module building

Without that fix we have the following while compiling compat-wireless.
  include/linux/mmzone.h:18:30: fatal error: generated/bounds.h: No 
such file or directory


Note that the compat-wireless recipe will be added in another commit.

make -C $kerneldir _mrproper_scripts deleted this file along with
other things so we resurrect it with this patch.

(From OE-Core rev: 2d114fd0cdf7486f18e53f2bf41c4f559e4b4a8d)

Signed-off-by: Denis 'GNUtoo' Carikli 
Signed-off-by: Koen Kooi 
Signed-off-by: Saul Wold 
Signed-off-by: Richard Purdie 


Cheers,

Bruce


+
# Remove the following binaries which cause strip errors
# during do_package for cross-compiled platforms
bin_files="arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] kernel.bbclass: Iff exists, copy bounds.h for external module building.

[Leon Woestenberg]

From: Leon Woestenberg 

Signed-off-by: Leon Woestenberg 
---
 meta/classes/kernel.bbclass |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index c21ab96..bd3e335 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -183,6 +183,12 @@ kernel_do_install() {
cp arch/powerpc/lib/crtsavres.o 
$kerneldir/arch/powerpc/lib/crtsavres.o
fi
 
+   # make -C $kerneldir _mrproper_scripts deleted this file, but we need 
it for
+   # building external modules like compat-wireless.
+   if [ -f include/generated/bounds.h ]; then
+   cp include/generated/bounds.h 
$kerneldir/include/generated/bounds.h
+   fi
+
# Remove the following binaries which cause strip errors
# during do_package for cross-compiled platforms
bin_files="arch/powerpc/boot/addnote arch/powerpc/boot/hack-coff \
-- 
1.7.0.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Delete unused hob images

[Paul Eggleton]

On Monday 30 July 2012 15:18:37 Giovanni Foiani wrote:
> I read this section in Poky Reference manual:
> 
> *A.2.13. build/tmp/deploy/images/*
> *
> *
> *This directory receives complete filesystem images. If you want to flash
> the resulting image from a build onto a device, look here for the image.*
> *
> *
> *Note, you should not remove any files from this directory by hand in an
> attempt to rebuild an image. If you want to clean out the cache, re-run the
> build using the following BitBake command: *
> * $ bitbake -c cleanall *
> 
> I built many images using hob and in my *build/tmp/deploy/images/ *folder
> there are a lot of rootfs images (like
> hob-image-imx53qsb-.rootfs.ext3 etc..) and I want to remove the
> unused ones to free some space..
> 
> I tried tp run:
> 
> *bitbake -c cleanall * hob-image-imx53qsb-
> 
> but I got:
> ERROR: Nothing PROVIDES 'hob-image-imx53qsb-'

I'm not sure where this came from originally, but it is not correct. I'll talk 
to Scott R about fixing this part of the manual.

> Can I safely remove these files by hand?

The hob-image-*, yes. In fact any actual image files in deploy/images are OK to 
delete (excluding *zImage*, *uImage*, etc. - those are kernels). All the 
warnings are trying to prevent is people deleting the entire contents of 
deploy/images and then wondering why the kernel, bootloader etc. that get 
produced as part of the process of building an image but are not part of the 
image itself aren't re-created when they build the image again afterwards.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 10:21 AM, Gary Thomas wrote:

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:
I'm on master branch trying to build core-image-minimal for the 
machine "pandaboard". Besides the basics, I put in a license 
statement for cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not 
inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= 
"master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = 
"master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = 
"master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"


ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

BBMASK by itself didn't solve my particular problem.  I'll try the 
other suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a 
BBMASK
statement somewhere and this one is being ignored because of the ?= 
assignment.



hmm..

right now  I have the build running by using the 
BB_DANGLINGAPPENDS_WARNONLY = "yes" statement.


When that is done, I'll test the BBMASK on a completely new build from 
scratch and see what I get.


Jim A

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Gary Thomas]

On 2012-07-30 08:11, Jim Abernathy wrote:

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for cloud9 into 
local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: 
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"


BBMASK by itself didn't solve my particular problem.  I'll try the other 
suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.


The only way you could get that same error is if you already have a BBMASK
statement somewhere and this one is being ignored because of the ?= assignment.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] denzil kernel build issues

[Frans Meulenbroeks]

Hi Bruce,

Thanks for your support.
See below

2012/7/30 Bruce Ashfield 

> On Mon, Jul 30, 2012 at 7:33 AM, Frans Meulenbroeks
>  wrote:
> > Dear all,
> >
> > I finally managed to find time to pick up porting my project to denzil
> and
> > did encounter two issues that I wanted to report back:
> >
> > First is that I could not find what the preferred way was to disable a
> > kernel option in my bsp.
> > (the option concerned is CONFIG_PM).
> > Of course I can sed it out in do_configure but I'd hoped it could be
> simpler
> > (I have tried:
> > CONFIG_PM=n
> > in my config snippet)
>
> Putting:
>
> # CONFIG_PM is not set
>
> in your configuration fragment will turn off an option, the BSP guide has a
> "# CONFIG_SMP is not set" as an example for this.
>

i thought it would and I have had this in my config too, but still it get
switched on. Guess there is something else in my config that sets this.
Will dive into this.

>
> >
> > Secondly a patch of mine does not seem to apply properly the first time,
> but
> > it does apply a second time.
> > This suggests a race between do_kernel_checkout and do_patch
>
> There shouldn't be any race ..  if this doesn't work:
>
>addtask kernel_checkout before do_patch after do_unpack
>
> Then there are some serious problems with bitbake's task scheduling.
>
> If you didn't do a clean between the two runs, the second is
> attempting to continue
> the patching and you still aren't getting what you want.
>

I did not do a clean inbetween. I figured patch would reattempt to patch
and, since the file is there it would continue.

The addtask line is there in one of the bitbake files.

The odd thing is that the exact same thing builds fine under 3.0.
Actually I was trying to move from 3.0 to 3.2 while stumbling on this.



> Without seeing what you've ported, or a work in progress I can't say
> exactly
> what is wrong, but your meta data is somehow wrong or completely missing.
> Have you set any meta or BSP SRCREVs explicitly ?
>

I have put my work-in-progress in:

https://www.dropbox.com/s/h58h6pq5b0f4u2s/patchproblem.tar.gz vi

you might want to edit conf/layer.conf as it has hardcoded paths.
If I go to meta-syrcxx/conf/machine/syrcxx.conf and set the preferred
kernel version to 3.0 things build fine.
Then I did set to 3.2 and it fails.
Note that apart from a PR bump the files
meta-syrcxx/recipes-kernel/linux/linux-yocto_3.2.bbappend
meta-syrcxx/recipes-kernel/linux/linux-yocto_3.0.bbappend
are identical (and I am just using files; so the same patches apply.

BTW our board is a powerpc 8313e based board (modeled after mpc8313e-rds)

One other thing I noticed; do_install seems to take quite some time; not
sure why this is (haven't investigated).

Best regards, Frans

>
> Cheers,
>
> Bruce
>
> >
> > Below is a log that illustrates this and demonstrates that things are ok
> the
> > 2nd time.
> > (btw I am also a little bit concerned on the command not found messages).
> > And of course any sugguestion for a fix is greatly appreciated.
> >
> > Best regards, Frans
> >
> > frans@frans-desktop:~/poky-denzil-7.0-build$ bitbake virtual/kernel
> > Parsing recipes: 100%
> >
> |##|
> > Time: 00:00:30
> > Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105 targets,
> 35
> > skipped, 0 masked, 0 errors.
> >
> > OE Build Configuration:
> > BB_VERSION= "1.15.1"
> > TARGET_ARCH   = "powerpc"
> > TARGET_OS = "linux-uclibc"
> > MACHINE   = "syrcxx"
> > DISTRO= "poky"
> > DISTRO_VERSION= "1.2"
> > TUNE_FEATURES = "m32 fpu-hard ppce300c3"
> > TARGET_FPU= ""
> > meta
> > meta-yocto
> > meta-syrcxx   = ":"
> >
> > NOTE: Resolving any missing task queue dependencies
> > NOTE: Preparing runqueue
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > NOTE: Running task 162 of 664 (ID: 6,
> > /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb
> ,
> > do_fetch)
> > NOTE: package
> >
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> > task do_fetch: Started
> > NOTE: package
> >
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> > task do_fetch: Succeeded
> > NOTE: Running task 644 of 664 (ID: 2,
> > /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb
> ,
> > do_unpack)
> > NOTE: package
> >
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> > task do_unpack: Started
> > NOTE: package
> >
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> > task do_unpack: Succeeded
> > Nmeta-syrcxx/recipes-kernel/linux/linux-yocto_3.2.bbappend
> meta-syrcxx/recipes-kernel/linux/linux-yocto_3.0.bbappendOTE:

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 09:56 AM, Gary Thomas wrote:

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:
I'm on master branch trying to build core-image-minimal for the 
machine "pandaboard". Besides the basics, I put in a license 
statement for cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not 
inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

BBMASK by itself didn't solve my particular problem.  I'll try the 
other suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...



When I just used the statement:

BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

I got the same error as my original post.

Jim A


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 4/4] crownbay: make v3.4 the default kernel

[nitin . a . kamble]

From: Nitin A Kamble 

Signed-off-by: Nitin A Kamble 
---
 meta-crownbay/conf/machine/crownbay-noemgd.conf |2 +-
 meta-crownbay/conf/machine/crownbay.conf|2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-crownbay/conf/machine/crownbay-noemgd.conf 
b/meta-crownbay/conf/machine/crownbay-noemgd.conf
index af85b00..4c869ee 100644
--- a/meta-crownbay/conf/machine/crownbay-noemgd.conf
+++ b/meta-crownbay/conf/machine/crownbay-noemgd.conf
@@ -4,7 +4,7 @@
 #@DESCRIPTION: Machine configuration for Crown Bay systems, without 
Intel-proprietary graphics bits
 # i.e. E660 + EG20T
 
-PREFERRED_VERSION_linux-yocto ?= "3.2%"
+PREFERRED_VERSION_linux-yocto ?= "3.4%"
 
 require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
diff --git a/meta-crownbay/conf/machine/crownbay.conf 
b/meta-crownbay/conf/machine/crownbay.conf
index a39d037..7d5e597 100644
--- a/meta-crownbay/conf/machine/crownbay.conf
+++ b/meta-crownbay/conf/machine/crownbay.conf
@@ -4,7 +4,7 @@
 #@DESCRIPTION: Machine configuration for Crown Bay systems
 # i.e. E660 + EG20T
 
-PREFERRED_VERSION_linux-yocto ?= "3.2%"
+PREFERRED_VERSION_linux-yocto ?= "3.4%"
 
 require conf/machine/include/tune-atom.inc
 require conf/machine/include/ia32-base.inc
-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 3/4] crownbay: add recipe extension for linux-yocto-3.4

[nitin . a . kamble]

From: Nitin A Kamble 

Add emgd branch info in git src_uri

At build time, the emgd-1.14 branch is merged with the crownbay bsp
kernel source branch to get emgd kernel driver's support.
  Reference it in the src_uri, and its commit-id to be used, so that
any changes in the emgd branch will not affect build unknowingly.

Signed-off-by: Nitin A Kamble 
---
 .../recipes-kernel/linux/linux-yocto_3.4.bbappend  |   20 
 1 files changed, 20 insertions(+), 0 deletions(-)
 create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend

diff --git a/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend 
b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
new file mode 100644
index 000..4f9dd70
--- /dev/null
+++ b/meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend
@@ -0,0 +1,20 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+COMPATIBLE_MACHINE_crownbay = "crownbay"
+KMACHINE_crownbay  = "crownbay"
+KBRANCH_crownbay  = "standard/default/crownbay"
+
+COMPATIBLE_MACHINE_crownbay-noemgd = "crownbay-noemgd"
+KMACHINE_crownbay-noemgd  = "crownbay"
+KBRANCH_crownbay-noemgd  = "standard/crownbay"
+
+SRCREV_machine_pn-linux-yocto_crownbay ?= 
"19f7e43b54aef08d58135ed2a897d77b624b320a"
+SRCREV_meta_pn-linux-yocto_crownbay ?= 
"d7a96809a585e06933d8c08adb9b9f66b21efb4c"
+SRCREV_emgd_pn-linux-yocto_crownbay ?= 
"86643bdd8cbad616a161ab91f51108cf0da827bc"
+
+SRCREV_machine_pn-linux-yocto_crownbay-noemgd ?= 
"19f7e43b54aef08d58135ed2a897d77b624b320a"
+SRCREV_meta_pn-linux-yocto_crownbay-noemgd ?= 
"d7a96809a585e06933d8c08adb9b9f66b21efb4c"
+
+KSRC_linux_yocto_3_4 ?= "git.yoctoproject.org/linux-yocto-3.4.git"
+SRC_URI_crownbay = 
"git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta,emgd-1.14;name=machine,meta,emgd"
+SRC_URI_crownbay-noemgd = 
"git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 2/4] crownbay: customize the xorg.conf for the flat panel on the kit

[nitin . a . kamble]

From: Nitin A Kamble 

The kit has Auo 800x600 LCD screen. Configuring Xorg for it.

This change also sets the resolution on the external monitor as
800x600

Signed-off-by: Nitin A Kamble 
---
 .../xserver-xf86-config/crownbay/xorg.conf |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git 
a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
 
b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
index 662f60f..d71173c 100644
--- 
a/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
+++ 
b/meta-crownbay/recipes-graphics/xorg-xserver/xserver-xf86-config/crownbay/xorg.conf
@@ -4,12 +4,26 @@
 ## DriverVer=
 ##
 
+# AUO G084SN05 V8 lcd flat panel
+Section "Monitor"
+Identifier "Monitor0"
+VendorName "Auo"
+#HorizSync   33.6 - 48.3
+#VertRefresh 60.0 - 60.0
+Option "DPMS"
+EndSection
+
 Section "Screen"
 Identifier"Screen0"
 Device"IntelEMGD-0"
 Monitor   "Monitor0"
+
+# for the AUO flat screen
 SubSection"Display"
+Depth  24
+Modes  "800x600"
 EndSubSection
+
 EndSection
 
 # Primary (First/only) display
-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 1/4] emgd-driver-bin: upgrade from 1.10 to 1.14

[nitin . a . kamble]

From: Nitin A Kamble 

1.14 is the latest released driver for emgd. This change is tested on
crownbay machine.

Add runtime dependency to libxcb-dri2

Otherwise the libxcb-dri2.so is not getting installed, and video
acceleration of emgd does not work. It is dynamic dependency of
emgd_drv_video.so

put files in gstreamer-0.10/.debug directory to the debug package.
It avoids debug files packaging warnings.

add downloadfilename param to SRC_URI

As the url does not have the filename of the tarball, specify it here
so that updated wget bitbake fetcher can save the downloaded file
accordingly.
BTW now EDC has also published another download URL on our request:
http://edc.intel.com/App_Shared/Downloads/LIN_IEMGD_1_14_GOLD_2443.tgz

And update emgd driver version in the README.

Signed-off-by: Nitin A Kamble 
---
 ...-driver-bin_1.10.bb => emgd-driver-bin_1.14.bb} |   17 +
 meta-crownbay/README   |8 
 2 files changed, 13 insertions(+), 12 deletions(-)
 rename common/recipes-graphics/xorg-xserver/{emgd-driver-bin_1.10.bb => 
emgd-driver-bin_1.14.bb} (88%)

diff --git a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb 
b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
similarity index 88%
rename from common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
rename to common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
index 5779e5d..b1ba1b8 100644
--- a/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.10.bb
+++ b/common/recipes-graphics/xorg-xserver/emgd-driver-bin_1.14.bb
@@ -1,9 +1,9 @@
-SUMMARY = "EMGD 1.10 xserver binaries"
-DESCRIPTION = "EMGD 1.10 includes some userspace binaries that use non-free \
+SUMMARY = "EMGD 1.14 xserver binaries"
+DESCRIPTION = "EMGD 1.14 includes some userspace binaries that use non-free \
 licensing, which are now available via a non-click-through downloadable \
 tarball, and is what this recipe now uses.  Since it is a non-free license, \
-this recipe is marked as 'License_emgd-driver-bin_1.10' and you need to add \
-to LICENSE_FLAGS_WHITELIST += \"License_emgd-driver-bin_1.10\" to your \
+this recipe is marked as 'License_emgd-driver-bin_1.14' and you need to add \
+to LICENSE_FLAGS_WHITELIST += \"License_emgd-driver-bin_1.14\" to your \
 local.conf in order to enable it in a build."
 LICENSE = "Intel-binary-only"
 LICENSE_FLAGS = "license_${PN}_${PV}"
@@ -16,17 +16,18 @@ EMGD_VIDEO_PLUGIN_DIR = "../common/video_plugin"
 LIC_FILES_CHKSUM = 
"file://${WORKDIR}/${EMGD_LIC_DIR}/License.txt;md5=b54f01caaf8483b3cb60c0c40f2bf22d"
 
 DEPENDS = "rpm-native xz-native"
+RDEPENDS = "libxcb-dri2"
 
-SRC_URI = 
"https://edc.intel.com/App_Shared/Downloads/LIN_EMGD_1_10_RC_2209.tgz";
+SRC_URI = 
"https://edc.intel.com/Download.aspx?id=6190;downloadfilename=LIN_IEMGD_1_14_GOLD_2443.tgz";
 
-SRC_URI[md5sum] = "e4a38d9efa0b086ae21b68145c4db4e9"
-SRC_URI[sha256sum] = 
"acea5f0f93a31553553428623c007d7ed0c604cf715fd87dfe075751da4be548"
+SRC_URI[md5sum] = "733a7f237ffce21238ce2c9956df4fd6"
+SRC_URI[sha256sum] = 
"bcdc333b5edbda7c746a83ef821ded4a0ca55ead30980e4e3680cdb6469f45a2"
 
 # These are closed binaries generated elsewhere so don't check ldflags
 INSANE_SKIP_${PN} = "ldflags"
 
 FILES_${PN} += "${libdir}/dri ${libdir}/gstreamer-0.10 
${libdir}/xorg/modules/drivers"
-FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug ${libdir}/dri/.debug"
+FILES_${PN}-dbg += "${libdir}/xorg/modules/drivers/.debug ${libdir}/dri/.debug 
${libdir}/gstreamer-0.10/.debug"
 
 S = "${WORKDIR}/${EMGD_RPM_DIR}"
 
diff --git a/meta-crownbay/README b/meta-crownbay/README
index b56c79a..2521432 100644
--- a/meta-crownbay/README
+++ b/meta-crownbay/README
@@ -6,7 +6,7 @@ The Crown Bay platform consists of the Intel Atom Z6xx 
processor,
 plus the Intel EG20T Platform Controller Hub (Tunnel Creek + Topcliff).
 
 It also supports the E6xx embedded on-chip graphics via the Intel
-Embedded Media and Graphics Driver (EMGD) 1.10 Driver.
+Embedded Media and Graphics Driver (EMGD) 1.14 Driver.
 
 
 Dependencies
@@ -63,7 +63,7 @@ common metadata shared between BSPs) e.g.:
 The meta-crownbay layer contains support for two different machine
 configurations. These configurations are identical except for the fact
 that the one prefixed with 'crownbay' makes use of the
-Intel-proprietary EMGD 1.10 graphics driver, while the one prefixed
+Intel-proprietary EMGD 1.14 graphics driver, while the one prefixed
 with 'crownbay-noemgd' does not.
 
 If you want to enable the layer that supports EMGD graphics add the
@@ -73,10 +73,10 @@ following to the local.conf file:
 
 The 'crownbay' machine includes the emgd-driver-bin package, which has
 a proprietary license that must be whitelisted by adding the string
-"license_emgd-driver-bin_1.10" to the LICENSE_FLAGS_WHITELIST variable
+"license_emgd-driver-bin_1.14" to the LICENSE_FLAGS_WHITELIST variable
 in your local.conf.  For example:
 
-  LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10

[yocto] [PATCH 0/4] update emgd driver recipe and yocto-kernel for crownbay BSP

[nitin . a . kamble]

From: Nitin A Kamble 

The following changes since commit 7bd163e41f6b861448ab19a13ded4b7c48e16641:

  gnu-efi_3.0m.bb: Fix tabs with spaces in python snippet (2012-07-27 11:41:17 
-0700)

are available in the git repository at:
  git://git.yoctoproject.org/meta-intel-contrib nitin/work
  http://git.yoctoproject.org/cgit.cgi/meta-intel-contrib/log/?h=nitin/work

Nitin A Kamble (4):
  emgd-driver-bin: upgrade from 1.10 to 1.14
  crownbay: customize the xorg.conf for the flat panel on the kit
  crownbay: add recipe extension for linux-yocto-3.4
  crownbay: make v3.4 the default kernel

 ...-driver-bin_1.10.bb => emgd-driver-bin_1.14.bb} |   17 +
 meta-crownbay/README   |8 
 meta-crownbay/conf/machine/crownbay-noemgd.conf|2 +-
 meta-crownbay/conf/machine/crownbay.conf   |2 +-
 .../xserver-xf86-config/crownbay/xorg.conf |   14 ++
 .../recipes-kernel/linux/linux-yocto_3.4.bbappend  |   20 
 6 files changed, 49 insertions(+), 14 deletions(-)
 rename common/recipes-graphics/xorg-xserver/{emgd-driver-bin_1.10.bb => 
emgd-driver-bin_1.14.bb} (88%)
 create mode 100644 meta-crownbay/recipes-kernel/linux/linux-yocto_3.4.bbappend

-- 
1.7.3.4

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 09:19 AM, Martin Jansa wrote:

On Mon, Jul 30, 2012 at 09:06:23AM -0400, Jim Abernathy wrote:

On 07/30/2012 09:00 AM, Martin Jansa wrote:

On Mon, Jul 30, 2012 at 08:53:50AM -0400, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine
"pandaboard". Besides the basics, I put in a license statement for
cloud9 into local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
 /home/jim/poky/meta \
 /home/jim/poky/meta-yocto \
 /home/jim/meta-openembedded/meta-oe \
 /home/jim/meta-ti \
 "

The error I'm getting is:

ERROR: ParseError at
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not
inherit file classes/systemd.bbclass

add meta-openembedded/meta-systemd to your BBLAYERS


When I do that I get the errors:

ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
ERROR: Command execution failed: Exited with 1

Add BB_DANGLINGAPPENDS_WARNONLY to
meta-openembedded/meta-systemd/conf/layer.conf
BB_DANDLINGAPPENDS_WARNONLY = "yes"  seems to have gotten me past the 
build errors for now.


I'll look at the BBMASK some more since it looks cleaner to just modify 
the local.conf file.


Jim A


or add meta-gnome/meta-efl layers if you would use them..

Cheers,


Jim A

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Gary Thomas]

On 2012-07-30 07:48, Jim Abernathy wrote:

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for cloud9 into 
local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: 
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"


BBMASK by itself didn't solve my particular problem.  I'll try the other 
suggestions and report back.


What other problem do you have?  That BBMASK should keep bitbake from
trying to parse the recipe mentioned above.

Note: I use these layers with Yocto all the time with that mask...

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 09:15 AM, Gary Thomas wrote:

On 2012-07-30 06:53, Jim Abernathy wrote:
I'm on master branch trying to build core-image-minimal for the 
machine "pandaboard". Besides the basics, I put in a license 
statement for cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not 
inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

BBMASK by itself didn't solve my particular problem.  I'll try the other 
suggestions and report back.


Jim A

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Martin Jansa]

On Mon, Jul 30, 2012 at 03:19:30PM +0200, Martin Jansa wrote:
> On Mon, Jul 30, 2012 at 09:06:23AM -0400, Jim Abernathy wrote:
> > On 07/30/2012 09:00 AM, Martin Jansa wrote:
> > > On Mon, Jul 30, 2012 at 08:53:50AM -0400, Jim Abernathy wrote:
> > >> I'm on master branch trying to build core-image-minimal for the machine
> > >> "pandaboard". Besides the basics, I put in a license statement for
> > >> cloud9 into local.conf.
> > >>
> > >> My bblayer.conf is as follows:
> > >>
> > >> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> > >> # changes incompatibly
> > >> LCONF_VERSION = "5"
> > >>
> > >> BBPATH = "${TOPDIR}"
> > >> BBFILES ?= ""
> > >>
> > >> BBLAYERS ?= " \
> > >> /home/jim/poky/meta \
> > >> /home/jim/poky/meta-yocto \
> > >> /home/jim/meta-openembedded/meta-oe \
> > >> /home/jim/meta-ti \
> > >> "
> > >>
> > >> The error I'm getting is:
> > >>
> > >> ERROR: ParseError at
> > >> /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not
> > >> inherit file classes/systemd.bbclass
> > > add meta-openembedded/meta-systemd to your BBLAYERS
> > >
> > When I do that I get the errors:
> > 
> > ERROR: No recipes available for:
> > /home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
> > /home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
> > ERROR: Command execution failed: Exited with 1
> 
> Add BB_DANGLINGAPPENDS_WARNONLY to
> meta-openembedded/meta-systemd/conf/layer.conf
> 
> or add meta-gnome/meta-efl layers if you would use them..

Or better BBMASK those meta-gnome/meta-efl subdirectories like
meta-systemd/README suggests:

To make BBMASK'ing per layer possible the following directory structure
is used:

$[LAYERDIR}//recipes-//.bbappend

Cheers,

> 
> Cheers,
> 
> > 
> > Jim A
> > >> Build Configuration:
> > >> BB_VERSION= "1.15.3"
> > >> TARGET_ARCH   = "arm"
> > >> TARGET_OS = "linux-gnueabi"
> > >> MACHINE   = "pandaboard"
> > >> DISTRO= "poky"
> > >> DISTRO_VERSION= "1.2+snapshot-20120730"
> > >> TUNE_FEATURES = "armv7a vfp neon cortexa9"
> > >> TARGET_FPU= "vfp-neon"
> > >> meta
> > >> meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
> > >> meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
> > >> meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"
> > >>
> > >> ERROR: Nothing PROVIDES 'pseudo-native'
> > >>
> > >>
> > >>
> > >> ___
> > >> yocto mailing list
> > >> yocto@yoctoproject.org
> > >> https://lists.yoctoproject.org/listinfo/yocto
> > 
> 
> -- 
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com



-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Martin Jansa]

On Mon, Jul 30, 2012 at 09:06:23AM -0400, Jim Abernathy wrote:
> On 07/30/2012 09:00 AM, Martin Jansa wrote:
> > On Mon, Jul 30, 2012 at 08:53:50AM -0400, Jim Abernathy wrote:
> >> I'm on master branch trying to build core-image-minimal for the machine
> >> "pandaboard". Besides the basics, I put in a license statement for
> >> cloud9 into local.conf.
> >>
> >> My bblayer.conf is as follows:
> >>
> >> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> >> # changes incompatibly
> >> LCONF_VERSION = "5"
> >>
> >> BBPATH = "${TOPDIR}"
> >> BBFILES ?= ""
> >>
> >> BBLAYERS ?= " \
> >> /home/jim/poky/meta \
> >> /home/jim/poky/meta-yocto \
> >> /home/jim/meta-openembedded/meta-oe \
> >> /home/jim/meta-ti \
> >> "
> >>
> >> The error I'm getting is:
> >>
> >> ERROR: ParseError at
> >> /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not
> >> inherit file classes/systemd.bbclass
> > add meta-openembedded/meta-systemd to your BBLAYERS
> >
> When I do that I get the errors:
> 
> ERROR: No recipes available for:
> /home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
> /home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
> ERROR: Command execution failed: Exited with 1

Add BB_DANGLINGAPPENDS_WARNONLY to
meta-openembedded/meta-systemd/conf/layer.conf

or add meta-gnome/meta-efl layers if you would use them..

Cheers,

> 
> Jim A
> >> Build Configuration:
> >> BB_VERSION= "1.15.3"
> >> TARGET_ARCH   = "arm"
> >> TARGET_OS = "linux-gnueabi"
> >> MACHINE   = "pandaboard"
> >> DISTRO= "poky"
> >> DISTRO_VERSION= "1.2+snapshot-20120730"
> >> TUNE_FEATURES = "armv7a vfp neon cortexa9"
> >> TARGET_FPU= "vfp-neon"
> >> meta
> >> meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
> >> meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
> >> meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"
> >>
> >> ERROR: Nothing PROVIDES 'pseudo-native'
> >>
> >>
> >>
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> 

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Delete unused hob images

[Giovanni Foiani]

Hi,

I read this section in Poky Reference manual:

*A.2.13. build/tmp/deploy/images/*
*
*
*This directory receives complete filesystem images. If you want to flash
the resulting image from a build onto a device, look here for the image.*
*
*
*Note, you should not remove any files from this directory by hand in an
attempt to rebuild an image. If you want to clean out the cache, re-run the
build using the following BitBake command: *
* $ bitbake -c cleanall *

I built many images using hob and in my *build/tmp/deploy/images/ *folder
there are a lot of rootfs images (like
hob-image-imx53qsb-.rootfs.ext3 etc..) and I want to remove the
unused ones to free some space..

I tried tp run:

*bitbake -c cleanall * hob-image-imx53qsb-

but I got:
ERROR: Nothing PROVIDES 'hob-image-imx53qsb-'

Can I safely remove these files by hand?

thanks

Giovanni
--

Dott. Ing. Giovanni Foiani

Cell:+39-349-3577515
Phone:+39-0532-97-4106
mail:giovanni.foi...@unife.it
CenTec - Corso Guercino, 47 - 44042 Cento (FE)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Gary Thomas]

On 2012-07-30 06:53, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for cloud9 into 
local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
   /home/jim/poky/meta \
   /home/jim/poky/meta-yocto \
   /home/jim/meta-openembedded/meta-oe \
   /home/jim/meta-ti \
   "

The error I'm getting is:

ERROR: ParseError at /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: 
Could not inherit file classes/systemd.bbclass

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'


Try adding this in local.conf:
  BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor)/"

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Jim Abernathy]

On 07/30/2012 09:00 AM, Martin Jansa wrote:

On Mon, Jul 30, 2012 at 08:53:50AM -0400, Jim Abernathy wrote:

I'm on master branch trying to build core-image-minimal for the machine
"pandaboard". Besides the basics, I put in a license statement for
cloud9 into local.conf.

My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/home/jim/poky/meta \
/home/jim/poky/meta-yocto \
/home/jim/meta-openembedded/meta-oe \
/home/jim/meta-ti \
"

The error I'm getting is:

ERROR: ParseError at
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not
inherit file classes/systemd.bbclass

add meta-openembedded/meta-systemd to your BBLAYERS


When I do that I get the errors:

ERROR: No recipes available for:
/home/jim/meta-openembedded/meta-systemd/meta-gnome/recipes-gnome/gdm/gdm_2.32.2.bbappend
/home/jim/meta-openembedded/meta-systemd/meta-efl/recipes-efl/efl/elsa_svn.bbappend
ERROR: Command execution failed: Exited with 1

Jim A

Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] build error pandaboard on master

[Martin Jansa]

On Mon, Jul 30, 2012 at 08:53:50AM -0400, Jim Abernathy wrote:
> I'm on master branch trying to build core-image-minimal for the machine 
> "pandaboard". Besides the basics, I put in a license statement for 
> cloud9 into local.conf.
> 
> My bblayer.conf is as follows:
> 
> # LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> LCONF_VERSION = "5"
> 
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
> 
> BBLAYERS ?= " \
>/home/jim/poky/meta \
>/home/jim/poky/meta-yocto \
>/home/jim/meta-openembedded/meta-oe \
>/home/jim/meta-ti \
>"
> 
> The error I'm getting is:
> 
> ERROR: ParseError at 
> /home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not 
> inherit file classes/systemd.bbclass

add meta-openembedded/meta-systemd to your BBLAYERS

> Build Configuration:
> BB_VERSION= "1.15.3"
> TARGET_ARCH   = "arm"
> TARGET_OS = "linux-gnueabi"
> MACHINE   = "pandaboard"
> DISTRO= "poky"
> DISTRO_VERSION= "1.2+snapshot-20120730"
> TUNE_FEATURES = "armv7a vfp neon cortexa9"
> TARGET_FPU= "vfp-neon"
> meta
> meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
> meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
> meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"
> 
> ERROR: Nothing PROVIDES 'pseudo-native'
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] denzil kernel build issues

[Bruce Ashfield]

On Mon, Jul 30, 2012 at 7:33 AM, Frans Meulenbroeks
 wrote:
> Dear all,
>
> I finally managed to find time to pick up porting my project to denzil and
> did encounter two issues that I wanted to report back:
>
> First is that I could not find what the preferred way was to disable a
> kernel option in my bsp.
> (the option concerned is CONFIG_PM).
> Of course I can sed it out in do_configure but I'd hoped it could be simpler
> (I have tried:
> CONFIG_PM=n
> in my config snippet)

Putting:

# CONFIG_PM is not set

in your configuration fragment will turn off an option, the BSP guide has a
"# CONFIG_SMP is not set" as an example for this.

>
> Secondly a patch of mine does not seem to apply properly the first time, but
> it does apply a second time.
> This suggests a race between do_kernel_checkout and do_patch

There shouldn't be any race ..  if this doesn't work:

   addtask kernel_checkout before do_patch after do_unpack

Then there are some serious problems with bitbake's task scheduling.

If you didn't do a clean between the two runs, the second is
attempting to continue
the patching and you still aren't getting what you want.

Without seeing what you've ported, or a work in progress I can't say exactly
what is wrong, but your meta data is somehow wrong or completely missing.
Have you set any meta or BSP SRCREVs explicitly ?

Cheers,

Bruce

>
> Below is a log that illustrates this and demonstrates that things are ok the
> 2nd time.
> (btw I am also a little bit concerned on the command not found messages).
> And of course any sugguestion for a fix is greatly appreciated.
>
> Best regards, Frans
>
> frans@frans-desktop:~/poky-denzil-7.0-build$ bitbake virtual/kernel
> Parsing recipes: 100%
> |##|
> Time: 00:00:30
> Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105 targets, 35
> skipped, 0 masked, 0 errors.
>
> OE Build Configuration:
> BB_VERSION= "1.15.1"
> TARGET_ARCH   = "powerpc"
> TARGET_OS = "linux-uclibc"
> MACHINE   = "syrcxx"
> DISTRO= "poky"
> DISTRO_VERSION= "1.2"
> TUNE_FEATURES = "m32 fpu-hard ppce300c3"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-syrcxx   = ":"
>
> NOTE: Resolving any missing task queue dependencies
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 162 of 664 (ID: 6,
> /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
> do_fetch)
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_fetch: Started
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_fetch: Succeeded
> NOTE: Running task 644 of 664 (ID: 2,
> /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
> do_unpack)
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_unpack: Started
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_unpack: Succeeded
> NOTE: Running task 645 of 664 (ID: 1,
> /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
> do_kernel_checkout)
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_kernel_checkout: Started
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_kernel_checkout: Succeeded
> NOTE: Running task 646 of 664 (ID: 0,
> /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
> do_validate_branches)
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_validate_branches: Started
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_validate_branches: Succeeded
> NOTE: Running task 647 of 664 (ID: 3,
> /home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
> do_patch)
> NOTE: package
> linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
> task do_patch: Started
> ERROR: Function failed: do_patch (see
> /home/frans/poky-denzil-7.0-build/tmp/work/syrcxx-poky-linux-uclibc/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81/temp/log.do_patch.27211
> for further information)
> ERROR: Logfile of failure stored in:
> /home/frans/poky-denzil-7.0-build/tmp/work/syrcxx-poky-linux-uclibc/linux-yocto-3.2.11+git1+

[yocto] build error pandaboard on master

[Jim Abernathy]

I'm on master branch trying to build core-image-minimal for the machine 
"pandaboard". Besides the basics, I put in a license statement for 
cloud9 into local.conf.


My bblayer.conf is as follows:

# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "5"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /home/jim/poky/meta \
  /home/jim/poky/meta-yocto \
  /home/jim/meta-openembedded/meta-oe \
  /home/jim/meta-ti \
  "

The error I'm getting is:

ERROR: ParseError at 
/home/jim/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not 
inherit file classes/systemd.bbclass


Build Configuration:
BB_VERSION= "1.15.3"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "pandaboard"
DISTRO= "poky"
DISTRO_VERSION= "1.2+snapshot-20120730"
TUNE_FEATURES = "armv7a vfp neon cortexa9"
TARGET_FPU= "vfp-neon"
meta
meta-yocto= "master:7411158e1f980cd71c432026fa2f68ab80e3541e"
meta-oe   = "master:9afc488a1b97bfc5378f139ba04a7a5297b15fdb"
meta-ti   = "master:9bc77dff5f84578e259f8225bfa0656d94a2a60a"

ERROR: Nothing PROVIDES 'pseudo-native'



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] denzil kernel build issues

[Frans Meulenbroeks]

Dear all,

I finally managed to find time to pick up porting my project to denzil and
did encounter two issues that I wanted to report back:

First is that I could not find what the preferred way was to disable a
kernel option in my bsp.
(the option concerned is CONFIG_PM).
Of course I can sed it out in do_configure but I'd hoped it could be simpler
(I have tried:
CONFIG_PM=n
in my config snippet)

Secondly a patch of mine does not seem to apply properly the first time,
but it does apply a second time.
This suggests a race between do_kernel_checkout and do_patch

Below is a log that illustrates this and demonstrates that things are ok
the 2nd time.
(btw I am also a little bit concerned on the command not found messages).
And of course any sugguestion for a fix is greatly appreciated.

Best regards, Frans

frans@frans-desktop:~/poky-denzil-7.0-build$ bitbake virtual/kernel
Parsing recipes: 100%
|##|
Time: 00:00:30
Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105 targets, 35
skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION= "1.15.1"
TARGET_ARCH   = "powerpc"
TARGET_OS = "linux-uclibc"
MACHINE   = "syrcxx"
DISTRO= "poky"
DISTRO_VERSION= "1.2"
TUNE_FEATURES = "m32 fpu-hard ppce300c3"
TARGET_FPU= ""
meta
meta-yocto
meta-syrcxx   = ":"

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 162 of 664 (ID: 6,
/home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_fetch)
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_fetch: Started
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_fetch: Succeeded
NOTE: Running task 644 of 664 (ID: 2,
/home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_unpack)
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_unpack: Started
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_unpack: Succeeded
NOTE: Running task 645 of 664 (ID: 1,
/home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_kernel_checkout)
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_kernel_checkout: Started
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_kernel_checkout: Succeeded
NOTE: Running task 646 of 664 (ID: 0,
/home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_validate_branches)
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_validate_branches: Started
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_validate_branches: Succeeded
NOTE: Running task 647 of 664 (ID: 3,
/home/frans/poky-denzil-7.0/meta/recipes-kernel/linux/linux-yocto_3.2.bb,
do_patch)
NOTE: package
linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81:
task do_patch: Started
ERROR: Function failed: do_patch (see
/home/frans/poky-denzil-7.0-build/tmp/work/syrcxx-poky-linux-uclibc/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81/temp/log.do_patch.27211
for further information)
ERROR: Logfile of failure stored in:
/home/frans/poky-denzil-7.0-build/tmp/work/syrcxx-poky-linux-uclibc/linux-yocto-3.2.11+git1+b14a08f5c7b469a5077c10942f4e1aec171faa9d_1+01e948c2bdf7f5ad9f2b30047a8d3493a1a2880a-r1.81/temp/log.do_patch.27211
Log data follows:
| Branch meta-temp set up to track remote branch meta from origin.
| Deleted branch meta-temp (was 3499d64).
| warning: could not find (or was already included):
cfg/dmaengine/dmaengine.scc
| warning: could not find (or was already included):
cfg/usb-mass-storage.scc
| warning: could not find (or was already included): cfg/vfat.scc
| warning: could not find (or was already included):
cfg/dmaengine/dmaengine.scc
| warning: could not find (or was already included): user-patches.scc
| ./2-syrcxx-215ef69425ed902858630c959dabd5ce.sco: line 21:
dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found
| ./2-syrcxx-215ef69425ed902858630c959dabd5ce.sco: line 21:
dmaengine_68b329da9893e34099c7d8ad5cb9c940: command not found
| [INFO] validating against known patches  (syrcxx-fsl-mpc8313e-rdb-meta)
Branch standard

[yocto] Availability for GTK Hob work

[Barros Pena, Belen]

Hi all,

Just wanted to let you know that I will not be available for Hob-related
work between July 30th and August 17th. I should be available again from
August 20th, hopefully full time until the new release.

If there are any urgent design issues, feel free to contact me, but it
might take a little time to respond.

Cheers

Belen

-
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the flat panel on the corwnbay kit

[Kamble, Nitin A]

> -Original Message-
> From: Darren Hart [mailto:dvh...@linux.intel.com]
> Sent: Saturday, July 28, 2012 3:27 AM
> To: Kamble, Nitin A
> Cc: yocto@yoctoproject.org; bruce.ashfi...@windriver.com; Zanussi, Tom
> Subject: Re: [yocto] [PATCH 2/6] crownbay: customize the xorg.conf for the
> flat panel on the corwnbay kit
> 
> 
> 
> On 07/26/2012 10:31 PM, Kamble, Nitin A wrote:
>  On 07/23/2012 03:06 AM, nitin.a.kam...@intel.com wrote:
> > From: Nitin A Kamble 
> >
> > The kit has Auo 800x600 LCD screen. Configuring Xorg for it.
> 
>  I presume the crownbay has additional display options? how does
>  this impact those?
> 
> >>> This change sets the resolution of the screen to 800x600. And this
> >>> is applicable to LCD screen on the kit as well as external monitor.
> >>> I will add a note about it in the log.
> >>
> >> I presume that without this change it was able to detect the
> >> appropriate resolution of the connected monitor, but not of the LCD?
> >>
> >> If so, this change effectively breaks that autodetection and forces
> >> everything to the 800x600 display which is arguably very
> >> low-resolution by today's standards. Why should this be the default?
> >> When you refer to "the kit", what exactly are you referring to?
> >>
> >> Also, is this a discussion you have already had with Tom? I don't
> >> want to contradict what he has said regarding this BSP.
> >
> >
> > EMGD driver on crownbay gives few resolutions as options. By default
> > it tries to set 1366x768 resolution for both LCD and external monitor.
> > The Crownbay kit is a suitcase kind of box, which has builtin LCD
> > screen of resolution 800x600. This LCD screen shows only
> > 800x600 of the default 1366x768 area. So The LCD is not able to show
> > all the screen, and IMO it is a functional issue.
> >
> > For my Dell 1704FPTi monitor which has 1280x1024 native resolution;
> > When connected to the crownbay,  X cannot find a working mode for this
> > monitor. But if I set 800x600 in the xorg.conf as this commit does,
> > then both LCD & external monitor can show the X screen without any
> > issues.
> 
> This seems like a bug to me. The driver should be able to probe the display
> and use the optimal resolution without it being specified in the Xorg.conf. So
> far as I know we don't specify resolution in any of the meta-intel BSPs:
> 
> dvhart@envy:~/source/poky/layers/meta-intel [denzil] $ find . -name
> xorg.conf | xargs grep -i Modes
> 
> So while I agree the kit screen should work out of the box, the fact that even
> your dell lcd monitor doesn't work is cause for concern. Is there anything in
> the Xorg log that indicates why it isn't able to get the EDID data?
> 
> --
> Darren
> 

In the xorg log I do not see any useful EDID information. Either these displays 
do not support EDID, or the EDID support in the EMGD driver is not working well 
with these devices. And the EMGD driver is closed source. So we can't fix it. 
So IMO keeping the resolution to 800x600 is the best possible solution for 
crownbay BSP.

Nitin



___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Usb-serial device support

[Giovanni Foiani]

Hi,

I built a distribution for iMX53 QSB with kernel 2.6.35-3 and I need
support for USB-serial devices.
When I plug the usb-serial converter I get this error..

*usb wakeup is here

*
*otg host Remote wakeup

 *
*usb 1-1: new full speed USB device using fsl-ehci and address 3

  *
*usb 1-1: device v067b p2303 is not supported *

I tried to recompile linux-imx kernel adding support for USB-serial
devices, I run:

   - bibake linux-imx -c menuconfig
   - added support for usb-serial devices in menuconfig
   - bitbake -f -c compile linux-imx
   - bitbake linux-imx

..but it didn't work..

Any suggestions?

Thanks

Giovanni
--

Dott. Ing. Giovanni Foiani

Cell:+39-349-3577515
Phone:+39-0532-97-4106
mail:giovanni.foi...@unife.it
CenTec - Corso Guercino, 47 - 44042 Cento (FE)
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [HOB / OMAP4430] error message without any explanation

[Tim Verstraete]

Hi,

I am running Ubuntu 12.04 LTS 64bit and on this the denzil release of Yocto 
with the meta-ti from the Yocto repository. All have been from the denzil 
release branch. Below you can find the settings files: local.conf and 
BBLAYERS.conf that I used for HOB. 

What I get is an error message that has no explanation or header or title name 
except for blank + close button. Where can I see which recipe is giving me the 
error?

I can run a core-minimal image though from command line.

Thanks in advance,

Kind regards,

Tim

BBLAYERS.conf:
# LAYER_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
LCONF_VERSION = "4"

BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + 
'/../..')}"

BBFILES ?= ""
BBLAYERS ?= " \
${BSPDIR}/poky-denzil-7.0.1/meta \
${BSPDIR}/poky-denzil-7.0.1/meta-yocto \
${BSPDIR}/poky-denzil-7.0.1/meta-ti \
"

LOCAL.conf:
#
# This file is your local configuration file and is where all local user 
settings
# are placed. The comments in this file give some guide to the options a new 
user
# to the system might want to change but pretty much any configuration option 
can
# be set in this file. More adventurous users can look at local.conf.extended 
# which contains other examples of configuration which can be placed in this 
file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases the 
# default values are provided as comments to show people example syntax. 
Enabling
# the option is a question of removing the # character and making any change to 
the
# variable as required.

#
# Parallelism Options
#
# These two options control how much parallelism BitBake should use. The first 
# option determines how many tasks bitbake should run in parallel:
#
BB_NUMBER_THREADS = "4"
# 
# The second option controls how many processes make should run in parallel when
# running compile tasks:
#
PARALLEL_MAKE = "-j 4"
#
# For a quad-core machine, BB_NUMBER_THREADS = "4", PARALLEL_MAKE = "-j 4" would
# be appropriate for example.

#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a 
selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
#MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for 
# demonstration purposes:
#
#MACHINE ?= "atom-pc"
#MACHINE ?= "beagleboard"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "routerstationpro"
#
# This sets the default machine to be qemux86 if no other machine is selected:
#MACHINE ?= "qemux86"
MACHINE ?= "pandaboard"

#
# Where to place downloads
#
# During a first build the system will download many different source code 
tarballs
# from various upstream projects. This can take a while, particularly if your 
network
# connection is slow. These are all stored in DL_DIR. When wiping and 
rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This 
directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build 
directory.
#
DLROOT_DIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) + 
'/../..')}"
DL_DIR ?= "${DLROOT_DIR}/yocto_sources"

#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built 
output.
# This is done using "shared state" files which can be thought of as cache 
objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would 
regenerate
# from these files if no changes were made to the configuration. If changes 
were made
# to the configuration, only shared state files where the state was still valid 
would
# be used (done using checksums).
#
# The default is a sstate-cache directory under TOPDIR.
#
#SSTATE_DIR ?= "${TOPDIR}/sstate-cache"

#
# Where to place the build output
#
# This option specifies where the bulk of the building work should be done and
# where BitBake should place its temporary files and output. Keep in mind that
# this includes the extraction and compilation of many applications and the 
toolchain
# which can use Gigabytes of hard disk space.
#
# The default is a tmp directory under TOPDIR.
#
#TMPDIR = "${TOPDIR}/tmp"

#
# Default policy config
#
# The distribution setting controls which policy settings are used as defaults.
# The default value is fine for general Yocto project use, at least initially.
# Ultimately when creating custom policy, people will likely end up subclassing 
# these defaults.
#
DISTRO ?= "poky"
# As an example of a subclass there is a "bleeding" edge policy configuration
# where many versions are set to the absolute latest code from the upstream 
# source control systems.

Re: [yocto] [SPAM] - Re: [HOB / i.MX6] unable to parse %s - Number of numbers in MIME From exceeds maximum threshold

[Tim Verstraete]

So indeed I have been able to get the HOB working on i.MX by getting the denzil 
release for the OE meta package.

Thanks for the feedback,

Kind regards,

Tim

-Original Message-
From: McClintock Matthew-B29882 [mailto:b29...@freescale.com] 
Sent: maandag 23 juli 2012 16:47
To: Tim Verstraete
Cc: yocto@yoctoproject.org
Subject: [SPAM] - Re: [yocto] [HOB / i.MX6] unable to parse %s - Number of 
numbers in MIME From exceeds maximum threshold

On Mon, Jul 23, 2012 at 4:08 AM, Tim Verstraete 
 wrote:
> Hi,
>
>
>
> I have installed yocto and downloaded meta-fsl-arm and 
> meta-openembedded. I started HOB, added those layers and when I select 
> imx6sabrelite target, HOB starts to parse the recipes but then stops and 
> gives following error:
> "error: unable to parse %s"
>
>
>
> What does this error message mean and what can I do about it ...

Are you using master or the last release denzil? Can you paste the entire log 
(if there was text)?

-M

>
>
>
> Thanks in advance,
>
>
>
> Kind regards,
>
>
>
> Tim
>
>
>
> BTW I am currently running Ubuntu 12.04 LTS 64bit but I also had this 
> on Ubuntu 10.04 LTS 64bit.
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto