Date   

Re: QEMU Size Increase from Yocto Thud to Zeus

Ross Burton <ross@...>
 

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



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:

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


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

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


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: June 10, 2021

Randy MacLeod
 

(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:
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




Re: bitbake controlling memory use

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


Re: bitbake controlling memory use

Ferry Toth
 

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


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

Robert Berger
 

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


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

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


Re: Extensible SDK of core-image-minimal fails to install

Hendrik
 

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

On 09.06.21 17:58, Hendrik wrote:
Hello World,

I'm trying to install an extensible SDK of `core-image-minimal` on a
system different from the build system (build system is Debian 10,
install system is e.g. Ubuntu 20.04). When doing this, the following
error occurs:

```
ERROR: Task
(virtual:native:/home/test/poky_sdk/layers/poky/meta/recipes-devtools
/pseudo/pseudo_git.bb:do_fetch) failed with exit code 'setscene whitelist'
```

The full log file `preparing_build_system.log` is available at:
https://pastebin.com/m9KmshY0

It seems `recipes-devtools/pseudo/pseudo_git.bb` does depend on the
build environment and therefore yields different hashes which results in
broken sstate-cache. Does someone know what exactly went wrong and how
to fix it?

Steps to reproduce:

Use the following `kas-project.yml`:

```yml
header:
  version: 10
machine: qemux86-64
distro: poky
local_conf_header:
  standard: |
    CONF_VERSION = "1"
    PACKAGE_CLASSES = "package_rpm"
repos:
  poky:
    url: "https://git.yoctoproject.org/git/poky"
    refspec: dunfell
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:
```

Then, run a kas container (https://github.com/siemens/kas, e.g. use
`kas-container` script): `./kas-container shell kas-project.yml` This
will start a Debian 10 container with kas installed.

Build the extensible SDK with `bitbake -c populate_sdk_ext
core-image-minimal`.

After finishing, install the extensible SDK on a different machine (for
testing purposes e.g. in a Docker container for example `ubuntu:20.04`).
It will result in the error mentioned above.

How do I fix that?

Thanks in advance!

Hendrik


Re: [meta-java] icedtea7 fetching error

Alexander Kanavin
 

I have reconfigured our build system to use an internal server via bbappend:


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:

I have also the tarball but the build will fail later in the configure phase stating:
icedtea7 "Invalid OpenJDK source zip specified".

Is there something more I can try ?





Re: QEMU Size Increase from Yocto Thud to Zeus

Ross Burton <ross@...>
 

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



Re: [meta-java] icedtea7 fetching error

stefano.fiore84@...
 

I have also the tarball but the build will fail later in the configure phase stating:
icedtea7 "Invalid OpenJDK source zip specified".

Is there something more I can try ?


QEMU Size Increase from Yocto Thud to Zeus

Aashik Aswin
 

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


[meta-zephyr][PATCH 3/3] zephyr-flash-bossac.bbclass: Enable board flashing via bossac

Wojciech Zmuda
 

From: Nagesh Shamnur <nagesh.shamnur@...>

Currently only dfu and pyocd flashing are supported. Some boards
such as Arduino Nano 33 BLE can be flashed via bossac which is
released by Arduino repo. Find the installed Arudino version of
bossac and flash using that tool.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
---
classes/zephyr-flash-bossac.bbclass | 50 +++++++++++++++++++++++++++
conf/machine/arduino-nano-33-ble.conf | 1 +
2 files changed, 51 insertions(+)
create mode 100644 classes/zephyr-flash-bossac.bbclass

diff --git a/classes/zephyr-flash-bossac.bbclass b/classes/zephyr-flash-bossac.bbclass
new file mode 100644
index 0000000..50222d5
--- /dev/null
+++ b/classes/zephyr-flash-bossac.bbclass
@@ -0,0 +1,50 @@
+#@DESCRIPTION: class file to flash boards like Arduino Nano BLE which depends on bossac for flashing
+
+python do_flash_usb() {
+ import shutil
+ import subprocess
+ import serial.tools.list_ports
+
+ # Note: make sure the installed bossac is set to PATH before running flash_usb()
+ # Check if bossac is avaiable for flashing
+ origbbenv = d.getVar("BB_ORIGENV", False)
+ bossac_path = shutil.which("bossac", path=origbbenv.getVar('PATH'))
+
+ if not bossac_path:
+ bb.fatal("ERROR: bossac not found, please install first and add to PATH")
+
+ board = d.getVar('BOARD')
+
+ if board == 'arduino_nano_33_ble':
+ # find the serial port to which board is connected to
+ for port in serial.tools.list_ports.comports():
+ if 'Arduino Nano 33 BLE' in port.description:
+ serial_port = port.device
+ break
+ else:
+ bb.fatal("ERROR: board not connected for flashing. Connect via USB and enable permission to connected port")
+
+ image = "%s/%s.bin" % (d.getVar('DEPLOY_DIR_IMAGE'), d.getVar('PN'))
+
+ command = [bossac_path, '-p', serial_port , '-R', '-e', '-w', '-v', '-b', image]
+ else:
+ bb.fatal("ERROR: Unsupported board %s" % board)
+
+ bb.note("command: %s" % command)
+ bb.plain("Attempting to flash board: %s" % board)
+
+ # Random failure are a possibility here, retry till there is a success for finite times
+ for _ in range(10, 0, -1):
+ try:
+ subprocess.check_call(command)
+ bb.plain("Bossac Flashing board: %s Success " % board)
+ break
+ except subprocess.CalledProcessError as e:
+ bb.warn("Failed to flash %s (error code: %s). Retrying after 1 second..." % (board, e.returncode))
+ time.sleep(1)
+}
+
+addtask do_flash_usb after do_deploy
+
+do_flash_usb[nostamp] = "1"
+do_flash_usb[vardepsexclude] = "BB_ORIGENV"
diff --git a/conf/machine/arduino-nano-33-ble.conf b/conf/machine/arduino-nano-33-ble.conf
index e45cfc2..18ba056 100644
--- a/conf/machine/arduino-nano-33-ble.conf
+++ b/conf/machine/arduino-nano-33-ble.conf
@@ -4,5 +4,6 @@
#@DESCRIPTION: Machine configuration for Arudino nano 33 ble and Arduino nano 33 ble sense

require conf/machine/include/nrf52.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-bossac"
ARCH_arduino-nano-33-ble = "arm"

--
2.25.1


[meta-zephyr][PATCH 2/3] arduino-nano-33-ble.conf: Add Arduino Nano 33 BLE and BLE Sense support

Wojciech Zmuda
 

From: Nagesh Shamnur <nagesh.shamnur@...>

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
---
conf/machine/arduino-nano-33-ble.conf | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 conf/machine/arduino-nano-33-ble.conf

diff --git a/conf/machine/arduino-nano-33-ble.conf b/conf/machine/arduino-nano-33-ble.conf
new file mode 100644
index 0000000..e45cfc2
--- /dev/null
+++ b/conf/machine/arduino-nano-33-ble.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: arduino-nano-33-ble
+
+#@DESCRIPTION: Machine configuration for Arudino nano 33 ble and Arduino nano 33 ble sense
+
+require conf/machine/include/nrf52.inc
+ARCH_arduino-nano-33-ble = "arm"
+
--
2.25.1

3521 - 3540 of 57342