Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:

From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.

Sounds good. I prefer the rockchip default of 1,500,000 anyway.

Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries

Odd that you'd be assigning the copyright to Garmin ;-)

+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS

Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"

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"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG = "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainline-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
++ mmc0 = &emmc;
++ mmc1 = &sdmmc;
+ ethernet0 = &gmac2io;
+ ethernet1 = &gmac2phy;
+ };
+--
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 = "rock64"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards

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"
--
2.30.2

On Mon, Jun 14, 2021 at 07:58:19AM -0400, Robert P. J. Day wrote:

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 :-),

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 seems
to work well with lots and lots of OE builds?

Ask 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.

rday

cu
Adrian

- Ryzen based for core count
- 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

--
Jack Mitchell, Consultant
https://www.tuxable.co.uk

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

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:

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Ross

On Mon, 14 Jun 2021 at 09:04, Aashik Aswin <thisisaash9698@...> wrote:

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?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

On Fri, 11 Jun 2021 at 11:40, Aashik Aswin <thisisaash9698@...> wrote:

Hi Experts,

I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.

Thud (4.19) - 223084 KiB qemu
Zeus (5.4) - 474757 KiB qemu

Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?

Appreciate your help.

TIA,
Aashik

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Ross

Hello,

you can use wildebeest's mirror:

ICEDTEA_HG_URL = "http://icedtea.wildebeest.org/hg/release/${ICEDTEA_PREFIX}"

Marvin

Hello.

On 11.06.21 03:26, Saini, Naveen Kumar wrote:

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Stefan Schmidt
Sent: Thursday, June 10, 2021 4:28 PM
To: yocto@...
Cc: Stefan Schmidt <stefan@...>; Stefan Schmidt
<stefan.schmidt@...>
Subject: [yocto] [meta-zephyr][PATCH v2 1/2] zephyr-kernel: Add
OpenThread add module to build

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-common.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-common.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 330fe59..35c4106 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -29,6 +29,7 @@ ZEPHYR_MODULES_append_arm =
"\;${S}/modules/cmsis"
ZEPHYR_MODULES_append_nordic = "\;${S}/modules/hal/nordic"
ZEPHYR_MODULES_append_stm32 = "\;${S}/modules/hal/stm32"
ZEPHYR_MODULES_append_openamp = "\;${S}/modules/lib/open-
amp\;${S}/modules/hal/libmetal"
+ZEPHYR_MODULES_append_openthread =
"\;${S}/modules/lib/openthread"

This is not required. It already listed in required sample recipe. Please remove it.

Fixed.

EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
b/recipes-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 =
"c3bd2094f92d574377f7af2aec147ae181aa5f8e"
SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-
kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5e43583..4937a77 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 = "\
git://github.com/zephyrproject-
rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=
stm32 \
git://github.com/zephyrproject-
rtos/mbedtls.git;protocol=https;destsuffix=git/modules/lib/mbedtls;name=
mbedtls \
git://github.com/zephyrproject-rtos/open-
amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-
amp \
+
+ git://github.com/zephyrproject-rtos/openthread.git;protocol=https;bran
+ ch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
git://github.com/zephyrproject-

It would cause build failure with v2.5.0. So add SRCREV_openthread in zephyr-kernel-src-2.5.0.inc too.

Indeed, I did not test with 2.5. Thanks for spotting. Fixed.

I send a v3 now.

regards
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

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

(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

Hi

Op 13-06-2021 om 02:38 schreef Randy MacLeod:

On 2021-06-12 12:31 p.m., Ferry Toth wrote:

Hi

Op 10-06-2021 om 22:35 schreef Ferry Toth:

Hi,

Op 10-06-2021 om 21:06 schreef Trevor Gamblin:

On 2021-06-10 5:22 a.m., Ferry Toth wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.

Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.

Your patch didn't apply clean on Gatesgarth, but fix seemd trivial. With this it builds cmake-native fine, thanks!

You can find it here: https://github.com/htot/meta-intel-edison/commit/8abce2f6f752407c7b2831dabf37cc358ce55bc7

I will check if any other build errors occurs, and if not will try to time image build with and without the patch to compare performance and see if it worth the effort.

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.

Hi 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

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..

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.

I'm available for testing.

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).

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

Ferry

On 2021-06-12 12:31 p.m., Ferry Toth wrote:

Hi
Op 10-06-2021 om 22:35 schreef Ferry Toth:

Hi,

Op 10-06-2021 om 21:06 schreef Trevor Gamblin:

On 2021-06-10 5:22 a.m., Ferry Toth wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.

Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.

Your patch didn't apply clean on Gatesgarth, but fix seemd trivial. With this it builds cmake-native fine, thanks!

You can find it here: https://github.com/htot/meta-intel-edison/commit/8abce2f6f752407c7b2831dabf37cc358ce55bc7

I will check if any other build errors occurs, and if not will try to time image build with and without the patch to compare performance and see if it worth the effort.

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.

Hi 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

Ferry

--
# Randy MacLeod
# Wind River Linux

Hi

Op 10-06-2021 om 22:35 schreef Ferry Toth:

Hi,

Op 10-06-2021 om 21:06 schreef Trevor Gamblin:

On 2021-06-10 5:22 a.m., Ferry Toth wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.

Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.

Your patch didn't apply clean on Gatesgarth, but fix seemd trivial. With this it builds cmake-native fine, thanks!

You can find it here: https://github.com/htot/meta-intel-edison/commit/8abce2f6f752407c7b2831dabf37cc358ce55bc7

I will check if any other build errors occurs, and if not will try to time image build with and without the patch to compare performance and see if it worth the effort.

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

Ferry

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@...

Hi,

On 12/06/2021 10:47, Richard Purdie wrote:

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

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

On Fri, 2021-06-11 at 22:30 +0200, Hendrik wrote:

I was able to reproduce the error even with plain poky (without kas):

```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?

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

I was able to reproduce the error even with plain poky (without kas):

```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