Re: [yocto] [meta-raspberrypi][PATCH 5/5] rpi-default-providers: Switch providers according to used gfx stack
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). 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 Will check what this message want me to say - anybody out there with helping hints? Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments
2015-08-11 21:20 skrev Alex J Lennon:
On 11/08/2015 19:54,
Petter Mabäcker wrote:
2015-08-11 19:04 skrev Alex J Lennon:
- remove placeholder defconfig and custom copying logic - use
KBUILD_DEFCONFIG for default in-tree configurations instead - do not
replace all Yocto configured settings in do_configure_prepen see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474 [1]
Signed-off-by: Alex J Lennon ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk ---
recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
insertions(+), 15 deletions(-) delete mode 100644
recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@ SECTION =
kernel LICENSE = GPLv2 LIC_FILES_CHKSUM =
file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7 -SRC_URI += -
file://defconfig - - COMPATIBLE_MACHINE = raspberrypi PV =
${LINUX_VERSION}+git${SRCREV} -# NOTE: For now we pull in the default
config from the RPi kernel GIT tree. -KERNEL_DEFCONFIG_raspberrypi ?=
bcmrpi_defconfig -KERNEL_DEFCONFIG_raspberrypi2 ?= bcm2709_defconfig
+KMACHINE ?= ${MACHINE} +KCONFIG_MODE = --alldefconfig
+KBUILD_DEFCONFIG_raspberrypi ?= bcmrpi_defconfig
+KBUILD_DEFCONFIG_raspberrypi2 ?= bcm2709_defconfig # CMDLINE for
raspberrypi CMDLINE = dwc_otg.lpm_enable=0 console=ttyAMA0,115200
kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait @@
-38,10 +35,6 @@ python __anonymous () { d.setVar(DEPENDS, depends) }
-do_kernel_configme_prepend() { - install -m 0644
${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig ||
die No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG}
available. -} - do_install_prepend() { install -d ${D}/lib/firmware }
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig
b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
100644 index ecbf32c..000 ---
a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@ -1
+0,0 @@ -# Dummy file to get through do_kernel_configme. diff --git
a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc index
fae78b7..103512b 100644 --- a/recipes-kernel/linux/linux.inc +++
b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
kernel_configure_variable() { } do_configure_prepend() { - # Clean
.config - echo ${B}/.config + mv -f ${B}/.config
${B}/.config.patched CONF_SED_SCRIPT= # oabi / eabi support @@ -109,7
+108,8 @@ do_configure_prepend() { # Keep this the last line # Remove
all modified configs and add the rest to .config - sed -e
${CONF_SED_SCRIPT} '${WORKDIR}/defconfig' '${B}/.config' + sed -e
${CONF_SED_SCRIPT} '${B}/.config.patched' '${B}/.config' + rm -f
${B}/.config.patched yes '' | oe_runmake oldconfig } -- 1.9.1
Nice,
some small comments only. Please write a short summary of the feature
(kernel-yocto: allow in-tree defconfig) but keep the bugzilla as a
reference for further info. Always good to have some background found
This is seems a significant core change so I wanted to make sure
these
individual changes were as easily searchable as possible in case
any
problems arise in future. Can you provide an example of what you
are
suggesting for the commit msg?
Perhaps something like:
Start
using the in-tree defconfig solution provided in poky[0]. To specify
an in-tree defconfig file, edit the recipe that builds your kernel so
that it has the following command form:
KBUILD_DEFCONFIG_KMACHINE ?=
defconfig_file
You need to append the variable with KMACHINE and then
supply the path to your in-tree defconfig file.
In order to achieve
this in meta-raspberrypi will need to:
- start using
KBUILD_DEFCONFIG_KMACHINE
- Remove placeholder defconfig and custom
copying logic.
- Avoid replacing all Yocto project configured settings
in do_configure_prepend.
For more background regarding this migration
read the bugzilla bug info[1].
[0] -
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
[1]
- https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
directly
in the commit msg itself. Have you tested it using both poky:master and
poky:fido?
Rpi2 fido 3.18.16 with/without sound patch, 4.1.3
with/without sound patch.
BR,
Alex
Ok, since there has been
some changes (not only the early DT change) in poky:master it would be
good to do the same tests there. Andrei have to correct me if wrong, but
since we have a fido branch in meta-raspberrypi that's the branch that
is recommended to use against poky:fido, 'master' is in first place
verified against poky:master (latest and greatest).
BR Petter
Links:
--
[1]
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
--
Re: [yocto] core-image-sato raspberrypi2
On Jul 21, 2015, at 6:07 PM, Edward Vidal devel...@sbcglobal.net wrote: Hi all, In the file poky/meta/recipes-graphics/libepoxy/libepoxy_git.bb I tried to add --disable-egl, with no success PACKAGECONFIG[x11] = --enable-glx, --disable-glx, virtual/libx11 | checking for EGL... no | configure: error: Package requirements (egl) were not met: | | No package 'egl’ found Please update to latest on meta-raspberrypi and apply https://lists.yoctoproject.org/pipermail/yocto/2015-August/026035.html https://lists.yoctoproject.org/pipermail/yocto/2015-August/026035.html if you want you can also apply below patch but is not must https://lists.yoctoproject.org/pipermail/yocto/2015-August/026074.html https://lists.yoctoproject.org/pipermail/yocto/2015-August/026074.html signature.asc Description: Message signed with OpenPGP using GPGMail -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments
On 12/08/2015 09:08, Petter Mabäcker wrote:
2015-08-11 21:20 skrev Alex J Lennon:
On 11/08/2015 19:54, Petter Mabäcker wrote:
2015-08-11 19:04 skrev Alex J Lennon:
- remove placeholder defconfig and custom copying logic - use
KBUILD_DEFCONFIG for default in-tree configurations instead - do not
replace all Yocto configured settings in do_configure_prepen see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
Signed-off-by: Alex J Lennon ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk ---
recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
insertions(+), 15 deletions(-) delete mode 100644
recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@
SECTION = kernel LICENSE = GPLv2 LIC_FILES_CHKSUM =
file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7 -SRC_URI +=
\ - file://defconfig \ - - COMPATIBLE_MACHINE = raspberrypi PV =
${LINUX_VERSION}+git${SRCREV} -# NOTE: For now we pull in the
default config from the RPi kernel GIT tree.
-KERNEL_DEFCONFIG_raspberrypi ?= bcmrpi_defconfig
-KERNEL_DEFCONFIG_raspberrypi2 ?= bcm2709_defconfig +KMACHINE ?=
${MACHINE} +KCONFIG_MODE = --alldefconfig
+KBUILD_DEFCONFIG_raspberrypi ?= bcmrpi_defconfig
+KBUILD_DEFCONFIG_raspberrypi2 ?= bcm2709_defconfig # CMDLINE for
raspberrypi CMDLINE = dwc_otg.lpm_enable=0 console=ttyAMA0,115200
kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
@@ -38,10 +35,6 @@ python __anonymous () { d.setVar(DEPENDS,
depends) } -do_kernel_configme_prepend() { - install -m 0644
${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig
|| die No default configuration for ${MACHINE} /
${KERNEL_DEFCONFIG} available. -} - do_install_prepend() { install
-d ${D}/lib/firmware } diff --git
a/recipes-kernel/linux/linux-raspberrypi/defconfig
b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
100644 index ecbf32c..000 ---
a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@
-1 +0,0 @@ -# Dummy file to get through do_kernel_configme. diff
--git a/recipes-kernel/linux/linux.inc
b/recipes-kernel/linux/linux.inc index fae78b7..103512b 100644 ---
a/recipes-kernel/linux/linux.inc +++
b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
kernel_configure_variable() { } do_configure_prepend() { - # Clean
.config - echo ${B}/.config + mv -f ${B}/.config
${B}/.config.patched CONF_SED_SCRIPT= # oabi / eabi support @@
-109,7 +108,8 @@ do_configure_prepend() { # Keep this the last line
# Remove all modified configs and add the rest to .config - sed -e
${CONF_SED_SCRIPT} '${WORKDIR}/defconfig' '${B}/.config' +
sed -e ${CONF_SED_SCRIPT} '${B}/.config.patched'
'${B}/.config' + rm -f ${B}/.config.patched yes '' | oe_runmake
oldconfig } -- 1.9.1
Nice, some small comments only. Please write a short summary of the
feature (kernel-yocto: allow in-tree defconfig) but keep the bugzilla
as a reference for further info. Always good to have some background
found
This is seems a significant core change so I wanted to make sure these
individual changes were as easily searchable as possible in case any
problems arise in future. Can you provide an example of what you are
suggesting for the commit msg?
Perhaps something like:
Start using the in-tree defconfig solution provided in poky[0]. To specify
an in-tree defconfig file, edit the recipe that builds your kernel so that
it has the following command form:
KBUILD_DEFCONFIG_KMACHINE ?= defconfig_file
You need to append the variable with KMACHINE and then supply the path to
your in-tree defconfig file.
In order to achieve this in meta-raspberrypi will need to:
- start using KBUILD_DEFCONFIG_KMACHINE
- Remove placeholder defconfig and custom copying logic.
- Avoid replacing all Yocto project configured settings in
do_configure_prepend.
For more background regarding this migration read the bugzilla bug info[1].
[0] -
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
[1] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474
Very comprehensive. Many thanks.
directly in the commit msg itself. Have you tested it using both
poky:master and poky:fido?
Rpi2 fido 3.18.16 with/without sound patch, 4.1.3 with/without sound patch.
BR,
Alex
Ok, since there has been some changes (not only the early DT change) in
poky:master it would be good to do the same tests there. Andrei have to
correct me if wrong, but since we have a fido branch in meta-raspberrypi
Re: [yocto] Add custom tools to yocto build environment
On Jul 22, 2015, at 12:00 AM, Lukas Weiss lukas.we...@janitza.de wrote: Hello yocto friends, I have a problem with yocto you could help me with. The Background: Iam working on a yocto-linux for a TI OMAP-L138, which is a ARM9+DSP in one package. The Linux on ARM is running fine, and does everything I want. I have implemented a kernel driver to start the DSP-Core from the Linux on the ARM9-Core, but now I need to generate the Firmware for the DSP with the Yocto buid system. Main problem is, that I need a compiler/toolchain from TI to compile the Code for the DSP in the yocto build environment. At this point I did not understand how to add tools to the yocto build environment at all. I think there must be a way to add software to my host (build) system for generating code for my target. But I have no idea how to do it. When I write a BB-recipe, the architecture of the resulting files is checked to be from targets type (arm in my case), but host tools are of type x86... (which is totally correct!) I think I need a recipe, which downloads the compiler/toolchain for the DSP, extracts and installs it to my yocto build environment, so that I can use it in another recipe that compiles my code to a loadable firmware-image (which is placed to my targets rootfs). Do you have any suggestions for me how to do that? This is a multi machine build case, and in single bitbake invocation we only support single arch. But this is not a big issue you can issue two cmds MACHINE=dsp-machine bitbake blah and then MACHINE=arm-machine bitbake blah I think DSP firmware is another rootfs+kernel or may be bare metal app, you could certainly use OE/Yocto tooling for that however, I think its not trivial if you want to build from source and I think there is no support for this DSP chip as supported architecture in OE, which means it will require changes in OE-Core to support the DSP architecture and then you would either build the toolchain internally or you can also hook in a prebuilt toolchain into OE and only after that you can start to build packages for firmware. You can look into git history and see how a new architecture is added ( mips64 was one I remember last I did ) you will need something like that. quick method would be to keep building DSP firmware outside OE/yocto environment ( as you have been ) then just package the final firmware blob into ARM image Thanks, Lukas -- ___ 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
Re: [yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: support configuration fragments
2015-08-12 10:28 skrev Alex J Lennon:
On 12/08/2015 09:08,
Petter Mabäcker wrote:
2015-08-11 21:20 skrev Alex J Lennon:
On 11/08/2015 19:54, Petter Mabäcker wrote:
2015-08-11
19:04 skrev Alex J Lennon:
- remove placeholder defconfig
and custom copying logic - use KBUILD_DEFCONFIG for default in-tree
configurations instead - do not replace all Yocto configured settings in
do_configure_prepen see:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474 [1]
Signed-off-by: Alex J Lennon ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk
mailto:ajlen...@dynamicdevices.co.uk ---
recipes-kernel/linux/linux-raspberrypi.inc | 15 ---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 -
recipes-kernel/linux/linux.inc | 6 +++--- 3 files changed, 7
insertions(+), 15 deletions(-) delete mode 100644
recipes-kernel/linux/linux-raspberrypi/defconfig diff --git
a/recipes-kernel/linux/linux-raspberrypi.inc
b/recipes-kernel/linux/linux-raspberrypi.inc index 7e36408..e38d905
100644 --- a/recipes-kernel/linux/linux-raspberrypi.inc +++
b/recipes-kernel/linux/linux-raspberrypi.inc @@ -6,17 +6,14 @@ SECTION =
kernel LICENSE = GPLv2 LIC_FILES_CHKSUM =
file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7 -SRC_URI += -
file://defconfig - - COMPATIBLE_MACHINE = raspberrypi PV =
${LINUX_VERSION}+git${SRCREV} -# NOTE: For now we pull in the default
config from the RPi kernel GIT tree. -KERNEL_DEFCONFIG_raspberrypi ?=
bcmrpi_defconfig -KERNEL_DEFCONFIG_raspberrypi2 ?= bcm2709_defconfig
+KMACHINE ?= ${MACHINE} +KCONFIG_MODE = --alldefconfig
+KBUILD_DEFCONFIG_raspberrypi ?= bcmrpi_defconfig
+KBUILD_DEFCONFIG_raspberrypi2 ?= bcm2709_defconfig # CMDLINE for
raspberrypi CMDLINE = dwc_otg.lpm_enable=0 console=ttyAMA0,115200
kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait @@
-38,10 +35,6 @@ python __anonymous () { d.setVar(DEPENDS, depends) }
-do_kernel_configme_prepend() { - install -m 0644
${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG} ${WORKDIR}/defconfig ||
die No default configuration for ${MACHINE} / ${KERNEL_DEFCONFIG}
available. -} - do_install_prepend() { install -d ${D}/lib/firmware }
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig
b/recipes-kernel/linux/linux-raspberrypi/defconfig deleted file mode
100644 index ecbf32c..000 ---
a/recipes-kernel/linux/linux-raspberrypi/defconfig +++ /dev/null @@ -1
+0,0 @@ -# Dummy file to get through do_kernel_configme. diff --git
a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc index
fae78b7..103512b 100644 --- a/recipes-kernel/linux/linux.inc +++
b/recipes-kernel/linux/linux.inc @@ -33,8 +33,7 @@
kernel_configure_variable() { } do_configure_prepend() { - # Clean
.config - echo ${B}/.config + mv -f ${B}/.config
${B}/.config.patched CONF_SED_SCRIPT= # oabi / eabi support @@ -109,7
+108,8 @@ do_configure_prepend() { # Keep this the last line # Remove
all modified configs and add the rest to .config - sed -e
${CONF_SED_SCRIPT} '${WORKDIR}/defconfig' '${B}/.config' + sed -e
${CONF_SED_SCRIPT} '${B}/.config.patched' '${B}/.config' + rm -f
${B}/.config.patched yes '' | oe_runmake oldconfig } -- 1.9.1
Nice,
some small comments only. Please write a short summary of the feature
(kernel-yocto: allow in-tree defconfig) but keep the bugzilla as a
reference for further info. Always good to have some background
found
This is seems a significant core change so I wanted to make
sure these individual changes were as easily searchable as possible in
case any problems arise in future. Can you provide an example of what
you are suggesting for the commit msg?
Perhaps something like: Start
using the in-tree defconfig solution provided in poky[0]. To specify
an in-tree defconfig file, edit the recipe that builds your kernel so
that it has the following command form: KBUILD_DEFCONFIG_KMACHINE ?=
defconfig_file You need to append the variable with KMACHINE and then
supply the path to your in-tree defconfig file. In order to achieve
this in meta-raspberrypi will need to: - start using
KBUILD_DEFCONFIG_KMACHINE - Remove placeholder defconfig and custom
copying logic. - Avoid replacing all Yocto project configured settings
in do_configure_prepend. For more background regarding this migration
read the bugzilla bug info[1]. [0] -
http://www.yoctoproject.org/docs/1.8/kernel-dev/kernel-dev.html#using-an-in-tree-defconfig-file
[2] [1] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=7474 [1]
Very comprehensive. Many thanks.
directly in the commit msg
itself. Have you tested it using both poky:master and poky:fido?
Rpi2 fido 3.18.16 with/without sound patch, 4.1.3 with/without sound
patch. BR, Alex
Ok, since there has been some changes (not only the
early DT change) in poky:master it would be good to do the same tests
there. Andrei have to correct me if wrong, but since we have a fido
branch in meta-raspberrypi that's the branch that is recommended to use
against poky:fido,
[yocto] [meta-raspberrypi] RFC on choice of tool for patch review
We've been having a discussion on a way forward to manage patches and code review and would like to open this up for discussion to agree a way forward. Options appear to be github, gerrit, or bitbucket although there may be others. This is in addition to continuing to send patches to the mailing list. Quote from Andrei, We dropped gerrit because at that time google dropped the support for loging in with their accounts and gerrit didn't support OAUTH. The only options left were involving me maintaining users / groups / permissions etc - which obviously didn't have the time for. So, at that time, we decided to use mailing list as the only way of patches review. Now, I work with github, bitbucket and gerrit and I definitely, as Alex said, feel the need of reviewing patches using a tool like these. But I want to state the fact that, even if we decide using them, we will still need to send patches to mailing list too - so we can keep the awareness of this project. In terms of preference, I don't really have one. The easiest would be github/bitbucket but I can invest some time in installing gerrit back (as they now have the required support for google accounts logins). So, I consider this is a community decision and, if a have to vote, I would go for github. Quote from Petter, About using github and similar, I'm a huge fan of gerrit [...] Gerrit is really nice for reviewing and working closely together with similar changesets that are ongoing.. ... For my five euro-cents, I have used Gerrit a little and GitHub more. I found Gerrit hard to get to grips with, but have been impressed with GitHub. So my own preference would be to use github as the UI and fork/pull-req/commenting support all seems very accessible and intuitive. Can others comment? Thanks, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review
On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote: We've been having a discussion on a way forward to manage patches and code review and would like to open this up for discussion to agree a way forward. There's http://patchwork.openembedded.org/. I'm not sure who maintains it, nor if anyone uses it, but patches sent to the mailing list end up there. OOI who are we in this context? What benefits would a change bring? Cheers, Joshua -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review
On 12/08/2015 10:45, Joshua Lock wrote: On Wed, 2015-08-12 at 10:25 +0100, Joshua Lock wrote: On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote: We've been having a discussion on a way forward to manage patches and code review and would like to open this up for discussion to agree a way forward. There's http://patchwork.openembedded.org/. I'm not sure who maintains it, nor if anyone uses it, but patches sent to the mailing list end up there. OOI who are we in this context? What benefits would a change bring? I managed to miss both the [yocto] and [meta-raspberrypi] tags on this mail, apologies for that. I guess that we are the meta-raspberrypi maintainers. Yes :) Andrei (maintainer) was using Gerrit but that went away for reasons outlined in the preceding email. Some visibility and control of the review process has been lost as a result and so it was suggested we kick off a conversation on what tooling to use to restore that. Still, the patchwork instance may be an option? The meta-freescale layers appear to be using it. Many thanks! Cheers, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?
Hi All, There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7 and the one in meta-selinux is 0.7.3. How about removing the one in meta-selinux and get this layer depends on meta-oe? Any suggestions? Thanks Wenzong -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] RFC on choice of tool for patch review
On Wed, 2015-08-12 at 10:25 +0100, Joshua Lock wrote: On Wed, 2015-08-12 at 10:17 +0100, Alex J Lennon wrote: We've been having a discussion on a way forward to manage patches and code review and would like to open this up for discussion to agree a way forward. There's http://patchwork.openembedded.org/. I'm not sure who maintains it, nor if anyone uses it, but patches sent to the mailing list end up there. OOI who are we in this context? What benefits would a change bring? I managed to miss both the [yocto] and [meta-raspberrypi] tags on this mail, apologies for that. I guess that we are the meta-raspberrypi maintainers. Still, the patchwork instance may be an option? The meta-freescale layers appear to be using it. Cheers, Joshua -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Selecting a preferred recipe version for devtools
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 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?
[[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?] On 15.08.12 (Wed 17:08) wenzong fan wrote: Hi All, There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7 and the one in meta-selinux is 0.7.3. How about removing the one in meta-selinux and get this layer depends on meta-oe? Any suggestions? The last time we had this discussion my sense was that most users of meta-selinux wanted to continue with it only depending on oe-core. That's my preference as well. I'm happy to merge an updated version of libcap-ng (or maybe I'll get to it myself, since I've known about it since Armin removed it from meta-security, that was the time of the last discussion, I think). All I'm saying right now is that this isn't a case of accidental duplication of recipes in multiple layers, it's the result of a conscious decision. It's totally worthwhile re-visiting that decision, though to make sure the reasons are still valid. -- -Joe MacDonald. :wq signature.asc Description: Digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Selecting a preferred recipe version for devtools
Hi all, I have two recipes for building Subversion (which I only need as a devtool on the build-machine): $ ls oe-core/meta/recipes-devtools/subversion/*.bb subversion_1.6.15.bb subversion_1.7.8.bb Naturally Yocto uses 1.7.8, which is the newer. However, unfortunately I must use 1.6.15 on my build machine. How can I instruct Yocto to use the older version? I tried to put a variable 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). One apparent solution is to simply remove the subversion_1.7.8.bb file, but I'm wondering if there is a better way, and how I can select a preferred version specifically for devtools. BR, Georg -- ___ 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 Wed, Aug 12, 2015 at 4:59 PM, Javier Martinez Canillas jav...@osg.samsung.com wrote: Hello, On 08/10/2015 10:22 AM, Javier Martinez Canillas wrote: Hello Andreas, On 08/10/2015 01:37 AM, Andreas Müller wrote: Khem definitely has a very good point. Maybe his way of putting it in words was not that productive. But the core idea was definitely right: I don't want rpi layer to introduce distro features. Agreed but I still have issues make the changes work What I have done to test: 1. add MASK_GPU_INTERRUPT = 0x400 DISTRO_FEATURES_append = vc4-gfx to my local.conf 2. put [1] on top of the VC4 patches sent (this is a WIP patch not yet finished) 3. tested running X11 I tested Andreas' WIP patch under X11 using the core-image-sato image and I could reproduce the same behavior. KMS/DRM works when using the modesetting Xorg DDX but no GLES with HW acceleration. I did only test with Weston since that is what Tizen uses and not with X11. I'll make sure to test with X11 and also include a mesa_%.bbappend for v2. Question: What setting does the trick getting vc4 driver created by mesa doing the OpenGL work. I see only swrast which is bulls... I'm not really a graphics person so I'll let Derek to answer this. He is in fact the author of most of these patches and I'm just working on push them upstream. Derek is on holidays until next week so I tried to dig on this. When running the glmark2-es2 benchmark I get: $ glmark2-es2 libEGL warning: DRI2: failed to authenticate ** Failed to set swap interval. Results may be bounded above by refresh rate. === glmark2 2014.03 === OpenGL Information GL_VENDOR: Mesa Project GL_RENDERER: Software Rasterizer GL_VERSION:OpenGL ES 2.0 Mesa 10.5.8 === so as Andreas said, it is using swrast instead of the VC4 hw one. And in fact by running strace I see that there is a open(/usr/lib/dri/swrast_dri.so,...) but /usr/lib/dri/vc4_dri.so is never opened. I tried bumping the mesa git recipe to use the same sha1 we are using in our Tizen port but ran into build issues... But I've reworked the patch series according to your suggestions and I can post a v2 if you want since at least KMS/DRM is working with Andreas' changes or do you want to first sort out the mesa bits for 3D HW accel before posting a v2? 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). Hope I have some energy left tonight to check further and let you know... Andreas -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-darwin][PATCH] osx-runtime: OSX Yosemite v10.10
On 08/11/15 17:48, Juro Bystricky wrote: Set of patches to allow building against OSX Yosemite v10.10 runtime. Excellent! My build failed, then I noticed your patches. Even with this patch applied, however, my build fails with native-libffi in do_patch. It appears the existing darwinfix.patch no longer applies. I updated the patch so libffi can now do_patch successfully, but I don't know if it builds since gcc-crosssdk-i386 fails in do_compile. | /z/layerindex/firefly/tmp/work/i386-linux/gcc-crosssdk-i386/4.9.3-r0/gcc-4.9.3/build.x86_64-linux.i386-pokysdk-darwin/./gcc/xgcc -B/z/layerindex/firefly/tmp/work/i386-linux/gcc-crosssdk-i386/4.9.3-r0/gcc-4.9.3/build.x86_64-linux.i386-pokysdk-darwin/./gcc/ -B/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/bin/ -B/z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/lib/ -isystem /z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/include -isystem /z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/sys-include --sysroot=/z/layerindex/firefly/tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin -O2 -g -Os -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -dynamiclib -nodefaultlibs -install_name /z/layerindex/firefly/tmp/sysroots/x86_64-linux/usr/i386-pokysdk-darwin/lib/libgcc_s.1.dylib -single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -Os -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o _floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o darwin-64_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc | ld: library not found for -ldylib1.o It's strange that it says library not found for -ldylib1.o because that library is in my sdk's sysroot: $ find . -name *dylib1* -print ./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/dylib1.o ./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/dylib1.10.5.o ./tmp/sysroots/i386-nativesdk-darwin-pokysdk-darwin/usr/lib/lazydylib1.o Have you had any success building? The line I'm using to invoke the build is: $ SDKMACHINE=i386-darwin bitbake core-image-minimal -c populate_sdk and the details of my build are: Build Configuration: BB_VERSION= 1.27.1 BUILD_SYS = x86_64-linux NATIVELSBSTRING = openSUSE-project-13.2 TARGET_SYS= arm-poky-linux-gnueabi MACHINE = firefly-emmc-mainline DISTRO= poky DISTRO_VERSION= 1.8+snapshot-20150812 TUNE_FEATURES = arm armv7a vfp neon cortexa15 TARGET_FPU= vfp-neon meta = master:4c3329630e5bf6f2229c6a85052ce71f7cc71703 meta-rockchip = contrib/twoerner/emmc-first-draft:be45e46f73c5ea7118e4be9511e1ee7652e1ebcf meta-yocto= master:eefd3580e451a09e7f4696f306d955a4caa1cf88 meta-darwin = contrib/twoerner/fixes:6234b82444b1ebf9bfb0ac8deb5cb582c89cb41d my layers are: openembedded-core/meta meta-rockchip meta-yocto/meta-yocto meta-darwin Thoughts? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-darwin][PATCH] osx-runtime: OSX Yosemite v10.10
= poky DISTRO_VERSION= 1.8+snapshot-20150812 TUNE_FEATURES = arm armv7a vfp neon cortexa15 TARGET_FPU= vfp-neon meta = master:4c3329630e5bf6f2229c6a85052ce71f7cc71703 meta-rockchip = contrib/twoerner/emmc-first- draft:be45e46f73c5ea7118e4be9511e1ee7652e1ebcf meta-yocto= master:eefd3580e451a09e7f4696f306d955a4caa1cf88 meta-darwin = contrib/twoerner/fixes:6234b82444b1ebf9bfb0ac8deb5cb582c89cb41d my layers are: openembedded-core/meta meta-rockchip meta-yocto/meta-yocto meta-darwin Thoughts? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
