Date   

Re: Build Yocto image for EeePC901

Darren Hart <dvhart@...>
 

On 07/19/2011 07:49 PM, Li, Simon wrote:
Hi, Darren,
Yes, I use poky-image-sato-live and it works well on EeePC901 now.
Since it run from USB drive directly, it runs quite slow.
Is there any way to install it into SSD driver from USB drive?
At boot time, press tab at the syslinux boot: prompt, it will list
"boot" and "install". It runs "boot" by default. Type "install" followed
by Enter and it will attempt to install on the hard disk - it will
destroy any data on the drive, so beware.

--
Darren

Thanks.

Best Regards,

Simon

-----Original Message-----
From: Darren Hart [mailto:dvhart@...]
Sent: Wednesday, July 20, 2011 2:36 AM
To: Li, Simon
Cc: yocto@...
Subject: Re: [yocto] Build Yocto image for EeePC901

On 07/18/2011 11:17 PM, Li, Simon wrote:
To whom may concern,

I tried to build Yocto for a real device, which is EeePC901. Because of
README.hardware mentioned.

Here are my steps:
# source poky-bernard-5.0.1/poky-init-build.env build-poky-5.0.1

Modify the local.conf (As attachment)

# bitbake poky-image-sato-directdisk

However I got the build failed, please refer to the attachment,
build_fail_log.txt

I think the key fail message is

| ERROR: Function 'poky-image-sato-directdisk: LIC_FILES_CHKSUM points
to invalid file: ${COREBASE}/LICENSE' failed

Is there any problem I got? Or where can I find the files? Thanks.
I _think_ this has to do with the move from POKY to CORE in the naming.
Looks like the directdisk image type may have been missed.

I suggest you try the poky-image-sato-live image and install from that.
The directdisk images have some known issues that I suspect will prevent
them from working for you.

--
Darren




Best Regards,



Simon





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


Re: Build Yocto image for EeePC901

Li, Simon <simon.li@...>
 

Hi, Darren,
Yes, I use poky-image-sato-live and it works well on EeePC901 now.
Since it run from USB drive directly, it runs quite slow.
Is there any way to install it into SSD driver from USB drive?
Thanks.

Best Regards,

Simon

-----Original Message-----
From: Darren Hart [mailto:dvhart@...]
Sent: Wednesday, July 20, 2011 2:36 AM
To: Li, Simon
Cc: yocto@...
Subject: Re: [yocto] Build Yocto image for EeePC901

On 07/18/2011 11:17 PM, Li, Simon wrote:
To whom may concern,

I tried to build Yocto for a real device, which is EeePC901. Because of
README.hardware mentioned.

Here are my steps:
# source poky-bernard-5.0.1/poky-init-build.env build-poky-5.0.1

Modify the local.conf (As attachment)

# bitbake poky-image-sato-directdisk

However I got the build failed, please refer to the attachment,
build_fail_log.txt

I think the key fail message is

| ERROR: Function 'poky-image-sato-directdisk: LIC_FILES_CHKSUM points
to invalid file: ${COREBASE}/LICENSE' failed

Is there any problem I got? Or where can I find the files? Thanks.
I _think_ this has to do with the move from POKY to CORE in the naming.
Looks like the directdisk image type may have been missed.

I suggest you try the poky-image-sato-live image and install from that.
The directdisk images have some known issues that I suspect will prevent
them from working for you.

--
Darren




Best Regards,



Simon





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


Re: Supporting upcoming distribution releases

niqingliang
 

Oh, sorry, I have found the git tree of openembedded-core.

On Wed, 2011-07-20 at 10:31 +0800, NiQingliang wrote:
update accroding your suggestion.
This patch is for bitbake indeed, but bitbake is not part of
openembedded. Is it RIGHT?


diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..acf4e96 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,34 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ # the 'python -V' need redirect to stdout
+ # once we can ensure every distribution has 'python2' (currently,
except
+ # ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ # and remove this patch.
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=""
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=$PY_BIN
+ break
+ fi
+ done
+ if [ -n "$PYTHON2_BIN" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ echo "NOTE: poky will use '$PY_BIN' to execute python code."
+ else
+ echo "ERROR: unable to find Python 2.x, BitBake requires
Python 2.6 or
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi


On Wed, 2011-07-20 at 09:13 +0800, Joshua Lock wrote:
On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
new version

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ # the 'python -V' need redirect to stdout
+ # once we can ensure every distribution has 'python2' (currently,
except
+ # ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ # and remove this patch.
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+ echo "WARNING: your default python is not 2.x, so autodetect..."
I'm not sure we need to print this.

+ PYTHON2_BIN=""
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=$PY_BIN
+ break
+ fi
+ done
+ if [ -n "$PYTHON2_BIN" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ echo "WARNING: poky will use '$PY_BIN' to execute python
code."
I can live without this message but if we do leave it in we should
probably call it a NOTE rather than WARNING.

+ else
+ echo "ERROR: poky can't find python 2.x."
Perhaps make this a little more informative?

ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.

+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi
I can verify that this works as expected (i.e. does nothing) on my
Fedora 15 machine with Python 2.7.1.

Could you submit the patch to the openembedded-core mailing list so that
it can be considered for inclusion in the Yocto project's shared
upstream?

Thanks,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
--
倪庆亮
TEL: 13588371863
E-MAIL: niqingliang@...
BLOG: http://niqingliang2003.wordpress.com


_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto
--
倪庆亮
TEL: 13588371863
E-MAIL: niqingliang@...
BLOG: http://niqingliang2003.wordpress.com


Re: Supporting upcoming distribution releases

niqingliang
 

update accroding your suggestion.
This patch is for bitbake indeed, but bitbake is not part of
openembedded. Is it RIGHT?


diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..acf4e96 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,34 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ # the 'python -V' need redirect to stdout
+ # once we can ensure every distribution has 'python2' (currently,
except
+ # ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ # and remove this patch.
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=""
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=$PY_BIN
+ break
+ fi
+ done
+ if [ -n "$PYTHON2_BIN" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ echo "NOTE: poky will use '$PY_BIN' to execute python code."
+ else
+ echo "ERROR: unable to find Python 2.x, BitBake requires
Python 2.6 or
+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi

On Wed, 2011-07-20 at 09:13 +0800, Joshua Lock wrote:
On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
new version

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ # the 'python -V' need redirect to stdout
+ # once we can ensure every distribution has 'python2' (currently,
except
+ # ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ # and remove this patch.
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+ echo "WARNING: your default python is not 2.x, so autodetect..."
I'm not sure we need to print this.

+ PYTHON2_BIN=""
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=$PY_BIN
+ break
+ fi
+ done
+ if [ -n "$PYTHON2_BIN" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ echo "WARNING: poky will use '$PY_BIN' to execute python
code."
I can live without this message but if we do leave it in we should
probably call it a NOTE rather than WARNING.

+ else
+ echo "ERROR: poky can't find python 2.x."
Perhaps make this a little more informative?

ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.

+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi
I can verify that this works as expected (i.e. does nothing) on my
Fedora 15 machine with Python 2.7.1.

Could you submit the patch to the openembedded-core mailing list so that
it can be considered for inclusion in the Yocto project's shared
upstream?

Thanks,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
--
倪庆亮
TEL: 13588371863
E-MAIL: niqingliang@...
BLOG: http://niqingliang2003.wordpress.com


Weekly test report for Yocto1.1 M2 RC3 20110717 build

Fan, WenhuaX <wenhuax.fan@...>
 

Hi, All

This is the weekly test report for Yocto1.1 M2 RC3 20110717 build. There are two new bug were found. All the lsb image build failed on autobuilder. For Crownbay image, Xorg eats lots of CPU’s resource after standby, and broken grub due to wrong root path. Standby and I2C issue still exist on Emenlow. Psplash failed issue exist on Blacksand in current build. 3D testing still is blocked on sugarbay. The rpm/zypper install/removal consume disk space issue still exists. Broken ldd issue still exist in current build also. For bug fixing, glxinfo and glxgears can work on Emenlow. Gcc/g++ can work in current images also. Parport_pc probe issue was fixed on Sugarbay.

NoteFor different images, they are built against different commit/branch on autobuilder. You can refer to “Commit Information” section for detailed information. The test report is archived @https://wiki.pokylinux.org/wiki/Yocto_1.1_Milestone_Test_Report

 

 

Test Summary:

---------------------------------------

 

Test Result Summary

Component

Target

Status

Comments

BSP

SugarBay

GOOD

3D testing blocked due to libsdl.so

CrownBay-emgd

GOOD

Xorg eats lots of CPU time after standby; broken grub due to wrong root path

JasperForest

GOOD

I/OAT DMA engine init failed;

Blacksand

GOOD

Psplash failed when boot up Yocto

eMenlow

GOOD

i2c_transfer error; Standby failed;

Beagleboard

GOOD

Everything runs well

Routerstationpro

GOOD

Everything runs well

Mpc8315e-rdb

GOOD

Everything runs well

QEMU

qemux86

GOOD

Perl not exist

qemux86-64

GOOD

Perl not exist

qemuarm

GOOD

Perl not exist

qemuppc

BUGGY

Perl not exist; unfs does not work with qemuppc.

qemumips

GOOD

Perl not exist

ADT

 

BUGGY

Unfs does not work with qemuppc;

 

Critical bugs, more than 50% test cases are blocked

 

Only Normal, Minor or Enhancement bugs, or less than 10% test cases failed

 

Normal, Major and Critical bugs, and more than 10% test cases failed

 

Detailed Test Result for each component

Target

Total TCs

Not Run

Passed

Failed

Not testable (Blocked)

Sugarbay Sato-SDK

59

0

57

0

2 (bug 883)

Jasperforest Sato-SDK

32

0

31

1 (bug 1188)

0

n450 Sato-SDK

56

0

56

0

0

eMenlow Sato-SDK

56

0

54

2(bug 310, 503)

0

Crownbay-Sato-SDK

56

0

56

0

0

Beagleboard

36

0

36

0

0

Routerstationpro

31

0

31

0

0

Mpc8315e-rdb

34

0

34

0

0

Qemux86-64 Sato

28

0

27

1 (bug 1172)

0

Qemux86-64 Sato-SDK

31

0

31

0

0

Qemux86 Sato

28

0

27

1 (bug 1172)

0

Qemux86 Sato-SDK

31

0

31

0

0

Qemumips Sato

28

0

27

1 (bug 1172)

0

Qemumips Sato-SDK

31

0

31

0

0

Qemuppc Sato

21

0

19

2 (bug 414, 1172)

0

Qemuppc Sato-SDK

24

0

23

1 (bug 414)

0

Qemuarm Sato

28

0

27

1 (bug 1172)

0

Qemuarm Sato-SDK

31

0

31

0

0

ADT

6

0

5

1 (bug 414)

0

Total

647

0

634

11

2

 

* You can check the detailed test result in attachment for each target.
** The failed/blocked case number is listed with failed cases’ bug number.

 

 

Commit Information

---------------------------------------

 

For Emenlow/Blacksand/Crownbay/Sugarbay/Jasperforest:

 

Tree/Branch: Poky/1.1_M2

Poky Commit id: fa4bcfdb73167f8159b88e5a4d711c0d37627a70

Meta Branch: 1.1_M2

Meta Commit id: 738d2bc6d1a0d7ff6589000893c1c8b4f983d76f

 

For Toolchain/Qemux86/Qemux86-64

 

Tree/Branch: Poky/1.1_M2

Poky Commit id: 93a2ca70482f09e93469481936302e7b6847156e

Meta Branch: 1.1_M2

Meta commit id1a6bcb62666b0fc67a66bd38a1c3f2a3399a249f

 

For qemuarm/mips/ppc/beagleboard/mpc8315e-rdb/routerstationpro:


Tree/Branch: Poky/1.1_M2
Poky Commit: 93a2ca70482f09e93469481936302e7b6847156e

 

 

Issue Summary

---------------------------------------

 

Component

Bug Number

Target Milestone

System & Core OS

Installation & Boot

Bug 1211 - [Blacksand] Psplash failed when boot up Yocto

1.1 M2

System Usage

Bug 1172: Perl not exist in sato image

1.1 M2

Bug 1174: [zypper/rpm] package install/removal costs lots of disk space

1.1 M3

Bug 1234: No response when I click the 'Install/Remove Software' icon

1.1 M4

Other

New! Bug 1257 - [crownbay] broken grub due to wrong root path

---

New! Bug 1258 -[crownbay] Xorg eats lots of CPU time after standby

---

ADT

Bug 414: [PPC] kernel panic when booting poky-image-sdk-qemuppc through UNFS

1.1 M3

 

 

Verified Fixed Bug:

---------------------------------------

 

1.       Bug 1187 - [sugarbay] parport_pc probe fail of 00:0b

2.     Bug 1233 - gcc can not work due to missing liblto_plugin.so with 20110708 build

3.     Bug 1235 - [Emenlow] Running glxinfo and glxgears commands failed.

4.       Bug 1237 - [sugarbay] Inconsistency detected by ld.so: dl-deps.c: 622: _dl_map_object_deps: Assertion `nlist > 1' failed!

 


Re: [PATCH] Add endianess macros used by previous endian-ness_handling.patch

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Jul 19, 2011 at 6:58 PM, Saul Wold <sgw@...> wrote:
Matthew:

Thanks for this patch.

What will happen on distros that do include these macros?  Will we get
redefines?  I don't see any conditional testing to determine if they exist
already.
I suspect redefines. I did compile this on a machine that did have the
defines in endian.h though and I got no messages from bitbake. I guess
I should check the compile log. Will do these things shortly.

-M


Re: Supporting upcoming distribution releases

Joshua Lock <josh@...>
 

On Thu, 2011-07-14 at 09:34 +0800, NiQingliang wrote:
new version

diff --git a/oe-init-build-env b/oe-init-build-env
index 77332a7..0fe1b5e 100755
--- a/oe-init-build-env
+++ b/oe-init-build-env
@@ -39,6 +39,35 @@ else
$OEROOT/scripts/oe-setup-builddir
unset OEROOT
unset BBPATH
+
+ # find the python 2.x, if the default python is not.
+ # NOTE:
+ # the 'python -V' need redirect to stdout
+ # once we can ensure every distribution has 'python2' (currently,
except
+ # ubuntu), we should change bitbake's shebang to '/usr/bin/env
python2',
+ # and remove this patch.
+ # precondition:
+ # $BUILDDIR is not NULL, but I doubt when it will be NULL.
+ # user have not made the file $BUILDDIR/python by himself.
+ if [ -z "`/usr/bin/env python -V 2>&1|grep '^Python 2\.'`" ]; then
+ echo "WARNING: your default python is not 2.x, so autodetect..."
I'm not sure we need to print this.

+ PYTHON2_BIN=""
+ for PY_BIN in `find /{usr/,}bin -regex '.*/python\(\|2\|2\.[0-9]*
\)'`; do
+ if [ -n "`$PY_BIN -V 2>&1|grep '^Python 2\.'`" ]; then
+ PYTHON2_BIN=$PY_BIN
+ break
+ fi
+ done
+ if [ -n "$PYTHON2_BIN" ]; then
+ ln -sf $PY_BIN $BUILDDIR/python
+ export PATH="$BUILDDIR:$PATH"
+ echo "WARNING: poky will use '$PY_BIN' to execute python
code."
I can live without this message but if we do leave it in we should
probably call it a NOTE rather than WARNING.

+ else
+ echo "ERROR: poky can't find python 2.x."
Perhaps make this a little more informative?

ERROR: unable to find Python 2.x, BitBake requires Python 2.6 or 2.7.

+ fi
+ unset PYTHON2_BIN
+ fi
+
[ -n "$BUILDDIR" ] && cd $BUILDDIR
fi
I can verify that this works as expected (i.e. does nothing) on my
Fedora 15 machine with Python 2.7.1.

Could you submit the patch to the openembedded-core mailing list so that
it can be considered for inclusion in the Yocto project's shared
upstream?

Thanks,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


Re: [PATCH 0/2][Image Creator] Hob Cache for speed up switching

Joshua Lock <josh@...>
 

On Mon, 2011-07-11 at 15:31 +0800, Ke Liping wrote:
From: Liping Ke <liping.ke@...>

The two patches are the implmentation of Hob Cache for accelarating
UI switching. If one configuration has been saved before, when user
switch back to the same configuration combination, we will use the
cache content instead of re-triggering parsing/loading phase.
I'm still not certain about merging this change, do you feel it's still
worth it once we've merged your change to reduce the tree generation
time?

If so we need to revise the second patch to invalidate the cached value
correctly. sdk-machine shouldn't affect the available packages but which
layers are enabled certainly will.

Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


Re: [PATCH 1/1][Image Creator] Remove unused target tree data for Hob

Joshua Lock <josh@...>
 

On Fri, 2011-07-15 at 11:31 +0800, Ke Liping wrote:
From: Liping Ke <liping.ke@...>

Since Hob only needes package dependency information, we can
create a new version of package information retrieving methods,
remove task dependency information, so that we can greatly
reduce data loading time for Hob

Signed-off-by: Liping Ke <liping.ke@...>
---
bitbake/lib/bb/cooker.py | 96 +++++++++++++++++++++++++++++++++++++---------
1 files changed, 77 insertions(+), 19 deletions(-)

diff --git a/bitbake/lib/bb/cooker.py b/bitbake/lib/bb/cooker.py
index 8badd2d..26ed2ae 100644
--- a/bitbake/lib/bb/cooker.py
+++ b/bitbake/lib/bb/cooker.py
@@ -296,13 +296,12 @@ class BBCooker:
if data.getVarFlag( e, 'python', envdata ):
logger.plain("\npython %s () {\n%s}\n", e, data.getVar(e, envdata, 1))

- def prepareTreeData(self, pkgs_to_build, task):
+ def prepareTreeData(self, pkgs_to_build, task, runqueue=True):
"""
Prepare a runqueue and taskdata object for iteration over pkgs_to_build
"""
# Need files parsed
self.updateCache()
-
# If we are told to do the None task then query the default task
if (task == None):
task = self.configuration.cmd
@@ -322,12 +321,22 @@ class BBCooker:
runlist.append([k, "do_%s" % task])
taskdata.add_unresolved(localdata, self.status)
I'd prefer this method end around, not take the runqueue parameter and
just be responsible for updating the cache and returning taskdata


- rq = bb.runqueue.RunQueue(self, self.configuration.data, self.status, taskdata, runlist)
- rq.rqdata.prepare()
-
- return taskdata, rq
-
- def generateDepTreeData(self, pkgs_to_build, task, more_meta=False):
+ # For some users, take Hob as example, we only need less dependency data
+ # mark this kind of user as "less_meta" data requester
+ if (runqueue):
+ rq = bb.runqueue.RunQueue(self, self.configuration.data, self.status, taskdata, runlist)
+ rq.rqdata.prepare()
+ return taskdata, rq
Runqueue construction could then be rolled into generateTaskDepTreeData

+ else:
+ tasks_fnid = []
+ if len(taskdata.tasks_name) == 0:
+ # Nothing to do
+ return
+ for task in xrange(len(taskdata.tasks_name)):
+ tasks_fnid.append(taskdata.tasks_fnid[task])
+ return taskdata, tasks_fnid
and creation of tasks_fnid could be rolled into generatePkgDepTreeData

+
+ def generateTaskDepTreeData(self, pkgs_to_build, task):
"""
Create a dependency tree of pkgs_to_build, returning the data.
When more_meta is set to True include summary, license and group
@@ -351,18 +360,10 @@ class BBCooker:
fn = taskdata.fn_index[fnid]
pn = self.status.pkg_fn[fn]
version = "%s:%s-%s" % self.status.pkg_pepvpr[fn]
- if more_meta:
- summary = self.status.summary[fn]
- lic = self.status.license[fn]
- section = self.status.section[fn]
if pn not in depend_tree["pn"]:
depend_tree["pn"][pn] = {}
depend_tree["pn"][pn]["filename"] = fn
depend_tree["pn"][pn]["version"] = version
- if more_meta:
- depend_tree["pn"][pn]["summary"] = summary
- depend_tree["pn"][pn]["license"] = lic
- depend_tree["pn"][pn]["section"] = section
Glad to see these go :-)

for dep in rq.rqdata.runq_depends[task]:
depfn = taskdata.fn_index[rq.rqdata.runq_fnid[dep]]
deppn = self.status.pkg_fn[depfn]
@@ -407,12 +408,69 @@ class BBCooker:
return depend_tree


+ def generatePkgDepTreeData(self, pkgs_to_build, task):
+ """
+ Create a dependency tree of pkgs_to_build, returning the data.
+ When more_meta is set to True include summary, license and group
+ information in the returned tree.
+ """
+ taskdata, tasks_fnid = self.prepareTreeData(pkgs_to_build, task, False)
per above tasks_fnid would be populated here.

+
+ seen_fnids = []
+ depend_tree = {}
+ depend_tree["depends"] = {}
+ depend_tree["pn"] = {}
+ depend_tree["rdepends-pn"] = {}
+ depend_tree["packages"] = {}
+ depend_tree["rdepends-pkg"] = {}
+
+ for task in xrange(len(tasks_fnid)):
+ fnid = tasks_fnid[task]
+ fn = taskdata.fn_index[fnid]
+ pn = self.status.pkg_fn[fn]
+ version = "%s:%s-%s" % self.status.pkg_pepvpr[fn]
+ summary = self.status.summary[fn]
+ lic = self.status.license[fn]
+ section = self.status.section[fn]
+ if pn not in depend_tree["pn"]:
+ depend_tree["pn"][pn] = {}
+ depend_tree["pn"][pn]["filename"] = fn
+ depend_tree["pn"][pn]["version"] = version
+ depend_tree["pn"][pn]["summary"] = summary
+ depend_tree["pn"][pn]["license"] = lic
+ depend_tree["pn"][pn]["section"] = section
+
+ if fnid not in seen_fnids:
+ seen_fnids.append(fnid)
+ packages = []
+
+ depend_tree["depends"][pn] = []
+ for dep in taskdata.depids[fnid]:
+ depend_tree["depends"][pn].append(taskdata.build_names_index[dep])
+
+ depend_tree["rdepends-pn"][pn] = []
+ for rdep in taskdata.rdepids[fnid]:
+ depend_tree["rdepends-pn"][pn].append(taskdata.run_names_index[rdep])
+
+ rdepends = self.status.rundeps[fn]
+ for package in rdepends:
+ packages.append(package)
+
+ for package in packages:
+ if package not in depend_tree["packages"]:
+ depend_tree["packages"][package] = {}
+ depend_tree["packages"][package]["pn"] = pn
+ depend_tree["packages"][package]["filename"] = fn
+ depend_tree["packages"][package]["version"] = version
+
+ return depend_tree
+
def generateDepTreeEvent(self, pkgs_to_build, task):
"""
Create a task dependency graph of pkgs_to_build.
Generate an event with the result
"""
- depgraph = self.generateDepTreeData(pkgs_to_build, task)
+ depgraph = self.generateTaskDepTreeData(pkgs_to_build, task)
bb.event.fire(bb.event.DepTreeGenerated(depgraph), self.configuration.data)

def generateDotGraphFiles(self, pkgs_to_build, task):
@@ -421,7 +479,7 @@ class BBCooker:
Save the result to a set of .dot files.
"""

- depgraph = self.generateDepTreeData(pkgs_to_build, task)
+ depgraph = self.generateTaskDepTreeData(pkgs_to_build, task)

# Prints a flattened form of package-depends below where subpackages of a package are merged into the main pn
depends_file = file('pn-depends.dot', 'w' )
@@ -628,7 +686,7 @@ class BBCooker:
pkgs = pkgs + extra_pkgs

# generate a dependency tree for all our packages
- tree = self.generateDepTreeData(pkgs, 'build', more_meta=True)
+ tree = self.generatePkgDepTreeData(pkgs, 'build')
bb.event.fire(bb.event.TargetsTreeGenerated(tree), self.configuration.data)

def buildWorldTargetList(self):
Looking good to me. The revised patch would ideally be sent to
bitbake-devel@...

Thanks,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


Re: [PATCH] Add endianess macros used by previous endian-ness_handling.patch

Saul Wold <sgw@...>
 

On 07/19/2011 04:37 PM, Matthew McClintock wrote:
Some distro's don't include these macros in /usr/include/endian.h
so we include them via this patch
Matthew:

Thanks for this patch.

What will happen on distros that do include these macros? Will we get redefines? I don't see any conditional testing to determine if they exist already.


Signed-off-by: Matthew McClintock<msm@...>
---
This fixes builds on my CentOS 5.5 box

.../ldconfig-native-2.12.1/endianess-header.patch | 102 ++++++++++++++++++++
meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb | 5 +-
2 files changed, 105 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch

diff --git a/meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch b/meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch
new file mode 100644
index 0000000..3653967

We need to track information about the patch in the patch itself, so can you please add details here and include a Signed-off-by line.

For information about commits and patches, please see
http://wiki.openembedded.org/index.php/Commit_Patch_Message_Guidelines

Also, this kind of patch actually goes to the openembedded-core@... email list.

Thanks for the patch submission.

Sau!

--- /dev/null
+++ b/meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch
@@ -0,0 +1,102 @@
+diff -purN ldconfig-native-2.12.1.orig/endian_extra.h ldconfig-native-2.12.1/endian_extra.h
+--- ldconfig-native-2.12.1.orig/endian_extra.h 1969-12-31 18:00:00.000000000 -0600
++++ ldconfig-native-2.12.1/endian_extra.h 2011-07-19 18:09:14.323048417 -0500
+@@ -0,0 +1,61 @@
++/* Copyright (C) 1992, 1996, 1997, 2000, 2008 Free Software Foundation, Inc.
++ This file is part of the GNU C Library.
++
++ The GNU C Library is free software; you can redistribute it and/or
++ modify it under the terms of the GNU Lesser General Public
++ License as published by the Free Software Foundation; either
++ version 2.1 of the License, or (at your option) any later version.
++
++ The GNU C Library is distributed in the hope that it will be useful,
++ but WITHOUT ANY WARRANTY; without even the implied warranty of
++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ Lesser General Public License for more details.
++
++ You should have received a copy of the GNU Lesser General Public
++ License along with the GNU C Library; if not, write to the Free
++ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
++ 02111-1307 USA. */
++
++#include<endian.h>
++
++#ifndef _ENDIAN_EXTRA_H
++#define _ENDIAN_EXTRA_H 1
++
++#ifdef __USE_BSD
++/* Conversion interfaces. */
++# include<byteswap.h>
++
++# if __BYTE_ORDER == __LITTLE_ENDIAN
++# define htobe16(x) __bswap_16 (x)
++# define htole16(x) (x)
++# define be16toh(x) __bswap_16 (x)
++# define le16toh(x) (x)
++
++# define htobe32(x) __bswap_32 (x)
++# define htole32(x) (x)
++# define be32toh(x) __bswap_32 (x)
++# define le32toh(x) (x)
++
++# define htobe64(x) __bswap_64 (x)
++# define htole64(x) (x)
++# define be64toh(x) __bswap_64 (x)
++# define le64toh(x) (x)
++# else
++# define htobe16(x) (x)
++# define htole16(x) __bswap_16 (x)
++# define be16toh(x) (x)
++# define le16toh(x) __bswap_16 (x)
++
++# define htobe32(x) (x)
++# define htole32(x) __bswap_32 (x)
++# define be32toh(x) (x)
++# define le32toh(x) __bswap_32 (x)
++
++# define htobe64(x) (x)
++# define htole64(x) __bswap_64 (x)
++# define be64toh(x) (x)
++# define le64toh(x) __bswap_64 (x)
++# endif
++#endif
++
++#endif /* endian_extra.h */
+diff -purN ldconfig-native-2.12.1.orig/cache.c ldconfig-native-2.12.1/cache.c
+--- ldconfig-native-2.12.1.orig/cache.c 2011-07-19 18:21:28.347041301 -0500
++++ ldconfig-native-2.12.1/cache.c 2011-07-19 18:22:54.118048064 -0500
+@@ -39,6 +39,8 @@
+ # define N_(msgid) msgid
+ #define _(msg) msg
+
++#include "endian_extra.h"
++
+ extern int be;
+
+ static uint16_t write16(uint16_t x, int be)
+diff -purN ldconfig-native-2.12.1.orig/readelflib.c ldconfig-native-2.12.1/readelflib.c
+--- ldconfig-native-2.12.1.orig/readelflib.c 2011-07-19 18:21:28.346041593 -0500
++++ ldconfig-native-2.12.1/readelflib.c 2011-07-19 18:23:05.324059875 -0500
+@@ -25,6 +25,9 @@
+
+ /* check_ptr checks that a pointer is in the mmaped file and doesn't
+ point outside it. */
++
++#include "endian_extra.h"
++
+ #undef check_ptr
+ #define check_ptr(ptr) \
+ do \
+diff -purN ldconfig-native-2.12.1.orig/readlib.c ldconfig-native-2.12.1/readlib.c
+--- ldconfig-native-2.12.1.orig/readlib.c 2011-07-19 18:21:28.346041593 -0500
++++ ldconfig-native-2.12.1/readlib.c 2011-07-19 18:23:23.877046210 -0500
+@@ -40,6 +40,8 @@
+
+ #include "ldconfig.h"
+
++#include "endian_extra.h"
++
+ #define _(msg) msg
+
+ #define Elf32_CLASS ELFCLASS32
diff --git a/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb b/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
index bacf9f8..00edb6e 100644
--- a/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
+++ b/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
@@ -9,9 +9,10 @@ SRC_URI = "file://ldconfig-native-2.12.1.tar.bz2 \
file://ldconfig_aux-cache_path_fix.patch \
file://32and64bit.patch \
file://endian-ness_handling.patch \
- file://flag_fix.patch "
+ file://flag_fix.patch \
+ file://endianess-header.patch"

-PR = "r0"
+PR = "r1"

inherit native


[PATCH] Add endianess macros used by previous endian-ness_handling.patch

Matthew McClintock
 

Some distro's don't include these macros in /usr/include/endian.h
so we include them via this patch

Signed-off-by: Matthew McClintock <msm@...>
---
This fixes builds on my CentOS 5.5 box

.../ldconfig-native-2.12.1/endianess-header.patch | 102 ++++++++++++++++++++
meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb | 5 +-
2 files changed, 105 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch

diff --git a/meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch b/meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch
new file mode 100644
index 0000000..3653967
--- /dev/null
+++ b/meta/recipes-core/eglibc/ldconfig-native-2.12.1/endianess-header.patch
@@ -0,0 +1,102 @@
+diff -purN ldconfig-native-2.12.1.orig/endian_extra.h ldconfig-native-2.12.1/endian_extra.h
+--- ldconfig-native-2.12.1.orig/endian_extra.h 1969-12-31 18:00:00.000000000 -0600
++++ ldconfig-native-2.12.1/endian_extra.h 2011-07-19 18:09:14.323048417 -0500
+@@ -0,0 +1,61 @@
++/* Copyright (C) 1992, 1996, 1997, 2000, 2008 Free Software Foundation, Inc.
++ This file is part of the GNU C Library.
++
++ The GNU C Library is free software; you can redistribute it and/or
++ modify it under the terms of the GNU Lesser General Public
++ License as published by the Free Software Foundation; either
++ version 2.1 of the License, or (at your option) any later version.
++
++ The GNU C Library is distributed in the hope that it will be useful,
++ but WITHOUT ANY WARRANTY; without even the implied warranty of
++ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
++ Lesser General Public License for more details.
++
++ You should have received a copy of the GNU Lesser General Public
++ License along with the GNU C Library; if not, write to the Free
++ Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
++ 02111-1307 USA. */
++
++#include <endian.h>
++
++#ifndef _ENDIAN_EXTRA_H
++#define _ENDIAN_EXTRA_H 1
++
++#ifdef __USE_BSD
++/* Conversion interfaces. */
++# include <byteswap.h>
++
++# if __BYTE_ORDER == __LITTLE_ENDIAN
++# define htobe16(x) __bswap_16 (x)
++# define htole16(x) (x)
++# define be16toh(x) __bswap_16 (x)
++# define le16toh(x) (x)
++
++# define htobe32(x) __bswap_32 (x)
++# define htole32(x) (x)
++# define be32toh(x) __bswap_32 (x)
++# define le32toh(x) (x)
++
++# define htobe64(x) __bswap_64 (x)
++# define htole64(x) (x)
++# define be64toh(x) __bswap_64 (x)
++# define le64toh(x) (x)
++# else
++# define htobe16(x) (x)
++# define htole16(x) __bswap_16 (x)
++# define be16toh(x) (x)
++# define le16toh(x) __bswap_16 (x)
++
++# define htobe32(x) (x)
++# define htole32(x) __bswap_32 (x)
++# define be32toh(x) (x)
++# define le32toh(x) __bswap_32 (x)
++
++# define htobe64(x) (x)
++# define htole64(x) __bswap_64 (x)
++# define be64toh(x) (x)
++# define le64toh(x) __bswap_64 (x)
++# endif
++#endif
++
++#endif /* endian_extra.h */
+diff -purN ldconfig-native-2.12.1.orig/cache.c ldconfig-native-2.12.1/cache.c
+--- ldconfig-native-2.12.1.orig/cache.c 2011-07-19 18:21:28.347041301 -0500
++++ ldconfig-native-2.12.1/cache.c 2011-07-19 18:22:54.118048064 -0500
+@@ -39,6 +39,8 @@
+ # define N_(msgid) msgid
+ #define _(msg) msg
+
++#include "endian_extra.h"
++
+ extern int be;
+
+ static uint16_t write16(uint16_t x, int be)
+diff -purN ldconfig-native-2.12.1.orig/readelflib.c ldconfig-native-2.12.1/readelflib.c
+--- ldconfig-native-2.12.1.orig/readelflib.c 2011-07-19 18:21:28.346041593 -0500
++++ ldconfig-native-2.12.1/readelflib.c 2011-07-19 18:23:05.324059875 -0500
+@@ -25,6 +25,9 @@
+
+ /* check_ptr checks that a pointer is in the mmaped file and doesn't
+ point outside it. */
++
++#include "endian_extra.h"
++
+ #undef check_ptr
+ #define check_ptr(ptr) \
+ do \
+diff -purN ldconfig-native-2.12.1.orig/readlib.c ldconfig-native-2.12.1/readlib.c
+--- ldconfig-native-2.12.1.orig/readlib.c 2011-07-19 18:21:28.346041593 -0500
++++ ldconfig-native-2.12.1/readlib.c 2011-07-19 18:23:23.877046210 -0500
+@@ -40,6 +40,8 @@
+
+ #include "ldconfig.h"
+
++#include "endian_extra.h"
++
+ #define _(msg) msg
+
+ #define Elf32_CLASS ELFCLASS32
diff --git a/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb b/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
index bacf9f8..00edb6e 100644
--- a/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
+++ b/meta/recipes-core/eglibc/ldconfig-native_2.12.1.bb
@@ -9,9 +9,10 @@ SRC_URI = "file://ldconfig-native-2.12.1.tar.bz2 \
file://ldconfig_aux-cache_path_fix.patch \
file://32and64bit.patch \
file://endian-ness_handling.patch \
- file://flag_fix.patch "
+ file://flag_fix.patch \
+ file://endianess-header.patch"

-PR = "r0"
+PR = "r1"

inherit native

--
1.7.5


Minutes: Yocto Technical Team (Tuesday, July 19, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

Liu, Song <song.liu@...>
 

Really sorry if many of the past meeting agenda and minutes have not been able to reach you. I had some problems with the Yocto project mailing list. Please let me know if you hear anyone still having this problem.

Thanks!
Song

Attendees:
Mark, Dave, Paul, Shane, Saul, Beth, Richard, Josh, Jason (TI), Darren, Sean (Dell), Song
 
New action list:
 
* Team: please take a look at the post 1.1 items on the wiki page and let Song know if there is any comment or concerns.
* Saul: Talk to Jianjun, QA should work with developers to make sure we can cover more distro testing (informal) before major release. Joshua and Darren volunteers for some of these testing.
* Beth/Darren/ScottR: document the central location in the release, and put any doc changes in the location after release.
* Song to setup go/no-go meeting next Monday to decide on the M2 release.
 
Agenda:
 
- opens - 5 min 
- Review Yocto 1.1 M2 Release Criteria - 20 min (Song) See details at: https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria
* All M2 features are completed.
* 'Lock kernel version' should be moved to M4 and will be completed between 8/8/11 and 8/15/11.
* All release criteria are green except testing related ones. Please see the wiki page.
* For M2 release, we should let Beth go ahead with the release as if we would be releasing M2 on time next Monday. On the other hand, we let QA run the full test. We will have a go/no-go meeting next Monday to decide if we release M2 based on the full test result of RC3.
 
- Review M3 status and schedule - 10 min (Song)
* All M3 committed features are on track. We need someone to handle multi-lib 9 and 8 tasks after Mark is done with them.
* Darren's two features (reduce image size and reduce boot time) should be all marked risky for M3. Darren will work on them separately in independent layers that won't affect 1.1 release so that his development work can be extended with more time.
 
- Discussion of using Weighted Defect density as one of the release criteria: (4th graph at: https://wiki.yoctoproject.org/wiki/Yocto_Bug_Trend ) - 10 min
 
* The team has concern that this will discourage developers from filing bugs.
* There is no perfect measure but it's better if we have measure to make sure we deliver quality software.
* This should not discourage QA and developers in the community from filing bugs.
* There are a lot of fixes that went in without leaving a track in Bugzilla.
* We will talk about this in 1.2 planning and try this out in 1.2 development and see how it goes.
 
- Opens - 10 min
1. Darren: documentation process for release, making sure we can update the README.hardware after release if needed.
* We should have a central location for putting doc changes after release. We don't have to update the release tarball.
 
 
- Action Item Review - 5 min (Song)
 
Action item list:
* Saul: talk to Jianjun, QA should work with developers to make sure we can cover more distro testing (informal) before major release. Joshua and Darren volunteers for some of these testing.
* Song: check status with Jianjun on Stabilization tasks he owned. (Done)
* Darren/Song: define deliverables of 'Fast boot time' for M3 and Yocto 1.1. (Done)
* Saul: circulate the idea of having a Sprint B for M3 via emails. (Done). Will just extend Sprint A to 27th.
* Saul: check update commits (one release criteria) (Done)
* Team: please take a look at the post 1.1 items on the wiki page and let Song know if there is any comment or concerns.


Re: Build Yocto image for EeePC901

Darren Hart <dvhart@...>
 

On 07/18/2011 11:17 PM, Li, Simon wrote:
To whom may concern,

I tried to build Yocto for a real device, which is EeePC901. Because of
README.hardware mentioned.

Here are my steps:
# source poky-bernard-5.0.1/poky-init-build.env build-poky-5.0.1

Modify the local.conf (As attachment)

# bitbake poky-image-sato-directdisk

However I got the build failed, please refer to the attachment,
build_fail_log.txt

I think the key fail message is

| ERROR: Function 'poky-image-sato-directdisk: LIC_FILES_CHKSUM points
to invalid file: ${COREBASE}/LICENSE' failed

Is there any problem I got? Or where can I find the files? Thanks.
I _think_ this has to do with the move from POKY to CORE in the naming.
Looks like the directdisk image type may have been missed.

I suggest you try the poky-image-sato-live image and install from that.
The directdisk images have some known issues that I suspect will prevent
them from working for you.

--
Darren




Best Regards,



Simon





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


Re: pseudo issue on CentOS5

McClintock Matthew-B29882 <B29882@...>
 

On Tue, Jul 19, 2011 at 12:06 PM, Joshua Lock <josh@...> wrote:
You can use 'objdump -T' for this, i.e. (from my F15 box):
joshual@scimitar:~
$ objdump -T /lib/libc.so.6 | grep realpath
416c3f00 g    DF .text  00000041 (GLIBC_2.0)  realpath
415e60e0 g    DF .text  00000478  GLIBC_2.3   realpath
4169a330 g    DF .text  00000037  GLIBC_2.4   __realpath_chk
Bug updated with:

[mattsm@busy poky (master)]$ cat /etc/issue
CentOS release 5.6 (Final)
Kernel \r on an \m

[mattsm@busy poky (master)]$ objdump -T /lib/libc.so.6 | grep realpath
009cca90 g DF .text 0000003f (GLIBC_2.0) realpath
008f75c0 g DF .text 000004c1 GLIBC_2.3 realpath
009a8030 g DF .text 00000038 GLIBC_2.4 __realpath_chk


[PATCH v2 5/5] flac: fix build issues with e500v2 (gnuspe) toolchain

Kumar Gala <galak@...>
 

For a PPC target flac will try to build with altivec optimizations.
Altivec and SPE are mutually exclusive options. Between flac's
configure choices and the ppce500v2 tune file options we'd end up with
a compile invocation with the following arguments:

-mabi=spe -mspe -mabi=altivec -maltivec

Which would cause the compile to fail due to the mutual exclusion.

Pulled in a patch from the debian SPE port that addresses this issue:

http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2010-June/010212.html

Signed-off-by: Kumar Gala <galak@...>
---
.../flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch | 74 ++++++++++++++++++++
meta/recipes-multimedia/flac/flac_1.2.1.bb | 5 +-
2 files changed, 77 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch

diff --git a/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch b/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch
new file mode 100644
index 0000000..8626336
--- /dev/null
+++ b/meta/recipes-multimedia/flac/flac-1.2.1/0001-No-AltiVec-on-SPE.patch
@@ -0,0 +1,74 @@
+From f9b017c2c958d968cc5dfd36dc68fc8e5fb89a58 Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior <bigeasy@...>
+Date: Fri, 11 Jun 2010 09:48:58 +0200
+Subject: [PATCH] No AltiVec on SPE
+
+Consider *gnuspe which matches powerpc-unknown-linux-gnuspe where
+AltiVec is not available at all. This triplet uses SPE which is
+incompatible with AltiVec shares the same opcode range and can't be used
+at all.
+
+Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...>
+---
+ configure.in | 8 ++++++++
+ src/libFLAC/Makefile.am | 10 +++++++++-
+ 2 files changed, 17 insertions(+), 1 deletions(-)
+
+diff --git a/configure.in b/configure.in
+index bfa6d8e..17b7c73 100644
+--- a/configure.in
++++ b/configure.in
+@@ -82,6 +82,14 @@ case "$host" in
+ *) OBJ_FORMAT=elf ;;
+ esac
+ AC_SUBST(OBJ_FORMAT)
++case "$host" in
++ *-gnuspe)
++ abi_spe=true
++ AC_DEFINE(FLAC__CPU_PPC_SPE)
++ AH_TEMPLATE(FLAC__CPU_PPC_SPE, [define if building for PowerPC with SPE ABI])
++ ;;
++esac
++AM_CONDITIONAL(FLaC__CPU_PPC_SPE, test "x$abi_spe" = xtrue)
+
+ # only needed because of ntohl() usage, can get rid of after that's gone:
+ case "$host" in
+diff --git a/src/libFLAC/Makefile.am b/src/libFLAC/Makefile.am
+index cbfb0ac..5785372 100644
+--- a/src/libFLAC/Makefile.am
++++ b/src/libFLAC/Makefile.am
+@@ -40,8 +40,13 @@ if FLaC__SYS_DARWIN
+ CPUCFLAGS = -faltivec -force_cpusubtype_ALL -DFLAC__NO_ASM
+ else
+ # Linux-gcc for PPC does not have -force_cpusubtype_ALL, it is Darwin-specific
++CPUCFLAGS =
++if FLaC__CPU_PPC_SPE
++else
++CPUCFLAGS += -maltivec -mabi=altivec
++endif
+ #@@@ PPC optimizations temporarily disabled
+-CPUCFLAGS = -maltivec -mabi=altivec -DFLAC__NO_ASM
++CPUCFLAGS += -DFLAC__NO_ASM
+ endif
+ endif
+
+@@ -58,6 +63,8 @@ endif
+ if FLaC__CPU_PPC
+ ARCH_SUBDIRS = ppc
+ if FLaC__HAS_AS__TEMPORARILY_DISABLED
++if FLaC__CPU_PPC_SPE
++else
+ LOCAL_EXTRA_LIBADD = ppc/as/libFLAC-asm.la
+ LOCAL_EXTRA_LDFLAGS = "-Wl,-read_only_relocs,warning"
+ else
+@@ -68,6 +75,7 @@ endif
+ endif
+ endif
+ endif
++endif
+
+ libFLAC_la_LIBADD = $(LOCAL_EXTRA_LIBADD) @OGG_LIBS@
+
+--
+1.5.6.5
+
diff --git a/meta/recipes-multimedia/flac/flac_1.2.1.bb b/meta/recipes-multimedia/flac/flac_1.2.1.bb
index 92bcec6..fc8e14f 100644
--- a/meta/recipes-multimedia/flac/flac_1.2.1.bb
+++ b/meta/recipes-multimedia/flac/flac_1.2.1.bb
@@ -14,12 +14,13 @@ LIC_FILES_CHKSUM = "file://COPYING.FDL;md5=ad1419ecc56e060eccf8184a87c4285f \
file://include/FLAC/all.h;beginline=64;endline=69;md5=64474f2b22e9e77b28d8b8b25c983a48"
DEPENDS = "libogg"

-PR = "r0"
+PR = "r1"

SRC_URI = "${SOURCEFORGE_MIRROR}/flac/flac-${PV}.tar.gz \
file://disable-xmms-plugin.patch;patch=1 \
file://flac-gcc43-fixes.patch;patch=1 \
- file://xmms.m4"
+ file://xmms.m4 \
+ file://0001-No-AltiVec-on-SPE.patch"

SRC_URI[md5sum] = "153c8b15a54da428d1f0fadc756c22c7"
SRC_URI[sha256sum] = "9635a44bceb478bbf2ee8a785cf6986fba525afb5fad1fd4bba73cf71f2d3edf"
--
1.7.3.4


[PATCH v2 4/5] openssl: Add handling for linux-gnuspe-powerpc

Kumar Gala <galak@...>
 

If trying to build for an e500v2 target openssl will fail to build since
the configure script didn't know how to handle a 'gnuspe' target.

Signed-off-by: Kumar Gala <galak@...>
---
meta/recipes-connectivity/openssl/openssl.inc | 3 +++
.../recipes-connectivity/openssl/openssl_0.9.8r.bb | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-connectivity/openssl/openssl.inc b/meta/recipes-connectivity/openssl/openssl.inc
index 39143ad..79620b3 100644
--- a/meta/recipes-connectivity/openssl/openssl.inc
+++ b/meta/recipes-connectivity/openssl/openssl.inc
@@ -80,6 +80,9 @@ do_configure () {
linux-powerpc)
target=linux-ppc
;;
+ linux-gnuspe-powerpc)
+ target=linux-ppc
+ ;;
linux-supersparc)
target=linux-sparcv8
;;
diff --git a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb b/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
index ea83cb8..344747f 100644
--- a/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
+++ b/meta/recipes-connectivity/openssl/openssl_0.9.8r.bb
@@ -1,6 +1,6 @@
require openssl.inc

-PR = "r3"
+PR = "r4"
SRC_URI += "file://debian/ca.patch \
file://debian/config-hurd.patch;apply=no \
file://debian/debian-targets.patch \
--
1.7.3.4


[PATCH v2 3/5] tune-ppce500v2: Add a tune file for PowerPC e500v2 cores

Kumar Gala <galak@...>
 

Signed-off-by: Kumar Gala <galak@...>
---
meta/conf/machine/include/tune-ppce500v2.inc | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc

* Removed TARGET_OS_powerpc (not needed)

diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
new file mode 100644
index 0000000..d76dbc9
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce500v2.inc
@@ -0,0 +1,4 @@
+TARGET_CC_ARCH = "-mcpu=8548 -mabi=spe -mspe"
+BASE_PACKAGE_ARCH = "ppce500v2"
+FEED_ARCH = "ppce500v2"
+PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
--
1.7.3.4


[PATCH v2 2/5] tclibc-*libc: Utilize TARGET_FPU for gnuspe setting

Kumar Gala <galak@...>
 

Its possible that BASE_PACKAGE_ARCH isn't set to ppce500 or ppce500v2 when
we build native toolchains. So we can utilize TARGET_FPU being set to
'ppc-efd' or 'ppc-efs' to determine if we should enable the gnuspe ABI.

Signed-off-by: Kumar Gala <galak@...>
---
meta/conf/distro/include/tclibc-eglibc.inc | 2 +-
meta/conf/distro/include/tclibc-glibc.inc | 2 +-
meta/conf/distro/include/tclibc-uclibc.inc | 1 +
3 files changed, 3 insertions(+), 2 deletions(-)

* Use ppc-efs, ppc-efd instead of spe
* Added change to uclibc as well

diff --git a/meta/conf/distro/include/tclibc-eglibc.inc b/meta/conf/distro/include/tclibc-eglibc.inc
index e070aad..9fab4dc 100644
--- a/meta/conf/distro/include/tclibc-eglibc.inc
+++ b/meta/conf/distro/include/tclibc-eglibc.inc
@@ -5,7 +5,7 @@
TARGET_OS = "linux"
TARGET_OS_arm = "linux-gnueabi"
TARGET_OS_armeb = "linux-gnueabi"
-TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"
+TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"

# Add glibc overrides to the overrides for eglibc.
OVERRIDES .= ":libc-glibc"
diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
index 5e7afc1..0370dfa 100644
--- a/meta/conf/distro/include/tclibc-glibc.inc
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -5,7 +5,7 @@
TARGET_OS = "linux"
TARGET_OS_arm = "linux-gnueabi"
TARGET_OS_armeb = "linux-gnueabi"
-TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in ['ppce500', 'ppce500v2']]}"
+TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"

# Add glibc to the overrides.
OVERRIDES =. "libc-glibc:"
diff --git a/meta/conf/distro/include/tclibc-uclibc.inc b/meta/conf/distro/include/tclibc-uclibc.inc
index 65693a9..2ccda5b 100644
--- a/meta/conf/distro/include/tclibc-uclibc.inc
+++ b/meta/conf/distro/include/tclibc-uclibc.inc
@@ -5,6 +5,7 @@
TARGET_OS = "linux-uclibc"
TARGET_OS_arm = "linux-uclibceabi"
TARGET_OS_armeb = "linux-uclibceabi"
+TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efd', 'ppc-efs']]}"

# Add uclibc overrides to the overrides.
OVERRIDES =. "libc-uclibc:"
--
1.7.3.4


[PATCH v2 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI

Kumar Gala <galak@...>
 

The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "ppc-efd" to distinguish this choice (Embedded
scalar single-precision floating-point). When building the toolchain for
this ABI we need configure gcc with --enable-e500_double.

Signed-off-by: Kumar Gala <galak@...>
---
meta/recipes-devtools/gcc/gcc-4.6.inc | 2 +-
meta/recipes-devtools/gcc/gcc-common.inc | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc-4.6.inc b/meta/recipes-devtools/gcc/gcc-4.6.inc
index 56064b5..b719155 100644
--- a/meta/recipes-devtools/gcc/gcc-4.6.inc
+++ b/meta/recipes-devtools/gcc/gcc-4.6.inc
@@ -1,6 +1,6 @@
require gcc-common.inc

-PR = "r8"
+PR = "r9"

# Third digit in PV should be incremented after a minor release
# happens from this branch on gcc e.g. currently its 4.6.0
diff --git a/meta/recipes-devtools/gcc/gcc-common.inc b/meta/recipes-devtools/gcc/gcc-common.inc
index 7bf036c..1684e78 100644
--- a/meta/recipes-devtools/gcc/gcc-common.inc
+++ b/meta/recipes-devtools/gcc/gcc-common.inc
@@ -12,6 +12,8 @@ FILESDIR = "${@os.path.dirname(bb.data.getVar('FILE',d,1))}/gcc-${PV}"
def get_gcc_fpu_setting(bb, d):
if bb.data.getVar('TARGET_FPU', d, 1) in [ 'soft' ]:
return "--with-float=soft"
+ if bb.data.getVar('TARGET_FPU', d, 1) in [ 'ppc-efd' ]:
+ return "--enable-e500_double"
return ""

def get_gcc_mips_plt_setting(bb, d):
--
1.7.3.4


[PATCH v2 0/5] Add support for PowerPC e500v2/SPE

Kumar Gala <galak@...>
 

The majority of support for the PowerPC e500v2/SPE target already
exists. However some minor cleans are required to get things working
completely.

The e500v2 utilizes a unique floating point programming model / ABI from
other PowerPC targets and thus requires special handling.

- k