Re: [yocto] [PATCH 0/5] Add support for PowerPC e500v2/SPE
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] building crownbay images
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/5] Add support for PowerPC e500v2/SPE
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI
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
>> 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
>>> ---
>>> 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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] pseudo issue on CentOS5
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. -M ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Agenda: Yocto Technical Team - (July 19, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))
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 - Review M3 status and schedule - 10 min (Song) - 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 - Opens - 10 min * Darren: documentation process for release, making sure we can update the README.hardware after release if needed. - 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. * Darren/Song: define deliverables of 'Fast boot time' for M3 and Yocto 1.1. * Saul: circulate the idea of having a Sprint B for M3 via emails. * Saul: check update commits (one release criteria) * 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. Conference details Conference name: Yocto Technical Team Conference date/start time: Tue Jun 28, 2011 at 10:00 AM Central Daylight Time Participants: 30 Duration: 60 minutes Participant passcode: 49611427 Dial-in number: 1.972.995. US Toll Free number: 1.877.561.6828 BlackBerry users, click this link to join your conference as a chairperson: 1.972.995.x67184230# BlackBerry users, click this link to join your conference as a participant: 1.972.995.x49611427# Depending on where you are dialing from, either your BlackBerry will pause and enter the passcode automatically or you will be prompted to click again to dial the passcode. Local and Global Access Numbers Country Dial-in number Australia: 1800 636 843 Czech Republic: 242 430 350 China (Beijing): >From office dial 8-995 or 8784277 Beijing Out of Office dial 5878 4277 China (Shanghai): >From office dial 8-995 or 3073322 Shanghai Out of Office dial 2307 3322 China (Shenzen): >From office dial 8-995 or 6007877 Shenzen Out of Office dial 2600 7877 China (Other Cities): >From IP phone dial 8-995 Other cities - Non IP phone dial 021-23073322 Denmark: 8060 1400 Finland: 09 41333477 France: 0497 275888 Germany: 08161 803232 Holland: 030 2417490 India: BSNL subscribers use 1800 425 9996 (Toll Free) Airtel subscribers use 0008 009 861 212 (Toll Free) >From TI Campus use 8995 Others use 2509 9555 (Landline within Bangalore) or 80 2509 9555 (Outside Bangalore) Israel: 09 790 6715 Italy: 039 69061234 (039 is local city code not country code) Japan: >From TI Campus use 8 995 Outside TI use 03 4331 3777 Malaysia: >From IP phone dial 2643799 >From Kuala Lumpur dial 4264 3799 Outside Kuala Lumpur dial (03)4264 3799 Norway: 2 295 8744 Philippines: >From Baguio City use 4471177 >From Metro Manila area use 8702477 Singapore: >From IP phone dial 3894777 Outside TI use 6389 4777 South Korea: >From IP phone dial 5606998 >From Seoul dial 5606998 Outside Seoul dial (02)5606998 Sweden: 08 58755577 Taiwan: >From IP phone dial 1363 >From Taipei dial 2241 1363 Outside Taipei dial (02)2241 1363 Turkey: Landline Only dial 0811 288 0001 then enter 877 633 1123 UK: 01604 663003 US: 972 995 or 1877 561 6828 Recurring conferences First scheduled conference: Tue Jun 28, 2011 Recurrence frequency: Weekly - Every 1 week(s) on Tuesday Recurrence ends: End on Fri Jun 22, 2012, 10:40 AM CDT ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Build Yocto image for EeePC901
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
NOTE: package task-poky-x11-sato-1.0-r30: task do_compile: Succeeded
NOTE: Running task 4394 of 5844 (ID: 279,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/tasks/task-poky-x11-sato.bb,
do_install)
NOTE: package task-poky-x11-sato-1.0-r30: task do_install: Started
NOTE: package task-poky-x11-sato-1.0-r30: task do_install: Succeeded
NOTE: Running task 4395 of 5844 (ID: 270,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/tasks/task-poky.bb,
do_configure)
NOTE: package task-poky-1.0-r33: task do_configure: Started
NOTE: package task-poky-1.0-r33: task do_configure: Succeeded
NOTE: Running task 4396 of 5844 (ID: 271,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/tasks/task-poky.bb,
do_compile)
NOTE: package task-poky-1.0-r33: task do_compile: Started
NOTE: package task-poky-1.0-r33: task do_compile: Succeeded
NOTE: Running task 4397 of 5844 (ID: 266,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/tasks/task-poky.bb,
do_install)
NOTE: package task-poky-1.0-r33: task do_install: Started
NOTE: package task-poky-1.0-r33: task do_install: Succeeded
NOTE: Running task 4398 of 5844 (ID: 257,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-core/tasks/task-base.bb,
do_configure)
NOTE: package task-base-1.0-r69: task do_configure: Started
NOTE: package task-base-1.0-r69: task do_configure: Succeeded
NOTE: Running task 4399 of 5844 (ID: 258,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-core/tasks/task-base.bb,
do_compile)
NOTE: package task-base-1.0-r69: task do_compile: Started
NOTE: package task-base-1.0-r69: task do_compile: Succeeded
NOTE: Running task 4400 of 5844 (ID: 253,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-core/tasks/task-base.bb,
do_install)
NOTE: package task-base-1.0-r69: task do_install: Started
NOTE: package task-base-1.0-r69: task do_install: Succeeded
NOTE: Running task 4401 of 5844 (ID: 7,
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/images/poky-image-sato-directdisk.bb,
do_configure)
NOTE: package poky-image-sato-directdisk-1.0-r0: task do_configure: Started
ERROR: Function 'poky-image-sato-directdisk: LIC_FILES_CHKSUM points to invalid
file: ${COREBASE}/LICENSE' failed
ERROR: Logfile of failure stored in:
/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/build-poky-5.0.1/tmp/work/core2-poky-linux/poky-image-sato-directdisk-1.0-r0/temp/log.do_configure.7341
Log data follows:
| NOTE: Checking autotools environment for common misconfiguration
| ERROR: Function 'poky-image-sato-directdisk: LIC_FILES_CHKSUM points to
invalid file: ${COREBASE}/LICENSE' failed
NOTE: package poky-image-sato-directdisk-1.0-r0: task do_configure: Failed
ERROR: Task 7
(/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/images/poky-image-sato-directdisk.bb,
do_configure) failed with exit code '1'
Waiting for 1 active tasks to finish:
0: zypper-1.5.3-git1+2c5bb6ceb99ecd950ef993e43d77bf0569ea0582-r5 do_compile
(pid 5879)
NOTE: package zypper-1.5.3-git1+2c5bb6ceb99ecd950ef993e43d77bf0569ea0582-r5:
task do_compile: Succeeded
ERROR:
'/media/588d449a-9bd9-4d87-aae1-6e3e86c669b3/poky-bernard-5.0.1/meta/recipes-sato/images/poky-image-sato-directdisk.bb'
failed
local.conf
Description: local.conf
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] native gcc compiler error
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 >>> 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 0x4100 = 0xf676e75, with >> unknown capability 0x1 = 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 root26344 Jul 16 22:40 lto-wrapper >>60 -rwxr-xr-x 1 root root60132 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trying to create OpenDDS recipe
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
| :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 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.our...@covidien.com
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI
On Mon, Jul 18, 2011 at 11:47 PM, 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
>> 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
>>> ---
>>> 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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/5] Add support for PowerPC e500v2/SPE
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@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/5] Add support for PowerPC e500v2/SPE
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 0/5] Add support for PowerPC e500v2/SPE
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] building crownbay images
> From: yocto-boun...@yoctoproject.org [mailto:yocto- > boun...@yoctoproject.org] 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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo issue on CentOS5
On Fri, 2011-07-15 at 21:23 +, 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 gDF .text 0041 (GLIBC_2.0) realpath 415e60e0 gDF .text 0478 GLIBC_2.3 realpath 4169a330 gDF .text 0037 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 1/5] gcc: Add gcc configure for PowerPC e500v2/SPE embedded floating point ABI
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
---
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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 0/5] Add support for PowerPC e500v2/SPE
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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 3/5] tune-ppce500v2: Add a tune file for PowerPC e500v2 cores
Signed-off-by: Kumar Gala --- 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 000..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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 4/5] openssl: Add handling for linux-gnuspe-powerpc
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
---
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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 5/5] flac: fix build issues with e500v2 (gnuspe) toolchain
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
---
.../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 000..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
+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
+---
+ 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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH v2 2/5] tclibc-*libc: Utilize TARGET_FPU for gnuspe setting
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
---
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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo issue on CentOS5
On Tue, Jul 19, 2011 at 12:06 PM, Joshua Lock 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 0041 (GLIBC_2.0) realpath > 415e60e0 g DF .text 0478 GLIBC_2.3 realpath > 4169a330 g DF .text 0037 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 gDF .text 003f (GLIBC_2.0) realpath 008f75c0 gDF .text 04c1 GLIBC_2.3 realpath 009a8030 gDF .text 0038 GLIBC_2.4 __realpath_chk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Technical Team (Tuesday, July 19, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))
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. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Add endianess macros used by previous endian-ness_handling.patch
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 --- 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 000..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.0 -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 ++ ++#ifndef _ENDIAN_EXTRA_H ++#define _ENDIAN_EXTRA_H 1 ++ ++#ifdef __USE_BSD ++/* Conversion interfaces. */ ++# include ++ ++# 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.c2011-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.c2011-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" i
Re: [yocto] [PATCH] Add endianess macros used by previous endian-ness_handling.patch
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 --- 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 000..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-c...@openembedded.org 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.0 -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 ++ ++#ifndef _ENDIAN_EXTRA_H ++#define _ENDIAN_EXTRA_H 1 ++ ++#ifdef __USE_BSD ++/* Conversion interfaces. */ ++# include ++ ++# 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.c2011-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.c2011-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 +
Re: [yocto] [PATCH 1/1][Image Creator] Remove unused target tree data for Hob
On Fri, 2011-07-15 at 11:31 +0800, Ke Liping wrote:
> From: 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
> ---
> 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
Re: [yocto] [PATCH 0/2][Image Creator] Hob Cache for speed up switching
On Mon, 2011-07-11 at 15:31 +0800, Ke Liping wrote: > From: 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] Add endianess macros used by previous endian-ness_handling.patch
On Tue, Jul 19, 2011 at 6:58 PM, Saul Wold 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 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Supporting upcoming distribution releases
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: niqingli...@insigma.com.cn
> BLOG: http://niqingliang2003.wordpress.com
>
>
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
倪庆亮
TEL:13588371863
E-MAIL: niqingli...@insigma.com.cn
BLOG: http://niqingliang2003.wordpress.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Build Yocto image for EeePC901
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:dvh...@linux.intel.com]
Sent: Wednesday, July 20, 2011 2:36 AM
To: Li, Simon
Cc: yocto@yoctoproject.org
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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
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] Build Yocto image for EeePC901
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:dvh...@linux.intel.com]
> Sent: Wednesday, July 20, 2011 2:36 AM
> To: Li, Simon
> Cc: yocto@yoctoproject.org
> 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@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
