Re: [yocto] Yocto Kernel Module Workflow Question
On 15-01-15 22:51, Glenn Schmottlach wrote: I am developing a codec kernel driver/module for the BeagleBone Black and have a question about the recommended work-flow for developing this module in the context of the Yocto/poky environment. Currently I'm working with the Daisy release using the meta-ti layer and the linux-ti-staging_3.14 kernel sources. The codec driver, at this point, is just an very minimal implementation. It follows closely the instructions described here: http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example The work involves a dummy (platform independent) ALSA driver for the DAC and then code modifications to the ALSA machine layer driver (sound/soc/davinci/davinci-evm) and the BeagleBone Black device tree to knit all of these pieces together. There seems to be two approaches for developing the codec driver. The first approach is to build the codec driver externally from the kernel sources (e.g. as described in working with "out-of-tree" modules in the Yocto Kernel Development Guide). With this model I can represent the codec driver as a separate Yocto/Bitbake recipe and simply include the resulting package in my target image. Unfortunately, the codec driver also requires changes to the kernel sources in the ALSA machine layer driver and device tree. My approach here is the create a linux-ti-staging_3.14.bbappend file that contains a series of patches to the kernel for the machine layer driver and device tree. In this scenario, the kernel sources do *not* explicitly know about this new codec since there are no changes to the sound/soc/codec Makefile and associated Kconfig's that describe the dependencies of the codec driver. This means of course that menuconfig won't show the codec as a build-able option. So the ALSA machine driver (davinci-evm) knows the name of the codec driver but nothing more other than it's association with a particular device tree configuration node (e.g. dtc_id). This may not be ideal for someone configuring the kernel since this codec doesn't appear as an option and the dependencies (as described in the Kconfig) are not clear. The work-around, albeit clumsy, is to bundle the changes to the Makefile/Kconfig's and the codec source itself as a set of patches referenced from the linux-ti-staging_3.14.bbappend file. Now building the kernel modules also builds the codec (e.g. no separate codec Bitbake recipe is required). This works but now my codec sources exist as a "patch" and stored directly in the recipe. Assuming I want to do iterative development with this module, every change to the codec sources require me to update the codec "patch". Also, the codec source must then effectively be version-controlled within the *.bbappend recipe itself (as a *.patch file or possibly as a naked codec.c that is copied into the destination kernel sources during the patch step of bitbake). Ideally, I'd like to maintain my codec driver outside of the kernel tree (since it is not dependent on the BeagleBone Black) and just maintain the *.bbappend to make the necessary platform-specific machine-layer/device-tree patches. I want the codec to be built with the kernel sources but not treated as a Yocto "out-of-tree" module. Is there a way for the *.bbappend to fetch the codec sources from another repo and place them in the kernel sound/soc/codecs directory before the kernel is built? Can anyone suggest a better/alternative work-flow that accommodates keeping the codec sources in a separate repo (much like the "out-of-tree" modules) while allowing seamless integration into the kernel sources. Fundamentally, I don't want the codec sources to be version controlled directly *inside* the *.bbappend recipe as either a patch or as a raw source file. Is there an alternative work-flow that works better with Yocto? Obvious alternative is to fork the kernel and manage it in your own repo. Using git "rebase" you can keep your changes on top, and git format-patch can generate patches for when you want your recipe to go out into the big bad world. The kernel source dir is a git repository, so you can us that as your repository for making changes too. Instead of pushing your work, use git format-patch to output the patches (into the bitbake recipe path). When you build the kernel, the git repo will contain your patches as commits. Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can't find the source code of kernel
On 2015-01-15 8:13 PM, neil...@emerson.com wrote:
Hi, Bruce
Thank you for your reply.
In the WORKDIR , it just has "linux-qemuarm-standard-build" and not have the
"linux".
Are you sure you are building Yocto 1.7 and not the master branch ?
Until about a month ago, every build had the source along side the
split build directory .. in a directory called linux. But as I
mentioned, we are working to move the kernel to build out of the
sysroot/shared working directory.
My WORKDIR directory is
"~/poky/build/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0",
but I don't find the tarball of "linux-14.24"
in download directory. It has tarball "linux-17.7.tar.xz".
Do you think whether these is the reason?
They shouldn't be related. But that tar.xz you reference above is
clearly from some other kernel build than the linux yocto variant.
I don't know how to set the version of linux when the project building the
image.
Maybe, I set the linux to 17.7 version, the problem can solve.
I'm not sure how you are getting a 17.7 tarball, but the linux-yocto
tree builds from a git repository, not a tarball.
In that directory where you see the qemuarm build you should also see a
git.indirectionsymlink that points to the git tree in downloads/git2/
Cheers,
Bruce
Do you have any other better suggestion? Thank you very much.
Neil
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Thursday, January 15, 2015 9:05 PM
To: Wu, Neil [CLIMATE/RS/CN]; yocto@yoctoproject.org
Subject: Re: [yocto] can't find the source code of kernel
On 2015-01-15 5:03 AM, neil...@emerson.com wrote:
Hi ,all
The version of poky is 1.7. I build the linux-yocto is successful .
bitbake linux-yocto
But, why I can't find the source code of linux in ${WORKDIR}.
It should be there (note: it is about to move in master, but not in 1.7.1).
In WORKDIR, you have "linux" (the source) and linux-$MACHINE-build (the
build).
Bruce
Best wishes
Neil
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Why not enable hard floating point?
On 2015-01-15, at 04:06, Mike Looijmans wrote: > -2- The CPU doesn't actually have floating point support and the kernel is > emulating it for you. This allows the platform to run "hf" binaries, at a > minor performance cost compared to completely doing the emulation in user > space (libc). >From my understanding, the Raspberry Pi (at least the model B, which is what I >have) has an FPU. Would it hurt to at least mention in the top-level README of the meta-raspberrypi layer that a user could enable hard FP by setting the DEFAULTTUNE? -- Jason Tang / t...@jtang.org -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can't find the source code of kernel
Hi, Bruce
Thank you for your reply.
In the WORKDIR , it just has "linux-qemuarm-standard-build" and not have the
"linux".
My WORKDIR directory is
"~/poky/build/tmp/work/qemuarm-poky-linux-gnueabi/linux-yocto/3.14.24+gitAUTOINC+a227f20eff_6166316d47-r0",
but I don't find the tarball of "linux-14.24"
in download directory. It has tarball "linux-17.7.tar.xz".
Do you think whether these is the reason?
I don't know how to set the version of linux when the project building the
image.
Maybe, I set the linux to 17.7 version, the problem can solve.
Do you have any other better suggestion? Thank you very much.
Neil
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Thursday, January 15, 2015 9:05 PM
To: Wu, Neil [CLIMATE/RS/CN]; yocto@yoctoproject.org
Subject: Re: [yocto] can't find the source code of kernel
On 2015-01-15 5:03 AM, neil...@emerson.com wrote:
> Hi ,all
>
> The version of poky is 1.7. I build the linux-yocto is successful .
>
> bitbake linux-yocto
>
> But, why I can't find the source code of linux in ${WORKDIR}.
It should be there (note: it is about to move in master, but not in 1.7.1).
In WORKDIR, you have "linux" (the source) and linux-$MACHINE-build (the
build).
Bruce
>
> Best wishes
>
> Neil
>
>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 0/2] linux-raspberrypi fixes
The following changes since commit 6c6f44136f7e1c97bc45be118a48bd9b1fef1072:
gstreamer1.0-plugins-bad: Making bbappend version independent (2014-11-20
12:32:36 +0100)
are available in the git repository at:
git://git.yoctoproject.org/poky-contrib petmab/rpi_fixes
http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=petmab/rpi_fixes
Petter Mabäcker (2):
linux-raspberrypi: fix do_configure failure
linux-raspberrypi: faulty branch and srcrev for 3.16
recipes-kernel/linux/linux-raspberrypi.inc | 8 +---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 +
.../{linux-raspberrypi_3.16.1.bb => linux-raspberrypi_3.16.5.bb} | 4 ++--
recipes-kernel/linux/linux.inc | 9 +
4 files changed, 13 insertions(+), 9 deletions(-)
create mode 100644 recipes-kernel/linux/linux-raspberrypi/defconfig
rename recipes-kernel/linux/{linux-raspberrypi_3.16.1.bb =>
linux-raspberrypi_3.16.5.bb} (69%)
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 2/2] linux-raspberrypi: faulty branch and srcrev for 3.16
linux-raspberrypi_3.16 used wrong branch (rpi-3.14.y instead of
rpi-3.16.y). Use latest SRCREV for 3.16 and bump version to 3.16.5.
Signed-off-by: Petter Mabäcker
---
.../{linux-raspberrypi_3.16.1.bb => linux-raspberrypi_3.16.5.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename recipes-kernel/linux/{linux-raspberrypi_3.16.1.bb =>
linux-raspberrypi_3.16.5.bb} (69%)
diff --git a/recipes-kernel/linux/linux-raspberrypi_3.16.1.bb
b/recipes-kernel/linux/linux-raspberrypi_3.16.5.bb
similarity index 69%
rename from recipes-kernel/linux/linux-raspberrypi_3.16.1.bb
rename to recipes-kernel/linux/linux-raspberrypi_3.16.5.bb
index 60aca96..97947c2 100644
--- a/recipes-kernel/linux/linux-raspberrypi_3.16.1.bb
+++ b/recipes-kernel/linux/linux-raspberrypi_3.16.5.bb
@@ -1,5 +1,5 @@
-SRCREV = "82692a293288c334f3da11895e63ea7d066db4f6"
-SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.14.y \
+SRCREV = "377c82aa1d31b37f1096096b0e4c65beb0bc5c49"
+SRC_URI =
"git://github.com/raspberrypi/linux.git;protocol=git;branch=rpi-3.16.y \
file://sl030raspberrypii2ckernel.patch \
"
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi][PATCH 1/2] linux-raspberrypi: fix do_configure failure
When building against newer yocto project releases below failure
occurs.
| DEBUG: Executing shell function do_configure
| NOTE: make oldconfig
| make: *** No rule to make target `oldconfig'. Stop.
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_configure
Fix this by trying to adapt more of the standard mechanism
that exists in yocto, in order to build "custom kernels".
Signed-off-by: Petter Mabäcker
---
recipes-kernel/linux/linux-raspberrypi.inc | 8 +---
recipes-kernel/linux/linux-raspberrypi/defconfig | 1 +
recipes-kernel/linux/linux.inc | 9 +
3 files changed, 11 insertions(+), 7 deletions(-)
create 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 e756b57..4145b1a 100644
--- a/recipes-kernel/linux/linux-raspberrypi.inc
+++ b/recipes-kernel/linux/linux-raspberrypi.inc
@@ -5,12 +5,14 @@ SECTION = "kernel"
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
+SRC_URI += " \
+file://defconfig \
+"
+
COMPATIBLE_MACHINE = "raspberrypi"
PV_append = "+git${SRCREV}"
-S = "${WORKDIR}/git"
-
# NOTE: For now we pull in the default config from the RPi kernel GIT tree.
KERNEL_DEFCONFIG = "bcmrpi_defconfig"
@@ -19,7 +21,7 @@ CMDLINE_raspberrypi = "dwc_otg.lpm_enable=0
console=ttyAMA0,115200 kgdboc=ttyAMA
UDEV_GE_141 ?= "1"
-do_configure_prepend() {
+do_kernel_configme_prepend() {
install -m 0644 ${S}/arch/${ARCH}/configs/${KERNEL_DEFCONFIG}
${WORKDIR}/defconfig || die "No default configuration for ${MACHINE} /
${KERNEL_DEFCONFIG} available."
}
diff --git a/recipes-kernel/linux/linux-raspberrypi/defconfig
b/recipes-kernel/linux/linux-raspberrypi/defconfig
new file mode 100644
index 000..ecbf32c
--- /dev/null
+++ b/recipes-kernel/linux/linux-raspberrypi/defconfig
@@ -0,0 +1 @@
+# Dummy file to get through do_kernel_configme.
diff --git a/recipes-kernel/linux/linux.inc b/recipes-kernel/linux/linux.inc
index 7a8f984..fae78b7 100644
--- a/recipes-kernel/linux/linux.inc
+++ b/recipes-kernel/linux/linux.inc
@@ -5,6 +5,7 @@ LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
inherit kernel siteinfo
+require recipes-kernel/linux/linux-yocto.inc
# Enable OABI compat for people stuck with obsolete userspace
ARM_KEEP_OABI ?= "1"
@@ -25,15 +26,15 @@ kernel_configure_variable() {
CONF_SED_SCRIPT="$CONF_SED_SCRIPT /CONFIG_$1[ =]/d;"
if test "$2" = "n"
then
-echo "# CONFIG_$1 is not set" >> ${S}/.config
+echo "# CONFIG_$1 is not set" >> ${B}/.config
else
-echo "CONFIG_$1=$2" >> ${S}/.config
+echo "CONFIG_$1=$2" >> ${B}/.config
fi
}
do_configure_prepend() {
# Clean .config
-echo "" > ${S}/.config
+echo "" > ${B}/.config
CONF_SED_SCRIPT=""
# oabi / eabi support
@@ -108,7 +109,7 @@ 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' >> '${S}/.config'
+sed -e "${CONF_SED_SCRIPT}" < '${WORKDIR}/defconfig' >> '${B}/.config'
yes '' | oe_runmake oldconfig
}
--
1.9.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Kernel Module Workflow Question
I am developing a codec kernel driver/module for the BeagleBone Black and have a question about the recommended work-flow for developing this module in the context of the Yocto/poky environment. Currently I'm working with the Daisy release using the meta-ti layer and the linux-ti-staging_3.14 kernel sources. The codec driver, at this point, is just an very minimal implementation. It follows closely the instructions described here: http://processors.wiki.ti.com/index.php/Sitara_Linux_SDK_Audio_DAC_Example The work involves a dummy (platform independent) ALSA driver for the DAC and then code modifications to the ALSA machine layer driver (sound/soc/davinci/davinci-evm) and the BeagleBone Black device tree to knit all of these pieces together. There seems to be two approaches for developing the codec driver. The first approach is to build the codec driver externally from the kernel sources (e.g. as described in working with "out-of-tree" modules in the Yocto Kernel Development Guide). With this model I can represent the codec driver as a separate Yocto/Bitbake recipe and simply include the resulting package in my target image. Unfortunately, the codec driver also requires changes to the kernel sources in the ALSA machine layer driver and device tree. My approach here is the create a linux-ti-staging_3.14.bbappend file that contains a series of patches to the kernel for the machine layer driver and device tree. In this scenario, the kernel sources do *not* explicitly know about this new codec since there are no changes to the sound/soc/codec Makefile and associated Kconfig's that describe the dependencies of the codec driver. This means of course that menuconfig won't show the codec as a build-able option. So the ALSA machine driver (davinci-evm) knows the name of the codec driver but nothing more other than it's association with a particular device tree configuration node (e.g. dtc_id). This may not be ideal for someone configuring the kernel since this codec doesn't appear as an option and the dependencies (as described in the Kconfig) are not clear. The work-around, albeit clumsy, is to bundle the changes to the Makefile/Kconfig's and the codec source itself as a set of patches referenced from the linux-ti-staging_3.14.bbappend file. Now building the kernel modules also builds the codec (e.g. no separate codec Bitbake recipe is required). This works but now my codec sources exist as a "patch" and stored directly in the recipe. Assuming I want to do iterative development with this module, every change to the codec sources require me to update the codec "patch". Also, the codec source must then effectively be version-controlled within the *.bbappend recipe itself (as a *.patch file or possibly as a naked codec.c that is copied into the destination kernel sources during the patch step of bitbake). Ideally, I'd like to maintain my codec driver outside of the kernel tree (since it is not dependent on the BeagleBone Black) and just maintain the *.bbappend to make the necessary platform-specific machine-layer/device-tree patches. I want the codec to be built with the kernel sources but not treated as a Yocto "out-of-tree" module. Is there a way for the *.bbappend to fetch the codec sources from another repo and place them in the kernel sound/soc/codecs directory before the kernel is built? Can anyone suggest a better/alternative work-flow that accommodates keeping the codec sources in a separate repo (much like the "out-of-tree" modules) while allowing seamless integration into the kernel sources. Fundamentally, I don't want the codec sources to be version controlled directly *inside* the *.bbappend recipe as either a patch or as a raw source file. Is there an alternative work-flow that works better with Yocto? Any feedback would be appreciated . . . thanks! -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] will yocto 1.7 work with eclipse luna?
On 08/01/2014 04:09 AM, Georgescu, Alexandru C wrote: Hi Robert, The upgrade to Luna is expected to happen during the 1.7 timeframe as shown here: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6251. After the upgrade will happen, it will merge into our QA flow to make sure that the core functionality exist. Hi, I'm looking for feedback on whether it's a good idea to try working with the Eclipse plugin on Luna with the Luna patch applied, which can be found in the 6251 bug report. Are users / developers already using it? I'm also wrestling with Luna in general being sluggish on my Ubuntu Linux boxes. I have seen various reports of this by others with suggestions on trying alternate JVM (e.g., Oracle) - so far, I'm having the best results with Oracle jdk1.8. Any guidance on moving to Luna (on Linux) at this point will be greatly appreciated. Bob Regards, -- Alexandru Georgescu Yocto QA Engineer SSG/SSD Open Source Technology Center Romania On 01/08/14 00:41, "Robert P. J. Day" wrote: already dropped scott rifenbark a note about this, but current dev manual recommends eclipse kepler, while eclipse luna is out, and fedora 22 appears to use that as the yum-installable version. so any issues with eclipse luna? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-mono] Mono updated to 3.12.0
I've updated support for Mono build in meta-mono master to 3.12.0 (the current release). I've performed basic build testing on an qemux86 build of core-image-mono, based on core-image-sato, running a "Hello World" console application and a "Hello World" Windows Forms application. There has been feedback that issues with armhf support are addressed in 3.10.0/3.12.0 but I have not yet had time to investigate. ref: https://bugzilla.xamarin.com/show_bug.cgi?id=20239 All feedback on testing and/or issues appreciated. Regards, Alex -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can't find the source code of kernel
On 2015-01-15 5:03 AM, neil...@emerson.com wrote:
Hi ,all
The version of poky is 1.7. I build the linux-yocto is successful .
bitbake linux-yocto
But, why I can’t find the source code of linux in ${WORKDIR}.
It should be there (note: it is about to move in master, but not in 1.7.1).
In WORKDIR, you have "linux" (the source) and linux-$MACHINE-build (the
build).
Bruce
Best wishes
Neil
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] can't find the source code of kernel
Hi ,all
The version of poky is 1.7. I build the linux-yocto is successful .
bitbake linux-yocto
But, why I can’t find the source code of linux in ${WORKDIR}.
Best wishes
Neil
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Why not enable hard floating point?
On 15-01-15 01:11, J. Tang wrote: On Jan 14, 2015, at 15:36 , Andrei Gherzan wrote: On Sat, Jan 10, 2015 at 10:38:50AM -0500, J. Tang wrote: The upstream meta-raspberrypi recipe builds an arm6 toolchain with only soft floating point. As an experiment, I enabled hard floating point by setting my DEFAULTTUNE to “armv6hf”. My code still ran correctly. Is there a reason why the meta-raspberrypi layer does not enable hard floating point? Well we played a little with this in the past. And we realised that, at that time at least, switching to hf didn't add any performace improvements. Did you test anything that proves the contrary? In my case, I was re-compiling MAME for the Raspberry Pi. The code has a dependency on hf. Furthermore, Rasbian is built with hf. If the CPU has actual hard-float support, then enabling it should increase floating point performance by an order of magnitude (e.g. 100x faster or so). If you don't see any real world performance improvements, My guess would be one of these cases: -1- The compiler is already creating FPU instructions, based on other properties of the target platform. The "hf" tune only changes the ABI, so that floating point values are passed to/from libraries in normal registers instead of FPU registers. This has very little impact on performance (unless you have some very badly designed libs). You can check if this is the case by examining disassember output for a bit of FPU code, if you see instructions starting with "F" in there, it's using the ARM VFP. -2- The CPU doesn't actually have floating point support and the kernel is emulating it for you. This allows the platform to run "hf" binaries, at a minor performance cost compared to completely doing the emulation in user space (libc). Met vriendelijke groet / kind regards, Mike Looijmans System Expert TOPIC Embedded Systems Eindhovenseweg 32-C, NL-5683 KH Best Postbus 440, NL-5680 AK Best Telefoon: (+31) (0) 499 33 69 79 Telefax: (+31) (0) 499 33 69 70 E-mail: mike.looijm...@topic.nl Website: www.topic.nl Please consider the environment before printing this e-mail Topic zoekt gedreven (embedded) software specialisten! http://topic.nl/vacatures/topic-zoekt-software-engineers/ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
