Re: [yocto] [PATCH 1/3] Add -ptest package group
Paul Eggleton wrote: +DEPCHAIN_POST = -dev -dbg -ptest Is this really what you want? Surely the tests for a particular piece of software are mostly independent of those of its dependencies? You're right, that change is not necessary. I misunderstood the purpose of DEPCHAIN_POST. -- Björn ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] License information of tasks
On Fri, Aug 24, 2012 at 11:39:10AM +0100, Paul Eggleton wrote:
On Friday 24 August 2012 12:05:41 Markus Hubig wrote:
First: tasks are packages without content.
| rpm -qpl task-core-boot-1.0-r9.stamp9g20.rpm
| (contains no files)
... so why do they need some license information in the first place?
This is something that annoys me as well. I have thought about adding the
ability to declare that a license is not applicable for those recipes that
don't actually distribute any files, in which case a check during do_deploy,
do_package and do_populate_sysroot would be enabled that would fail if the
recipe ended up distributing anything. Unfortunately we don't have hooks in
all of the necessary places to make this practical, but it is still something
I would like to resolve.
Hmm, it seems you don't have to use LIC_FILES_CHKSUM in a image recipe. So
maybe one can adapt it from there ...
2) Set your own variable to the value of LAYERDIR in layer.conf and then use
that in the recipe; however that would make the recipe even more hardwired to
the specific layer.
Hmm OK but this seems nevertheless a good solution ... will try it.
3) Refer to a license file in ${COMMON_LICENSE_DIR}; this is discouraged as
it
may break if files in there are moved around although I think that is less
likely in future.
Also OK IMHO ...
4) Copy the license file into the directory containing the recipe. This is
the
recommended method for recipes that do actually distribute files, but seems
excessive for a task.
That's bad cause I have to duplicate all files this way. My first thought was
to use the License files I already included into my layers for this ...
Ultimately though is it really important that the license for a recipe that
distributes no files be any particular license?
Yes I also think these files (themselves) are covered my the layer license and
since they don't distribute any files don't need an additional license.
Maybe some day there will be a distinction of the licence information between
the Yocto stuff like Layers, tasks, images and recipes and the created
software.
Cheers, Markus
--
Human beings were created by water to transport it uphill.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.3 M3 Full Pass test results
Hello Richard, Even if the installer is used in the default mode, issues still occur (see comment 7). I think the root cause for these is the same, so I did not submit a new bug. Thank you, Laurentiu -Original Message- From: Purdie, Richard Sent: Friday, August 24, 2012 1:22 PM To: Serban, Laurentiu Cc: yocto@yoctoproject.org; Liu, Song; Stewart, David C; Wold, Saul Subject: Re: 1.3 M3 Full Pass test results On Thu, 2012-08-23 at 20:13 +0100, Serban, Laurentiu wrote: Here are the results for the full pas tests on 1.3 M3 RC2. The commit used for testing is 8b8748c8f963900b83dc0fdd7757556f917fe4fd. Some details about the encountered issues below: BSP – Sudoku-savant project build issue (2878) ADT – the relocatable sdk issue (2980) causes 13 test cases to be on faile/blocked state I thought it worked as long as you didn't have to relocate it so no tests should have been blocked, we just have the relocation issue? , also the Clutter C template issue is unsolved (2577) Core Build System – x32 is still an issue (2888), cleaning sstate issue is still not solved (2897), incremental RPM image generation (2969), source archiving (2619), the kvm issue was reproduced by another colleague (2790) Yocto BSP creation via JSON (2693) or for qemu (2991) fails, multilib issue (2918 – this requires a little more investigation from QA), HOB - all seems ok for RC2 Self-hosted-image - cannot start on Virtual Box (X issue), it is very slow on qemu and it has a m4 package build (3005) issue on VMWare. If the self-hosted-image is used on machine with internet connectivity via proxy there will be an initial sanity check failure, but this is not a blocking issue. A mention for the performance testing: on a Ubbuntu 12.04 i7 machine using 8 threads the build time was 83 minutes (with prior fetching). How does this compare with our other performance numbers. From what I remember, we used to hover around the 105-115 minute mark. Did we have some significant speed gains or is this just an artefact of changing the test machine? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [linux-yocto-3.2][PATCH] arm: Fix linking errors with binutils 2.23
On 12-08-22 04:22 PM, Khem Raj wrote: On Wed, Aug 22, 2012 at 12:24 PM, Bruce Ashfield bruce.ashfi...@windriver.com wrote: I haven't looked yet, will 3.4+ need the same fix ? yes looking at 3.4 code. But havent tried that yet I've merged this to the 3.2 tree and the 3.4 tree. I haven't seen any build failures, but then again, I wasn't seeing any before :) It's pushed to the kernel trees, I'll send some SRCREV updates later today. Cheers, Bruce ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
Hi Khem,
On Aug 24, 2012, at 8:35 PM, Khem Raj wrote:
On Fri, Aug 24, 2012 at 9:27 AM, Elvis Dowson elvis.dow...@gmail.com wrote:
I just observed that TARGET_FPU is not getting populated, when you do
a build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU =
soft, but for fpu-hard targets, it display TARGET_FPU = .
that means default is hard for this architecture. This option is
essentially used to configure gcc
unless your fpu is special like fsl one's you are good here.
The FPU unit is an IP core, that is attached to a generic PowerPC405 or
PowerPC440 embedded processor core on the FPGA, which by default doesn't
contain an FPU unit.
In the Xilinx FPGA hardware project, I have to add this FPU unit, and there are
some additional options that I can see relevant to this setup with the FPU
unit, such as -mxilinx-fpu and -mfpu=dp_full
Should I specify them in TUNE_CCARGS (as shown below) or
TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for both
variables ?
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppc405e, -mcpu=405fp
-mxilinx-fpu -mfpu=dp_full, , d)}
AVAILTUNES += ppc405e
TUNE_FEATURES_tune-ppc405e = m32 ppc405e fpu-hard
Best regards,
Elvis Dowson___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
On Fri, Aug 24, 2012 at 9:49 AM, Elvis Dowson elvis.dow...@gmail.com wrote:
Should I specify them in TUNE_CCARGS (as shown below) or
TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for
both variables ?
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppc405e,
-mcpu=405fp -mxilinx-fpu -mfpu=dp_full, , d)}
yes. However if there are some special ABI extentions becasue of FP
that gcc should configure itself with
then that should be specified in TARGET_FPU. I havent looked into gcc
code to check if it knows about xilinx-fpu
at configure time
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TARGET_FPU not getting populated for powerpc 405/440 fpu-hard targets
On 8/24/12 11:49 AM, Elvis Dowson wrote:
Hi Khem,
On Aug 24, 2012, at 8:35 PM, Khem Raj wrote:
On Fri, Aug 24, 2012 at 9:27 AM, Elvis Dowson elvis.dow...@gmail.com
mailto:elvis.dow...@gmail.com wrote:
I just observed that TARGET_FPU is not getting populated, when you do
a build for fpu-hard targets. For fpu-soft targets, it displays TARGET_FPU =
soft, but for fpu-hard targets, it display TARGET_FPU = .
that means default is hard for this architecture. This option is
essentially used to configure gcc
unless your fpu is special like fsl one's you are good here.
The FPU unit is an IP core, that is attached to a generic PowerPC405 or
PowerPC440 embedded processor core on the FPGA, which by default doesn't contain
an FPU unit.
In the Xilinx FPGA hardware project, I have to add this FPU unit, and there are
some additional options that I can see relevant to this setup with the FPU unit,
such as -mxilinx-fpu and -mfpu=dp_full
Should I specify them in TUNE_CCARGS (as shown below)
or TUNE_FEATURES_tune-ppc405e (not done below) or specify the same values for
both variables ?
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, ppc405e, -mcpu=405fp
-mxilinx-fpu -mfpu=dp_full, , d)}
AVAILTUNES += ppc405e
TUNE_FEATURES_tune-ppc405e = m32 ppc405e fpu-hard
fpu-hard is the classic PowerPC FPU unit. If that is what these ip blocks
implement then there is nothing further required.
If the unit does NOT include a classic PowerPC FPU, then you should not be using
fpu-hard.
If it -also- implements additional FPU instructions via the -m...fpu stuff
specific to the IP blocks, then that is where the target_fpu comes in and some
other changes will be necessary It's been a while since I worked through
this, but the e500 stuff may be a reasonable example of how to implement it.
--Mark
Best regards,
Elvis Dowson
___
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] configuring WiFi in Yocto
When I configured WiFi with Yocto on a n450 based netbook, all I had to do was get the right drivers for the hardware included in the Yocto 3.2 kernel, then I could use the GUI Connection Manager to configure the WiFi so the hardware would connect to my WiFi network. However, I'm now trying to configure a different WiFi on a Cedartrail system. The card is a Realtek RTL8188CE and the hardware is a DN2800MT Cedartrail board. For Cedartrail the current BSP under Denzil is on kernel 3.0. Not sure what made the difference, but Connection Manager does not have an option for Wireless networks. iwconfig list both lo and eth0, both of course have no wireless extensions. I was expecting to see wlan0. If I do lspci -v, it shows I have my RTL8188CE hardware connected to the kernel module rtl8192ce, which was loaded in support of the wifi card along with the other modules I put into my config fragment file: CONFIG_RTL8192CE=m CONFIG_RTL8192C_COMMON=m CONFIG_RTLWIFI=m CONFIG_MAC80211=m CONFIG_CFG80211=m What does it take to get the wlan0 device so Connection Manger will recognize it? Jim A ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
