[yocto] where to put IMAGE_INSTALL??

2012-01-12 Thread Jim Abernathy 
There seems to be some sensitivity to where I put the statement 
IMAGE_INSTALL += web-webkit.


At first I just modifed the meta/receipes-sato/image/core-image-sato.bb 
file to include it.  That caused the webkit to be built.


Since that is not an ideal location, I removed it and put it into the 
local.conf file.  That also caused the webkit to be built, but I wanted 
it to be part of my BSP permanently.


I thought about creating a core-image-sato.bbappend file with the 
IMAGE_INSTALL += web-webkit in it and put that into the BSP, but that 
didn't cause the webkit to be built. Under the meta-intel/meta-n450 
directory, I created a receipes-jfa directory and put the 
core-image-sato.bbappend file there.


I must be missing a key rule about directory parsing and .bbappend files.

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

Re: [yocto] where to put IMAGE_INSTALL??

2012-01-12 Thread Gary Thomas 

On 2012-01-12 05:53, Jim Abernathy wrote:

There seems to be some sensitivity to where I put the statement IMAGE_INSTALL += 
web-webkit.

At first I just modifed the meta/receipes-sato/image/core-image-sato.bb file to 
include it. That caused the webkit to be built.

Since that is not an ideal location, I removed it and put it into the 
local.conf file. That also caused the webkit to be built, but I wanted it to be 
part of my BSP permanently.

I thought about creating a core-image-sato.bbappend file with the IMAGE_INSTALL += 
web-webkit in it and put that into the BSP, but that didn't cause the webkit 
to be built. Under
the meta-intel/meta-n450 directory, I created a receipes-jfa directory and put 
the core-image-sato.bbappend file there.

I must be missing a key rule about directory parsing and .bbappend files.


Look at the how the layers are parsed - this info is in layer/conf/layer.conf

Try putting your .bbappend file in
   .../meta-intel/meta-n450/recipes-jfa/images/core-image-sato.bbappend

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Request to enable SMP and virtio for qemux86/x86-64

2012-01-12 Thread Zhai, Edwin 

Bruce,
Thanks for your efforts!

Edwin

On 2012/1/11 20:43, Bruce Ashfield wrote:

On 12-01-11 02:01 AM, Zhai, Edwin wrote:

Bruce,
Can we enable SMP and virtio by default for qemux86/x86-64? This can
achieve
huge perf boost for workload inside qemu. E.g. we enabled self-hosted
image,
where we build yocto inside qemu.

Attached patch showes the kernel config option.

Is it reasonable?


It should be. I just need to look at the fallback modes, and how this
impacts different host systems. That being said, I've run with similar
configs in the past (depending on the workload) with no issues.

qemux8-64 is already SMP, so it would just need the addition of virtio
devices, which just means we'd look at this as any BSP/target config
update.

But with graceful degradation (i.e maxcpus with SMP set) and agreement
that we'd like to simulate SMP by default, then we can make the change
and I'll merge it into the base config for the target and pull it into
the kernel tree.

Cheers,

Bruce






Thanks,
Edwin





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

Re: [yocto] where to put IMAGE_INSTALL??

2012-01-12 Thread Jim Abernathy 

On 01/12/2012 08:06 AM, Gary Thomas wrote:

On 2012-01-12 05:53, Jim Abernathy wrote:
There seems to be some sensitivity to where I put the statement 
IMAGE_INSTALL += web-webkit.


At first I just modifed the 
meta/receipes-sato/image/core-image-sato.bb file to include it. That 
caused the webkit to be built.


Since that is not an ideal location, I removed it and put it into the 
local.conf file. That also caused the webkit to be built, but I 
wanted it to be part of my BSP permanently.


I thought about creating a core-image-sato.bbappend file with the 
IMAGE_INSTALL += web-webkit in it and put that into the BSP, but 
that didn't cause the webkit to be built. Under
the meta-intel/meta-n450 directory, I created a receipes-jfa 
directory and put the core-image-sato.bbappend file there.


I must be missing a key rule about directory parsing and .bbappend 
files.


Look at the how the layers are parsed - this info is in 
layer/conf/layer.conf


Try putting your .bbappend file in
   .../meta-intel/meta-n450/recipes-jfa/images/core-image-sato.bbappend

I think you are correct now that I look more closely at the 
meta-n450/conf/layer.conf file.


It has:
BBFILES := ${BBFILES} ${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend

which tells me that it will not find 
recipes-jfa/core-image-sato.bbappend, but will find 
meta-n450/recipes-jfa/images/core-image-sato.bbappend


Thanks,

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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Brian Hutchinson 
Yet another follow up.  I finally found my C3 Beagleboard and the
default kernel built off master yesterday works on that platform too.

I was able to do another build with the tips you guys gave and it
looks like it is picking up the kernel from my local git repo now.  I
did the calibrate example and while I couldn't see the printk's due
to the silent boot being turned on somehow, uname -a was different
than the default image  mine is now:

root@beagleboard:~# uname -a
Linux beagleboard 3.0.14-yocto-standard+ #1 PREEMPT Thu Jan 12
08:45:10 EST 2012 armv7l GNU/Linux

And just for sanity, I made another copy of my bare clone and verified
that I pushed the calibrate changes correctly.

So it looks like I'm good now thanks to your help!

Do I have to do a cleanall every time I'm finished pushing changes
back to my local kernel repo?

Is there a document that gives clues as to how to setup a local u-boot
repo for making changes to it?  Is is simply changing the u-boot
recipe SRC_URI to use my local u-boot git repo in
poky/meda/recipes-bsp/u-boot or is it more involved than that?  Is
there a u-boot dev layer like the poky-extras/meta-kernel-dev?

Regards,

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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Jack Mitchell 

On 12/01/12 15:21, Brian Hutchinson wrote:

Yet another follow up.  I finally found my C3 Beagleboard and the
default kernel built off master yesterday works on that platform too.

I was able to do another build with the tips you guys gave and it
looks like it is picking up the kernel from my local git repo now.  I
did the calibrate example and while I couldn't see the printk's due
to the silent boot being turned on somehow, uname -a was different
than the default image  mine is now:

root@beagleboard:~# uname -a
Linux beagleboard 3.0.14-yocto-standard+ #1 PREEMPT Thu Jan 12
08:45:10 EST 2012 armv7l GNU/Linux

And just for sanity, I made another copy of my bare clone and verified
that I pushed the calibrate changes correctly.

So it looks like I'm good now thanks to your help!

Do I have to do a cleanall every time I'm finished pushing changes
back to my local kernel repo?

Is there a document that gives clues as to how to setup a local u-boot
repo for making changes to it?  Is is simply changing the u-boot
recipe SRC_URI to use my local u-boot git repo in
poky/meda/recipes-bsp/u-boot or is it more involved than that?  Is
there a u-boot dev layer like the poky-extras/meta-kernel-dev?

Regards,

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


Brian,

What image are you building, as I cannot get core-image-minimal to boot 
at all on my xM. I am currently trying to fix a hosed sd card (who knows 
what happened to it!) and then I will see if it has made any difference.


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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Bruce Ashfield 

On 12-01-12 10:21 AM, Brian Hutchinson wrote:

Yet another follow up.  I finally found my C3 Beagleboard and the
default kernel built off master yesterday works on that platform too.

I was able to do another build with the tips you guys gave and it
looks like it is picking up the kernel from my local git repo now.  I
did the calibrate example and while I couldn't see the printk's due
to the silent boot being turned on somehow, uname -a was different
than the default image  mine is now:

root@beagleboard:~# uname -a
Linux beagleboard 3.0.14-yocto-standard+ #1 PREEMPT Thu Jan 12
08:45:10 EST 2012 armv7l GNU/Linux

And just for sanity, I made another copy of my bare clone and verified
that I pushed the calibrate changes correctly.

So it looks like I'm good now thanks to your help!

Do I have to do a cleanall every time I'm finished pushing changes
back to my local kernel repo?


The bitbake AUTOREV code should take care of updating the clone
of your local repo in downloads/git2. I take it that this isn't
happening ?



Is there a document that gives clues as to how to setup a local u-boot
repo for making changes to it?  Is is simply changing the u-boot
recipe SRC_URI to use my local u-boot git repo in
poky/meda/recipes-bsp/u-boot or is it more involved than that?  Is
there a u-boot dev layer like the poky-extras/meta-kernel-dev?


It should be (largely) as simple as that. We could create something
simple and throw it in with the meta-kernel-dev layer if there's any
interest in adding it.

Cheers,

Bruce



Regards,

Brian


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

[yocto] qemu EFI build failure

2012-01-12 Thread Josef Ahmad 
I tried to build a qemux86 EFI image, by setting:
- in my local.conf: IMAGE_FSTYPES += live
- in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi

The build gave me the following error:



bash-3.00$ bitbake core-image-minimal
Loading cache: 100%
|###|
ETA:  00:00:00
Loaded 1083 entries from dependency cache.

OE Build Configuration:
BB_VERSION= 1.15.0
TARGET_ARCH   = i586
TARGET_OS = linux
MACHINE   = qemux86
DISTRO= poky
DISTRO_VERSION= 1.1+snapshot-20120111
TUNE_FEATURES = m32 i586
TARGET_FPU= 
meta
meta-yocto= (nobranch):468998cddbe1a803096c9b357e1b5daa3b7e8c2e

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 1082 of 1701 (ID: 139,
/tmp/localdisk/josef/yocto-stable/poky/meta/recipes-bsp/grub/grub-efi-native_1.99.bb,
do_configure)
NOTE: Running task 1682 of 1701 (ID: 97,
/tmp/localdisk/josef/yocto-stable/poky/meta/recipes-core/images/core-image-minimal-initramfs.bb,
do_rootfs)
NOTE: package grub-efi-i586-native-1.99-r2: task do_configure: Started
NOTE: package core-image-minimal-initramfs-1.0-r0: task do_rootfs: Started
NOTE: package core-image-minimal-initramfs-1.0-r0: task do_rootfs: Succeeded
ERROR: Function 'do_configure' failed (see
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/temp/log.do_configure.8536
for further information)
ERROR: Logfile of failure stored in:
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/temp/log.do_configure.8536
Log data follows:
| automake (GNU automake) 1.11.2
| Copyright (C) 2011 Free Software Foundation, Inc.
| License GPLv2+: GNU GPL version 2 or later
http://gnu.org/licenses/gpl-2.0.html
| This is free software: you are free to change and redistribute it.
| There is NO WARRANTY, to the extent permitted by law.
|
| Written by Tom Tromey tro...@redhat.com
|and Alexandre Duret-Lutz a...@gnu.org.
| AUTOV is 1.11
| NOTE: Executing autoreconf --verbose --install --force
--exclude=autopoint -I
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/aclocal-copy/
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/m4/
-I/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.11
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/aclocal-copy/
| autoreconf: Entering directory `.'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: aclocal -I
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/aclocal-copy/
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/m4/
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.11
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/aclocal-copy/
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/aclocal-copy/
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/m4/
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/sysroots/x86_64-linux/usr/share/aclocal-1.11
-I 
/tmp/localdisk/josef/yocto-stable/mytestbuild/tmp/work/x86_64-linux/grub-efi-i586-native-1.99-r2/grub-1.99/aclocal-copy/
--force --warnings=cross -I m4
| aclocal: unknown warning category `cross'
| configure.ac:515: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
| ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
| acinclude.m4:317: grub_CHECK_ENABLE_EXECUTE_STACK is expanded from...
| configure.ac:515: the top level
| configure.ac:518: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
| ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
| acinclude.m4:397: grub_CHECK_PIE is expanded from...
| configure.ac:518: the top level
| configure.ac:526: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
| ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
| acinclude.m4:344: grub_CHECK_STACK_PROTECTOR is expanded from...
| configure.ac:526: the top level
| configure.ac:532: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected in body
| ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
| acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from...
| configure.ac:532: the top level
| autoreconf: configure.ac: tracing
| configure.ac:515: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call
detected

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Brian Hutchinson 
On Thu, Jan 12, 2012 at 11:00 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
 The bitbake AUTOREV code should take care of updating the clone
 of your local repo in downloads/git2. I take it that this isn't
 happening ?

... haven't tried ... was just sticking to the example in the
documentation which says to push changes and do a cleanall.  The spin
time on my dev machine wasn't too bad but long enough to get old quick
if I had to do it often.

 It should be (largely) as simple as that. We could create something
 simple and throw it in with the meta-kernel-dev layer if there's any
 interest in adding it.

Just wanting to know what the best practice is as I have lots of
platforms to support.

Regards,

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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Bruce Ashfield 

On 12-01-12 11:20 AM, Brian Hutchinson wrote:

On Thu, Jan 12, 2012 at 11:00 AM, Bruce Ashfield
bruce.ashfi...@windriver.com  wrote:

The bitbake AUTOREV code should take care of updating the clone
of your local repo in downloads/git2. I take it that this isn't
happening ?


... haven't tried ... was just sticking to the example in the
documentation which says to push changes and do a cleanall.  The spin


Good point. I hadn't noticed that it was in there. Worth trying
without it, and raising a bug if it isn't required. It's
bitbake internals rather than kernel at play here, so I'm far
from authoritative about what should or shouldn't work.


time on my dev machine wasn't too bad but long enough to get old quick
if I had to do it often.


Agreed!




It should be (largely) as simple as that. We could create something
simple and throw it in with the meta-kernel-dev layer if there's any
interest in adding it.


Just wanting to know what the best practice is as I have lots of
platforms to support.


I prefer to work this way, since managing patches in a source git
repository is much easier for me. If you only have a few patches,
then they can just be pushed on top and added to the SRC_URI, but
you'd be doing more development under tmp/work/ in that case .. and
I'm paranoid about losing things :)

Cheers,

Bruce



Regards,

Brian


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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Brian Hutchinson 
On Thu, Jan 12, 2012 at 10:56 AM, Jack Mitchell m...@communistcode.co.uk 
wrote:
 Brian,

 What image are you building, as I cannot get core-image-minimal to boot at
 all on my xM. I am currently trying to fix a hosed sd card (who knows what
 happened to it!) and then I will see if it has made any difference.

Probably the same images as you.  I switched my branch to master and
the default kernel built was 3.0.12.

You might have to smoke your SD card (re-partition it for boot  root)
and copy MLO first, then u-boot.bin and uImage.  Copying MLO first is
key.  I know this can be a pain.  Google for beagleboard SD Card
script to find one of the scripts that automates setting up the SD
Card.  They just create the partitions etc., you still have to copy
the contents to the card in the right order.  MLO is the first you
copy on the boot partition, the order the rest are copied don't matter
AFAIK.

I also have a boot.scr with:

setenv bootcmd 'mmc init; fatload mmc 0:1 0x8030 uImage; bootm 0x8030'
setenv setenv bootargs 'console=ttyO2,115200n8 root=/dev/mmcblk0p2
rootwait rootfstype=ext3 rw'
boot

Hope that helps!

Regards,

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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Brian Hutchinson 
On Thu, Jan 12, 2012 at 11:24 AM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
 I prefer to work this way, since managing patches in a source git
 repository is much easier for me. If you only have a few patches,
 then they can just be pushed on top and added to the SRC_URI, but
 you'd be doing more development under tmp/work/ in that case .. and
 I'm paranoid about losing things :)

I know it probably isn't the best way (did it mostly because I was in
a hurry and never took the time to think about the right way to do
it) but I've made changes to the kernel  u-boot before in the tmp
directories (with Angstrom and Arago) and build images manually (make
uImage etc.) and that was OK for quick/dirty things but I've gotten
burned before by forgetting my changes and doing a bitbake build and
wiping out my changes.   I like the method of pointing yocto to local
git repos and think that is better for long term development as it
will contain history and would be easy to determine what changed etc.
I'd like to do something similar with u-boot and thought you guys had
worked out a defacto standard way but in looking through all the docs
it doesn't look that way.

Regards,

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

Re: [yocto] qemu EFI build failure

2012-01-12 Thread Darren Hart 


On 01/12/2012 08:19 AM, Josef Ahmad wrote:
 I tried to build a qemux86 EFI image, by setting:
 - in my local.conf: IMAGE_FSTYPES += live
 - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi
 

I haven't tried live images with QEMU. For one thing, they aren't really
necessary as you can specify all the boot parameters on the qemu command
line. Is there are reason you want to use the live image specifically?

Also, in order to properly test EFI in QEMU, you will need to use an EFI
BIOS - I believe you're aware of this already - but this isn't currently
supported by the runqemu scripts that ship with yocto.

 The build gave me the following error:


I'll do some test builds - it isn't clear to me what is going on here.

snip

 
 
 Has anyone encountered the same error?  I'm not sure I set up the
 correct configuration. Also, is there another way to append efi to
 MACHINE_FEATURES rather than by modifying qemux86.conf?

You should be able to do something like:
MACHINE_FEATURES_append_qemux86 = efi

Note that you will also need to enable the efi support in the kernel,
which is done with the KERNEL_FEATURES variable, something like:
KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc

Either of these can be set in your local.conf.


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

Re: [yocto] Does Edison work with Beagleboard linux-yocto-3.0 kernel?

2012-01-12 Thread Bruce Ashfield 

On 12-01-12 11:48 AM, Brian Hutchinson wrote:

On Thu, Jan 12, 2012 at 11:24 AM, Bruce Ashfield
bruce.ashfi...@windriver.com  wrote:

I prefer to work this way, since managing patches in a source git
repository is much easier for me. If you only have a few patches,
then they can just be pushed on top and added to the SRC_URI, but
you'd be doing more development under tmp/work/ in that case .. and
I'm paranoid about losing things :)


I know it probably isn't the best way (did it mostly because I was in
a hurry and never took the time to think about the right way to do
it) but I've made changes to the kernel  u-boot before in the tmp
directories (with Angstrom and Arago) and build images manually (make
uImage etc.) and that was OK for quick/dirty things but I've gotten
burned before by forgetting my changes and doing a bitbake build and
wiping out my changes.   I like the method of pointing yocto to local
git repos and think that is better for long term development as it
will contain history and would be easy to determine what changed etc.
I'd like to do something similar with u-boot and thought you guys had
worked out a defacto standard way but in looking through all the docs
it doesn't look that way.


Ah yes. Nothing in particular. I was a non-oe import to yocto, so a
lot of what I've done is from being bitten in the past and making sure
that it didn't happen to me in a new environment.

Of course, I'm all for general solutions and getting feedback as well!

Cheers,

Bruce



Regards,

Brian


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

[yocto] [PATCH] meta-intel/common: fix ptr-int and Werror=address compile errors

2012-01-12 Thread Tom Zanussi 
A couple of things that had previously been warnings are now errors,
so they need to be fixed up.

The first problem is a comparison between the address of a static
struct and NULL, which can never be valid.  A different fix for this
is upstream, which includes an API usage change; we don't need that to
fix this problem.

The second problem is a cast from pointer to integer in fbdevhw.c.
This also is fixed upstream by removing the whole section of code
which is bogus anyway, which is also done here.

This also adds a missing PR to the xserver-xorg recipe.

Signed-off-by: Tom Zanussi tom.zanu...@intel.com
---
 .../xorg-xserver/xserver-xorg-1.9.3.inc|5 +
 .../xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch   |   92 
 .../xserver-xorg-1.9.3/werror-address-fix.patch|   49 +++
 3 files changed, 146 insertions(+), 0 deletions(-)
 create mode 100644 
common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
 create mode 100644 
common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/werror-address-fix.patch

diff --git a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc 
b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
index 888445d..8c7009f 100644
--- a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
+++ b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
@@ -4,6 +4,10 @@ SRC_URI += file://nodolt.patch \
 # Misc build failure for master HEAD
 SRC_URI += file://fix_open_max_preprocessor_error.patch
 
+# What once were warnings now are errors, fix those up
+SRC_URI += file://werror-address-fix.patch \
+file://ptr-to-int-cast-fix.patch
+
 PROTO_DEPS += xf86driproto dri2proto
 DEPENDS += font-util
 EXTRA_OECONF += --enable-dri --enable-dri2 --enable-dga
@@ -13,3 +17,4 @@ LIC_FILES_CHKSUM = 
file://COPYING;md5=3dd2bbe3563837f80ed8926b06c1c353
 SRC_URI[md5sum] = 5bef6839a76d029204ab31aa2fcb5201
 SRC_URI[sha256sum] = 
864831f51e841ff37f2445d1c85b86b559c8860a435fb496aead4f256a2b141d
 
+PR = r1
diff --git 
a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
 
b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
new file mode 100644
index 000..705cffc
--- /dev/null
+++ 
b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
@@ -0,0 +1,92 @@
+Upstream-Status: Inappropriate [already upstream]
+
+It's broken for devices with BARs above 4G, and the sysfs method should
 
+work everywhere anyway.  As a pleasant side effect, this fixes some
 
+warnings:  
 
+   
 
+fbdevhw.c: In function 'fbdev_open_pci':   
 
+fbdevhw.c:333:4: warning: cast from pointer to integer of different size   
 
+fbdevhw.c:334:4: warning: cast from pointer to integer of different size   
 
+fbdevhw.c:336:4: warning: cast from pointer to integer of different size   
 
+fbdevhw.c:337:4: warning: cast from pointer to integer of different size   
 
+   
 
+Signed-off-by: Adam Jackson ajax (a] redhat.com  
 
+Integrated-by: Tom Zanussi tom.zanussi (a] intel.com
+
+Index: xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c
+===
+--- xorg-server-1.9.3.orig/hw/xfree86/fbdevhw/fbdevhw.c2012-01-12 
10:32:07.097729262 -0600
 xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c 2012-01-12 
10:32:55.076732780 -0600
+@@ -291,14 +291,7 @@
+ {
+ structfb_fix_screeninfo fix;
+ char  filename[256];
+-int   fd,i,j;
+-
+-
+-/* There are two ways to that we can determine which fb device is
+- * associated with this PCI device.  The more modern way is to look in
+- * the sysfs directory for the PCI device for a file named
+- * graphics/fb*
+- */
++int   fd, i;
+ 
+ for (i = 0; i  8; i++) {
+   sprintf(filename, 
+@@ -331,55 +324,10 @@
+   }
+ }
+ 
+-
+-/* The other way is to examine the resources associated with each fb
+- * device and see if there is a match with the PCI device.  This technique
+- * has some problems on certain mixed 64-bit / 32-bit architectures.
+- * There is a flaw in the fb_fix_screeninfo structure in that it only
+- * returns the low 32-bits of the address of the resources associated with
+- * a device.  However, on a mixed architecture the base addresses of PCI
+- * devices, even for 32-bit applications, may be higher than 0x0f000.
+- */
+-
+-for (i = 0; i  8; i++) {
+-  sprintf(filename,/dev/fb%d,i);
+-  if (-1 == (fd = open(filename,O_RDWR,0))) {
+-  xf86DrvMsg(-1, X_WARNING,
+- open %s: %s\n, filename,

Re: [yocto] where to put IMAGE_INSTALL??

2012-01-12 Thread Jim Abernathy 

On 01/12/2012 08:06 AM, Gary Thomas wrote:

On 2012-01-12 05:53, Jim Abernathy wrote:
There seems to be some sensitivity to where I put the statement 
IMAGE_INSTALL += web-webkit.


At first I just modifed the 
meta/receipes-sato/image/core-image-sato.bb file to include it. That 
caused the webkit to be built.


Since that is not an ideal location, I removed it and put it into the 
local.conf file. That also caused the webkit to be built, but I 
wanted it to be part of my BSP permanently.


I thought about creating a core-image-sato.bbappend file with the 
IMAGE_INSTALL += web-webkit in it and put that into the BSP, but 
that didn't cause the webkit to be built. Under
the meta-intel/meta-n450 directory, I created a receipes-jfa 
directory and put the core-image-sato.bbappend file there.


I must be missing a key rule about directory parsing and .bbappend 
files.


Look at the how the layers are parsed - this info is in 
layer/conf/layer.conf


Try putting your .bbappend file in
   .../meta-intel/meta-n450/recipes-jfa/images/core-image-sato.bbappend

I just tested your method of putting the .bbappend file in the directory 
above and it work just fine.  I also found out that you should not put 
the IMAGE_INSTALL in the local.conf.  It builds okay, but the resulting 
image will not boot.  Tom pointing me the a statement in the Poky 
reference manual about not doing this as well.


JIm A

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

[yocto] QtCreator and Yocto SDK

2012-01-12 Thread Marc Ferland 
Hi,

I'm currently looking for instructions on how to integrate a Yocto SDK
with QtCreator.

I've successfully built my application by sourcing the environment file
and simply calling qmake/make, but QtCreator refuses to build the
project.

Any ideas/tips?

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

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

2012-01-12 Thread Tom Zanussi 
On Fri, 2011-12-16 at 19:03 -0800, Bruce Ashfield wrote:
 On 11-12-16 8:34 PM, Darren Hart wrote:
  On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:
 
  With the attached Darren's kern-tools-native_git.bb file, build was 
  success.
  Thanks
  Kishore.
 
  See the patch I just sent:kern-tools: Include do_install() in bbappend
  for what I believe to be the solution.
 
  I suppose the proper solution would be to version the kern-tools-native
  recipe when major things like that change, but given the nature of this
  layer, I think the above patch is adequate.
 
 That's not the solution to either problem (well, yes, it's a solution
 and there's nothing inherently wrong with it, it's just covering up
 the underlying issue) which is a layer dependency issue. In this case,
 meta-kernel-dev tracks the master branch of poky, not any other branch
 or version. And that is implicit, not explicit, hence why it got into
 this tangle.
 
 We could simply branch meta-kernel-dev and have an edison branch for
 it, not modify the appends to contain something that will just break
 again in the future.
 
 But meta-kernel-dev isn't officially used by much at the moment, so
 I'm not convinced that branching it is worth the trouble (but I can
 be convinced otherwise). I'd rather either just remove the kern-tools
 bbappend (I'm probably the only one on the planet that really needs
 it), or just trust people to know what they are up to with the
 meta-kernel-dev layer.
 

Revisiting this - meta-kernel-dev is used in the documentation, and
Scott has now run up against this when testing and updating it.  Since
the documentation does use edison, and the walk-throughs have the user
check out edison branches of both poky and the BSP layers, it would be
consistent to have the user also do the same for meta-kernel-dev.
Probably just an edison branch with the kern-tools bbappend removed
would work fine...

Tom

 Alternatively, we wait for layer dependency tooling and use that :)
 
 Cheers,
 
 Bruce
 
 
  --
  Darren
 
 
  -Original Message-
  From: Bodke, Kishore K
  Sent: Friday, December 16, 2011 5:07 PM
  To: Hart, Darren
  Cc: Bruce Ashfield; yocto@yoctoproject.org
  Subject: RE: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
  branch.
 
  Hi,
  I still get the same error below after changing the 
  kern-tools-native_git.bb file.
 
  SRCREV ?= 364437739c45a5e771d1f7b3ac73c35f1328fd97
  PR = r11
 
 
  ERROR: Function 'do_kernel_configme' failed (see 
  /usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
   for further information)
  ERROR: Logfile of failure stored in: 
  /usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
  Log data follows:
  | [INFO] doing kernel configme
  | [INFO] Branch yocto/standard/preempt-rt/base used by 
  common-pc-preempt-rt.scc
  | [INFO] collecting configs in ./meta/meta-series
  | mv: cannot stat 
  `/usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/linux-crystalforest-preempt-rt-build/.tmp.config*':
   No such file or directory
  | creation of pre-processed config data failed
  | config of yocto/standard/preempt-rt/base (common-pc-preempt-rt.scc) 
  failed
  | ERROR: Function 'do_kernel_configme' failed (see 
  /usr/local/src/yocto_1_1/poky/build/tmp/work/crystalforest-poky-linux/linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1/temp/log.do_kernel_configme.27942
   for further information)
  NOTE: package 
  linux-yocto-rt-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+0936e13cc65d816f1759e2322c5e3fc82a5037f3-r1:
   task do_kernel_configme: Failed
  NOTE: package gcc-cross-4.6.1+svnr175454-r10: task do_configure: Started
  ERROR: Task 716 
  (/usr/local/src/yocto_1_1/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.0.bb,
   do_kernel_configme) failed with exit code '1'
 
  Thanks
  Kishore.
 
  -Original Message-
  From: Hart, Darren
  Sent: Friday, December 16, 2011 3:08 PM
  To: Bodke, Kishore K
  Cc: Bruce Ashfield; yocto@yoctoproject.org
  Subject: Re: kernel-tools failure for linux-yoctort_3.0.bb for poky/edison 
  branch.
 
  On 12/16/2011 02:12 PM, Bodke, Kishore K wrote:
  I am building core-image-sato.
  I have not changed any boot parameters.
  Everything was default settings.
 
  By image format I mean are you using a live image?
  core-image-sato-*.hddimg or are you formatting a disk and copying over
  contents of the rootfs? The kernel parameters are specified in
  meta-intel and meta-romley.
 
  My guess is something has gone wrong in

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

2012-01-12 Thread Darren Hart 
On 01/12/2012 12:39 PM, Tom Zanussi wrote:
 On Fri, 2011-12-16 at 19:03 -0800, Bruce Ashfield wrote:
 On 11-12-16 8:34 PM, Darren Hart wrote:
 On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:

 With the attached Darren's kern-tools-native_git.bb file, build was 
 success.
 Thanks
 Kishore.

 See the patch I just sent:kern-tools: Include do_install() in bbappend
 for what I believe to be the solution.

 I suppose the proper solution would be to version the kern-tools-native
 recipe when major things like that change, but given the nature of this
 layer, I think the above patch is adequate.

 That's not the solution to either problem (well, yes, it's a solution
 and there's nothing inherently wrong with it, it's just covering up
 the underlying issue) which is a layer dependency issue. In this case,
 meta-kernel-dev tracks the master branch of poky, not any other branch
 or version. And that is implicit, not explicit, hence why it got into
 this tangle.

 We could simply branch meta-kernel-dev and have an edison branch for
 it, not modify the appends to contain something that will just break
 again in the future.

 But meta-kernel-dev isn't officially used by much at the moment, so
 I'm not convinced that branching it is worth the trouble (but I can
 be convinced otherwise). I'd rather either just remove the kern-tools
 bbappend (I'm probably the only one on the planet that really needs
 it), or just trust people to know what they are up to with the
 meta-kernel-dev layer.

 
 Revisiting this - meta-kernel-dev is used in the documentation, and
 Scott has now run up against this when testing and updating it.  Since
 the documentation does use edison, and the walk-throughs have the user
 check out edison branches of both poky and the BSP layers, it would be
 consistent to have the user also do the same for meta-kernel-dev.
 Probably just an edison branch with the kern-tools bbappend removed
 would work fine...
 
 Tom

Works for me.

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

Re: [yocto] qemu EFI build failure

2012-01-12 Thread Darren Hart 
On 01/12/2012 10:27 AM, Darren Hart wrote:
 
 
 On 01/12/2012 08:19 AM, Josef Ahmad wrote:
 I tried to build a qemux86 EFI image, by setting:
 - in my local.conf: IMAGE_FSTYPES += live
 - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi

 
 I haven't tried live images with QEMU. For one thing, they aren't really
 necessary as you can specify all the boot parameters on the qemu command
 line. Is there are reason you want to use the live image specifically?
 
 Also, in order to properly test EFI in QEMU, you will need to use an EFI
 BIOS - I believe you're aware of this already - but this isn't currently
 supported by the runqemu scripts that ship with yocto.
 
 The build gave me the following error:
 
 
 I'll do some test builds - it isn't clear to me what is going on here.
 
 snip
 


 Has anyone encountered the same error?  I'm not sure I set up the
 correct configuration. Also, is there another way to append efi to
 MACHINE_FEATURES rather than by modifying qemux86.conf?
 
 You should be able to do something like:
 MACHINE_FEATURES_append_qemux86 = efi
 
 Note that you will also need to enable the efi support in the kernel,
 which is done with the KERNEL_FEATURES variable, something like:
 KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc
 
 Either of these can be set in your local.conf.
 

More accurately:

MACHINE_FEATURES_append_qemux86= efi pcbios
KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc
IMAGE_FSTYPES += live

With these added to local.conf and building for qemux86 I see the same
configure failures reported by Kishore and Josef:

| ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
| acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from...

I've discussed in IRC with Nitin and he thinks this may be related to
the automake update and is looking into it.

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

Re: [yocto] [PATCH] meta-intel/common: fix ptr-int and Werror=address compile errors

2012-01-12 Thread Darren Hart 


On 01/12/2012 10:33 AM, Tom Zanussi wrote:
 A couple of things that had previously been warnings are now errors,
 so they need to be fixed up.
 
 The first problem is a comparison between the address of a static
 struct and NULL, which can never be valid.  A different fix for this
 is upstream, which includes an API usage change; we don't need that to
 fix this problem.
 
 The second problem is a cast from pointer to integer in fbdevhw.c.
 This also is fixed upstream by removing the whole section of code
 which is bogus anyway, which is also done here.
 
 This also adds a missing PR to the xserver-xorg recipe.
 
 Signed-off-by: Tom Zanussi tom.zanu...@intel.com

I'm fine with the patch given your upstream API change comment above. I
am curious about just dropping the struct == NULL test as opposed to
testing for some value in the structure that would indicate the intended
condition. If you're happy with it as is, then:

Acked-by: Darren Hart dvh...@linux.intel.com

 ---
  .../xorg-xserver/xserver-xorg-1.9.3.inc|5 +
  .../xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch   |   92 
 
  .../xserver-xorg-1.9.3/werror-address-fix.patch|   49 +++
  3 files changed, 146 insertions(+), 0 deletions(-)
  create mode 100644 
 common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  create mode 100644 
 common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/werror-address-fix.patch
 
 diff --git a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc 
 b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
 index 888445d..8c7009f 100644
 --- a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
 +++ b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
 @@ -4,6 +4,10 @@ SRC_URI += file://nodolt.patch \
  # Misc build failure for master HEAD
  SRC_URI += file://fix_open_max_preprocessor_error.patch
  
 +# What once were warnings now are errors, fix those up
 +SRC_URI += file://werror-address-fix.patch \
 +file://ptr-to-int-cast-fix.patch
 +
  PROTO_DEPS += xf86driproto dri2proto
  DEPENDS += font-util
  EXTRA_OECONF += --enable-dri --enable-dri2 --enable-dga
 @@ -13,3 +17,4 @@ LIC_FILES_CHKSUM = 
 file://COPYING;md5=3dd2bbe3563837f80ed8926b06c1c353
  SRC_URI[md5sum] = 5bef6839a76d029204ab31aa2fcb5201
  SRC_URI[sha256sum] = 
 864831f51e841ff37f2445d1c85b86b559c8860a435fb496aead4f256a2b141d
  
 +PR = r1
 diff --git 
 a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  
 b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
 new file mode 100644
 index 000..705cffc
 --- /dev/null
 +++ 
 b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
 @@ -0,0 +1,92 @@
 +Upstream-Status: Inappropriate [already upstream]
 +
 +It's broken for devices with BARs above 4G, and the sysfs method should  

 +work everywhere anyway.  As a pleasant side effect, this fixes some  

 +warnings:

 + 

 +fbdevhw.c: In function 'fbdev_open_pci': 

 +fbdevhw.c:333:4: warning: cast from pointer to integer of different size 

 +fbdevhw.c:334:4: warning: cast from pointer to integer of different size 

 +fbdevhw.c:336:4: warning: cast from pointer to integer of different size 

 +fbdevhw.c:337:4: warning: cast from pointer to integer of different size 

 + 

 +Signed-off-by: Adam Jackson ajax (a] redhat.com

 +Integrated-by: Tom Zanussi tom.zanussi (a] intel.com
 +
 +Index: xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c
 +===
 +--- xorg-server-1.9.3.orig/hw/xfree86/fbdevhw/fbdevhw.c  2012-01-12 
 10:32:07.097729262 -0600
  xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c   2012-01-12 
 10:32:55.076732780 -0600
 +@@ -291,14 +291,7 @@
 + {
 + struct  fb_fix_screeninfo fix;
 + charfilename[256];
 +-int fd,i,j;
 +-
 +-
 +-/* There are two ways to that we can determine which fb device is
 +- * associated with this PCI device.  The more modern way is to look in
 +- * the sysfs directory for the PCI device for a file named
 +- * graphics/fb*
 +- */
 ++int fd, i;
 + 
 + for (i = 0; i  8; i++) {
 + sprintf(filename, 
 +@@ -331,55 +324,10 @@
 + }
 + }
 + 
 +-
 +-/* The other way is to examine the resources associated with each fb
 +- * device and see if there is a match with the PCI device.  This 
 technique
 +- * has some problems on certain mixed 64-bit / 32-bit architectures.
 +- * There is a flaw in the fb_fix_screeninfo structure in that it only
 +-

Re: [yocto] kernel-tools failure for linux-yoctort_3.0.bb for poky/edison branch.

2012-01-12 Thread Bruce Ashfield 

On 12-01-12 03:52 PM, Darren Hart wrote:

On 01/12/2012 12:39 PM, Tom Zanussi wrote:

On Fri, 2011-12-16 at 19:03 -0800, Bruce Ashfield wrote:

On 11-12-16 8:34 PM, Darren Hart wrote:

On 12/16/2011 05:22 PM, Bodke, Kishore K wrote:


With the attached Darren's kern-tools-native_git.bb file, build was success.
Thanks
Kishore.


See the patch I just sent:kern-tools: Include do_install() in bbappend
for what I believe to be the solution.

I suppose the proper solution would be to version the kern-tools-native
recipe when major things like that change, but given the nature of this
layer, I think the above patch is adequate.


That's not the solution to either problem (well, yes, it's a solution
and there's nothing inherently wrong with it, it's just covering up
the underlying issue) which is a layer dependency issue. In this case,
meta-kernel-dev tracks the master branch of poky, not any other branch
or version. And that is implicit, not explicit, hence why it got into
this tangle.

We could simply branch meta-kernel-dev and have an edison branch for
it, not modify the appends to contain something that will just break
again in the future.

But meta-kernel-dev isn't officially used by much at the moment, so
I'm not convinced that branching it is worth the trouble (but I can
be convinced otherwise). I'd rather either just remove the kern-tools
bbappend (I'm probably the only one on the planet that really needs
it), or just trust people to know what they are up to with the
meta-kernel-dev layer.



Revisiting this - meta-kernel-dev is used in the documentation, and
Scott has now run up against this when testing and updating it.  Since
the documentation does use edison, and the walk-throughs have the user
check out edison branches of both poky and the BSP layers, it would be
consistent to have the user also do the same for meta-kernel-dev.
Probably just an edison branch with the kern-tools bbappend removed
would work fine...

Tom


Works for me.


Seems ok. I can create a branch shortly, once I'm slightly out from
under my 3.2 tree creation rush.

Bruce





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

Re: [yocto] qemu EFI build failure

2012-01-12 Thread Darren Hart 
On 01/12/2012 01:28 PM, Bodke, Kishore K wrote:
 I have only 
 MACHINE_FEATURES += efi
 KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc.
 
 I am not having IMAGE_FSTYPES += live.

The live change is just to trigger the live image type which builds
grub-efi-native for efi systems. qemux86 needs this added explicitly.

--
Darren

 
 Thanks
 Kishore.
 -Original Message-
 From: Hart, Darren 
 Sent: Thursday, January 12, 2012 1:20 PM
 To: Ahmad, Josef
 Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A
 Subject: Re: [yocto] qemu EFI build failure
 
 On 01/12/2012 10:27 AM, Darren Hart wrote:


 On 01/12/2012 08:19 AM, Josef Ahmad wrote:
 I tried to build a qemux86 EFI image, by setting:
 - in my local.conf: IMAGE_FSTYPES += live
 - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi


 I haven't tried live images with QEMU. For one thing, they aren't really
 necessary as you can specify all the boot parameters on the qemu command
 line. Is there are reason you want to use the live image specifically?

 Also, in order to properly test EFI in QEMU, you will need to use an EFI
 BIOS - I believe you're aware of this already - but this isn't currently
 supported by the runqemu scripts that ship with yocto.

 The build gave me the following error:


 I'll do some test builds - it isn't clear to me what is going on here.

 snip



 Has anyone encountered the same error?  I'm not sure I set up the
 correct configuration. Also, is there another way to append efi to
 MACHINE_FEATURES rather than by modifying qemux86.conf?

 You should be able to do something like:
 MACHINE_FEATURES_append_qemux86 = efi

 Note that you will also need to enable the efi support in the kernel,
 which is done with the KERNEL_FEATURES variable, something like:
 KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc

 Either of these can be set in your local.conf.

 
 More accurately:
 
 MACHINE_FEATURES_append_qemux86= efi pcbios
 KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc
 IMAGE_FSTYPES += live
 
 With these added to local.conf and building for qemux86 I see the same
 configure failures reported by Kishore and Josef:
 
 | ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
 | acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from...
 
 I've discussed in IRC with Nitin and he thinks this may be related to
 the automake update and is looking into it.
 


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

Re: [yocto] [PATCH] meta-intel/common: fix ptr-int and Werror=address compile errors

2012-01-12 Thread Tom Zanussi 
On Thu, 2012-01-12 at 13:24 -0800, Darren Hart wrote:
 
 On 01/12/2012 10:33 AM, Tom Zanussi wrote:
  A couple of things that had previously been warnings are now errors,
  so they need to be fixed up.
  
  The first problem is a comparison between the address of a static
  struct and NULL, which can never be valid.  A different fix for this
  is upstream, which includes an API usage change; we don't need that to
  fix this problem.
  
  The second problem is a cast from pointer to integer in fbdevhw.c.
  This also is fixed upstream by removing the whole section of code
  which is bogus anyway, which is also done here.
  
  This also adds a missing PR to the xserver-xorg recipe.
  
  Signed-off-by: Tom Zanussi tom.zanu...@intel.com
 
 I'm fine with the patch given your upstream API change comment above. I
 am curious about just dropping the struct == NULL test as opposed to
 testing for some value in the structure that would indicate the intended
 condition. If you're happy with it as is, then:
 

Well, the struct == NULL test can obviously never affect anything at
run-time, and by definition never has, so can be safely removed.

Changing the code to actually test something inside the struct that may
or may not be meaningful would mean auditing all the code to find out
whether the contents are always in a sane state for that test.

Given the choice between a fix that makes no run-time changes and has no
possibility of causing a regression vs spending a lot of time making an
old version of obviously buggy code I know nothing about perfect, I
chose the former.  While I'm at it, I should also probably fix the 7000
other warnings - the only reason I'm in here in the first place is that
a couple of them suddenly turned into errors...

Tom

 Acked-by: Darren Hart dvh...@linux.intel.com
 
  ---
   .../xorg-xserver/xserver-xorg-1.9.3.inc|5 +
   .../xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch   |   92 
  
   .../xserver-xorg-1.9.3/werror-address-fix.patch|   49 +++
   3 files changed, 146 insertions(+), 0 deletions(-)
   create mode 100644 
  common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
   create mode 100644 
  common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/werror-address-fix.patch
  
  diff --git a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc 
  b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
  index 888445d..8c7009f 100644
  --- a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
  +++ b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
  @@ -4,6 +4,10 @@ SRC_URI += file://nodolt.patch \
   # Misc build failure for master HEAD
   SRC_URI += file://fix_open_max_preprocessor_error.patch
   
  +# What once were warnings now are errors, fix those up
  +SRC_URI += file://werror-address-fix.patch \
  +file://ptr-to-int-cast-fix.patch
  +
   PROTO_DEPS += xf86driproto dri2proto
   DEPENDS += font-util
   EXTRA_OECONF += --enable-dri --enable-dri2 --enable-dga
  @@ -13,3 +17,4 @@ LIC_FILES_CHKSUM = 
  file://COPYING;md5=3dd2bbe3563837f80ed8926b06c1c353
   SRC_URI[md5sum] = 5bef6839a76d029204ab31aa2fcb5201
   SRC_URI[sha256sum] = 
  864831f51e841ff37f2445d1c85b86b559c8860a435fb496aead4f256a2b141d
   
  +PR = r1
  diff --git 
  a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
   
  b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  new file mode 100644
  index 000..705cffc
  --- /dev/null
  +++ 
  b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  @@ -0,0 +1,92 @@
  +Upstream-Status: Inappropriate [already upstream]
  +
  +It's broken for devices with BARs above 4G, and the sysfs method should
   
  +work everywhere anyway.  As a pleasant side effect, this fixes some
   
  +warnings:  
   
  +   
   
  +fbdevhw.c: In function 'fbdev_open_pci':   
   
  +fbdevhw.c:333:4: warning: cast from pointer to integer of different size   
   
  +fbdevhw.c:334:4: warning: cast from pointer to integer of different size   
   
  +fbdevhw.c:336:4: warning: cast from pointer to integer of different size   
   
  +fbdevhw.c:337:4: warning: cast from pointer to integer of different size   
   
  +   
   
  +Signed-off-by: Adam Jackson ajax (a] redhat.com  
   
  +Integrated-by: Tom Zanussi tom.zanussi (a] intel.com
  +
  +Index: xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c
  +===
  +--- xorg-server-1.9.3.orig/hw/xfree86/fbdevhw/fbdevhw.c2012-01-12 
  10:32:07.097729262 -0600

Re: [yocto] [PATCH] meta-intel/common: fix ptr-int and Werror=address compile errors

2012-01-12 Thread Darren Hart 


On 01/12/2012 01:47 PM, Tom Zanussi wrote:
 On Thu, 2012-01-12 at 13:24 -0800, Darren Hart wrote:

 On 01/12/2012 10:33 AM, Tom Zanussi wrote:
 A couple of things that had previously been warnings are now errors,
 so they need to be fixed up.

 The first problem is a comparison between the address of a static
 struct and NULL, which can never be valid.  A different fix for this
 is upstream, which includes an API usage change; we don't need that to
 fix this problem.

 The second problem is a cast from pointer to integer in fbdevhw.c.
 This also is fixed upstream by removing the whole section of code
 which is bogus anyway, which is also done here.

 This also adds a missing PR to the xserver-xorg recipe.

 Signed-off-by: Tom Zanussi tom.zanu...@intel.com

 I'm fine with the patch given your upstream API change comment above. I
 am curious about just dropping the struct == NULL test as opposed to
 testing for some value in the structure that would indicate the intended
 condition. If you're happy with it as is, then:

 
 Well, the struct == NULL test can obviously never affect anything at
 run-time, and by definition never has, so can be safely removed.
 
 Changing the code to actually test something inside the struct that may
 or may not be meaningful would mean auditing all the code to find out
 whether the contents are always in a sane state for that test.

Ah, yes, good point. Looks good to me as is.

--
Darren

 
 Given the choice between a fix that makes no run-time changes and has no
 possibility of causing a regression vs spending a lot of time making an
 old version of obviously buggy code I know nothing about perfect, I
 chose the former.  While I'm at it, I should also probably fix the 7000
 other warnings - the only reason I'm in here in the first place is that
 a couple of them suddenly turned into errors...
 
 Tom
 
 Acked-by: Darren Hart dvh...@linux.intel.com

 ---
  .../xorg-xserver/xserver-xorg-1.9.3.inc|5 +
  .../xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch   |   92 
 
  .../xserver-xorg-1.9.3/werror-address-fix.patch|   49 +++
  3 files changed, 146 insertions(+), 0 deletions(-)
  create mode 100644 
 common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  create mode 100644 
 common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/werror-address-fix.patch

 diff --git a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc 
 b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
 index 888445d..8c7009f 100644
 --- a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
 +++ b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
 @@ -4,6 +4,10 @@ SRC_URI += file://nodolt.patch \
  # Misc build failure for master HEAD
  SRC_URI += file://fix_open_max_preprocessor_error.patch
  
 +# What once were warnings now are errors, fix those up
 +SRC_URI += file://werror-address-fix.patch \
 +file://ptr-to-int-cast-fix.patch
 +
  PROTO_DEPS += xf86driproto dri2proto
  DEPENDS += font-util
  EXTRA_OECONF += --enable-dri --enable-dri2 --enable-dga
 @@ -13,3 +17,4 @@ LIC_FILES_CHKSUM = 
 file://COPYING;md5=3dd2bbe3563837f80ed8926b06c1c353
  SRC_URI[md5sum] = 5bef6839a76d029204ab31aa2fcb5201
  SRC_URI[sha256sum] = 
 864831f51e841ff37f2445d1c85b86b559c8860a435fb496aead4f256a2b141d
  
 +PR = r1
 diff --git 
 a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  
 b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
 new file mode 100644
 index 000..705cffc
 --- /dev/null
 +++ 
 b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
 @@ -0,0 +1,92 @@
 +Upstream-Status: Inappropriate [already upstream]
 +
 +It's broken for devices with BARs above 4G, and the sysfs method should
  
 +work everywhere anyway.  As a pleasant side effect, this fixes some
  
 +warnings:  
  
 +   
  
 +fbdevhw.c: In function 'fbdev_open_pci':   
  
 +fbdevhw.c:333:4: warning: cast from pointer to integer of different size   
  
 +fbdevhw.c:334:4: warning: cast from pointer to integer of different size   
  
 +fbdevhw.c:336:4: warning: cast from pointer to integer of different size   
  
 +fbdevhw.c:337:4: warning: cast from pointer to integer of different size   
  
 +   
  
 +Signed-off-by: Adam Jackson ajax (a] redhat.com  
  
 +Integrated-by: Tom Zanussi tom.zanussi (a] intel.com
 +
 +Index: xorg-server-1.9.3/hw/xfree86/fbdevhw/fbdevhw.c
 +===
 +--- xorg-server-1.9.3.orig/hw/xfree86/fbdevhw/fbdevhw.c2012-01-12 
 10:32:07.097729262

Re: [yocto] [PATCH] meta-intel/common: fix ptr-int and Werror=address compile errors

2012-01-12 Thread Tom Zanussi 
On Thu, 2012-01-12 at 13:49 -0800, Darren Hart wrote:
 
 On 01/12/2012 01:47 PM, Tom Zanussi wrote:
  On Thu, 2012-01-12 at 13:24 -0800, Darren Hart wrote:
 
  On 01/12/2012 10:33 AM, Tom Zanussi wrote:
  A couple of things that had previously been warnings are now errors,
  so they need to be fixed up.
 
  The first problem is a comparison between the address of a static
  struct and NULL, which can never be valid.  A different fix for this
  is upstream, which includes an API usage change; we don't need that to
  fix this problem.
 
  The second problem is a cast from pointer to integer in fbdevhw.c.
  This also is fixed upstream by removing the whole section of code
  which is bogus anyway, which is also done here.
 
  This also adds a missing PR to the xserver-xorg recipe.
 
  Signed-off-by: Tom Zanussi tom.zanu...@intel.com
 
  I'm fine with the patch given your upstream API change comment above. I
  am curious about just dropping the struct == NULL test as opposed to
  testing for some value in the structure that would indicate the intended
  condition. If you're happy with it as is, then:
 
  
  Well, the struct == NULL test can obviously never affect anything at
  run-time, and by definition never has, so can be safely removed.
  
  Changing the code to actually test something inside the struct that may
  or may not be meaningful would mean auditing all the code to find out
  whether the contents are always in a sane state for that test.
 
 Ah, yes, good point. Looks good to me as is.
 

OK, thanks for the ack..

Tom


 --
 Darren
 
  
  Given the choice between a fix that makes no run-time changes and has no
  possibility of causing a regression vs spending a lot of time making an
  old version of obviously buggy code I know nothing about perfect, I
  chose the former.  While I'm at it, I should also probably fix the 7000
  other warnings - the only reason I'm in here in the first place is that
  a couple of them suddenly turned into errors...
  
  Tom
  
  Acked-by: Darren Hart dvh...@linux.intel.com
 
  ---
   .../xorg-xserver/xserver-xorg-1.9.3.inc|5 +
   .../xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch   |   92 
  
   .../xserver-xorg-1.9.3/werror-address-fix.patch|   49 +++
   3 files changed, 146 insertions(+), 0 deletions(-)
   create mode 100644 
  common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
   create mode 100644 
  common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/werror-address-fix.patch
 
  diff --git a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc 
  b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
  index 888445d..8c7009f 100644
  --- a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
  +++ b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3.inc
  @@ -4,6 +4,10 @@ SRC_URI += file://nodolt.patch \
   # Misc build failure for master HEAD
   SRC_URI += file://fix_open_max_preprocessor_error.patch
   
  +# What once were warnings now are errors, fix those up
  +SRC_URI += file://werror-address-fix.patch \
  +file://ptr-to-int-cast-fix.patch
  +
   PROTO_DEPS += xf86driproto dri2proto
   DEPENDS += font-util
   EXTRA_OECONF += --enable-dri --enable-dri2 --enable-dga
  @@ -13,3 +17,4 @@ LIC_FILES_CHKSUM = 
  file://COPYING;md5=3dd2bbe3563837f80ed8926b06c1c353
   SRC_URI[md5sum] = 5bef6839a76d029204ab31aa2fcb5201
   SRC_URI[sha256sum] = 
  864831f51e841ff37f2445d1c85b86b559c8860a435fb496aead4f256a2b141d
   
  +PR = r1
  diff --git 
  a/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
   
  b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  new file mode 100644
  index 000..705cffc
  --- /dev/null
  +++ 
  b/common/recipes-graphics/xorg-xserver/xserver-xorg-1.9.3/ptr-to-int-cast-fix.patch
  @@ -0,0 +1,92 @@
  +Upstream-Status: Inappropriate [already upstream]
  +
  +It's broken for devices with BARs above 4G, and the sysfs method should  
 
  +work everywhere anyway.  As a pleasant side effect, this fixes some  
 
  +warnings:
 
  + 
 
  +fbdevhw.c: In function 'fbdev_open_pci': 
 
  +fbdevhw.c:333:4: warning: cast from pointer to integer of different size 
 
  +fbdevhw.c:334:4: warning: cast from pointer to integer of different size 
 
  +fbdevhw.c:336:4: warning: cast from pointer to integer of different size 
 
  +fbdevhw.c:337:4: warning: cast from pointer to integer of different size 
 
  + 
 
  +Signed-off-by: Adam Jackson ajax (a] redhat.com
 
  +Integrated-by: Tom Zanussi tom.zanussi (a] intel.com
  +
  +Index:

Re: [yocto] qemu EFI build failure

2012-01-12 Thread Bodke, Kishore K 
I have only 
MACHINE_FEATURES += efi
KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc.

I am not having IMAGE_FSTYPES += live.

Thanks
Kishore.
-Original Message-
From: Hart, Darren 
Sent: Thursday, January 12, 2012 1:20 PM
To: Ahmad, Josef
Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A
Subject: Re: [yocto] qemu EFI build failure

On 01/12/2012 10:27 AM, Darren Hart wrote:
 
 
 On 01/12/2012 08:19 AM, Josef Ahmad wrote:
 I tried to build a qemux86 EFI image, by setting:
 - in my local.conf: IMAGE_FSTYPES += live
 - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi

 
 I haven't tried live images with QEMU. For one thing, they aren't really
 necessary as you can specify all the boot parameters on the qemu command
 line. Is there are reason you want to use the live image specifically?
 
 Also, in order to properly test EFI in QEMU, you will need to use an EFI
 BIOS - I believe you're aware of this already - but this isn't currently
 supported by the runqemu scripts that ship with yocto.
 
 The build gave me the following error:
 
 
 I'll do some test builds - it isn't clear to me what is going on here.
 
 snip
 


 Has anyone encountered the same error?  I'm not sure I set up the
 correct configuration. Also, is there another way to append efi to
 MACHINE_FEATURES rather than by modifying qemux86.conf?
 
 You should be able to do something like:
 MACHINE_FEATURES_append_qemux86 = efi
 
 Note that you will also need to enable the efi support in the kernel,
 which is done with the KERNEL_FEATURES variable, something like:
 KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc
 
 Either of these can be set in your local.conf.
 

More accurately:

MACHINE_FEATURES_append_qemux86= efi pcbios
KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc
IMAGE_FSTYPES += live

With these added to local.conf and building for qemux86 I see the same
configure failures reported by Kishore and Josef:

| ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
| acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from...

I've discussed in IRC with Nitin and he thinks this may be related to
the automake update and is looking into it.

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

Re: [yocto] qemu EFI build failure

2012-01-12 Thread Kamble, Nitin A 

I just sent a patch to oecore mailing list to fix the grub issue with automake 
1.11.2.

Thanks,
Nitin


 -Original Message-
 From: Hart, Darren
 Sent: Thursday, January 12, 2012 1:39 PM
 To: Bodke, Kishore K
 Cc: Ahmad, Josef; yocto@yoctoproject.org; Kamble, Nitin A
 Subject: Re: [yocto] qemu EFI build failure
 
 On 01/12/2012 01:28 PM, Bodke, Kishore K wrote:
  I have only
  MACHINE_FEATURES += efi
  KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc.
 
  I am not having IMAGE_FSTYPES += live.
 
 The live change is just to trigger the live image type which builds
 grub-efi-native for efi systems. qemux86 needs this added explicitly.
 
 --
 Darren
 
 
  Thanks
  Kishore.
  -Original Message-
  From: Hart, Darren
  Sent: Thursday, January 12, 2012 1:20 PM
  To: Ahmad, Josef
  Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A
  Subject: Re: [yocto] qemu EFI build failure
 
  On 01/12/2012 10:27 AM, Darren Hart wrote:
 
 
  On 01/12/2012 08:19 AM, Josef Ahmad wrote:
  I tried to build a qemux86 EFI image, by setting:
  - in my local.conf: IMAGE_FSTYPES += live
  - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES += efi
 
 
  I haven't tried live images with QEMU. For one thing, they aren't
 really
  necessary as you can specify all the boot parameters on the qemu
 command
  line. Is there are reason you want to use the live image
 specifically?
 
  Also, in order to properly test EFI in QEMU, you will need to use an
 EFI
  BIOS - I believe you're aware of this already - but this isn't
 currently
  supported by the runqemu scripts that ship with yocto.
 
  The build gave me the following error:
 
 
  I'll do some test builds - it isn't clear to me what is going on
 here.
 
  snip
 
 
 
  Has anyone encountered the same error?  I'm not sure I set up the
  correct configuration. Also, is there another way to append efi
 to
  MACHINE_FEATURES rather than by modifying qemux86.conf?
 
  You should be able to do something like:
  MACHINE_FEATURES_append_qemux86 = efi
 
  Note that you will also need to enable the efi support in the
 kernel,
  which is done with the KERNEL_FEATURES variable, something like:
  KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc
 
  Either of these can be set in your local.conf.
 
 
  More accurately:
 
  MACHINE_FEATURES_append_qemux86= efi pcbios
  KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc
  IMAGE_FSTYPES += live
 
  With these added to local.conf and building for qemux86 I see the
 same
  configure failures reported by Kishore and Josef:
 
  | ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded
 from...
  | acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from...
 
  I've discussed in IRC with Nitin and he thinks this may be related to
  the automake update and is looking into it.
 
 
 
 --
 Darren Hart
 Intel Open Source Technology Center
 Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] qemu EFI build failure

2012-01-12 Thread Kamble, Nitin A 
Here is the commit: 
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=nitin/misc

Nitin

 -Original Message-
 From: yocto-boun...@yoctoproject.org [mailto:yocto-
 boun...@yoctoproject.org] On Behalf Of Kamble, Nitin A
 Sent: Thursday, January 12, 2012 2:32 PM
 To: Hart, Darren; Bodke, Kishore K
 Cc: Ahmad, Josef; yocto@yoctoproject.org
 Subject: Re: [yocto] qemu EFI build failure
 
 
 I just sent a patch to oecore mailing list to fix the grub issue with
 automake 1.11.2.
 
 Thanks,
 Nitin
 
 
  -Original Message-
  From: Hart, Darren
  Sent: Thursday, January 12, 2012 1:39 PM
  To: Bodke, Kishore K
  Cc: Ahmad, Josef; yocto@yoctoproject.org; Kamble, Nitin A
  Subject: Re: [yocto] qemu EFI build failure
 
  On 01/12/2012 01:28 PM, Bodke, Kishore K wrote:
   I have only
   MACHINE_FEATURES += efi
   KERNEL_FEATURES_append_cedartrail += cfg/efi-ext.scc.
  
   I am not having IMAGE_FSTYPES += live.
 
  The live change is just to trigger the live image type which builds
  grub-efi-native for efi systems. qemux86 needs this added explicitly.
 
  --
  Darren
 
  
   Thanks
   Kishore.
   -Original Message-
   From: Hart, Darren
   Sent: Thursday, January 12, 2012 1:20 PM
   To: Ahmad, Josef
   Cc: yocto@yoctoproject.org; Bodke, Kishore K; Kamble, Nitin A
   Subject: Re: [yocto] qemu EFI build failure
  
   On 01/12/2012 10:27 AM, Darren Hart wrote:
  
  
   On 01/12/2012 08:19 AM, Josef Ahmad wrote:
   I tried to build a qemux86 EFI image, by setting:
   - in my local.conf: IMAGE_FSTYPES += live
   - in poly/meta/conf/machine/qemux86.conf: MACHINE_FEATURES +=
 efi
  
  
   I haven't tried live images with QEMU. For one thing, they aren't
  really
   necessary as you can specify all the boot parameters on the qemu
  command
   line. Is there are reason you want to use the live image
  specifically?
  
   Also, in order to properly test EFI in QEMU, you will need to use
 an
  EFI
   BIOS - I believe you're aware of this already - but this isn't
  currently
   supported by the runqemu scripts that ship with yocto.
  
   The build gave me the following error:
  
  
   I'll do some test builds - it isn't clear to me what is going on
  here.
  
   snip
  
  
  
   Has anyone encountered the same error?  I'm not sure I set up the
   correct configuration. Also, is there another way to append efi
  to
   MACHINE_FEATURES rather than by modifying qemux86.conf?
  
   You should be able to do something like:
   MACHINE_FEATURES_append_qemux86 = efi
  
   Note that you will also need to enable the efi support in the
  kernel,
   which is done with the KERNEL_FEATURES variable, something like:
   KERNEL_FEATURES_append_qemux86 = conf/efi-ext.scc
  
   Either of these can be set in your local.conf.
  
  
   More accurately:
  
   MACHINE_FEATURES_append_qemux86= efi pcbios
   KERNEL_FEATURES_append_qemux86= cfg/efi-ext.scc
   IMAGE_FSTYPES += live
  
   With these added to local.conf and building for qemux86 I see the
  same
   configure failures reported by Kishore and Josef:
  
   | ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded
  from...
   | acinclude.m4:363: grub_CHECK_STACK_ARG_PROBE is expanded from...
  
   I've discussed in IRC with Nitin and he thinks this may be related
 to
   the automake update and is looking into it.
  
 
 
  --
  Darren Hart
  Intel Open Source Technology Center
  Yocto Project - Linux Kernel
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Developer Manual Appendix B example

2012-01-12 Thread James Abernathy 
I'm trying to do the Developer Manual Appendix B example exactly as written
only changing the path to my home directory. When I get to B.1.8.3, bitbake
after patching the kernel calibrate.c and modifiing the path to the local
git repository for linux-yocto, I get an error on the build.  The log file
of the error is below:

[INFO] doing kernel configme
[INFO] Branch yocto/standard/common-pc/base used by common-pc-standard.scc
[INFO] collecting configs in ./meta/meta-series
mv: cannot stat
`/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.tmp.config*':
No such file or directory
creation of pre-processed config data failed
config of yocto/standard/common-pc/base (common-pc-standard.scc) failed
ERROR: Function 'do_kernel_configme' failed (see
/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/temp/log.do_kernel_configme.15214
for further information)

Any help would be appreciated.

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

Re: [yocto] Developer Manual Appendix B example

2012-01-12 Thread Bruce Ashfield 

On 12-01-12 09:50 PM, James Abernathy wrote:
I'm trying to do the Developer Manual Appendix B example exactly as 
written only changing the path to my home directory. When I get to 
B.1.8.3, bitbake after patching the kernel calibrate.c and modifiing 
the path to the local git repository for linux-yocto, I get an error 
on the build.  The log file of the error is below:


Funny how things tend to arrive in bunches. We just discussed this today 
on the
list. The meta-kernel-dev layer is tied to master, and causes this 
problem when
used with edison. And that's what you are seeing here. I'm going to 
create a edison

branch for meta-kernel-dev to match up the tool SRCREVs.

In the meantime, if you remove the kern-tools-native_git.bbappend from 
the meta-kernel-dev
layer, the AUTOREV setting will be removed, and you won't pull in tools 
that are too

new for the matching kernel.

Cheers,

Bruce



[INFO] doing kernel configme
[INFO] Branch yocto/standard/common-pc/base used by common-pc-standard.scc
[INFO] collecting configs in ./meta/meta-series
mv: cannot stat 
`/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.tmp.config*': 
No such file or directory

creation of pre-processed config data failed
config of yocto/standard/common-pc/base (common-pc-standard.scc) failed
ERROR: Function 'do_kernel_configme' failed (see 
/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/temp/log.do_kernel_configme.15214 
for further information)


Any help would be appreciated.

Jim A


___
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] Developer Manual Appendix B example

2012-01-12 Thread James Abernathy 
On Thu, Jan 12, 2012 at 9:54 PM, Bruce Ashfield 
bruce.ashfi...@windriver.com wrote:

 **
 On 12-01-12 09:50 PM, James Abernathy wrote:

 I'm trying to do the Developer Manual Appendix B example exactly as
 written only changing the path to my home directory. When I get to B.1.8.3,
 bitbake after patching the kernel calibrate.c and modifiing the path to the
 local git repository for linux-yocto, I get an error on the build.  The log
 file of the error is below:


 Funny how things tend to arrive in bunches. We just discussed this today
 on the
 list. The meta-kernel-dev layer is tied to master, and causes this problem
 when
 used with edison. And that's what you are seeing here. I'm going to create
 a edison
 branch for meta-kernel-dev to match up the tool SRCREVs.

 In the meantime, if you remove the kern-tools-native_git.bbappend from the
 meta-kernel-dev
 layer, the AUTOREV setting will be removed, and you won't pull in tools
 that are too
 new for the matching kernel.

 That worked as you said.  I thought it was odd how we did a git checkout
for Linux and Poky, but not the poky-extras repositories.

Jim A

Cheers,

 Bruce


 [INFO] doing kernel configme
 [INFO] Branch yocto/standard/common-pc/base used by common-pc-standard.scc
 [INFO] collecting configs in ./meta/meta-series
 mv: cannot stat
 `/home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/linux-qemux86-standard-build/.tmp.config*':
 No such file or directory
 creation of pre-processed config data failed
 config of yocto/standard/common-pc/base (common-pc-standard.scc) failed
 ERROR: Function 'do_kernel_configme' failed (see
 /home/jim/poky/build/tmp/work/qemux86-poky-linux/linux-yocto-3.0.4+git1+d05450e4aef02c1b7137398ab3a9f8f96da74f52_1+72671808fdbe69a9fe03fd8f094e7c59da04a28c-r2/temp/log.do_kernel_configme.15214
 for further information)

 Any help would be appreciated.

 Jim A


 ___
 yocto mailing 
 listyocto@yoctoproject.orghttps://lists.yoctoproject.org/listinfo/yocto



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

Re: [yocto] Developer Manual Appendix B example

2012-01-12 Thread Brian Hutchinson 
On Thu, Jan 12, 2012 at 9:54 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
 Funny how things tend to arrive in bunches. We just discussed this today

Ha!  Thanks Jim for making me feel better  at least I wasn't the
only one that had trouble ;-)

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

Re: [yocto] Unable to set system clock

2012-01-12 Thread Lauri Hintsala 

Hello guys,

On 01/11/2012 01:36 PM, Gary Thomas wrote:

There is a bug #1767 that can make the system always reset the clock
to the saved timestamp on boot.

I am not pretty sure for this because I am able to set system clock
using freescale provided rootfs. This problem I am getting only with
poky rootfs. I guess I need to change some recipe. It would be a great
help if you can help me in that.


The problem is that even when you set the date, your Poky system
does not use it when the system is rebooted because of this bug.

The simplest work-around (until the bug fix is finalized) is to
add the 'coreutils' package to your image.


I found the same bug and I fixed it in December. I didn't know there was 
open bug related to that. Anyway patch is available in master branch of 
poky: 
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=91367de75575e79a94b2f90b6b7aa8740a039fc5


Regards,
Lauri Hintsala
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto