Re: [meta-rockchip][PATCH v2] Rock64: add machine
Trevor Woerner
Hi Yann,
Thanks for the contribution! On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote: From: Yann Dirson <yann@...>Sounds good. I prefer the rockchip default of 1,500,000 anyway. Odd that you'd be assigning the copyright to Garmin ;-) +# Released under the MIT license (see COPYING.MIT for the terms)Can you also specify an OSS-friendly licence too? +Personally I'd prefer to see a rock64 wic file which includes an rk3328 default, even if it is a copy of the rock-pi-4 layout. +IMAGE_FSTYPES += "wic wic.bmap"I have a roc-rk3328-cc ("renegade") board I should investigate adding. Then I can see if this applies there as well. +SRC_URI_append_rock64 = " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch"
|
|
Re: thoughts on YP-friendly developer laptop?
Adrian Bunk
On Mon, Jun 14, 2021 at 07:58:19AM -0400, Robert P. J. Day wrote:
When using a laptop with only 16 GB RAM to build with 8 or 16 threads, on what drive will the heavily used large swap partition be? gcc loves to use > 2 GB RAM for non-trivial C++ code, with 16 threads I'd recommend 64 GB RAM. and a dual drive layout that seemsAsk for the specs of the SSD and do the math. E.g. 150 TBW / 50 GB/build = 3000 builds If you are building from scratch so often that the resulting number is a worry, I'd rather buy 128 GB RAM and use a tmpfs instead of creating a spinning rust bottleneck. rdaycu Adrian
|
|
Re: thoughts on YP-friendly developer laptop?
Jack Mitchell
- Ryzen based for core count
toggle quoted messageShow quoted text
- No dedicated GPU as more wattage available for CPU + less heat for cpu boosting - Dual NVMe slots, or at least on-board emmc + NVMe slot, hold tmp in NVMe, replace if it dies. Probably not going to be an issue, I have a 1TB NVMe drive which I've been doing multiple daily builds on for 2 years which is still at 99% health. For a decent manufacturer? Dell aren't recommended at the moment as the QA due to pandemic conditions is lacking and machines are arriving broken. HP do some decent Ryzen based laptops, as do Lenovo. For a wild card you can also check out System76 but they're just OEM rebrands. Good luck, it's a minefield out there. Regards, Jack
On 14/06/2021 12:58, Robert P. J. Day wrote:
|
|
thoughts on YP-friendly developer laptop?
Robert P. J. Day
starting to think about a new laptop that will, among other things,
do lots of OE/YP builds, and i'll start with this as the basis for a few questions about hard drives: https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e while an SSD would be delightful, i'm concerned about how doing frequent 40-50G builds would wear out an SSD. so i was considering looking for something with a fast regular HD for the actual build directories, but room to put in an M.2 NVMe that would hold fairly static content, like the OS itself, all the layers, a local source mirror and so on. am i overthinking this? anyone have a laptop setup that is smokin' fast (yeah, 8 core AMD ryzen :-), and a dual drive layout that seems to work well with lots and lots of OE builds? rday
|
|
Re: QEMU Size Increase from Yocto Thud to Zeus
Zoran
Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.Does it mean that with the local.conf line: # enable,disable,depends,rdepends # PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu," The QEMU is completely removed (this is all that needs to be done, or...)? Thank you, Zee _______ On Mon, Jun 14, 2021 at 12:14 PM Ross Burton <ross@...> wrote:
|
|
Re: QEMU Size Increase from Yocto Thud to Zeus
Ross Burton <ross@...>
Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.
toggle quoted messageShow quoted text
Ross
On Mon, 14 Jun 2021 at 09:04, Aashik Aswin <thisisaash9698@...> wrote:
|
|
Re: [meta-java] icedtea7 fetching error
marvin.franke@...
Hello,
you can use wildebeest's mirror: ICEDTEA_HG_URL = "http://icedtea.wildebeest.org/hg/release/${ICEDTEA_PREFIX}" Marvin
|
|
Re: [meta-zephyr][PATCH v2 1/2] zephyr-kernel: Add OpenThread add module to build
Stefan Schmidt
Hello.
On 11.06.21 03:26, Saini, Naveen Kumar wrote: Fixed.-----Original Message-----This is not required. It already listed in required sample recipe. Please remove it. Indeed, I did not test with 2.5. Thanks for spotting. Fixed.It would cause build failure with v2.5.0. So add SRCREV_openthread in zephyr-kernel-src-2.5.0.inc too. I send a v3 now. regards Stefan Schmidt
|
|
[meta-zephyr][PATCH v3 2/2] zephyr-openthread-echo-client: Add new echo-client variant for OpenThread
Stefan Schmidt
From: Stefan Schmidt <stefan.schmidt@...>
Similar to the normal echo-client example it demonstrates socket usage, but in this variant we enable the OpenThread config overlay and add the needed module to the build. Signed-off-by: Stefan Schmidt <stefan.schmidt@...> --- .../zephyr-kernel/zephyr-openthread-echo-client.bb | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 recipes-kernel/zephyr-kernel/zephyr-openthread-echo-c= lient.bb diff --git a/recipes-kernel/zephyr-kernel/zephyr-openthread-echo-client.b= b b/recipes-kernel/zephyr-kernel/zephyr-openthread-echo-client.bb new file mode 100644 index 0000000..c985df2 --- /dev/null +++ b/recipes-kernel/zephyr-kernel/zephyr-openthread-echo-client.bb @@ -0,0 +1,8 @@ +include zephyr-sample.inc + +ZEPHYR_SRC_DIR =3D "${S}/samples/net/sockets/echo_client" + +ZEPHYR_MODULES_append =3D "\;${S}/modules/lib/mbedtls" +ZEPHYR_MODULES_append =3D "\;${S}/modules/lib/openthread" + +EXTRA_OECMAKE +=3D "-DOVERLAY_CONFIG=3Doverlay-ot.conf" --=20 2.31.1
|
|
[meta-zephyr][PATCH v3 1/2] zephyr-kernel: Add OpenThread add module to build
Stefan Schmidt
From: Stefan Schmidt <stefan.schmidt@...>
OpenThread support in Zephyr is realised as an external module. Make sure we pull it in and have it available for applications to use it. Signed-off-by: Stefan Schmidt <stefan.schmidt@...> --- recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 1 + recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc | 1 + recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 1 + 3 files changed, 3 insertions(+) diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/r= ecipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc index 545197f..9cdc721 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc @@ -4,6 +4,7 @@ SRCREV_cmsis =3D "c3bd2094f92d574377f7af2aec147ae181aa5f8= e" SRCREV_nordic =3D "f3434da6446380fcdd426dbe2866af21d0d549b6" SRCREV_stm32 =3D "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635" SRCREV_open-amp =3D "de1b85a13032a2de1d8b6695ae5f800b613e739d" +SRCREV_openthread =3D "385e19da1ae15f27872c2543b97276a42f102ead" SRCREV_libmetal =3D "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94" SRCREV_tinycrypt =3D "3e9a49d2672ec01435ffbf0d788db6d95ef28de0" SRCREV_mbedtls =3D "24d84ecff195fb15c889d9046e44e4804d626c67" diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc b/r= ecipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc index 8475b5b..4910db2 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc @@ -4,6 +4,7 @@ SRCREV_cmsis =3D "c3bd2094f92d574377f7af2aec147ae181aa5f8= e" SRCREV_nordic =3D "574493fe29c79140df4827ab5d4a23df79d03681" SRCREV_stm32 =3D "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df" SRCREV_open-amp =3D "6010f0523cbc75f551d9256cf782f173177acdef" +SRCREV_openthread =3D "385e19da1ae15f27872c2543b97276a42f102ead" SRCREV_libmetal =3D "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb" SRCREV_tinycrypt =3D "3e9a49d2672ec01435ffbf0d788db6d95ef28de0" SRCREV_mbedtls =3D "5765cb7f75a9973ae9232d438e361a9d7bbc49e7" diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes= -kernel/zephyr-kernel/zephyr-kernel-src.inc index d65cc06..fb62cae 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc @@ -15,6 +15,7 @@ SRC_URI =3D "\ git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=3Dhttps;d= estsuffix=3Dgit/modules/hal/stm32;name=3Dstm32 \ git://github.com/zephyrproject-rtos/mbedtls.git;protocol=3Dhttps;des= tsuffix=3Dgit/modules/lib/mbedtls;name=3Dmbedtls \ git://github.com/zephyrproject-rtos/open-amp.git;protocol=3Dhttps;de= stsuffix=3Dgit/modules/lib/open-amp;name=3Dopen-amp \ + git://github.com/zephyrproject-rtos/openthread.git;protocol=3Dhttps;= branch=3Dzephyr;destsuffix=3Dgit/modules/lib/openthread;name=3Dopenthread= \ git://github.com/zephyrproject-rtos/libmetal.git;protocol=3Dhttps;de= stsuffix=3Dgit/modules/hal/libmetal;name=3Dlibmetal \ git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=3Dhttps;d= estsuffix=3Dgit/modules/crypto/tinycrypt;name=3Dtinycrypt \ file://0001-cmake-add-yocto-toolchain.patch \ --=20 2.31.1
|
|
Re: QEMU Size Increase from Yocto Thud to Zeus
Aashik Aswin
Thanks for the clarification, yes I am installing QEMU in my image. Is there some way that we can disable the additional architectures and streamline the size ? Thanks
On Fri, Jun 11, 2021 at 8:48 PM Ross Burton <ross@...> wrote: Are you installing qemu into your image though?
|
|
Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: June 10, 2021
(Buried on my desktop, better late than never)
Attendees: Alex, Richard, Saul, Randy, Tony, Trevor 1. valgrind: - taskset work-around really helps. - working on stack_changes bug for qemuarm43 - reproduced on master, hardknott but not gatesgarth - Let's drop it for now to reduce the AB noise. 2. task summary script: - procpath compared to top -bn1 - about the same number of syscalls (strace) - about 5x more cpu and 2x more ram. - could be a problem in that we'd need to boostrap since procpath-native would need to be built at the beginning of each bitbake run or be added to buildtools or hacked into y-ab-helper. - it might be simpler to screen-scrape top output... 3. make: job server - working and able to build images now. - testing to confirm that it actually limits the load - we'll submit for master-next once that's confirmed. 4. There's a problem in qemu/kernel corruption apparently from an ltp test. Richard has done lots of work to go back to the near pristine 5.10 kernel and the problem still happens so that seems to eliminate the possibility that it's a linux-yocto specific issue. Richard has a patch in here: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d7d65aae104caa03afc28837b0abe0b486d5a8b8 and to reproduce the problem you should be able to just run: IMAGE_INSTALL_append = ' ltp' TEST_SUITES = 'ping ssh ltp' then bitbake core-image-sato; bitbake core-image-sato -c testimage ( qemux86-64, with kvm) then look for BUG: in log in core-image-sato WORKDIR/testimage/qemu* i.e.: tmp/work/qemux86_64-poky-linux/core-image-sato/1.0-r0/testimage/ Reproducible about 70% of the time. RP: revert qemu-6.0 to 5.x: The problem persists. using ubu-20.04 5. Remaining more frequent issues: valgrind: https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2168 6. There are 3 patches in master-next that we need to decide on: - library preload: read qemu libs into memory. - helpful but maybe treat as a bandaid until we are able to reduce the IO and cpu spikes. - qemu-runner? timeout increase 120 -> 240 - ptest timeouts 300 -> 450? 7. The additional (top and qemu log) output when qemu hangs is merged. Thanks Sakib. 8. Plans for the week: Richard: build M1, debug ltp issue. Alex: full day on ltp tomorrow? Sakib: task summary Trevor: make job server Tony: more valgrind bugs/work-arounds. Saul: have QMP deal with sigusr1 to close the QMP socket Randy: test ltp failure
|
|
Re: bitbake controlling memory use
Ferry Toth
Hi
Op 13-06-2021 om 02:38 schreef Randy MacLeod: On 2021-06-12 12:31 p.m., Ferry Toth wrote:I watched running processes from KDE ksysguard and I believe the number of compilers was actually restricted with the patch. On the other hand the server I tried was running munin which logs #processes over time and there I didn't see a difference. Confused..HiHi Ferry, the next thing we try will be to patch 'make' to log when the jobserverI'm available for testing. A little RTFM / UTSL may also be required.I do like the jobserver idea a lot. Especially if it would take memory restrictions into account as well. The problem with building nodejs (and probably rust as well), there is lots to compile so you really want -j 16. But then during linking ld uses 4GB per instance, and there are 5 started. So on my machine I wouldn't want to start more then 3. - Trevor
|
|
Re: bitbake controlling memory use
On 2021-06-12 12:31 p.m., Ferry Toth wrote:
HiHi Ferry, Thanks for the update. Trevor and I saw similar (lack of ) results. Trevor even trying getting kea, which uses 'make' to be done the 'configure' stage, for two builds in differect dirs. Then to run the two 'bitbake -c compile kea' with and with out the patch with the expectation that with the job server patch and the right number of jobs, the two builds would take longer. I don't know the exact timing but there was no noticeable difference. We did strace things to confirm that the make wrapper was being called and the actual make was being called by the wrapper. I suspect that the next thing we try will be to patch 'make' to log when the jobserver kicks in or to play with some make jobserver demo such as: https://github.com/olsner/jobclient to get some experience with how things are supposed to work and to be able to strace a successful use of the job server feature. A little RTFM / UTSL may also be required. ../Randy This is on 4 core/8ht i7-3770 CPU @ 3.40GHz with 16Gb RAM and nodejs restricted to -j 2 (so that alone takes ~ 60min to build).- Trevor -- # Randy MacLeod # Wind River Linux
|
|
Re: bitbake controlling memory use
Ferry Toth
Hi
Op 10-06-2021 om 22:35 schreef Ferry Toth: Hi,It works fine. To measure time I first built https://github.com/htot/meta-intel-edison (gatesgarth), so everything needed is downloaded and cached. Then prior to each run I `rm -rf out` and `rm -rf bbcache/sstate-cache/*` to force everything to rebuild. And then `time bitbake -k edison-image` With patch: real 218m12,686s user 0m24,058s sys 0m4,379s Without: real 219m36,944s user 0m24,770s sys 0m4,266s Strange, I expected more. This is on 4 core/8ht i7-3770 CPU @ 3.40GHz with 16Gb RAM and nodejs restricted to -j 2 (so that alone takes ~ 60min to build). - Trevor
|
|
QA notification for completed autobuilder build (yocto-3.4_M1.rc1)
Pokybuild User <pokybuild@...>
A build flagged for QA (yocto-3.4_M1.rc1) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.4_M1.rc1 Build hash information: bitbake: 398a1686176c695d103591089a36e25173f9fd6e meta-arm: 6c3d62c776fc45b4bae47d178899e84b17248b31 meta-gplv2: 1ee1a73070d91e0c727f9d0db11943a61765c8d9 meta-intel: 0937728bcd98dd13d2c6829e1cd604ea2e53e5cd meta-mingw: bfd22a248c0db4c57d5a72d675979d8341a7e9c1 oecore: 3b2903ccc791d5dedd84c75227f38ae4c8d29251 poky: 59d93693bf24e02ca0f05fe06d96a46f4f0f1bf8 This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@...
|
|
Re: Extensible SDK of core-image-minimal fails to install
Hi,
On 12/06/2021 10:47, Richard Purdie wrote: I think it may be this bug:Not a fix, but a workaround, if you are willing to use containers is to create a build container and a similar sdk container. I added more information to the bug above. Regards, Robert
|
|
Re: Extensible SDK of core-image-minimal fails to install
Richard Purdie
On Fri, 2021-06-11 at 22:30 +0200, Hendrik wrote:
I was able to reproduce the error even with plain poky (without kas):I think it may be this bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14428 We don't have a fix as yet, it looks difficult to solve :( Cheers, Richard
|
|
Re: Extensible SDK of core-image-minimal fails to install
Hendrik
I was able to reproduce the error even with plain poky (without kas):
toggle quoted messageShow quoted text
```bash git clone -b dunfell https://git.yoctoproject.org/git/poky cd poky source oe-init-build-env bitbake -c populate_sdk_ext core-image-minimal ``` After successful build, copy the `build/tmp/deploy/sdk/poky....sh` to another machine (with different OS) and run it there. I tried several different installation machines and they fail consistently to install the extensible SDK if they run a different OS than the build machine (e.g. Debian 10 vs. Ubuntu 18.04 vs. 20.04). See the exakt error and complete log output in my previous message. What is happening here? Did I use the extensible SDK wrongly? Is it expected to be incompatible? Thanks in advance! Hendrik
On 09.06.21 17:58, Hendrik wrote:
Hello World,
|
|
Re: [meta-java] icedtea7 fetching error
Alexander Kanavin
I have reconfigured our build system to use an internal server via bbappend: ICEDTEA_HG_URL = "https://internal.artifact.server/icedtea/" placed all the tarballs there according to expected locations, and it works just fine. Alex
On Fri, 11 Jun 2021 at 12:44, <stefano.fiore84@...> wrote:
|
|