Re: [yocto] Selecting a preferred recipe version for devtools
Khem Raj raj.k...@gmail.com wrote: On Wed, Aug 12, 2015 at 6:48 AM, PIEWALD Georg georg.piew...@frequentis.com wrote: PREFERRED_VERSION_subversion = 1.6.15 in my local.conf, but it turned out that this only affects the builds for the target-machine (cortexa8hf-vfp-neon-3.8-oe-linux-gnueabi), but not the devtools on the build-machine (x86_64-linux). you might need to set preferred version for native extension as well. PREFERRED_VERSION_subversion-native = 1.6.15 That did the trick, thanks a lot! Georg -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-cgl][PATCH] ocfs2-tools-1.4.3: fix SRC_URI[md5sum] and SRC_URI[sha256sum]
The md5sum and sha256sum of source archive present in the
recipe differs with actual md5sum and sha256sum of source archive
present in upstream
(https://github.com/flexiant/ocfs2-tools/archive/ocfs2-tools-1.4.3.zip),
this results in fetch error as below while building ocfs2-tools;
--snip --
ERROR: Fetcher failure for URL:
'https://github.com/flexiant/ocfs2-tools/archive/ocfs2-tools-1.4.3.zip'.
Checksum mismatch!
(snip)
SRC_URI[md5sum] = 299191b04ced0d5f71670c799314e684
SRC_URI[sha256sum] =
6ccac6910f2b91f79326b06f02b8760de863ba881335757063100823b910a45f
Otherwise you should retry the download and/or check with upstream to determine
if the file has become corrupted or otherwise unexpectedly modified.
-- CUT --
Signed-off-by: Jagadeesh Krishnanjanappa jkrishnanjana...@mvista.com
---
meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb
b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb
index 1296fd6..a4407ce 100644
--- a/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb
+++ b/meta-cgl-common/recipes-cgl/ocfs2-tools/ocfs2-tools_1.4.3.bb
@@ -20,8 +20,8 @@ SRC_URI = \
file://o2cb.service \
file://ocfs2.service \
-SRC_URI[md5sum] = 296f1242f4d00d188231d726d7a1d148
-SRC_URI[sha256sum] =
a809f03c62e515a4c23e98c4b4c3f8150377af2cf44cd2a2ee56e175b0e4d0b3
+SRC_URI[md5sum] = 299191b04ced0d5f71670c799314e684
+SRC_URI[sha256sum] =
6ccac6910f2b91f79326b06f02b8760de863ba881335757063100823b910a45f
S = ${WORKDIR}/ocfs2-tools-ocfs2-tools-1.4.3
inherit autotools-brokensep pkgconfig
DEPENDS = corosync openais cluster-glue pacemaker libxml2 linux-libc-headers
e2fsprogs
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack
Hello Andreas, On 08/12/2015 10:22 PM, Andreas Müller wrote: On Wed, Aug 12, 2015 at 7:15 PM, Andreas Müller schnitzelt...@googlemail.com wrote: FYI: I managed to get the vc4 driver loaded (should be in my repo branch vc4-2). With this I get some repeating kernel error messages (don't have them here). I am sure that I read something about these messages when preparing vc4 (yes I started similar before you sent patches). Awesome, I tried to get it working yesterday but couldn't. Good work! Hope I have some energy left tonight to check further and let you know... From xorg perspective all looks fine [595923.730] (II) modeset(0): [DRI2] Setup complete [595923.730] (II) modeset(0): [DRI2] DRI driver: vc4 [595923.730] (II) modeset(0): [DRI2] VDPAU driver: vc4 [595923.740] (--) RandR disabled [595923.745] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [595923.745] (II) AIGLX: enabled GLX_ARB_create_context [595923.745] (II) AIGLX: enabled GLX_ARB_create_context_profile [595923.745] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile [595923.745] (II) AIGLX: enabled GLX_INTEL_swap_event [595923.745] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [595923.745] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB [595923.745] (II) AIGLX: enabled GLX_ARB_fbconfig_float [595923.745] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [595923.747] (II) AIGLX: Loaded and initialized vc4 [595923.747] (II) GLX: Initialized DRI2 GL provider for screen 0 [595923.782] (II) modeset(0): Setting screen physical size to 338 x 270 but kernel complains periodically ~6s with [ 36.814922] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate [ 43.060516] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate [ 49.325115] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate [ 55.558433] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate Yes, I was able to reproduce the issue. My X -verbose output: http://hastebin.com/onovosojuw.md Will check what this message want me to say - anybody out there with helping hints? No clue. I was looking and the error is in the VC4_SUBMIT_CL ioctl cmd handler (vc4_submit_cl_ioctl) in drivers/gpu/drm/vc4/vc4_gem.c. AFAIU bo_handle_count is supposed to always be 0 but somehow mesa is passing 0 on it. The ioctl call is in vc4_flush (src/gallium/drivers/vc4/vc4_context.c) in mesa. So it seems this is a mesa issue. I've asked Eric Anholt in #dri-devel on IRC if his kernel is supposed to work with mesa 10.5.8 or if there is a minimum version / sha1 that is needed. Andreas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas)
Hi all, I am not affiliated to any Yocto Project member organisation, but am assisting with integration at the Automotive Grade Linux project, which is re-using some work from upstreams at git.yoctoproject.org Recently members of the AGL community have started contributing patches for meta-renesas at our mirror [1]. We would like to offer this and future work to upstream, and I am hoping to understand so that I can help guide AGL's activities so that we are properly aligned. Please can someone guide us on the accepted way to offer these and subsequent patches? br Paul [1] https://gerrit.automotivelinux.org/gerrit/#/c/4047/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][fido][PATCH 1/4] linux-raspberrypi: Update 3.18 branch to 3.18.11
Update linux-raspberrypi_3.18 to latest version. Remove sl030raspberrypii2ckernel.patch since it will not apply anymore and its content seems to be obsolite in later kernel versions. [Support #56] Change-Id: I91e57f4e65d9c1c9d12014f5d11b0acd950e2d1d Signed-off-by: Petter Mabäcker pet...@technux.se Signed-off-by: Andrei Gherzan and...@gherzan.ro (cherry picked from commit c9f29df249b80ab488e4ea6eddc01a6522a28c09) Signed-off-by: Petter Mabäcker pet...@technux.se --- recipes-kernel/linux/linux-raspberrypi_3.18.bb | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/recipes-kernel/linux/linux-raspberrypi_3.18.bb b/recipes-kernel/linux/linux-raspberrypi_3.18.bb index 921e702..6d8b155 100644 --- a/recipes-kernel/linux/linux-raspberrypi_3.18.bb +++ b/recipes-kernel/linux/linux-raspberrypi_3.18.bb @@ -1,8 +1,6 @@ -LINUX_VERSION ?= 3.18.5 +LINUX_VERSION ?= 3.18.11 -SRCREV = a6cf3c99bc89e2c010c2f78fbf9e3ed478ccfd46 -SRC_URI = git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y \ - file://sl030raspberrypii2ckernel.patch \ - +SRCREV = d64fa8121fca9883d6fb14ca06d2abf66496195e +SRC_URI = git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.18.y require linux-raspberrypi.inc -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 2/2] rrs: avoid too many columns in the recipes table
Currently, when you select 'Can't be updated' in the upstream
status filter, the resulting table will add the 'No update reason'
column to the default column set.
Although this is probably useful information to see in the
table itself, it results in too many columns, and a rather
unpleasant layout change.
This patch hides the 'Summary' column whenever you select
'Can't be updated' in the upstream status filter, effectively
replacing the 'Summary' with the 'No update reason' column,
which is probably more relevant in this context. Now you
have less columns distracting you, and a slightly less
jumpy layout change.
A designer would have come up with this solution in the
first place. Sadly, she was never asked.
Signed-off-by: Belen Barros Pena belen.barros.p...@linux.intel.com
---
templates/rrs/recipes.html | 2 ++
1 file changed, 2 insertions(+)
diff --git a/templates/rrs/recipes.html b/templates/rrs/recipes.html
index 3ac73d2..8927b2f 100644
--- a/templates/rrs/recipes.html
+++ b/templates/rrs/recipes.html
@@ -218,8 +218,10 @@ $(document).ready(function() {
function applyFilters() {
if (upstreamStatus == 'Can\'t be updated') {
$('.no_update_reason_column').show()
+$('.summary_column').hide()
} else {
$('.no_update_reason_column').hide()
+$('.summary_column').show()
}
if (upstreamStatus == 'All') {
--
2.3.2 (Apple Git-55)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][fido][PATCH 2/4] If SERIAL_CONSOLE is already define by another layer, this value may not be good.
From: Thomas Perrot thomas.per...@tupi.fr Signed-off-by: Thomas Perrot thomas.per...@tupi.fr (cherry picked from commit c8532df1c2e4812b3520d32ed49be943bea2edd9) Signed-off-by: Petter Mabäcker pet...@technux.se --- conf/machine/include/rpi-base.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/machine/include/rpi-base.inc b/conf/machine/include/rpi-base.inc index a26803a..1dda207 100644 --- a/conf/machine/include/rpi-base.inc +++ b/conf/machine/include/rpi-base.inc @@ -7,7 +7,7 @@ include conf/machine/include/soc-family.inc IMAGE_FSTYPES ?= tar.bz2 ext3 rpi-sdimg -SERIAL_CONSOLE ?= 115200 ttyAMA0 +SERIAL_CONSOLE = 115200 ttyAMA0 XSERVER = \ xserver-xorg \ -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas)
Hi Nikolay! On 2015-08-13 13:32, Nikolay Dimitrov wrote: On 08/13/2015 02:21 PM, Paul Sherwood wrote: Hi all, I am not affiliated to any Yocto Project member organisation, but am assisting with integration at the Automotive Grade Linux project, which is re-using some work from upstreams at git.yoctoproject.org Recently members of the AGL community have started contributing patches for meta-renesas at our mirror [1]. We would like to offer this and future work to upstream, and I am hoping to understand so that I can help guide AGL's activities so that we are properly aligned. Please can someone guide us on the accepted way to offer these and subsequent patches? br Paul [1] https://gerrit.automotivelinux.org/gerrit/#/c/4047/ Haven't seen you for a quite a while after Karlsruhe, hope you're doing fine. Small world! I am very well thank you - it's great to re-connect with old friends here :-) Regarding the upstreaming guidelines, the usual steps apply - ask contributors to push patches as close to the upstream project as possible, and just then go downstream, like this (in order of preference): 1. Upstream components 2. Yocto meta layer (which you are reusing) 3. AGL repos Understood, thank you. So in this case, for patches to meta-renesas, should we email them to this list, or another list, or send directly to the maintainer, or is there another mechanism established? Also, it would be great if your AGL maintainers can enforce appropriate patch tracking by Upstream-status tag + description, as it will help everyone. Yes, I completely agree. br Paul Kind regards, Nikolay -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/2] rrs: remove sorting from the 'No update reason' column
Nothing useful can come from sorting by this column.
Signed-off-by: Belen Barros Pena belen.barros.p...@linux.intel.com
---
templates/rrs/recipes.html | 1 +
1 file changed, 1 insertion(+)
diff --git a/templates/rrs/recipes.html b/templates/rrs/recipes.html
index 5d2ee5f..3ac73d2 100644
--- a/templates/rrs/recipes.html
+++ b/templates/rrs/recipes.html
@@ -293,6 +293,7 @@ $(document).ready(function() {
2: { sorter: false },
5: { sorter: false },
6: { sorter: false },
+7: { sorter: false },
}
});
{% endif %}
--
2.3.2 (Apple Git-55)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas)
Hi Paul, On 08/13/2015 02:21 PM, Paul Sherwood wrote: Hi all, I am not affiliated to any Yocto Project member organisation, but am assisting with integration at the Automotive Grade Linux project, which is re-using some work from upstreams at git.yoctoproject.org Recently members of the AGL community have started contributing patches for meta-renesas at our mirror [1]. We would like to offer this and future work to upstream, and I am hoping to understand so that I can help guide AGL's activities so that we are properly aligned. Please can someone guide us on the accepted way to offer these and subsequent patches? br Paul [1] https://gerrit.automotivelinux.org/gerrit/#/c/4047/ Haven't seen you for a quite a while after Karlsruhe, hope you're doing fine. Regarding the upstreaming guidelines, the usual steps apply - ask contributors to push patches as close to the upstream project as possible, and just then go downstream, like this (in order of preference): 1. Upstream components 2. Yocto meta layer (which you are reusing) 3. AGL repos Also, it would be great if your AGL maintainers can enforce appropriate patch tracking by Upstream-status tag + description, as it will help everyone. Kind regards, Nikolay -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][fido][PATCH 4/4] rpi-default-providers: Let users overwrite the default providers
From: Andrei Gherzan and...@gherzan.ro [Feature #65] Signed-off-by: Andrei Gherzan and...@gherzan.ro Signed-off-by: Pierre FICHEUX pierre.fich...@gmail.com (cherry picked from commit ade923f17d242f9a043b1714deb584929a2ffe8e) Signed-off-by: Petter Mabäcker pet...@technux.se --- conf/machine/include/rpi-default-providers.inc | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/conf/machine/include/rpi-default-providers.inc b/conf/machine/include/rpi-default-providers.inc index ee3a3ac..cabbd43 100644 --- a/conf/machine/include/rpi-default-providers.inc +++ b/conf/machine/include/rpi-default-providers.inc @@ -1,10 +1,10 @@ # RaspberryPi BSP default providers -PREFERRED_PROVIDER_virtual/kernel = linux-raspberrypi -PREFERRED_PROVIDER_u-boot = u-boot-rpi -PREFERRED_PROVIDER_virtual/xserver = xserver-xorg +PREFERRED_PROVIDER_virtual/kernel ?= linux-raspberrypi +PREFERRED_PROVIDER_u-boot ?= u-boot-rpi +PREFERRED_PROVIDER_virtual/xserver ?= xserver-xorg PREFERRED_PROVIDER_virtual/egl ?= userland PREFERRED_PROVIDER_virtual/libgles2 ?= userland PREFERRED_PROVIDER_virtual/libgl ?= mesa-gl PREFERRED_PROVIDER_virtual/mesa ?= mesa-gl -PREFERRED_PROVIDER_jpeg = jpeg +PREFERRED_PROVIDER_jpeg ?= jpeg -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][fido][PATCH 0/4] Backport of various fixes
Backport of various fixes and important updates (backward compatible) from meta-raspberrypi:master to meta-raspberrypi:fido The following changes since commit b896a7da70dd7a16ba7ffd664f7747cb37e1d142: .gitignore: Ignore some stuff (2015-03-12 22:20:51 +0100) are available in the git repository at: git://git.yoctoproject.org/poky-contrib petmab/rpi_fido_fixes http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/rpi_fido_fixes Andrei Gherzan (1): rpi-default-providers: Let users overwrite the default providers Khem Raj (1): userland: Fix POSIX compliance expectation Petter Mabäcker (1): linux-raspberrypi: Update 3.18 branch to 3.18.11 Thomas Perrot (1): If SERIAL_CONSOLE is already define by another layer, this value may not be good. conf/machine/include/rpi-base.inc | 2 +- conf/machine/include/rpi-default-providers.inc | 8 ++--- .../userland/0001-Use-newer-POSIX-macro.patch | 35 ++ recipes-graphics/userland/userland_git.bb | 1 + recipes-kernel/linux/linux-raspberrypi_3.18.bb | 8 ++--- 5 files changed, 44 insertions(+), 10 deletions(-) create mode 100644 recipes-graphics/userland/userland/0001-Use-newer-POSIX-macro.patch -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][fido][PATCH 3/4] userland: Fix POSIX compliance expectation
From: Khem Raj raj.k...@gmail.com
We have errors like below with glibc 2.22+
net_sockets_common.c:139:20: error: storage size of 'hints' isn't known
struct addrinfo hints, *info, *p;
^
newer glibc has now fixed the definitions of getaddrinfo and ilk to be
enabled with correct posix version.
Signed-off-by: Khem Raj raj.k...@gmail.com
(cherry picked from commit f188f3d756f59fb4dc64cc1a64263c2251f76ae5)
Signed-off-by: Petter Mabäcker pet...@technux.se
---
.../userland/0001-Use-newer-POSIX-macro.patch | 35 ++
recipes-graphics/userland/userland_git.bb | 1 +
2 files changed, 36 insertions(+)
create mode 100644
recipes-graphics/userland/userland/0001-Use-newer-POSIX-macro.patch
diff --git
a/recipes-graphics/userland/userland/0001-Use-newer-POSIX-macro.patch
b/recipes-graphics/userland/userland/0001-Use-newer-POSIX-macro.patch
new file mode 100644
index 000..2a092c2
--- /dev/null
+++ b/recipes-graphics/userland/userland/0001-Use-newer-POSIX-macro.patch
@@ -0,0 +1,35 @@
+From 12f7718bb0e08e2c06825c7ab7541b3c5bfe74c1 Mon Sep 17 00:00:00 2001
+From: Khem Raj raj.k...@gmail.com
+Date: Sun, 9 Aug 2015 08:55:05 -0700
+Subject: [PATCH] Use newer POSIX macro
+
+Define _POSIX_C_SOURCE such that it demands correct
+posix interfaces, netdb.h declares interfaces such as
+getaddrinfo if __USE_POSIX, i.e. POSIX.1:1990 or later.
+However, these interfaces were new in the 2001 edition of POSIX
+therefore ask for Extension from POSIX.1:2001 since we use addrinfo
+structure here.
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+---
+Upstream-Status: Submitted
+
+ containers/CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/containers/CMakeLists.txt b/containers/CMakeLists.txt
+index a29a885..5570038 100644
+--- a/containers/CMakeLists.txt
b/containers/CMakeLists.txt
+@@ -13,7 +13,7 @@ add_definitions(-DDL_PATH_PREFIX=${VMCS_PLUGIN_DIR}/)
+
+ SET( GCC_COMPILER_FLAGS -Wall -g -O2 -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Wcast-qual -Wwrite-strings -Wundef )
+ SET( GCC_COMPILER_FLAGS ${GCC_COMPILER_FLAGS} -Wextra
)#-Wno-missing-field-initializers )
+-SET( GCC_COMPILER_FLAGS ${GCC_COMPILER_FLAGS} -std=c99
-D_POSIX_C_SOURCE=199309L )
++SET( GCC_COMPILER_FLAGS ${GCC_COMPILER_FLAGS} -std=c99
-D_POSIX_C_SOURCE=200112L )
+ SET( GCC_COMPILER_FLAGS ${GCC_COMPILER_FLAGS} -Wno-missing-field-initializers
)
+ SET( GCC_COMPILER_FLAGS ${GCC_COMPILER_FLAGS} -Wno-unused-value )
+
+--
+2.1.4
+
diff --git a/recipes-graphics/userland/userland_git.bb
b/recipes-graphics/userland/userland_git.bb
index 729c42a..861029d 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -16,6 +16,7 @@ SRCFORK = raspberrypi
SRCREV = 3b81b91c18ff19f97033e146a9f3262ca631f0e9
SRC_URI =
git://github.com/${SRCFORK}/userland.git;protocol=git;branch=${SRCBRANCH} \
+ file://0001-Use-newer-POSIX-macro.patch \
S = ${WORKDIR}/git
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas)
Hi Paul, On 08/13/2015 04:24 PM, Paul Sherwood wrote: Hi Nikolay! On 2015-08-13 13:32, Nikolay Dimitrov wrote: On 08/13/2015 02:21 PM, Paul Sherwood wrote: Hi all, I am not affiliated to any Yocto Project member organisation, but am assisting with integration at the Automotive Grade Linux project, which is re-using some work from upstreams at git.yoctoproject.org Recently members of the AGL community have started contributing patches for meta-renesas at our mirror [1]. We would like to offer this and future work to upstream, and I am hoping to understand so that I can help guide AGL's activities so that we are properly aligned. Please can someone guide us on the accepted way to offer these and subsequent patches? br Paul [1] https://gerrit.automotivelinux.org/gerrit/#/c/4047/ Haven't seen you for a quite a while after Karlsruhe, hope you're doing fine. Small world! I am very well thank you - it's great to re-connect with old friends here :-) Regarding the upstreaming guidelines, the usual steps apply - ask contributors to push patches as close to the upstream project as possible, and just then go downstream, like this (in order of preference): 1. Upstream components 2. Yocto meta layer (which you are reusing) 3. AGL repos Understood, thank you. So in this case, for patches to meta-renesas, should we email them to this list, or another list, or send directly to the maintainer, or is there another mechanism established? Usually I would advice to send the patches to a Renesas-specific ML, but I couldn't find it in the OE layers index, so it would be best to ask the Renesas team. @Stephen, Takeshi, Nobuhiro: Can you please advice which is the proper ML for sending meta-renesas patches? Thanks. Also, it would be great if your AGL maintainers can enforce appropriate patch tracking by Upstream-status tag + description, as it will help everyone. Yes, I completely agree. br Paul Have a nice day, Nikolay -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas)
Hi, -Original Message- From: Nikolay Dimitrov [mailto:picmas...@mail.bg] Sent: 13 August 2015 15:11 To: Paul Sherwood paul.sherw...@codethink.co.uk Cc: yocto@yoctoproject.org; automotive-discussi...@lists.linuxfoundation.org; Stephen Lawrence stephen.lawre...@renesas.com; Takeshi Saito takeshi.saito...@renesas.com; Nobuhiro Iwamatsu(Retired) nobuhiro.iwamatsu...@renesas.com Subject: Re: [yocto] How to submit patches upstream for repos at git.yoctoproject.org (eg meta-renesas) [snip] Understood, thank you. So in this case, for patches to meta-renesas, should we email them to this list, or another list, or send directly to the maintainer, or is there another mechanism established? Usually I would advice to send the patches to a Renesas-specific ML, but I couldn't find it in the OE layers index, so it would be best to ask the Renesas team. @Stephen, Takeshi, Nobuhiro: Can you please advice which is the proper ML for sending meta-renesas patches? Thanks. The MAINTAINERS file [1] says email Genivi branch changes directly to me :). However in the case of AGL I recall the AGL meeting minutes saying they were going to start with a local branch. I don't know the reasoning, perhaps to facilitate the aggressive timescale for the first release before processes bed down or are agreed. So that appears to be the short term upstream. Can the attendees share the detail? In the medium term a shared source would simplify but the utility of that will depend largely on the extent to which version roadmaps can be aligned for both alliances else there will just be separate branches anyway. [1] https://github.com/slawr/meta-renesas/blob/genivi-7.0-bsp-1.8.0/MAINTAINERS Regards Steve -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 0/4] Add support for 4.1 kernel with vc4 DRM/KMS driver
Hello Andrei, This series adds support for Eric Anholt's v4.1 kernel, that has support for the vc4 DRM/KMS driver. Which is the new open source graphics driver stack for the Raspberry Pi to be used instead of the userland driver. This is a second version of the series which addresses feedback provided by Andreas Müller, Khem Raj, Petter Mabäcker and you. The first version of the series can be found at [0]. Some of the v1 patches have already been picked and are now in the meta-raspberrypi master branch. The v4.1 kernel is under heavy development so is a work-in-progress and should not be used in production. That's why it's not set as the default virtual/kernel provider but the user can change the default providers in case wants to use the VC4 driver. But even when it's still a development kernel, having the recipe in the meta-raspberrypi will allow people to test it. We have been using it in the Tizen RPi2 port [1] for some time. The patches in the series are for: Patch 1/4 allows to set the mask_gpu_interrupt0 option in config.txt Patch 2/4 adds a recipe for the 4.1 and some patches to make it stable Patch 3/4 Documents how to switch the default providers for vc4 gfx stack Patch 4/4 Adds a section to the README that explains that two gfx stacks are available and that the user can change the default providers. As discussed in v1, the following has to be added in local.conf to build: KERNEL_DEVICETREE = \ bcm2708-rpi-b.dtb \ bcm2708-rpi-b-plus.dtb \ bcm2709-rpi-2-b.dtb \ \ overlays/hifiberry-amp-overlay.dtb \ overlays/hifiberry-dac-overlay.dtb \ overlays/hifiberry-dacplus-overlay.dtb \ overlays/hifiberry-digi-overlay.dtb \ overlays/iqaudio-dac-overlay.dtb \ overlays/iqaudio-dacplus-overlay.dtb \ overlays/lirc-rpi-overlay.dtb \ overlays/pps-gpio-overlay.dtb \ overlays/w1-gpio-overlay.dtb \ overlays/w1-gpio-pullup-overlay.dtb \ [0]: https://www.mail-archive.com/yocto@yoctoproject.org/msg25164.html [1]: http://blogs.s-osg.org/tizen-rpi2-now-supporting-3d-acceleration/ Best regards, Javier Changes in v2: - Fix commit message about mask GPU irq option. Suggested by Andrei Gherzan. - Add a linux-raspberrypi-vc4 recipe insted of a linux-raspberrypi one. Suggested by Petter Mabäcker, Andreas Müller and Andrei Gherzan. - Split the readme change in a separate patch. Suggested by Andrei Gherzan. - Don't make the vc4 patches inclusion conditional since will always be needed when choosing the recipe. Suggested by Andrei Gherzan. - Don't add a feature and allow users to change the default provider manually aided by a comment. Suggested by Andreas Müller and Andrei Gherzan. Derek Foreman (3): rpi-config: Allow to mask GPU irqs linux-raspberrypi: Add a 4.1 linux kernel with vc4 support rpi-default-providers: Document how to switch providers for vc4 gfx stack Javier Martinez Canillas (1): README: Add a section about graphic stacks README | 31 -- conf/machine/include/rpi-default-providers.inc | 10 ++ recipes-bsp/bootfiles/rpi-config_git.bb| 6 ++ ..._defconfig-Enable-config-options-for-vc4-.patch | 48 + ...-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch | 85 +++ .../0003-drm-vc4-Use-the-fbdev_cma-helpers.patch | 115 + .../0004-drm-vc4-Allow-vblank-to-be-disabled.patch | 26 + .../0005-drm-vc4-Disable-KMS-operations.patch | 95 + .../linux/linux-raspberrypi-vc4/defconfig | 1 + recipes-kernel/linux/linux-raspberrypi-vc4_4.1.bb | 12 +++ 10 files changed, 421 insertions(+), 8 deletions(-) create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0002-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0003-drm-vc4-Use-the-fbdev_cma-helpers.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0004-drm-vc4-Allow-vblank-to-be-disabled.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0005-drm-vc4-Disable-KMS-operations.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/defconfig create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4_4.1.bb -- 2.4.3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] overriding install in recipe for nativesdk
On Tue, Jul 14, 2015 at 9:57 PM, Marcin Krzemiński mar.krzemin...@gmail.com wrote: Currently in our yocto layer there is a recipe for u-boot that also produce mkimage binary for host, I would like to have mkimage in SDK. Now, there is a separate recipe in yocto to do that, but I am wondering is it possible in some way to override install function for nativesdk. Then I could use same sources for u-boot and I won't be downloading them twice.maybe there is another way that I can try? you could use shared-workdir model like what kernel and gcc use but maintenance of such a setup is high it may be appealing for components with large sourcecode and multiple recipes uboot may not be particularly suitable -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 1/4] rpi-config: Allow to mask GPU irqs
From: Derek Foreman der...@osg.samsung.com
The rpi firmware has support for a mask_gpu_interrupt option that can be
defined in the boot/config.txt file. The option makes the VPU not handle
certain interrupts such as V3D. This option is needed by the VC4 DRM/KMS
driver but it is not possible to set it from the meta-raspberrypi layer.
Signed-off-by: Derek Foreman der...@osg.samsung.com
[javier: Made it a config option]
Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
---
Changes in v2:
- Fix commit message about mask GPU irq option. Suggested by Andrei Gherzan.
README | 22 ++
recipes-bsp/bootfiles/rpi-config_git.bb | 6 ++
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/README b/README
index d70f21fe06ed..678c0eb4a4e3 100644
--- a/README
+++ b/README
@@ -20,10 +20,11 @@ Contents:
2.F. Optional - Video camera support with V4L2 drivers
2.G. Optional - Enable offline compositing support
2.H. Optional - Enable kgdb over console support
-2.I. Images
-2.J. Boot to U-Boot
-2.K. Image with Initramfs
-2.L. Device tree support
+2.I. Optional - Mask GPU interrupts
+2.J. Images
+2.K. Boot to U-Boot
+2.L. Image with Initramfs
+2.M. Device tree support
3. Extra apps
3.A. omxplayer
4. Source code and mirrors
@@ -145,7 +146,12 @@ To add the kdbg over console (kgdboc) parameter to the
kernel command line,
set this variable in local.conf:
ENABLE_KGDB = 1
-2.I. Images
+2.I. Optional - Mask GPU interrupts
+===
+To mask the GPU interrupts, set in your local.conf
+MASK_GPU_INTERRUPT = 0x400
+
+2.J. Images
===
* rpi-hwup-image
Hardware up image
@@ -155,7 +161,7 @@ ENABLE_KGDB = 1
Image based on rpi-basic-image which includes most of the packages in this
layer and some media samples.
-2.J. Boot to U-Boot
+2.K. Boot to U-Boot
===
To have u-boot load kernel image, set in your local.conf
KERNEL_IMAGETYPE = uImage
@@ -163,7 +169,7 @@ KERNEL_IMAGETYPE = uImage
This will make kernel.img be u-boot image which will load uImage.
By default, kernel.img is the actual kernel image (ex. Image).
-2.K. Image with Initramfs
+2.L. Image with Initramfs
=
To build an initramfs image :
* Set this 3 kernel variables (in linux-raspberrypi.inc for example)
@@ -176,7 +182,7 @@ To build an initramfs image :
* Set the meta-rasberrypi variable (in raspberrypi.conf for example)
- KERNEL_INITRAMFS = -initramfs
-2.L. Device tree support
+2.M. Device tree support
=
Device tree for RPi is only supported when using linux-raspberrypi 3.18+
kernels.
diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
b/recipes-bsp/bootfiles/rpi-config_git.bb
index 29ced342426c..56477a8821bb 100644
--- a/recipes-bsp/bootfiles/rpi-config_git.bb
+++ b/recipes-bsp/bootfiles/rpi-config_git.bb
@@ -66,6 +66,12 @@ do_deploy() {
echo # Enable offline compositing
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
echo dispmanx_offline=1 ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
fi
+
+# Mask GPU interrupts
+if [ -n ${MASK_GPU_INTERRUPT} ]; then
+echo # Mask GPU interrupts
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+echo mask_gpu_interrupt0=${MASK_GPU_INTERRUPT}
${DEPLOYDIR}/bcm2835-bootfiles/config.txt
+fi
}
addtask deploy before do_package after do_install
--
2.4.3
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 3/4] rpi-default-providers: Document how to switch providers for vc4 gfx stack
From: Derek Foreman der...@osg.samsung.com The Raspberry Pi boards can use one of two graphics stacks: The userland user-space driver or the VC4 drm/kms kernel driver. This patch documents how the user user can choose if the VC4 driver has to be used instead and set the right preferred providers for that case. Signed-off-by: Derek Foreman der...@osg.samsung.com [javier: Extend commit msg and made conditional instead removing userland] Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- Changes in v2: - Don't add a feature and allow users to change the default provider manually aided by a comment. Suggested by Andreas Müller and Andrei Gherzan. conf/machine/include/rpi-default-providers.inc | 10 ++ 1 file changed, 10 insertions(+) diff --git a/conf/machine/include/rpi-default-providers.inc b/conf/machine/include/rpi-default-providers.inc index ee3a3acce7bd..e007bbb60216 100644 --- a/conf/machine/include/rpi-default-providers.inc +++ b/conf/machine/include/rpi-default-providers.inc @@ -8,3 +8,13 @@ PREFERRED_PROVIDER_virtual/libgles2 ?= userland PREFERRED_PROVIDER_virtual/libgl ?= mesa-gl PREFERRED_PROVIDER_virtual/mesa ?= mesa-gl PREFERRED_PROVIDER_jpeg = jpeg + +# To use a kernel with the VC4 DRM/KMS driver instead, comment the +# virtual kernel, egl, libgles2, libgl and mesa preferred provider +# above and uncomment the following lines. +# +# PREFERRED_PROVIDER_virtual/kernel = linux-raspberrypi-vc4 +# PREFERRED_PROVIDER_virtual/egl ?= mesa +# PREFERRED_PROVIDER_virtual/libgles2 ?= mesa +# PREFERRED_PROVIDER_virtual/libgl ?= mesa +# PREFERRED_PROVIDER_virtual/mesa ?= mesa -- 2.4.3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH v2 4/4] README: Add a section about graphic stacks
On Aug 13, 2015, at 10:07 AM, Javier Martinez Canillas jav...@osg.samsung.com wrote: This patch adds to the README a section that explains the RPi can different graphics stacks and that the user can choose by manually changing providers. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- Changes in v2: None README | 9 + 1 file changed, 9 insertions(+) diff --git a/README b/README index 678c0eb4a4e3..0569b353870c 100644 --- a/README +++ b/README @@ -25,6 +25,7 @@ Contents: 2.K. Boot to U-Boot 2.L. Image with Initramfs 2.M. Device tree support +2.O. Graphic stacks 3. Extra apps 3.A. omxplayer 4. Source code and mirrors @@ -195,6 +196,14 @@ kernels. NOTE: KERNEL_DEVICETREE is default enabled for kernel = 3.18 and always disabled for older kernel versions. +2.O. Graphic stacks +=== +The Raspberry Pi boards can use one of two graphics stacks: The userland +user-space driver or the vc4 DRM/KMS kernel driver. By default userland +is used since the vc4 is still experimental. But this can be changed by +modifying the defaults for the kernel, egl, gles2, libgl and mesa providers. +This is explained in the conf/machine/include/rpi-default-providers.inc file. + you may want to add pointer to the commented out code that you have added to select them in rpi-default-providers.inc 3. Extra apps = -- 2.4.3 signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] (no subject)
On Mon, Jul 13, 2015 at 10:56 PM, Alvaro Martinez Tovar alvaromartinezto...@yahoo.es wrote: Dear all, I am working with Qt5.5.0 and QtCreator 3.4.2 open source. On the hardware side I work with a i.MX6 sabre platform for smart devices. As a first aproach, after having created the image fsl-image-qt5 correctly (I think), I would like to run different examples by cross compiling and executing them on the SABRE platform. On my PC I run Ubuntu 14.04 LTS. When I compile all the examples to run on the Ubuntu PC, they all work properly (bluetooth, qtquick ...) However, when I try to cross-compile and run them on the SABRE platform, I get execution errors with some of them. When I try to run a bluetooth scanner, I get: ./btscanner: error while loading shared libraries: libQt5Bluetooth.so.5: cannot open shared object file: No such file or directory When I try to run a Qtquick example (dasboard), I get: Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable. Qt Warning: Could not find a location of the system's Compose files. Consider setting the QTCOMPOSE environment variable. QQmlApplicationEngine failed to load component qrc:/qml/dashboard.qml:45 module QtQuick.Extras is not installed qrc:/qml/dashboard.qml:43 module QtQuick.Controls is not installed qrc:/qml/dashboard.qml:44 module QtQuick.Controls.Styles is not installed qrc:/qml/dashboard.qml:45 module QtQuick.Extras is not installed qrc:/qml/dashboard.qml:43 module QtQuick.Controls is not installed qrc:/qml/dashboard.qml:44 module QtQuick.Controls.Styles is not installed qrc:/qml/dashboard.qml:45 module QtQuick.Extras is not installed qrc:/qml/dashboard.qml:43 module QtQuick.Controls is not installed qrc:/qml/dashboard.qml:44 module QtQuick.Controls.Styles is not installed Can you please give me any advice on what to do? I am stuck at this point. you should use same version of qt that you are getting for meta-qt5 and 5.5 is not yet in there the latest on master is 5.4 thank you in advance! Regards -- ___ 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] meta-toolchain uclibc issue
On Jul 16, 2015, at 8:56 AM, paul grant home.paul.gr...@gmail.com wrote: Hello All, I'm trying to build a cross compiler toolchain for PowerPC (mpc8544). I'm able to successfully bitbake the meta-toolchain target for glibc, when I check inside the sysroot directory of the sdk, I find the following directories: ppce500v2-poky-linux-gnuspe x86_64-pokysdk-linux The directory ppce500v2-poky-linux-gnuspe, contains root filesystem for target (ppc500v2). The directory x86_64-pokysdk-linux, contains the cross development tools, for my host, particularly gcc (powerpc-poky-linux-gnuspe-gcc) If I execute: powerpc-poky-linux-gnuspe-gcc -v the target is set to: powerpc-poky-linux which I interpret to mean a powerpc based target with glibclinux I want to build a uclibc toolchain: to this I understand you need to add the following line to my local.conf: TCLIBC = uclibc After doing so, I am again able successfully build the target meta-toolchain. Again if I look inside the sysroot directory two directories have been created: ppce500v2-poky-linux-uclibcspe x86_64-pokysdk-linux ppce500v2-poky-linux-uclibcspe, this time the root filesystem is based on uclibc and this is refelected in the name. x86_64-pokysdk-linux, again a directory to hold the host tools has been created. The gcc tools are located in under directory ./usr/bin/powerpc-poky-linux-gnuspe as before, If I execute: powerpc-poky-linux-gnuspe-gcc -v the target is set to: powerpc-poky-linux However given that I've selected uclibc, I was expecting the gcc tools to be located under a directory: ./usr/bin/powerpc-poky-linux-uclibcspe to reflect the fact that the tools are targeting uclibc. so where are they found instead ? If I look inside the environment script created by the meta-toolchain target it shares this expectation as is reflected by the extract for CC envvar: export CC=powerpc-poky-linux-uclibcspe-gcc -m32 -mcpu=8548 -mabi=spe -mspe -mfloat-gprs=double --sysroot=$SDKTARGETSYSROOT If I search the files created by the target meta-toolchain, it has actually created an apprpriate gcc located deeply nested under the work diretcory, a gcc toolset of the correct form has been created, namely: powerpc-poky-linux-uclibcspe-g++ Just to confirm when I run with the -v option it shows its target as: powerpc-poky-linux-uclibcspe Can someone clarify what's happening here?!? 1. Are my expectations correct? 2. If so, why is the correct toolchain created, but not put in the correct place by the populate-sdk target? -cpopulate_sdk would generate a self installer which will be a shell script inside your deploy area you can install it on a machine and use it outside yocto/OE build env, for using internal toolchain from native sysroot as you have been trying you don’t need to build sdk and meta-toolchain is supposed to be replace with image specific SDKs, use -cpopulate_sdk imagename to generate SDKs Thanks in advance for any help you can provide! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 4/4] README: Add a section about graphic stacks
This patch adds to the README a section that explains the RPi can different graphics stacks and that the user can choose by manually changing providers. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- Changes in v2: None README | 9 + 1 file changed, 9 insertions(+) diff --git a/README b/README index 678c0eb4a4e3..0569b353870c 100644 --- a/README +++ b/README @@ -25,6 +25,7 @@ Contents: 2.K. Boot to U-Boot 2.L. Image with Initramfs 2.M. Device tree support +2.O. Graphic stacks 3. Extra apps 3.A. omxplayer 4. Source code and mirrors @@ -195,6 +196,14 @@ kernels. NOTE: KERNEL_DEVICETREE is default enabled for kernel = 3.18 and always disabled for older kernel versions. +2.O. Graphic stacks +=== +The Raspberry Pi boards can use one of two graphics stacks: The userland +user-space driver or the vc4 DRM/KMS kernel driver. By default userland +is used since the vc4 is still experimental. But this can be changed by +modifying the defaults for the kernel, egl, gles2, libgl and mesa providers. +This is explained in the conf/machine/include/rpi-default-providers.inc file. + 3. Extra apps = -- 2.4.3 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH v2 2/4] linux-raspberrypi: Add a 4.1 linux kernel with vc4 support
From: Derek Foreman der...@osg.samsung.com This adds Eric Anholt's WIP kernel with dri/kms/3d support for the GPU on the rpi2. Adding a recipe that tracks this kernel, will make it easier to test this setup. This recipe should only used for testing purposes for now, so it will not be set as the default but can be chosen by changing the default providers. Signed-off-by: Derek Foreman der...@osg.samsung.com [javier: Extended commit message and set default preference to -1] Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- Changes in v2: - Add a linux-raspberrypi-vc4 recipe insted of a linux-raspberrypi one. Suggested by Petter Mabäcker, Andreas Müller and Andrei Gherzan. - Split the readme change in a separate patch. Suggested by Andrei Gherzan. - Don't make the vc4 patches inclusion conditional since will always be needed when choosing the recipe. Suggested by Andrei Gherzan. ..._defconfig-Enable-config-options-for-vc4-.patch | 48 + ...-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch | 85 +++ .../0003-drm-vc4-Use-the-fbdev_cma-helpers.patch | 115 + .../0004-drm-vc4-Allow-vblank-to-be-disabled.patch | 26 + .../0005-drm-vc4-Disable-KMS-operations.patch | 95 + .../linux/linux-raspberrypi-vc4/defconfig | 1 + recipes-kernel/linux/linux-raspberrypi-vc4_4.1.bb | 12 +++ 7 files changed, 382 insertions(+) create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0002-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0003-drm-vc4-Use-the-fbdev_cma-helpers.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0004-drm-vc4-Allow-vblank-to-be-disabled.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/0005-drm-vc4-Disable-KMS-operations.patch create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4/defconfig create mode 100644 recipes-kernel/linux/linux-raspberrypi-vc4_4.1.bb diff --git a/recipes-kernel/linux/linux-raspberrypi-vc4/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch b/recipes-kernel/linux/linux-raspberrypi-vc4/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch new file mode 100644 index ..1ea62489e077 --- /dev/null +++ b/recipes-kernel/linux/linux-raspberrypi-vc4/0001-ARM-bcm2709_defconfig-Enable-config-options-for-vc4-.patch @@ -0,0 +1,48 @@ +From 5908700d3cb88114002aa66f920e91961ebe91e4 Mon Sep 17 00:00:00 2001 +From: Derek Foreman der...@osg.samsung.com +Date: Fri, 24 Jul 2015 01:58:31 +0200 +Subject: [PATCH 1/5] ARM: bcm2709_defconfig: Enable config options for vc4 + support + +Add the needed Kconfig symbols to build Eric Anholt's WIP kernel +4.1 Linux kernel with vc4 dri/kms/3d support. Also increase CMA +size from 5 MiB to 256 MiB as that is needed by the driver. + +Signed-off-by: Derek Foreman der...@osg.samsung.com +--- + arch/arm/configs/bcm2709_defconfig | 5 - + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/arch/arm/configs/bcm2709_defconfig b/arch/arm/configs/bcm2709_defconfig +index a3067bfb610f..7891bb17df57 100644 +--- a/arch/arm/configs/bcm2709_defconfig b/arch/arm/configs/bcm2709_defconfig +@@ -39,6 +39,7 @@ CONFIG_MAC_PARTITION=y + CONFIG_CFQ_GROUP_IOSCHED=y + CONFIG_ARCH_BCM2709=y + CONFIG_BCM2709_DT=y ++# CONFIG_VDSO is not set + # CONFIG_CACHE_L2X0 is not set + CONFIG_SMP=y + CONFIG_HAVE_ARM_ARCH_TIMER=y +@@ -388,7 +389,7 @@ CONFIG_NFC_PN533=m + CONFIG_DEVTMPFS=y + CONFIG_DEVTMPFS_MOUNT=y + CONFIG_DMA_CMA=y +-CONFIG_CMA_SIZE_MBYTES=5 ++CONFIG_CMA_SIZE_MBYTES=256 + CONFIG_BLK_DEV_LOOP=y + CONFIG_BLK_DEV_CRYPTOLOOP=m + CONFIG_BLK_DEV_DRBD=m +@@ -771,6 +772,8 @@ CONFIG_VIDEO_TW9906=m + CONFIG_VIDEO_OV7640=m + CONFIG_VIDEO_MT9V011=m + CONFIG_FB=y ++CONFIG_DRM=y ++CONFIG_DRM_VC4=y + CONFIG_FB_BCM2708=y + CONFIG_FB_SSD1307=m + # CONFIG_BACKLIGHT_GENERIC is not set +-- +2.4.3 + diff --git a/recipes-kernel/linux/linux-raspberrypi-vc4/0002-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch b/recipes-kernel/linux/linux-raspberrypi-vc4/0002-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch new file mode 100644 index ..acc09760e820 --- /dev/null +++ b/recipes-kernel/linux/linux-raspberrypi-vc4/0002-ARM-dts-Fix-i2c-for-bcm2709-RPI2-B-board.patch @@ -0,0 +1,85 @@ +From 8882728be24f35f81da4558c84fb18658e23fcc9 Mon Sep 17 00:00:00 2001 +From: Derek Foreman der...@osg.samsung.com +Date: Wed, 27 May 2015 13:20:21 -0500 +Subject: [PATCH 2/5] ARM: dts: Fix i2c for bcm2709 RPI2 B board + +Fix up device tree and i2c setup for rpi2 + +Signed-off-by: Derek Foreman der...@osg.samsung.com +--- + arch/arm/boot/dts/bcm2708_common.dtsi | 2 +- + arch/arm/boot/dts/bcm2709-rpi-2-b.dts | 6 ++ + drivers/i2c/busses/i2c-bcm2708.c | 6 +- + 3 files changed, 12 insertions(+), 2
[yocto] [oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to right list.
Resending to the right list. (yocto@yoctoproject.org rather than openembedded-de...@lists.openembedded.org ) Radzy will be working on meta-selinux and I've suggested that the start with a package uprev or two once the upstream selinux release intentions are known. ../Randy --- Going on-list like I should have originally. On 2015-07-31 01:33 PM, Joe MacDonald wrote: Hey Randy, Good to hear from you. [meta-selinux updates for oe-core-1.9] On 15.07.31 (Fri 01:05) Randy MacLeod wrote: What's the plan for meta-selinux in the next 2 months? Roy dug up the current meta-selinux, upstream versions: swig 2.0.103.0.6 python-ipy 0.81 0.83 audit 2.3.22.4.3 refpolicy-mls 2.201403112.20141203 libcap-ng 0.7.30.7.7 setools 3.3.83.3.8 sepolgengit1.2.2 libsemanage git 2.4 checkpolicy 2.3 2.4 policycoreutils git 2.4 selinux-config 0.1 0.1 libsepolgit 2.4 libsemanage 2.3 2.4 sepolgen 1.2.11.2.2 libsepol2.3 2.4 libselinux git 2.4 policycoreutils 2.3 2.4 libselinux 2.3 2.4 ustr 1.0.41.0.4 There's a backlog of meta-selinux patches to integrate that have been in my merge queue for rather a long time now. I expect to clear that out, which will include an update to the most recent (not the current, any longer, I don't think) refpolicy and a new recipe that will build from the refpolicy git repository rather than release tarballs. I think this'll be a significant benefit to everyone in that it'll make it much easier to migrate patches and to try out a new release without waiting for a full update. Those are the big things on the horizon. The other one is the filesystem labelling work being done by the community. It looks quite good and as soon as I get a few minutes to try it out a bit more on some oddball configurations to ensure we aren't bringing in any new dependencies (after having just scrubbed a bunch of bashisms and hidden deps), it'll likely get merged. There's nothing on the radar in the short term that hasn't already been discussed on the mailing list, though, AFAIK. -J. So when Radzy is back in a week from being OOO, hopefully Joe's backlog will be cleared and we all can update pkgs as needed. We can split up that work however it makes sense; just tell the list if you start working on a package. My quick review of git logs and my memory of selinux releases tells me that there tends to be an late fall release. I looked at the Changelog for a few of the components of: https://github.com/SELinuxProject/selinux and things seem to be moving along more quickly than usual so that pattern might not hold. Is anyone subscribed to the list: https://www.nsa.gov/research/selinux/list.shtml if so is there talk of an approximate release date that would help us decide if we went to update now or in a month or so? Oh and is selinux happy under gcc-5.2+? ../Randy Roy can you summarize the state of each recipe? i.e. current version and upstream version? I'd like to make sure that we're up to date when oe-core-1.9 is released. -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ Openembedded-devel mailing list openembedded-de...@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 4/4] weston: Enable rpi compositor backend
oe-core default configure options disables it Signed-off-by: Khem Raj raj.k...@gmail.com --- recipes-graphics/wayland/weston_%.bbappend | 4 1 file changed, 4 insertions(+) create mode 100644 recipes-graphics/wayland/weston_%.bbappend diff --git a/recipes-graphics/wayland/weston_%.bbappend b/recipes-graphics/wayland/weston_%.bbappend new file mode 100644 index 000..c3a7421 --- /dev/null +++ b/recipes-graphics/wayland/weston_%.bbappend @@ -0,0 +1,4 @@ +EXTRA_OECONF_append_rpi = \ +--enable-rpi-compositor \ +WESTON_NATIVE_BACKEND=rpi-backend.so \ + -- 2.1.4 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido qt4-embedded packaging problems
On Thu, Aug 13, 2015 at 1:56 PM, Richard Cagley rcag...@gmail.com wrote: When I try to bitbake core-image-minimal-dev I get an error involving cpio when I include qt4-embedded in my CORE_IMAGE_EXTRA_INSTALL list. I looked in the log file and I see a bunch of PT_INTERP segment not corresponding to .interp section and STT_GNU_IFUNC not handled on ARM yet errors and then a final failure about rootfs creation due to cpio. these are prelink errors. Which release are you on ? Is there something special I need to do to include qt4-embedded for an arm target? No. Although as a workaround you can disable cross prelink by removing it from USER_CLASSES in local.conf and see if that works then we know its a prelinking issue. -- ___ 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] [oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to right list.
[[oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to right list.] On 15.08.13 (Thu 17:37) Randy MacLeod wrote: Resending to the right list. (yocto@yoctoproject.org rather than openembedded-de...@lists.openembedded.org ) Radzy will be working on meta-selinux and I've suggested that the start with a package uprev or two once the upstream selinux release intentions are known. Well, the backlog is cleared out (not quite true, but I'm waiting on a final verification from my autobuilders before merging the last couple of patches) and it looks like I didn't destroy Phil's work on the filesystem labelling bits when rebasing them, so I expect I'll merge those tomorrow too. Let's say everything after that is negotiable. :-) -J. ../Randy --- Going on-list like I should have originally. On 2015-07-31 01:33 PM, Joe MacDonald wrote: Hey Randy, Good to hear from you. [meta-selinux updates for oe-core-1.9] On 15.07.31 (Fri 01:05) Randy MacLeod wrote: What's the plan for meta-selinux in the next 2 months? Roy dug up the current meta-selinux, upstream versions: swig 2.0.103.0.6 python-ipy 0.81 0.83 audit 2.3.22.4.3 refpolicy-mls 2.201403112.20141203 libcap-ng 0.7.30.7.7 setools 3.3.83.3.8 sepolgengit1.2.2 libsemanage git 2.4 checkpolicy 2.3 2.4 policycoreutils git 2.4 selinux-config 0.1 0.1 libsepolgit 2.4 libsemanage 2.3 2.4 sepolgen 1.2.11.2.2 libsepol2.3 2.4 libselinux git 2.4 policycoreutils 2.3 2.4 libselinux 2.3 2.4 ustr 1.0.41.0.4 There's a backlog of meta-selinux patches to integrate that have been in my merge queue for rather a long time now. I expect to clear that out, which will include an update to the most recent (not the current, any longer, I don't think) refpolicy and a new recipe that will build from the refpolicy git repository rather than release tarballs. I think this'll be a significant benefit to everyone in that it'll make it much easier to migrate patches and to try out a new release without waiting for a full update. Those are the big things on the horizon. The other one is the filesystem labelling work being done by the community. It looks quite good and as soon as I get a few minutes to try it out a bit more on some oddball configurations to ensure we aren't bringing in any new dependencies (after having just scrubbed a bunch of bashisms and hidden deps), it'll likely get merged. There's nothing on the radar in the short term that hasn't already been discussed on the mailing list, though, AFAIK. -J. So when Radzy is back in a week from being OOO, hopefully Joe's backlog will be cleared and we all can update pkgs as needed. We can split up that work however it makes sense; just tell the list if you start working on a package. My quick review of git logs and my memory of selinux releases tells me that there tends to be an late fall release. I looked at the Changelog for a few of the components of: https://github.com/SELinuxProject/selinux and things seem to be moving along more quickly than usual so that pattern might not hold. Is anyone subscribed to the list: https://www.nsa.gov/research/selinux/list.shtml if so is there talk of an approximate release date that would help us decide if we went to update now or in a month or so? Oh and is selinux happy under gcc-5.2+? ../Randy Roy can you summarize the state of each recipe? i.e. current version and upstream version? I'd like to make sure that we're up to date when oe-core-1.9 is released. -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido qt4-embedded packaging problems
On Thu, Aug 13, 2015 at 4:43 PM, Khem Raj raj.k...@gmail.com wrote: On Thu, Aug 13, 2015 at 1:56 PM, Richard Cagley rcag...@gmail.com wrote: When I try to bitbake core-image-minimal-dev I get an error involving cpio when I include qt4-embedded in my CORE_IMAGE_EXTRA_INSTALL list. I looked in the log file and I see a bunch of PT_INTERP segment not corresponding to .interp section and STT_GNU_IFUNC not handled on ARM yet errors and then a final failure about rootfs creation due to cpio. these are prelink errors. Which release are you on ? fido with poky and meta-xilinx. 1.26 for bitbake. Is there something special I need to do to include qt4-embedded for an arm target? No. Although as a workaround you can disable cross prelink by removing it from USER_CLASSES in local.conf and see if that works then we know its a prelinking issue. I removed image-prelink from USER_CLASSES in my local.conf and got the same result. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/4] userland: Fix install prefix and generate pkgconfigs
several userspace libraries like libepoxy poke for pkgconfigs ( .pc )
files to detect egl support, and comes out to fail in configure stage,
one of the patches now adds support to generate .pc files for some known
cases. it could be further extended if needed for other libraries too
Secondly, the default CMAKE_INSTALL_PREFIX is /opt/vc but in OE we use
proper /usr so lets make this change as well, it simplifies do_install()
.so are not versioned so we need to grapple with OE's defaults of
expecting versioned .so files.
Adjust packages for -dev package such that it can automatically package
pkgconfig files and inherit pkgconfig because in cmake code we are not
looking for pkgconfig so we need the dependency also put in place for
consistent builds
Signed-off-by: Khem Raj raj.k...@gmail.com
---
.../0002-set-VMCS_INSTALL_PREFIX-to-usr.patch | 29 ++
...make-generate-and-install-pkgconfig-files.patch | 114 +
recipes-graphics/userland/userland_git.bb | 21 ++--
3 files changed, 152 insertions(+), 12 deletions(-)
create mode 100644
recipes-graphics/userland/userland/0002-set-VMCS_INSTALL_PREFIX-to-usr.patch
create mode 100644
recipes-graphics/userland/userland/0003-cmake-generate-and-install-pkgconfig-files.patch
diff --git
a/recipes-graphics/userland/userland/0002-set-VMCS_INSTALL_PREFIX-to-usr.patch
b/recipes-graphics/userland/userland/0002-set-VMCS_INSTALL_PREFIX-to-usr.patch
new file mode 100644
index 000..1c981af
--- /dev/null
+++
b/recipes-graphics/userland/userland/0002-set-VMCS_INSTALL_PREFIX-to-usr.patch
@@ -0,0 +1,29 @@
+From 05554d8486050546efc3c0605015786c8b267d19 Mon Sep 17 00:00:00 2001
+From: Khem Raj raj.k...@gmail.com
+Date: Sun, 9 Aug 2015 23:58:17 -0700
+Subject: [PATCH 1/2] set VMCS_INSTALL_PREFIX to /usr
+
+in OE we dont use /opt/vc but standard prefix
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+---
+Upstream-Status: Submitted
+ makefiles/cmake/vmcs.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/makefiles/cmake/vmcs.cmake b/makefiles/cmake/vmcs.cmake
+index 0f8641b..e9d576d 100644
+--- a/makefiles/cmake/vmcs.cmake
b/makefiles/cmake/vmcs.cmake
+@@ -10,7 +10,7 @@ INCLUDE(CPack)
+ if (ANDROID)
+ SET(VMCS_INSTALL_PREFIX /vendor/brcm/islands CACHE PATH Prefix prepended
to install directories FORCE)
+ else()
+- SET(VMCS_INSTALL_PREFIX /opt/vc CACHE PATH Prefix prepended to install
directories FORCE)
++ SET(VMCS_INSTALL_PREFIX /usr CACHE PATH Prefix prepended to install
directories FORCE)
+ endif()
+
+ SET(CMAKE_INSTALL_PREFIX ${VMCS_INSTALL_PREFIX} CACHE INTERNAL Prefix
+--
+2.1.4
+
diff --git
a/recipes-graphics/userland/userland/0003-cmake-generate-and-install-pkgconfig-files.patch
b/recipes-graphics/userland/userland/0003-cmake-generate-and-install-pkgconfig-files.patch
new file mode 100644
index 000..c644d52
--- /dev/null
+++
b/recipes-graphics/userland/userland/0003-cmake-generate-and-install-pkgconfig-files.patch
@@ -0,0 +1,114 @@
+From ef43e09c2d13b88c2e92cffc94b68003afcb1f13 Mon Sep 17 00:00:00 2001
+From: Khem Raj raj.k...@gmail.com
+Date: Sun, 9 Aug 2015 23:59:32 -0700
+Subject: [PATCH 2/2] cmake: generate and install pkgconfig files
+
+many packages expect packageconfig support especially for detecting EGL
+libraries. This patch helps in compiling those packages on RPi
+
+Signed-off-by: Khem Raj raj.k...@gmail.com
+---
+Upstream-Status: Submitted
+ CMakeLists.txt | 10 +-
+ pkgconfig/bcm_host.pc.in | 10 ++
+ pkgconfig/egl.pc.in | 12
+ pkgconfig/glesv2.pc.in | 12
+ pkgconfig/vg.pc.in | 11 +++
+ 5 files changed, 54 insertions(+), 1 deletion(-)
+ create mode 100644 pkgconfig/bcm_host.pc.in
+ create mode 100644 pkgconfig/egl.pc.in
+ create mode 100644 pkgconfig/glesv2.pc.in
+ create mode 100644 pkgconfig/vg.pc.in
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index d8f776c..f15dc2b 100644
+--- a/CMakeLists.txt
b/CMakeLists.txt
+@@ -105,6 +105,14 @@ set(vmcs_host_apps_VERSION_MAJOR 1)
+ set(vmcs_host_apps_VERSION_MINOR 0)
+
+ include_directories(${PROJECT_BINARY_DIR})
+-
++include(FindPkgConfig QUIET)
++if(PKG_CONFIG_FOUND)
++ # Produce a pkg-config file
++ foreach(PCFILE bcm_host.pc egl.pc glesv2.pc vg.pc)
++ configure_file(pkgconfig/${PCFILE}.in ${PCFILE} @ONLY)
++ install(FILES ${CMAKE_CURRENT_BINARY_DIR}/${PCFILE}
++ DESTINATION ${CMAKE_INSTALL_PREFIX}/lib/pkgconfig)
++ endforeach()
++endif()
+ # Remove cache entry, if one added by command line
+ unset(KHRONOS_EGL_PLATFORM CACHE)
+diff --git a/pkgconfig/bcm_host.pc.in b/pkgconfig/bcm_host.pc.in
+new file mode 100644
+index 000..c7237c5
+--- /dev/null
b/pkgconfig/bcm_host.pc.in
+@@ -0,0 +1,10 @@
++prefix=@CMAKE_INSTALL_PREFIX@
++exec_prefix=${prefix}
++libdir=${exec_prefix}/lib
++includedir=${prefix}/include
++
++Name: bcm_host
++Description: Broadcom VideoCore host API
[yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers
vcos headers include headers like vcos_platform.h vcos_futex_mutex.h
vcos_platform_types.h and these headers are different based on
platform/OSes. e.g. OS targets that support pthreads these headers
should come from pthreads/ folder but not for others. So one would add
right -I option for every package that accesses them directly or
indirectly. so if a software does #include EGL/egl.h then it will
break
| In file included from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/usr/include/interface/vcos/vcos_assert.h:149:0,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/usr/include/interface/vcos/vcos.h:114,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/usr/include/interface/vmcs_host/vc_dispmanx.h:33,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/usr/include/EGL/eglplatform.h:110,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/usr/include/EGL/egl.h:36,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/../shared/platform.h:29,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/window.h:33,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-neon-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/eventdemo.c:40:
|
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/usr/include/interface/vcos/vcos_types.h:38:33:
fatal error: vcos_platform_types.h: No such file or directory
| #include vcos_platform_types.h
| ^
| compilation terminated.
This is wrong, it should not happen since doing simple #include
EGL/egl.h should not demand manual addition of some internal paths
tobe added to -I flags.
This patch fixes the headers which refer to headers inside pthreads/
folder to prefix them with pthreads/ so we dont have to specify
additional paths
This fixes weston on rpi and I believe there are more patches now to
recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
recipes-multimedia/omxplayer/omxplayer_git.bb
which can be removed as well
Signed-off-by: Khem Raj raj.k...@gmail.com
---
recipes-graphics/userland/userland_git.bb | 8
1 file changed, 8 insertions(+)
diff --git a/recipes-graphics/userland/userland_git.bb
b/recipes-graphics/userland/userland_git.bb
index 6c7200c..188237a 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -37,6 +37,14 @@ PACKAGECONFIG[wayland] = -DBUILD_WAYLAND=TRUE,,wayland,
CFLAGS_append = -fPIC
+do_install_append () {
+ for f in `find ${D}${includedir}/interface/vcos/ -name *.h`; do
+ sed -i 's/include vcos_platform.h/include
pthreads\/vcos_platform.h/g' ${f}
+ sed -i 's/include vcos_futex_mutex.h/include
pthreads\/vcos_futex_mutex.h/g' ${f}
+ sed -i 's/include vcos_platform_types.h/include
pthreads\/vcos_platform_types.h/g' ${f}
+ done
+}
+
# Shared libs from userland package build aren't versioned, so we need
# to force the .so files into the runtime package (and keep them
# out of -dev package).
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fido qt4-embedded packaging problems
On Thu, Aug 13, 2015 at 5:47 PM, Richard Cagley rcag...@gmail.com wrote: On Thu, Aug 13, 2015 at 4:43 PM, Khem Raj raj.k...@gmail.com wrote: On Thu, Aug 13, 2015 at 1:56 PM, Richard Cagley rcag...@gmail.com wrote: When I try to bitbake core-image-minimal-dev I get an error involving cpio when I include qt4-embedded in my CORE_IMAGE_EXTRA_INSTALL list. I looked in the log file and I see a bunch of PT_INTERP segment not corresponding to .interp section and STT_GNU_IFUNC not handled on ARM yet errors and then a final failure about rootfs creation due to cpio. these are prelink errors. Which release are you on ? fido with poky and meta-xilinx. 1.26 for bitbake. ok Is there something special I need to do to include qt4-embedded for an arm target? No. Although as a workaround you can disable cross prelink by removing it from USER_CLASSES in local.conf and see if that works then we know its a prelinking issue. I removed image-prelink from USER_CLASSES in my local.conf and got the same result. can you remove tmp/ and rebuild ? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] preempt and meta support in linux-yocto-4.1
On Thu, Aug 13, 2015 at 8:19 AM, Cristian Bercaru cristian.berc...@windriver.com wrote: Could you give me the URL repository used to create the meta data? It's right in the SRC_URI of the kernel recipes in master. git://git.yoctoproject.org/yocto-kernel-cache Bruce Thanks, Cristian The only thing that has changed is that the meta data is pulled from a separate repository (the same repository that has always been used to create the meta branch), and after that, nothing at all changes to the configuration, patch and build phases. On 08/07/2015 05:10 AM, Bruce Ashfield wrote: On Thu, Aug 6, 2015 at 11:21 AM, Paul Gortmaker paul.gortma...@windriver.com wrote: On 2015-08-05 03:44 PM, Cristian Bercaru wrote: Hello! Does linux-yocto-4.1 implement all the preempt-rt support in standard/preempt-rt branch? or Does it have a preempt-rt patch, like 3.4, 3.10 and 3.14? It has always been on a branch IIRC, and I don't think we've ever used a monolithic -rt patch that was applied at build time. correct. The preempt-rt support is in place for 4.1 and is in the same format as the other linux-yocto kernels. standard/preempt-rt has the broken out -rt patches applied on top of the 4.1 baseline. How is the kernel configuration built in 4.1? I don't see any meta branch. Does it use configuration fragments, defconfigs, both or is it left at the BSP developers' choice? The meta content was separated out of the kernel source repo, to be its own entity, but you can still find the content that was there before in tmp/work-shared/genericx86-64/kernel-source/.kernel-meta (for x86, insert your own board/bsp name as appropriate) Also correct (thanks Paul). The only thing that has changed is that the meta data is pulled from a separate repository (the same repository that has always been used to create the meta branch), and after that, nothing at all changes to the configuration, patch and build phases. Cheers, Bruce You can see some of the recent tooling commits relating to meta dir handling on top of tree here: http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-tools/ Paul. -- Thank you, Cristian Bercaru -- ___ 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 -- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[yocto] Problem creating debug build with inlined functions
Hello, We're trying to create a debug build so we can use our image with gdb, however we're unable to get it to compile. We've added the lines DEBUG_BUILD = 1 and EXTRA_IMAGE_FEATURES += tools-sdk dbg-pkgs tools-debug debug-tweaks to the local.conf file, but it seems to be failing on glibc. The errors we get have to do with inlined functions (./tlsdeschtab.h:28:1: error: inlining failed in call to 'hash_tlsdesc': indirect function call with a yet undetermined callee [-Werror=inline] | hash_tlsdesc (void *p)). Are we missing a compile flag? We tried adding -gdwarf-2 to the CFLAGS option in local.conf but still got the same error. Any help would be appreciated! Thanks, Todd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] fido qt4-embedded packaging problems
When I try to bitbake core-image-minimal-dev I get an error involving cpio when I include qt4-embedded in my CORE_IMAGE_EXTRA_INSTALL list. I looked in the log file and I see a bunch of PT_INTERP segment not corresponding to .interp section and STT_GNU_IFUNC not handled on ARM yet errors and then a final failure about rootfs creation due to cpio. Is there something special I need to do to include qt4-embedded for an arm target? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No '/lib/modules' directory in image, modprobe fails
On Tue, Aug 11, 2015 at 6:36 PM, Khem Raj raj.k...@gmail.com wrote: On Aug 11, 2015, at 5:53 PM, Todd Efflam todd.eff...@gmail.com wrote: Hello, We're trying to load and unload modules using modprobe but are having problems. The command fails with modprobe: can't change directory to '/lib/modules': no such file or directory. There is actually no /lib/modules directory on the image at all. We tried to install the linux-libc-headers package but it failed and I think the reason is we are using the 3.14 kernel and the package is 3.19. Any help would be appreciated! linux-libc-headers is kernel APIs for userland. The modules are generated as individual packages during kernel build. You can choose which modules you want to package default it none. if you want all default modules to be included in image you can add MACHINE_EXTRA_RRECOMMENDS = kernel-modules” to you machine.conf Otherwise if you know which ones your system needs then you can add it to IMAGE_INSTALL individually. IMAGE_INSTALL += kernel-module-name-of-module” -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto Thank you this fixed the problem! -Todd -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ***SPAM*** [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers
Hi Khem, It's OK to me to change all of them, but for the EGL detection just the vcos_platform[_types].h are mandatory to fix... I've tested that with my patch - which just provides those 2 - on several packages, and it works fine with only those it seems. There seems to be some apparently non-consistent include policies in userland, but Alex raised my attention to the fact that it seems to be a feature, and a potentially contentious issue - at least, in the past. Best regards, Herve -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: vendredi 14 août 2015 04:57 To: Herve Jourdain herve.jourd...@neuf.fr Cc: yocto@yoctoproject.org; Andrei Gherzan and...@gherzan.ro; pet...@technux.se; Alex J Lennon ajlen...@dynamicdevices.co.uk Subject: Re: ***SPAM*** [yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers On Aug 13, 2015, at 7:00 PM, Herve Jourdain herve.jourd...@neuf.fr wrote: Hi Khem, I have submitted a patch similar to this one, but yours is more elegant in the way it provides the patch - you do a sed in the install_append, while I was just literally providing a patch file, which is bigger. So I personally would vote for this one. I have one question, though: for me, only modifying the #include vcos_platform.h and #include vcos_platform_types.h was enough to make it work for everything I tested. What is the part that requires also modifying #include vcos_futex_mutex.h? Just look at the includes, they logically wont work so I went ahead and changed all locations of the reference to files under threads/ folder, which is complete fix then. Best regards, Herve -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Khem Raj Sent: vendredi 14 août 2015 02:41 To: yocto@yoctoproject.org Subject: ***SPAM*** [yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers vcos headers include headers like vcos_platform.h vcos_futex_mutex.h vcos_platform_types.h and these headers are different based on platform/OSes. e.g. OS targets that support pthreads these headers should come from pthreads/ folder but not for others. So one would add right -I option for every package that accesses them directly or indirectly. so if a software does #include EGL/egl.h then it will break | In file included from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vcos/vcos_assert.h:149:0, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vcos/vcos.h:114, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vmcs_host/vc_dispmanx.h:33, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/EGL/eglplatform.h:110, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/EGL/egl.h:36, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf- vfp-ne on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/../shar ed/pla tform.h:29, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf- vfp-ne on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/window. h:33, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf- vfp-ne on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/eventde mo.c:4 0: | /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vcos/vcos_types.h:38:33: fatal error: vcos_platform_types.h: No such file or directory | #include vcos_platform_types.h | ^ | compilation terminated. This is wrong, it should not happen since doing simple #include EGL/egl.h should not demand manual addition of some internal paths tobe added to -I flags. This patch fixes the headers which refer to headers inside pthreads/ folder to prefix them with pthreads/ so we dont have to specify additional paths This fixes weston on rpi and I believe there are more patches now to recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend recipes-multimedia/omxplayer/omxplayer_git.bb which can be removed as well Signed-off-by: Khem Raj raj.k...@gmail.com --- recipes-graphics/userland/userland_git.bb | 8 1 file changed, 8 insertions(+) diff --git a/recipes-graphics/userland/userland_git.bb b/recipes-graphics/userland/userland_git.bb index 6c7200c..188237a 100644 --- a/recipes-graphics/userland/userland_git.bb +++ b/recipes-graphics/userland/userland_git.bb @@ -37,6 +37,14 @@ PACKAGECONFIG[wayland] = -DBUILD_WAYLAND=TRUE,,wayland,
Re: [yocto] ***SPAM*** [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers
Hi Khem,
I have submitted a patch similar to this one, but yours is more elegant in
the way it provides the patch - you do a sed in the install_append, while I
was just literally providing a patch file, which is bigger.
So I personally would vote for this one.
I have one question, though: for me, only modifying the #include
vcos_platform.h and #include vcos_platform_types.h was enough to make it
work for everything I tested.
What is the part that requires also modifying #include vcos_futex_mutex.h?
Best regards,
Herve
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Khem Raj
Sent: vendredi 14 août 2015 02:41
To: yocto@yoctoproject.org
Subject: ***SPAM*** [yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust
include location for pthreads-headers
vcos headers include headers like vcos_platform.h vcos_futex_mutex.h
vcos_platform_types.h and these headers are different based on
platform/OSes. e.g. OS targets that support pthreads these headers should
come from pthreads/ folder but not for others. So one would add right -I
option for every package that accesses them directly or indirectly. so if a
software does #include EGL/egl.h then it will break
| In file included from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vcos/vcos_assert.h:149:0,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vcos/vcos.h:114,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vmcs_host/vc_dispmanx.h:33,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/EGL/eglplatform.h:110,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/EGL/egl.h:36,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-ne
on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/../shared/pla
tform.h:29,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-ne
on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/window.h:33,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-ne
on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/eventdemo.c:4
0:
|
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vcos/vcos_types.h:38:33:
fatal error: vcos_platform_types.h: No such file or directory
| #include vcos_platform_types.h
| ^
| compilation terminated.
This is wrong, it should not happen since doing simple #include EGL/egl.h
should not demand manual addition of some internal paths tobe added to -I
flags.
This patch fixes the headers which refer to headers inside pthreads/ folder
to prefix them with pthreads/ so we dont have to specify additional paths
This fixes weston on rpi and I believe there are more patches now to
recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
recipes-multimedia/omxplayer/omxplayer_git.bb
which can be removed as well
Signed-off-by: Khem Raj raj.k...@gmail.com
---
recipes-graphics/userland/userland_git.bb | 8
1 file changed, 8 insertions(+)
diff --git a/recipes-graphics/userland/userland_git.bb
b/recipes-graphics/userland/userland_git.bb
index 6c7200c..188237a 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -37,6 +37,14 @@ PACKAGECONFIG[wayland] = -DBUILD_WAYLAND=TRUE,,wayland,
CFLAGS_append = -fPIC
+do_install_append () {
+ for f in `find ${D}${includedir}/interface/vcos/ -name *.h`; do
+ sed -i 's/include vcos_platform.h/include
pthreads\/vcos_platform.h/g' ${f}
+ sed -i 's/include vcos_futex_mutex.h/include
pthreads\/vcos_futex_mutex.h/g' ${f}
+ sed -i 's/include vcos_platform_types.h/include
pthreads\/vcos_platform_types.h/g' ${f}
+ done
+}
+
# Shared libs from userland package build aren't versioned, so we need #
to force the .so files into the runtime package (and keep them # out of
-dev package).
--
2.1.4
--
___
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] ***SPAM*** [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers
On Aug 13, 2015, at 7:00 PM, Herve Jourdain herve.jourd...@neuf.fr wrote:
Hi Khem,
I have submitted a patch similar to this one, but yours is more elegant in
the way it provides the patch - you do a sed in the install_append, while I
was just literally providing a patch file, which is bigger.
So I personally would vote for this one.
I have one question, though: for me, only modifying the #include
vcos_platform.h and #include vcos_platform_types.h was enough to make it
work for everything I tested.
What is the part that requires also modifying #include vcos_futex_mutex.h”?
Just look at the includes, they logically won’t work so I went ahead and
changed all locations
of the reference to files under threads/ folder, which is complete fix then.
Best regards,
Herve
-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Khem Raj
Sent: vendredi 14 août 2015 02:41
To: yocto@yoctoproject.org
Subject: ***SPAM*** [yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust
include location for pthreads-headers
vcos headers include headers like vcos_platform.h vcos_futex_mutex.h
vcos_platform_types.h and these headers are different based on
platform/OSes. e.g. OS targets that support pthreads these headers should
come from pthreads/ folder but not for others. So one would add right -I
option for every package that accesses them directly or indirectly. so if a
software does #include EGL/egl.h then it will break
| In file included from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vcos/vcos_assert.h:149:0,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vcos/vcos.h:114,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vmcs_host/vc_dispmanx.h:33,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/EGL/eglplatform.h:110,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/EGL/egl.h:36,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-ne
on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/../shared/pla
tform.h:29,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-ne
on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/window.h:33,
| from
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf-vfp-ne
on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/eventdemo.c:4
0:
|
/mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspberrypi2/
usr/include/interface/vcos/vcos_types.h:38:33:
fatal error: vcos_platform_types.h: No such file or directory
| #include vcos_platform_types.h
| ^
| compilation terminated.
This is wrong, it should not happen since doing simple #include EGL/egl.h
should not demand manual addition of some internal paths tobe added to -I
flags.
This patch fixes the headers which refer to headers inside pthreads/ folder
to prefix them with pthreads/ so we dont have to specify additional paths
This fixes weston on rpi and I believe there are more patches now to
recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend
recipes-multimedia/omxplayer/omxplayer_git.bb
which can be removed as well
Signed-off-by: Khem Raj raj.k...@gmail.com
---
recipes-graphics/userland/userland_git.bb | 8
1 file changed, 8 insertions(+)
diff --git a/recipes-graphics/userland/userland_git.bb
b/recipes-graphics/userland/userland_git.bb
index 6c7200c..188237a 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -37,6 +37,14 @@ PACKAGECONFIG[wayland] = -DBUILD_WAYLAND=TRUE,,wayland,
CFLAGS_append = -fPIC
+do_install_append () {
+ for f in `find ${D}${includedir}/interface/vcos/ -name *.h`; do
+ sed -i 's/include vcos_platform.h/include
pthreads\/vcos_platform.h/g' ${f}
+ sed -i 's/include vcos_futex_mutex.h/include
pthreads\/vcos_futex_mutex.h/g' ${f}
+ sed -i 's/include vcos_platform_types.h/include
pthreads\/vcos_platform_types.h/g' ${f}
+ done
+}
+
# Shared libs from userland package build aren't versioned, so we need #
to force the .so files into the runtime package (and keep them # out of
-dev package).
--
2.1.4
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
yocto mailing list
Re: [yocto] Problem creating debug build with inlined functions
On Thu, Aug 13, 2015 at 1:25 PM, Todd Efflam todd.eff...@gmail.com wrote: Hello, We're trying to create a debug build so we can use our image with gdb, however we're unable to get it to compile. We've added the lines DEBUG_BUILD = 1 and EXTRA_IMAGE_FEATURES += tools-sdk dbg-pkgs tools-debug debug-tweaks to the local.conf file, but it seems to be failing on glibc. The errors we get have to do with inlined functions (./tlsdeschtab.h:28:1: error: inlining failed in call to 'hash_tlsdesc': indirect function call with a yet undetermined callee [-Werror=inline] | hash_tlsdesc (void *p)). Are we missing a compile flag? We tried adding -gdwarf-2 to the CFLAGS option in local.conf but still got the same error. Any help would be appreciated! when you choose DEBUG_BUILD = 1 it also changes the default optimization settings for glibc to -O which is -O1 really. Thats not a common flag used to build glibc so you might have fallen into less used case Please test out this patch and let me know if it fixed the problem for you http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/masterid=16935bb4b6df99c6443dab06c77a9cfd4eb35f5d Thanks, Todd -- ___ 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] ***SPAM*** [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers
On Aug 13, 2015, at 8:15 PM, Herve Jourdain herve.jourd...@neuf.fr wrote: Hi Khem, It's OK to me to change all of them, but for the EGL detection just the vcos_platform[_types].h are mandatory to fix... I've tested that with my patch - which just provides those 2 - on several packages, and it works fine with only those it seems. yes I know. but I thought of doing a complete fix for other unforeseen scenarios too. There seems to be some apparently non-consistent include policies in userland, but Alex raised my attention to the fact that it seems to be a feature, and a potentially contentious issue - at least, in the past. well, its broadcom SDK which targets more than Linux OS so they have a valid point of expecting it to be added via compiler paths so there software keeps working without having to deal with OS specific nuances. but here in OE we know we are always Linux so we can make our life easier. Best regards, Herve -Original Message- From: Khem Raj [mailto:raj.k...@gmail.com] Sent: vendredi 14 août 2015 04:57 To: Herve Jourdain herve.jourd...@neuf.fr Cc: yocto@yoctoproject.org; Andrei Gherzan and...@gherzan.ro; pet...@technux.se; Alex J Lennon ajlen...@dynamicdevices.co.uk Subject: Re: ***SPAM*** [yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers On Aug 13, 2015, at 7:00 PM, Herve Jourdain herve.jourd...@neuf.fr wrote: Hi Khem, I have submitted a patch similar to this one, but yours is more elegant in the way it provides the patch - you do a sed in the install_append, while I was just literally providing a patch file, which is bigger. So I personally would vote for this one. I have one question, though: for me, only modifying the #include vcos_platform.h and #include vcos_platform_types.h was enough to make it work for everything I tested. What is the part that requires also modifying #include vcos_futex_mutex.h”? Just look at the includes, they logically won’t work so I went ahead and changed all locations of the reference to files under threads/ folder, which is complete fix then. Best regards, Herve -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Khem Raj Sent: vendredi 14 août 2015 02:41 To: yocto@yoctoproject.org Subject: ***SPAM*** [yocto] [meta-raspberrypi][PATCH 3/4] userland: Adjust include location for pthreads-headers vcos headers include headers like vcos_platform.h vcos_futex_mutex.h vcos_platform_types.h and these headers are different based on platform/OSes. e.g. OS targets that support pthreads these headers should come from pthreads/ folder but not for others. So one would add right -I option for every package that accesses them directly or indirectly. so if a software does #include EGL/egl.h then it will break | In file included from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vcos/vcos_assert.h:149:0, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vcos/vcos.h:114, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vmcs_host/vc_dispmanx.h:33, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/EGL/eglplatform.h:110, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/EGL/egl.h:36, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf- vfp-ne on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/../shar ed/pla tform.h:29, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf- vfp-ne on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/window. h:33, | from /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/work/armv7at2hf- vfp-ne on-angstrom-linux-gnueabi/weston/1.8.0-r0/weston-1.8.0/clients/eventde mo.c:4 0: | /mnt/home/kraj/work/angstrom/build/tmp-angstrom-glibc/sysroots/raspber rypi2/ usr/include/interface/vcos/vcos_types.h:38:33: fatal error: vcos_platform_types.h: No such file or directory | #include vcos_platform_types.h | ^ | compilation terminated. This is wrong, it should not happen since doing simple #include EGL/egl.h should not demand manual addition of some internal paths tobe added to -I flags. This patch fixes the headers which refer to headers inside pthreads/ folder to prefix them with pthreads/ so we dont have to specify additional paths This fixes weston on rpi and I believe there are more patches now to recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_%.bbappend recipes-multimedia/omxplayer/omxplayer_git.bb which
[yocto] [PATCH 3/3] audit: build gen_xxx natively
From: Wenzong Fan wenzong@windriver.com The gen_xxx used for generating sources at compile-time, they are built by native C compiler but may involve cross-compilation options via CFLAGS, just use CFLAGS_FOR_BUILD to remove the issue. Signed-off-by: Wenzong Fan wenzong@windriver.com --- .../audit/audit/audit-build-gen_xxx-natively.patch | 566 + recipes-security/audit/audit_2.4.3.bb | 1 + 2 files changed, 567 insertions(+) create mode 100644 recipes-security/audit/audit/audit-build-gen_xxx-natively.patch diff --git a/recipes-security/audit/audit/audit-build-gen_xxx-natively.patch b/recipes-security/audit/audit/audit-build-gen_xxx-natively.patch new file mode 100644 index 000..dd3fa5c --- /dev/null +++ b/recipes-security/audit/audit/audit-build-gen_xxx-natively.patch @@ -0,0 +1,566 @@ +From b5db56c8bd99e6b0020c000843b6b7df2fcc926f Mon Sep 17 00:00:00 2001 +From: Wenzong Fan wenzong@windriver.com +Date: Thu, 13 Aug 2015 05:21:22 -0400 +Subject: [PATCH] audit: build gen_xxx natively + +The targets gen_xxx used for generating sources at compile-time, both +CC CFLAGS should not include any cross-compilation options. + +Upstream-Status: Pending + +Signed-off-by: Wenzong Fan wenzong@windriver.com +--- + auparse/Makefile.am | 74 + + lib/Makefile.am | 34 + 2 files changed, 108 insertions(+) + +diff --git a/auparse/Makefile.am b/auparse/Makefile.am +index 742f7ba..989817e 100644 +--- a/auparse/Makefile.am b/auparse/Makefile.am +@@ -82,7 +82,9 @@ gen_accesstabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h accesstab.h + gen_accesstabs_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=accesstab.h' + $(gen_accesstabs_h_OBJECTS): CC=$(CC_FOR_BUILD) + $(gen_accesstabs_h_OBJECTS): CPPFLAGS=$(CPPFLAGS_FOR_BUILD) ++$(gen_accesstabs_h_OBJECTS): CFLAGS=$(CFLAGS_FOR_BUILD) + gen_accesstabs_h$(BUILD_EXEEXT): CC=$(CC_FOR_BUILD) ++gen_accesstabs_h$(BUILD_EXEEXT): CFLAGS=$(CFLAGS_FOR_BUILD) + accesstabs.h: gen_accesstabs_h Makefile + ./gen_accesstabs_h --i2s-transtab access $@ + +@@ -90,7 +92,9 @@ gen_captabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h captab.h + gen_captabs_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=captab.h' + $(gen_captabs_h_OBJECTS): CC=$(CC_FOR_BUILD) + $(gen_captabs_h_OBJECTS): CPPFLAGS=$(CPPFLAGS_FOR_BUILD) ++$(gen_captabs_h_OBJECTS): CFLAGS=$(CFLAGS_FOR_BUILD) + gen_captabs_h$(BUILD_EXEEXT): CC=$(CC_FOR_BUILD) ++gen_captabs_h$(BUILD_EXEEXT): CFLAGS=$(CFLAGS_FOR_BUILD) + captabs.h: gen_captabs_h Makefile + ./gen_captabs_h --i2s cap $@ + +@@ -98,7 +102,9 @@ gen_clock_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h clocktab.h + gen_clock_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=clocktab.h' + $(gen_clock_h_OBJECTS): CC=$(CC_FOR_BUILD) + $(gen_clock_h_OBJECTS): CPPFLAGS=$(CPPFLAGS_FOR_BUILD) ++$(gen_clock_h_OBJECTS): CFLAGS=$(CFLAGS_FOR_BUILD) + gen_clock_h$(BUILD_EXEEXT): CC=$(CC_FOR_BUILD) ++gen_clock_h$(BUILD_EXEEXT): CFLAGS=$(CFLAGS_FOR_BUILD) + clocktabs.h: gen_clock_h Makefile + ./gen_clock_h --i2s clock $@ + +@@ -107,7 +113,9 @@ gen_clone_flagtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h \ + gen_clone_flagtabs_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=clone-flagtab.h' + $(gen_clone_flagtabs_h_OBJECTS): CC=$(CC_FOR_BUILD) + $(gen_clone_flagtabs_h_OBJECTS): CPPFLAGS=$(CPPFLAGS_FOR_BUILD) ++$(gen_clone_flagtabs_h_OBJECTS): CFLAGS=$(CFLAGS_FOR_BUILD) + gen_clone-flagtabs_h$(BUILD_EXEEXT): CC=$(CC_FOR_BUILD) ++gen_clone-flagtabs_h$(BUILD_EXEEXT): CFLAGS=$(CFLAGS_FOR_BUILD) + clone-flagtabs.h: gen_clone-flagtabs_h Makefile + ./gen_clone-flagtabs_h --i2s-transtab clone_flag $@ + +@@ -115,7 +123,9 @@ gen_epoll_ctls_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h epoll_ctl.h + gen_epoll_ctls_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=epoll_ctl.h' + $(gen_epoll_ctls_h_OBJECTS): CC=$(CC_FOR_BUILD) + $(gen_epoll_ctls_h_OBJECTS): CPPFLAGS=$(CPPFLAGS_FOR_BUILD) ++$(gen_epoll_ctls_h_OBJECTS): CFLAGS=$(CFLAGS_FOR_BUILD) + gen_epoll_ctls_h$(BUILD_EXEEXT): CC=$(CC_FOR_BUILD) ++gen_epoll_ctls_h$(BUILD_EXEEXT): CFLAGS=$(CFLAGS_FOR_BUILD) + epoll_ctls.h: gen_epoll_ctls_h Makefile + ./gen_epoll_ctls_h --i2s epoll_ctl $@ + +@@ -123,7 +133,9 @@ gen_famtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h famtab.h + gen_famtabs_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=famtab.h' + $(gen_famtabs_h_OBJECTS): CC=$(CC_FOR_BUILD) + $(gen_famtabs_h_OBJECTS): CPPFLAGS=$(CPPFLAGS_FOR_BUILD) ++$(gen_famtabs_h_OBJECTS): CFLAGS=$(CFLAGS_FOR_BUILD) + gen_famtabs_h$(BUILD_EXEEXT): CC=$(CC_FOR_BUILD) ++gen_famtabs_h$(BUILD_EXEEXT): CFLAGS=$(CFLAGS_FOR_BUILD) + famtabs.h: gen_famtabs_h Makefile + ./gen_famtabs_h --i2s fam $@ + +@@ -132,7 +144,9 @@ gen_flagtabs_h_SOURCES = ../lib/gen_tables.c ../lib/gen_tables.h flagtab.h + gen_flagtabs_h_CFLAGS = $(CFLAGS_FOR_BUILD) '-DTABLE_H=../auparse/flagtab.h' +
[yocto] [PATCH 2/3] audit: fix unknown-configure-option --with-armeb
From: Wenzong Fan wenzong@windriver.com
The option has been replaced by --with-arm:
$ ./configure -h
--with-arm enable Arm eabi processor support
Signed-off-by: Wenzong Fan wenzong@windriver.com
---
recipes-security/audit/audit_2.4.3.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/recipes-security/audit/audit_2.4.3.bb
b/recipes-security/audit/audit_2.4.3.bb
index 7fd8692..460ace0 100644
--- a/recipes-security/audit/audit_2.4.3.bb
+++ b/recipes-security/audit/audit_2.4.3.bb
@@ -38,7 +38,7 @@ EXTRA_OECONF += --without-prelude \
--without-python3 \
--disable-zos-remote \
-EXTRA_OECONF_append_arm = --with-armeb=yes
+EXTRA_OECONF_append_arm = --with-arm=yes
EXTRA_OEMAKE += PYLIBVER='python${PYTHON_BASEVERSION}' \
PYINC='${STAGING_INCDIR}/$(PYLIBVER)' \
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH 1/3] audit: clean PR after package updated
From: Wenzong Fan wenzong@windriver.com After the PV updated, it's safe to clean the PR and get PRSERVER manage it. Signed-off-by: Wenzong Fan wenzong@windriver.com --- recipes-security/audit/audit_2.4.3.bb | 1 - 1 file changed, 1 deletion(-) diff --git a/recipes-security/audit/audit_2.4.3.bb b/recipes-security/audit/audit_2.4.3.bb index 79cca30..7fd8692 100644 --- a/recipes-security/audit/audit_2.4.3.bb +++ b/recipes-security/audit/audit_2.4.3.bb @@ -4,7 +4,6 @@ storing and searching the audit records generated by the audit subsystem \ in the Linux kernel. HOMEPAGE = http://people.redhat.com/sgrubb/audit/; SECTION = base -PR = r8 LICENSE = GPLv2+ LGPLv2+ LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f -- 1.9.1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack
Hello Andreas, On 08/13/2015 06:00 PM, Andreas Müller wrote: On Thu, Aug 13, 2015 at 5:43 PM, Javier Martinez Canillas jav...@osg.samsung.com wrote: Hi Thanks a lot!l. I am afraid my build machine at home (RPi is hobby) is about to die for hard-disk issues. As soon as it's back I will try with updated mesa. As I cannot do myself currently: Can you give glmark-es2 a try? There is an issue with glmark-es2, even though it says === glmark2 2014.03 === OpenGL Information GL_VENDOR: Broadcom GL_RENDERER: Gallium 0.4 on VC4 GL_VERSION:OpenGL ES 2.0 Mesa 10.7.0-devel (git-1762568fd39b) and the framerate is higher than with glmark2: [build] use-vbo=false: FPS: 50 FrameTime: 20.000 ms [build] use-vbo=true: FPS: 54 FrameTime: 18.519 ms [texture] texture-filter=nearest: FPS: 53 FrameTime: 18.868 ms The image is frozen and no errors shown in the kernel log buffer. Eric did not answer me yet which mesa version or sha1 is known to work well with X11 + OpenGL ES. Andreas Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack
On Thu, Aug 13, 2015 at 5:43 PM, Javier Martinez Canillas jav...@osg.samsung.com wrote: Hi Thanks a lot!l. I am afraid my build machine at home (RPi is hobby) is about to die for hard-disk issues. As soon as it's back I will try with updated mesa. As I cannot do myself currently: Can you give glmark-es2 a try? Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack
Hello, On 08/13/2015 09:22 AM, Javier Martinez Canillas wrote: Hello Andreas, On 08/12/2015 10:22 PM, Andreas Müller wrote: On Wed, Aug 12, 2015 at 7:15 PM, Andreas Müller schnitzelt...@googlemail.com wrote: FYI: I managed to get the vc4 driver loaded (should be in my repo branch vc4-2). With this I get some repeating kernel error messages (don't have them here). I am sure that I read something about these messages when preparing vc4 (yes I started similar before you sent patches). Awesome, I tried to get it working yesterday but couldn't. Good work! Hope I have some energy left tonight to check further and let you know... From xorg perspective all looks fine [595923.730] (II) modeset(0): [DRI2] Setup complete [595923.730] (II) modeset(0): [DRI2] DRI driver: vc4 [595923.730] (II) modeset(0): [DRI2] VDPAU driver: vc4 [595923.740] (--) RandR disabled [595923.745] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer [595923.745] (II) AIGLX: enabled GLX_ARB_create_context [595923.745] (II) AIGLX: enabled GLX_ARB_create_context_profile [595923.745] (II) AIGLX: enabled GLX_EXT_create_context_es2_profile [595923.745] (II) AIGLX: enabled GLX_INTEL_swap_event [595923.745] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control [595923.745] (II) AIGLX: enabled GLX_EXT_framebuffer_sRGB [595923.745] (II) AIGLX: enabled GLX_ARB_fbconfig_float [595923.745] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects [595923.747] (II) AIGLX: Loaded and initialized vc4 [595923.747] (II) GLX: Initialized DRI2 GL provider for screen 0 [595923.782] (II) modeset(0): Setting screen physical size to 338 x 270 but kernel complains periodically ~6s with [ 36.814922] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate [ 43.060516] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate [ 49.325115] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate [ 55.558433] [drm:vc4_submit_cl_ioctl] *ERROR* Rendering requires BOs to validate Yes, I was able to reproduce the issue. My X -verbose output: http://hastebin.com/onovosojuw.md Will check what this message want me to say - anybody out there with helping hints? No clue. I was looking and the error is in the VC4_SUBMIT_CL ioctl cmd handler (vc4_submit_cl_ioctl) in drivers/gpu/drm/vc4/vc4_gem.c. AFAIU bo_handle_count is supposed to always be 0 but somehow mesa is passing 0 on it. The ioctl call is in vc4_flush (src/gallium/drivers/vc4/vc4_context.c) in mesa. So it seems this is a mesa issue. I've asked Eric Anholt in #dri-devel on IRC if his kernel is supposed to work with mesa 10.5.8 or if there is a minimum version / sha1 that is needed. So I spent a lot of time trying to figure out what is wrong with mesa 10.5.8 and then gave up and tried updating mesa to the version we are using for our Tizen port that works. I did the change in the meta layer just for testing purposes. This is the diff [0] on top of the kernel patches and Andreas' latest changes. I did this because it was a known mesa version that works and indeed Xorg starts and the Rendering requires BOs to validate error is gone. The complete Xorg log is at [1]. Also, glmark2 says: === glmark2 2014.03 === OpenGL Information GL_VENDOR: Broadcom GL_RENDERER: Gallium 0.4 on VC4 GL_VERSION:2.1 Mesa 10.7.0-devel (git-1762568fd39b) === And I see the horse and the box spinning. It gives me a 33-35 FPS but the last texture-filter=linear test fails with: [drm:vc4_use_bo] *ERROR* BO index -980025344 greater than BO count 9 So there are still some issues. The glkmar2 log is at [2]. I'll post the v2 of the vc4 kernel recipe patches since the problem seems to be with mesa 10.5.8 and also is working for us with Weston. At least so we all are on the same page and testing with the same set of patches. Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America [0]: http://hastebin.com/karakapeqa.diff [1]: http://hastebin.com/foyanotema.vhdl [2]: http://hastebin.com/ikotadavop.vbs -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
