[yocto] [prelink-cross][PATCH 1/1] rtld: remove if check before free
No need of explicit NULL check before free Signed-off-by: Maninder Singh maninder...@samsung.com --- trunk/src/rtld/rtld.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/trunk/src/rtld/rtld.c b/trunk/src/rtld/rtld.c index 35dfde7..3ed1db3 100644 --- a/trunk/src/rtld/rtld.c +++ b/trunk/src/rtld/rtld.c @@ -1270,7 +1270,6 @@ process_one_dso (DSO *dso, int host_paths) (uint32_t) l-l_map_start); } - if (filename) free (filename); cur_dso_ent = cur_dso_ent-next; -- 1.7.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[linux-yocto] Missing Kernel Modules (GPU folder and radeon.ko)
Hi all, I am trying to integrate the AMD Radeon E8860 graphics card on to a Yocto (poky-dizzy-12.0.1) embedded machine. Ialready have the open source xf86-video-ati driver (7.4.0) installed into my Yocto image. The problem is that the kernel module radeon.ko, and all of its dependencies under the GPU and I2C folders seems to be missing from the kernel. Without these .ko files, Yocto cannot recognize the external graphics card, and udev cannot generate an appropriate device node (/dev/dri/card0) for Xorg to use. I've already tried adding the following line to my local.conf: CORE_IMAGE_EXTRA_INSTALL_append = kernel-modules This populates the file system with .ko's but none seem to be the ones I need for my graphics card to run, which are radeon.ko, drm.ko, drm_kms_helper.ko, ttm.ko, and i2c_algo_bit.ko. I am missing the entire lib/modules/KERNEL_VERSION/kernel/drivers/gpu folder and also most of the contents in lib/modules/KERNEL_VERSION/kernel/drivers/i2c. I wondered if it was just a matter of implementing the .config file correctly. But I've already executed $bitbake linux-yocto -c menconfig and enabled the appropriate configuration flags for each of these modules. Perhaps this just a matter of appending to the kernel.bbclass file which is responsible for executing the kernel Makefiles, and building these .ko's? Can you guys please check your own lib/modules/KERNEL_VERSION/kernel directory to see that these .ko's exist? I'd like to know if there is something else that isn't enabled or included into the build, or if it's something I need to hardcode in order to fix this issue. Thanks, Simon -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] [PATCHv2 1/1] Disable parallel build for umip.
From: Siva Borra siva.bo...@enea.com umip build fails due to parallel build order issue, hence disabling the same. [LXCR-4977] Signed-off-by: Siva Borra siva.bo...@enea.com --- meta-cgl-common/recipes-extended/umip/umip%.bbappend | 1 + 1 file changed, 1 insertion(+) create mode 100644 meta-cgl-common/recipes-extended/umip/umip%.bbappend diff --git a/meta-cgl-common/recipes-extended/umip/umip%.bbappend b/meta-cgl-common/recipes-extended/umip/umip%.bbappend new file mode 100644 index 000..2858472 --- /dev/null +++ b/meta-cgl-common/recipes-extended/umip/umip%.bbappend @@ -0,0 +1 @@ +PARALLEL_MAKE = -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [LXCR-4977 PATCH 1/1] Add makedumpfile recipe to cgl.
From: Siva Borra siva.bo...@enea.com
Add the makedumpfile package recipe to
the cgl layer.
[LXCR-4977]
Signed-off-by: Siva Borra siva.bo...@enea.com
---
.../makedumpfile/files/alias-powerpc-powerpc32.patch | 13 +
.../recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb | 20
2 files changed, 33 insertions(+)
create mode 100644
meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
create mode 100644
meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
diff --git
a/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
new file mode 100644
index 000..70ad663
--- /dev/null
+++
b/meta-cgl-common/recipes-cgl/makedumpfile/files/alias-powerpc-powerpc32.patch
@@ -0,0 +1,13 @@
+diff -rupN makedumpfile-1.5.8/Makefile makedumpfile-1.5.8/Makefile
+--- makedumpfile-1.5.8/Makefile2015-03-24 02:58:33.0 +0100
makedumpfile-1.5.8/Makefile2015-06-23 11:08:30.595655336 +0200
+@@ -25,7 +25,8 @@ endif
+ ARCH := $(shell echo ${TARGET} | sed -e s/i.86/x86/ -e s/sun4u/sparc64/ \
+ -e s/arm.*/arm/ -e s/sa110/arm/ \
+ -e s/s390x/s390/ -e s/parisc64/parisc/ \
+- -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/)
++ -e s/ppc64/powerpc64/ -e s/ppc/powerpc32/ \
++ -e s/powerpc/powerpc32/)
+
+ CROSS :=
+ ifneq ($(TARGET), $(HOST_ARCH))
diff --git a/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
new file mode 100644
index 000..6c32306
--- /dev/null
+++ b/meta-cgl-common/recipes-cgl/makedumpfile/makedumpfile_1.5.8.bb
@@ -0,0 +1,20 @@
+DESCRIPTION = Make dump file utility
+LICENSE = GPLv2
+
+LIC_FILES_CHKSUM = file://COPYING;md5=751419260aa954499f7abaabaa882bbe
+
+SRC_URI =
http://sourceforge.net/projects/makedumpfile/files/makedumpfile/1.5.8/makedumpfile-${PV}.tar.gz;name=makedumpfile
\
+ file://alias-powerpc-powerpc32.patch \
+
+
+SRC_URI[makedumpfile.md5sum] = 642d975349dff744c6027d4486499258
+SRC_URI[makedumpfile.sha256sum] =
dd9c6c40c1ae6774b61bbe7b53f5ebbee9734f576d8ecb75ffb929288f5ea64d
+
+DEPENDS = zlib elfutils bzip2
+
+EXTRA_OEMAKE = TARGET=${TARGET_ARCH}
+
+do_install() {
+ install -d ${D}${bindir}/
+ install -c -m 755 ${S}/makedumpfile ${D}${bindir}/
+}
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH 4/6] meta: features/bluetooth: Change the CONFIG_BT as module
On 2015-06-22 10:02 PM, Ng, Wei Tee wrote: Hi Bruce, I've tested on my side without this patch and there is no any issue found. You may proceed to merge this series without this patch. Thanks! Sounds good. I've merged the changes now! Bruce Christian, thanks for the clarification and apologize for my mistake. Regards, Wei Tee -Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Tuesday, June 23, 2015 3:24 AM To: Iorga, Cristian; Ng, Wei Tee; linux-yocto@yoctoproject.org Subject: Re: [linux-yocto] [PATCH 4/6] meta: features/bluetooth: Change the CONFIG_BT as module On 2015-06-22 02:39 PM, Iorga, Cristian wrote: Hi Wei, Bruce, This change will break the qemu machines as far as I know, please don't include it as qemu machine just lie they has BT hardware so that it won't break some OE self-tests that run automatically. Due to that, making generic BT support a module won't work, BlueZ will not work correctly as auto-detection does not work (on qemu machines, that is). That's the reason for making BT a built-in and not a module. At this point, I forgot all the details, I will investigate later and come up with a detailed explanation. Thanks for the update. Wei Tee: If I merge all the other patches in this series except this one .. will we have issues ? Bruce Regards, Cristian -Original Message- From: linux-yocto-boun...@yoctoproject.org [mailto:linux-yocto-boun...@yoctoproject.org] On Behalf Of wei.tee...@intel.com Sent: Friday, June 19, 2015 11:51 AM To: linux-yocto@yoctoproject.org Subject: [linux-yocto] [PATCH 4/6] meta: features/bluetooth: Change the CONFIG_BT as module From: Ng Wei Tee wei.tee...@intel.com Change the configuration of CONFIG_BT to build as module. Signed-off-by: Ng Wei Tee wei.tee...@intel.com --- .../kernel-cache/features/bluetooth/bluetooth.cfg |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/cfg/kernel-cache/features/bluetooth/bluetooth.cfg b/meta/cfg/kernel-cache/features/bluetooth/bluetooth.cfg index fefb357..683bf19 100644 --- a/meta/cfg/kernel-cache/features/bluetooth/bluetooth.cfg +++ b/meta/cfg/kernel-cache/features/bluetooth/bluetooth.cfg @@ -1,4 +1,4 @@ -CONFIG_BT=y +CONFIG_BT=m CONFIG_BT_6LOWPAN=y CONFIG_BT_RFCOMM=m CONFIG_BT_RFCOMM_TTY=y -- 1.7.9.5 -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 2015-06-23 3:15 PM, Robert Calhoun wrote:
On 4/30/15 10:06 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote:
What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to another
known kernel recipe ?
How would I see which kernel recipe is used?
This is where my brute force techniques probably break down. I just
do a 'bitbake virtual/kernel' and you'll see it display which
recipe is being built.
If you haven't added compatibility for your new machine to any
recipe, I'm betting that linux-dummy is used.
I did not customize anything except for aforementioned steps, simply
copied beaglebone.conf to astro.conf in the same directory. Also I did
not touch any kernel recipes (kernel is built externally), maybe that's
what's missing?
It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.
Bruce
Jan
I encountered the same error (ERROR: No kernel-abiversion file found
(build/tmp/sysroots/{machinename}/pkgdata/kernel-depmod/kernel-abiversion),
cannot run depmod, aborting) after porting my system from poky-daisy to
poky-fido. My machine config sets PREFERRED_PROVIDER_virtual/kernel =
linux-dummy, as we currently use a monolithic out-of-tree 2.6 kernel.
It's a clean fido checkout, and I tried trashing tmp and rebuilding
everything to no effect.
Based on
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image.bbcl
ass I have worked around this by setting:
USE_DEPMOD = 0
in my image configuration. This works, and allows the root file system to
be built.
Is it a bug that depmod is not skipped automatically when linux-dummy is
specified? Am I risking death and destruction by overriding it? (We don't
have any kernel modules.)
See Saul's patch from about 33 minutes ago:
[OE-core] [PATCH][masterfido] image.bbclass: Disable USE_DEPMOD for the
dummy kernel
:)
Bruce
Thanks,
Rob Calhoun
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] [PATCH] ds1307-rtc-overlay.dtb has been removed from the kernel tree, and most overlays have been moved to the dts/overlays directory
Hi, On Thu, Jun 18, 2015 at 10:33 AM, Andrei Gherzan and...@gherzan.ro wrote: Hello, On 18 Jun 2015 10:22, Herve Jourdain herve.jourd...@neuf.fr wrote: Hi Andrei, Well, it seems that the current meta-raspberrypi is pulling the kernel from github, and the kernel on github already has these features in. Which is why I could compile fine with the current meta-raspberrypi 2or 3 weeks ago, but it failed 2 days ago when I tried to do a fresh build... Therefore, I believe the change in the meta-raspberrypi is already needed for the 3.18.y branch, because the kernel already has it. This is interesting. I'll check it tonight. I re-downloaded and recompiled kernel on the current meta-raspberrypi master HEAD and had no issues. What meta-raspberrypi revision are you using? -- Andrei Gherzan e: and...@gherzan.ro w: www.gherzan.ro -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing
On 4/30/15 10:06 AM, Bruce Ashfield bruce.ashfi...@windriver.com wrote:
On 2015-04-30 08:27 AM, Schaumlöffel, Jan wrote:
What kernel recipe is used when your machine is set to 'astro' ?
Something custom ? Or have you added machine compatibility to another
known kernel recipe ?
How would I see which kernel recipe is used?
This is where my brute force techniques probably break down. I just
do a 'bitbake virtual/kernel' and you'll see it display which
recipe is being built.
If you haven't added compatibility for your new machine to any
recipe, I'm betting that linux-dummy is used.
I did not customize anything except for aforementioned steps, simply
copied beaglebone.conf to astro.conf in the same directory. Also I did
not touch any kernel recipes (kernel is built externally), maybe that's
what's missing?
It is plausible. But in theory, linux-dummy should still provide
what you need (but since it doesn't build anything, there is
no abi .. and no modules can be built against it) .. so the
error isn't graceful.
Bruce
Jan
I encountered the same error (ERROR: No kernel-abiversion file found
(build/tmp/sysroots/{machinename}/pkgdata/kernel-depmod/kernel-abiversion),
cannot run depmod, aborting) after porting my system from poky-daisy to
poky-fido. My machine config sets PREFERRED_PROVIDER_virtual/kernel =
linux-dummy, as we currently use a monolithic out-of-tree 2.6 kernel.
It's a clean fido checkout, and I tried trashing tmp and rebuilding
everything to no effect.
Based on
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/image.bbcl
ass I have worked around this by setting:
USE_DEPMOD = 0
in my image configuration. This works, and allows the root file system to
be built.
Is it a bug that depmod is not skipped automatically when linux-dummy is
specified? Am I risking death and destruction by overriding it? (We don't
have any kernel modules.)
Thanks,
Rob Calhoun
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] do_make_scripts race condition with externalsrc
Hello, I encountered the same error as described by Mikhail Zakharov last November in... https://lists.yoctoproject.org/pipermail/yocto/2014-November/022151.html My output was nearly identical to that reported (the only thing different being a different recipe that builds out-of-tree kernel modules as externalsrc). Like the other case reported, I am using 1.6 (actually a Freescale QorIQ SDK 1.7 snapshot). I also noticed on a number of occasions the build/tmp/kernel-scripts.lock is a directory, when I think it is supposed to be just a file. Whenever it is created as a directory and it doesn't get properly cleaned up, attempting to build anything kernel related thereafter potentially hangs those bitbake tasks indefinitely. You have to Ctrl-C twice and then delete the build/tmp/kernel-scripts.lock directory that was left there. Then things work back to normal (until the next time). My understanding is that the externalsrc bbclass excludes a number of tasks that aren't relevant to external source (such as fetch, unpack and patch). Is it possible that one of the excluded tasks is needed to ensure the proper handling of the kernel-scripts.lock when building kernel modules? Regards, Darcy Darcy Watkins :: Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [P2] dwatk...@sierrawireless.commailto:dwatk...@sierrawireless.com :: www.sierrawireless.comhttp://www.sierrawireless.com/ :: www.inmotiontechnology.comhttp://www.inmotiontechnology.com/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] meta-mono: Issue building 4.0.2.4
The double nested output folder looks odd to me but leaving that, it looks like a file is being installed twice. Anyone else seeing this? meta meta-skeleton = (HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad meta-yocto meta-yocto-bsp= (HEADdetachedat16caaab):16caaabfcc678b03a0cd88aaeac15f9b8d1c3dad meta-mono = master:35e8ede514dd35eb3d645d5de22282d0e8204f86 meta-oe meta-webserver= (HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec meta-ti = (HEADdetachedatb81014d):b81014dbb5cc39fdfa66af87d18b72eb9eb3c701 meta-nodejs = (HEADdetachedate724e27):e724e270bc23a14f12d4a0d73869199457a1b925 bitbake-npm = (HEADdetachedatd88833b):d88833bcf52da7d00e775ca8c2e63ca44cf6ace1 meta-ros = (HEADdetachedatbdc603b):bdc603b821eae5e1d966ec25e63f6832f6386dc8 meta-rust = (HEADdetachedat61708ed):61708ed85e76beafdb08b6caf340abeae13bf4b2 meta-qt5 = (HEADdetachedat378dfc2):378dfc20ad0e024412da7f3be22efe04c3421c6d meta-ruby meta-python meta-networking = (HEADdetachedatdf6c7b1):df6c7b1279790d27ebfd58fbdfbac89bde5782ec (output snipped) | /usr/bin/install -c -c -m 644 frameworks/net_4.5.xml /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml | /usr/bin/install -c -c -m 644 targets/Microsoft.WebApplication.targets /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications | mkdir -p -- /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/14.0/bin/MSBuild | /usr/bin/install -c -c -m 644 targets/Microsoft.Portable.Common.targets /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.Common.targets | /usr/bin/install -c -c -m 644 targets/Microsoft.WebApplication.targets /home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild/Microsoft/VisualStudio/v9.0/WebApplications | /usr/bin/install: cannot create regular file '/home/cmorgan/projects/yocto/build/tmp/work/x86_64-linux/mono-native/4.0.2.4-r0/image/home/cmorgan/projects/yocto/build/tmp/sysroots/x86_64-linux/usr/lib/mono/xbuild-frameworks/.NETFramework/v4.5/RedistList/FrameworkList.xml': File exists | Makefile:42: recipe for target 'install-frameworks' failed | make[6]: *** [install-frameworks] Error 1 | make[6]: *** Waiting for unfinished jobs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Kernel driver backports
Hello, I am attempting to build kernel driver backports 3.18.1-1 to backport newer drivers into older kernels (3.4 for i586 and 3.12 for armv7). This is in poky 1.6 (daisy). I have everything building OK, and they seem to work OK on the target, BUT the tasks that split the packages up will name the kernel-module-XXX sub-packages the same as those originally built in the kernel. Even though the package version from backports has the backports version (different from the kernel version), this still results in a QA warning - attempt to install files into a shared area when they already exist (which I believe is a QA fatal error in newer version of yocto). The modules as shipped from kernel wind up under /lib/modules/.../kernel/drivers/... The modules as shipped from backports wind up under /lib/modules/.../updates/drivers/... So there is actually no real issue present. They can both be installed on the target. I think that the solution would be to override the sub-package naming such that instead of... kernel-module-ath9k-hw-3.12... .rpm ...and... kernel-module-ath9k-hw-3.18.1-1... .rpm ...have something like... kernel-module-ath9k-hw-3.12... .rpm ...and... backports-kernel-module-ath9k-hw-3.18.1-1... .rpm Then there should be no QA issue and since the files are at different locations on the target system, there shouldn't be any conflict there either. Anyone know how to override the package splitter for kernel modules to use a different prefix? ... or do I need to derive a new bbclass? I tried setting KERNEL_MODULES_META_PACKAGE to something different, but that seems to have no effect. Regards, Darcy Darcy Watkins :: Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main +1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [P2] dwatk...@sierrawireless.commailto:dwatk...@sierrawireless.com :: www.sierrawireless.comhttp://www.sierrawireless.com/ :: www.inmotiontechnology.comhttp://www.inmotiontechnology.com/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
