Date   

Re: pseudo issue on CentOS5

Joshua Lock <josh@...>
 

On Fri, 2011-07-15 at 21:23 +0000, McClintock Matthew-B29882 wrote:
This bug: http://bugzilla.yoctoproject.org/show_bug.cgi?id=1177 only
occurs on my CentOS 5 boxes (not on my Fedora 13 box). I have
determined that this git patch
4b66ce472871618cfe4761861392b7f9c3c265b0 is causing the problem.
Reverting the patch fixes this.

Still looking at this more but I thought I would share this with
everyone and see if anyone has a more specific reason why this is
happening.
I filed bug #1251[1] based on our conversation on IRC and a brief follow
on with Mark, who does some pseudo work.

Mark indicated that we'll need to check glibc on the CentOS machine and
find the symbol and versions for all of the realpath functions.

I need to set up a CentOS VM before I can get around to this but if you
get opportunity you could do so and update the bug?

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

Thanks,
Joshua

1. http://bugzilla.yoctoproject.org/show_bug.cgi?id=1251
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre


Re: building crownbay images

David Stewart
 

From: yocto-bounces@... [mailto:yocto-
bounces@...] On Behalf Of Andre Haupt

Hi all,

I am new to Yocto and to Distro work in general.

I want to use Yocto on the Kontron nanoETXexpressTT boards.
(http://de.kontron.com/products/computeronmodules/com+express/com+
express+ultra/nanoetxexpresstt.html)

These boards are based on the Intel Atom E6xx and the EG20T platform
controller hub, so i think it is a good idea to start with the crownbay BSP.

What would be the best, known to work, way to produce crownbay-noemgd
images for poky bernard?
Should i use git? Which branches should i use (the docs are contraditing at
least in parts)?
Hi Andre - Tom is on holiday this week, so let me take a stab at this.

"Known to be good" - I try to make sure that the tarballs on the project website are a good way to go. These are on www.yoctoproject.org/download and then click "BSP Downloads". You can also get them from a git branch, but I don't know for sure which it is.

I read somewhere, that i should install Yocto to /usr/local/src/yocto.
Is this really necessary?
I don't. I just create a subdirectory in my home dir and untar the release there.

If you create and use the App Developer Tools, installing the cross tools in /opt/ is common.

Thanks for any hints.

regards,

Andre

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


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

Saul Wold <sgw@...>
 

On 07/19/2011 08:40 AM, Kumar Gala wrote:

On Jul 19, 2011, at 10:32 AM, Saul Wold wrote:

On 07/19/2011 06:17 AM, Kumar Gala wrote:

On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:


Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:

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.

These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
Will do so, it was unclear to me how patches go from oe-core to/from yocto.
Kumar,

If it goes into the meta/recipes or meta/conf area then it goes to oe-core, if the patch is the PPC machine-specific and changes are in meta-yocto, then it should go to the yocto ml.

As mentioned above, all these patches should go to oe-core

I hope that clears things up.

Sau!
Its a start, how to things go from oe-core git to yocto git?
Richard Purdie the maintainer for both has a process he uses to merge changes from oe-core to yocto. Anything in oe-core will be merged into yocto's meta directory.

Sau!

- k


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

Kumar Gala <galak@...>
 

On Jul 19, 2011, at 10:32 AM, Saul Wold wrote:

On 07/19/2011 06:17 AM, Kumar Gala wrote:

On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:


Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:

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.

These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
Will do so, it was unclear to me how patches go from oe-core to/from yocto.
Kumar,

If it goes into the meta/recipes or meta/conf area then it goes to oe-core, if the patch is the PPC machine-specific and changes are in meta-yocto, then it should go to the yocto ml.

As mentioned above, all these patches should go to oe-core

I hope that clears things up.

Sau!
Its a start, how to things go from oe-core git to yocto git?

- k


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

Saul Wold <sgw@...>
 

On 07/19/2011 06:17 AM, Kumar Gala wrote:

On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:


Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:

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.

These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
Will do so, it was unclear to me how patches go from oe-core to/from yocto.
Kumar,

If it goes into the meta/recipes or meta/conf area then it goes to oe-core, if the patch is the PPC machine-specific and changes are in meta-yocto, then it should go to the yocto ml.

As mentioned above, all these patches should go to oe-core

I hope that clears things up.

Sau!

- k
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Weekly test report for Yocto1.1 M2 RC3 20110717 build

Xu, Jiajun <jiajun.xu@...>
 

Hi, All

       This is the weekly test report for Yocto 1.1 M2 RC3 20110717 build. Since all lsb images build failed on autobuilder, jasperforest testing is performed against sato-sdk. There are 2 new bugs found in this testing. The 2 bugs are all for crownbay image – kernel not loadable due to broken grug and Xorg eats lots of CPU resource after standby. The old 2 HIGH bugs still exist but we have workaround to continue the testing – psplash failed to load on blacksand and broken ldd with wrong path to ld.so. 3D testing could not be performed on sugarbay due to lack of libsdl.so. There is no critical bug blocking QA in this weekly testing.

       For bug fixing, the 4 HIGH priority bugs in RC2 are fixed – X server failed on crownbay; gcc can not work; glx commands not work on emenlow; Inconsistency detected by ld.so on sugarbay.

Note: For different images, they are built against different commit/branch on autobuilder. You can refer to “Commit Information” section for detailed information.

Currently we have finished 100% weekly testing. 60% of fullpass test cases have not been executed. Core build testing is almost finished now. Next we will finish the other components testing, including power/performance testing, compliance testing and stress testing.

 

Test Summary:

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

Test Result Summary

Component

Target

Status

Comments

BSP

SugarBay

GOOD

3D testing blocked due to lack of 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

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

Bug 1236 - Broken ldd due to wrong path for ld.so

1.1 M3

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!

 

Best Regards,

Jiajun

 


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

Khem Raj
 

On Mon, Jul 18, 2011 at 11:47 PM, Kumar Gala <galak@...> wrote:

On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "spe" to distinguish this choice.  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..409ad01 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 [ 'spe' ]:
+        return "--enable-e500_double"
    return ""
this will enable e500_double even for e500v1 which IIRC does not have
DFP support
have you tried building for e500v1 with this ?
I think you are correct.  Any suggestions on how to distinguish e500v1 vs e500v2?  Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.

I could do:

TARGET_FPU = "ppc-efs"  [Embedded scalar single-precision floating-point]
TARGET_FPU = "ppc-efd"  [Embedded scalar double-precision floating-point]
thats fine. using spfp or dpfp is another option.
however you have to make sure that TARGET_FPU is not checking for spe
anywhere in whole tree


Than meta/recipes-devtools/gcc/gcc-common.inc:

 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 ""

And meta/conf/distro/include/tclibc-*libc.inc:

TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"

thoughts?

- k


Trying to create OpenDDS recipe

Paul Ourada
 

I hope this is the correct place to post this. If not, please let me
know.

I'm trying to create a recipe for OpenDDS. The recipe works so far as
fetching, unpacking, and configuration. Or it seems to. :) Part of the
configuration piece is that it also pulls down ACE+TAO real-time CORBA.
This part works fine as well.

I set S as follows to match the unpacking directories enforced by the
tar file:

S = ${WORKINGDIR}/DDS

The package comes with a configuration script pre-built, and it expects
to be told where glibc is. So, I write do_configure as follows:

EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"

do_configure() {
${S}/configure ${EXTRA_OECONF}
}

The problem that I run into is during compilation. I write the following
for do_compile()

do_compile() {
oenote ${STAGING_DIR}
cd ${S} && make
}

This works right up until there is a compile error in ACE+TAO. Of
course, I build the entire DDS package, including ACE+TAO, with no
hiccups in Ubuntu, so I understand that this is a
cross-compile/environment issue.

The compile error is that it cannot find features.h, which is clearly in
${STAGING_LIBDIR}/${MACHINE}/usr/include. The compile command which is
being executed is as follows (this is going to be ugly, let me know if
there's a better way to include this, such as a pastebin somewhere):

| make[1]: Entering directory
`/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
_wrappers/TAO/TAO_IDL'
|
| GNUmakefile:
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/TAO/TAO_IDL/GNUmakefile.TAO_IDL_EXE MAKEFLAGS=w
|
| i586-poky-linux-g++ -march=i586
--sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86
-fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith
-ggdb -pipe -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE
-I/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/AC
E_wrappers -DACE_HAS_EXCEPTIONS -DACE_NO_INLINE -I../.. -Iinclude
-Ibe_include -Ife -I.. -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++
-march=i586 --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"
-c -o .obj/driver/drv_preproc.o driver/drv_preproc.cpp
| <command-line>:0:22: warning: missing terminating " character
| In file included from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-linux-common.h:30:0,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-linux.h:14,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config.h:1,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-macros.h:24,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-lite.h:24,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/os_include/os_limits.h:21,
| from include/idl_defines.h:70,
| from driver/drv_preproc.cpp:70:
|
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-posix.h:7:20: fatal error: unistd.h: No such file or
directory
| compilation terminated.
| make[1]: *** [.obj/driver/drv_preproc.o] Error 1
| make[1]: Leaving directory
`/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
_wrappers/TAO/TAO_IDL'
| make: *** [TAO_IDL_EXE] Error 2
| ERROR: Function 'do_compile' failed (see
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/temp
/log.do_compile.17412 for further information)
NOTE: package opendds-2.3-r0: task do_compile: Failed
ERROR: Task 5
(/opt/yocto/poky-bernard-5.0.1/meta/recipes-middleware/opendds/opendds_2
.3.bb, do_compile) failed with exit code '1'

The thing that is puzzling me is that --sysroot seems to be pointing in
the general direction of ${STAGING_DIR} and so the include directive,
#include <features.h> should be good. I have checked, and features.h is
in the /usr/include subdirectory there.

Does anyone have a clue they could lend me?

Thanks,

Paul E. Ourada
Sr. Principal Software Engineer
Covidien, Energy-based Devices
5920 Longbow Drive
Boulder, CO 80301
paul.ourada@...
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741


Re: native gcc compiler error

Kumar Gala <galak@...>
 

On Jul 18, 2011, at 12:22 PM, Saul Wold wrote:

On 07/18/2011 07:54 AM, Kumar Gala wrote:

On Jul 18, 2011, at 9:45 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 5:58 AM, Kumar Gala<galak@...> wrote:
I've been working on trying to get an e500v2 (linux-gnuspe) compiler working and seem to have build a native toolchain. However when I try and compile a simple hello world style app I get:

root@p2020-ds:~# gcc float.c
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
compilation terminated.

Wondering if anyone's seen this before and had any ideas.
You can try -fno-use-linker-plugin as a workaround. Does
liblto_plugin.so exist on target rfs ?
it might be then gcc driver bug if the library is not there then we
forgot to package it.
File appears to be there:
root@p2020-ds:/# file /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0
./usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/liblto_plugin.so.0.0.0: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked, with unknown capability 0x41000000 = 0xf676e75, with unknown capability 0x10000 = 0x70402, stripped

root@p2020-ds:~# ls -lstr /usr/libexec/gcc/powerpc-poky-linux-gnuspe/4.6.1/
total 31624
9812 -rwxr-xr-x 1 root root 10046304 Jul 16 22:40 lto1
28 -rwxr-xr-x 1 root root 26344 Jul 16 22:40 lto-wrapper
60 -rwxr-xr-x 1 root root 60132 Jul 16 22:40 liblto_plugin.so.0.0.0
124 -rwxr-xr-x 1 root root 124776 Jul 16 22:40 collect2
11208 -rwxr-xr-x 1 root root 11476244 Jul 16 22:40 cc1plus
10392 -rwxr-xr-x 1 root root 10640644 Jul 16 22:40 cc1
0 lrwxrwxrwx 1 root root 22 Jul 17 15:07 liblto_plugin.so.0 -> liblto_plugin.so.0.0.0

So not clear why its not finding it.
This looks similar to Yocto Bug 1233 (http://bugzilla.yoctoproject.org/show_bug.cgi?id=1233

Can you confirm if you have the following commit in your branch?
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=2429773613cb95b6a0541b5cce6ce1338d5cfc2b

It's possible you might be missing this and it's not finding the file correctly.

As Richard mentioned also, an strace output would be helpful if you do have the above commit.

Thanks
Sau!
So it appears the fix for bug 1233 isn't complete. Should I re-open the bug or a new one?

- k


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

Kumar Gala <galak@...>
 

Adding openembedded-core to see if any feedback on my query.

- k

On Jul 19, 2011, at 1:47 AM, Kumar Gala wrote:


On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "spe" to distinguish this choice. 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..409ad01 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 [ 'spe' ]:
+ return "--enable-e500_double"
return ""
this will enable e500_double even for e500v1 which IIRC does not have
DFP support
have you tried building for e500v1 with this ?
I think you are correct. Any suggestions on how to distinguish e500v1 vs e500v2? Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.

I could do:

TARGET_FPU = "ppc-efs" [Embedded scalar single-precision floating-point]
TARGET_FPU = "ppc-efd" [Embedded scalar double-precision floating-point]

Than meta/recipes-devtools/gcc/gcc-common.inc:

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 ""

And meta/conf/distro/include/tclibc-*libc.inc:

TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"

thoughts?

- k
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


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

Kumar Gala <galak@...>
 

On Jul 19, 2011, at 2:44 AM, Koen Kooi wrote:


Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:

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.

These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree
Will do so, it was unclear to me how patches go from oe-core to/from yocto.

- k


building crownbay images

Andre Haupt <andre@...>
 

Hi all,

I am new to Yocto and to Distro work in general.

I want to use Yocto on the Kontron nanoETXexpressTT boards.
(http://de.kontron.com/products/computeronmodules/com+express/com+express+ultra/nanoetxexpresstt.html)

These boards are based on the Intel Atom E6xx and the EG20T platform
controller hub, so i think it is a good idea to start with the crownbay
BSP.

What would be the best, known to work, way to produce crownbay-noemgd images
for poky bernard?
Should i use git? Which branches should i use (the docs are contraditing
at least in parts)?

I read somewhere, that i should install Yocto to /usr/local/src/yocto.
Is this really necessary?

Thanks for any hints.

regards,

Andre


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

Koen Kooi
 

Op 19 jul 2011, om 07:21 heeft Kumar Gala het volgende geschreven:

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.

These should be sent to the oe-core list against the oe-core tree, not the poky list against the poky tree


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

Kumar Gala <galak@...>
 

On Jul 19, 2011, at 1:04 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "spe" to distinguish this choice. 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..409ad01 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 [ 'spe' ]:
+ return "--enable-e500_double"
return ""
this will enable e500_double even for e500v1 which IIRC does not have
DFP support
have you tried building for e500v1 with this ?
I think you are correct. Any suggestions on how to distinguish e500v1 vs e500v2? Utilizing BASE_PACKAGE_ARCH has problems w/native builds since it seems to get set to x86_64 at some point.

I could do:

TARGET_FPU = "ppc-efs" [Embedded scalar single-precision floating-point]
TARGET_FPU = "ppc-efd" [Embedded scalar double-precision floating-point]

Than meta/recipes-devtools/gcc/gcc-common.inc:

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 ""

And meta/conf/distro/include/tclibc-*libc.inc:

TARGET_OS_powerpc = "linux${@['','-gnuspe'][bb.data.getVar('TARGET_FPU',d,1) in ['ppc-efs', 'ppc-efd']]}"

thoughts?

- k


Re: [PATCH 2/5] tclibc-*glibc: Utilize TARGET_FPU for gnuspe setting

Kumar Gala <galak@...>
 

On Jul 19, 2011, at 1:08 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
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
"spe" 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 +-
2 files changed, 2 insertions(+), 2 deletions(-)
similar change is needed for tclibc-uclibc.inc as well. something like

TARGET_OS_powerpc =
"linux-uclibc${@['','spe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in
['ppce500', 'ppce500v2']]}"
I can add it, but unshure if anyone has e500/spe working with uclibc.

- k


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

Kumar Gala <galak@...>
 

On Jul 19, 2011, at 1:01 AM, Khem Raj wrote:

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
Signed-off-by: Kumar Gala <galak@...>
---
meta/conf/machine/include/tune-ppce500v2.inc | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
create mode 100644 meta/conf/machine/include/tune-ppce500v2.inc

diff --git a/meta/conf/machine/include/tune-ppce500v2.inc b/meta/conf/machine/include/tune-ppce500v2.inc
new file mode 100644
index 0000000..9901045
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce500v2.inc
@@ -0,0 +1,5 @@
+TARGET_CC_ARCH = "-mcpu=8548 -mabi=spe -mspe"
+BASE_PACKAGE_ARCH = "ppce500v2"
+FEED_ARCH = "ppce500v2"
+PACKAGE_EXTRA_ARCHS = "powerpc ppce500v2"
+TARGET_OS_powerpc = "linux-gnuspe"
I think TARGET_OS is unwanted here
Thanks, left over from my debug attempts.

- k


[PATCH] tune-ppce500mc: Add a tune file for PowerPC e500mc core

Kumar Gala <galak@...>
 

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

diff --git a/meta/conf/machine/include/tune-ppce500mc.inc b/meta/conf/machine/include/tune-ppce500mc.inc
new file mode 100644
index 0000000..763ec1a
--- /dev/null
+++ b/meta/conf/machine/include/tune-ppce500mc.inc
@@ -0,0 +1,4 @@
+TARGET_CC_ARCH = "-mcpu=e500mc"
+BASE_PACKAGE_ARCH = "ppce500mc"
+FEED_ARCH = "ppce500mc"
+PACKAGE_EXTRA_ARCHS = "powerpc ppce500mc"
--
1.7.3.4


Build Yocto image for EeePC901

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

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.

 

Best Regards,

 

Simon

 


Re: [PATCH 2/5] tclibc-*glibc: Utilize TARGET_FPU for gnuspe setting

Khem Raj
 

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
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
"spe" 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 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
similar change is needed for tclibc-uclibc.inc as well. something like

TARGET_OS_powerpc =
"linux-uclibc${@['','spe'][bb.data.getVar('BASE_PACKAGE_ARCH',d,1) in
['ppce500', 'ppce500v2']]}"

diff --git a/meta/conf/distro/include/tclibc-eglibc.inc b/meta/conf/distro/include/tclibc-eglibc.inc
index e070aad..0cddcd4 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 ['spe']]}"

 # 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..22f7d29 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 ['spe']]}"

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

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


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

Khem Raj
 

On Mon, Jul 18, 2011 at 10:21 PM, Kumar Gala <galak@...> wrote:
The e500v2 core utilizes a unique floating point programming model / ABI.
We utilize TARGET_FPU = "spe" to distinguish this choice.  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..409ad01 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 [ 'spe' ]:
+        return "--enable-e500_double"
    return ""
this will enable e500_double even for e500v1 which IIRC does not have
DFP support
have you tried building for e500v1 with this ?

 def get_gcc_mips_plt_setting(bb, d):
--
1.7.3.4

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