Hi all,

Intel and WR YP QA is now running QA execution for YP build yocto-3.1.rc2.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Monday, April 13.

Thanks,
Sangeeta

On 2020-03-30 2:57 a.m., Mikko Rapeli wrote:

Hi,
Generic approaches for reducing yocto target image size where buildhistory
is an important source of information:
* review and minimize distro features, enable only what you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-distro
* review and minimize image recipe, install only those image features and packages
which you need
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-image
* review the needed binary packages: traverse the tree of dependencies what you need,
review every single recipe and change PACKAGECONFIG or build flags to remove
features which you do not need. This it may be possible to remove large set
of dependencies from images, e.g. language bindings, debug tools. In some cases
one just needs a single binary executable or shared library but it is bundled
in a larger binary package with more complex dependencies. For these cases
add a bbappend to custom layers to change the packaging to only include what
you need.
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-PACKAGECONFIG
* change compiler flags from default O2 to Os optimization. This can work for
some recipes which are not prerformance critical or to the whole build. Note
that many SW components break this in their own build scripts by adding
O2 or even O3 by default. Check from buildhistory that binary sizes go smaller
after switch from O2 to Os and review every important recipe which did not.
You may be able to save up to 15% in rootfs size this way, but all depends
on the details of SW components and image contents.
see poky/meta/conf/bitbake.conf
I've followed this for multiple products and found out that poky is nice to work with
but BSP layers add or depend on all kinds of extra things that products do not need.
Thus I have ended by BBMASK'ing away large parts of BSP layer recipes in distro
configs. This with multiple x86 and ARM BSP layers from various SoC vendors.

I've also seen this problem and was frustrated by it.

The BSP vendors/developers want to test the full feature set of the
hardware but they often don't bother stripping out packages after
confirming that everything works. This results in bloat that can
be a problem for some users.

Using BBMASK is a good coping mechanism! :)

It would also be good if BSP developers split the BSP into the
essential elements and extras. Where to draw the line between
two such categories can tricky. One could also have finer-grained
packagegroups but splitting things into essential and extras is
a good start.

In WR Linux, we have a setup tool that let's you add 'features'
This comes from a layer that improves ease of use for some people:

https://github.com/WindRiver-Labs/wr-template/blob/WRLINUX_10_19_BASE/README

and is always used in the WR Linux distro.

And as can be seen here:
https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_19_BASE/wrlinux-distro/templates/feature/bsp-extras

There is a generic BSP independent feature that you can add to
a setup:

feature/bsp-extras

Adds some useful tools defined by the BSP_EXTRAS_PACKAGES option
in the BSP layer.

To see the list of available tools, run the bitbake -e command in
a sourced terminal, and look for the BSP_EXTRAS_PACKAGES.

Maybe this description will help get BSP developers to agree on
doing something similar regardless of the 'setup/wr-template' layer.

Good luck and keep your BSPs minimal!

../Randy

Also, RTFM :)
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#building-a-tiny-system
Hope this helps,
-Mikko

--
# Randy MacLeod
# Wind River Linux

Hi Stefan,

I agree that it is odd that a recipe copies a file, in this case the bl31 bootloader image, from the deploy area to the recipe area. This bootloader binary is created by the imx-atf recipe. imx-atf is listed as a dependency for imx-boot which is the recipe that is failing in your build. Therefore I would expect imx-atf to run before imx-boot. However, a recipe's do_compile task does not depend on another recipe's do_deploy task but on the other recipe's do_install task. What likely happened is that imx-boot do_compile was started after imx-atf do_install completed but before imx-atf do_deploy has completed. For imx-boot to work correctly it should copy the files from imx-atf's staging area rather than the deploy directory.

I suggest that you try to run imx-atf alone to see if it builds and if the bl31 image is built and placed into the deploy directory. And then run your build again.

:rjs

Hi,
I have encountered a curious problem when trying to create my own poky-based distribution.
My distribution poky-mydist.conf in conf/distro/ of my own layer:

require conf/distro/poky.conf

DISTRO = "poky-mydist"

DISTRO_NAME = "Poky my dist (Custom Project Distro)"

DISTROOVERRIDES = "poky:poky-mydist"

 

DISTRO_FEATURES += "ppp"

This distro is basically identical to the base poky from poky.conf. I just added a feature to be able to verify that my distro is being used.

When I build core-image-base however, I get the following error:

ERROR: imx-boot-0.2-r0 do_compile: Function failed: do_compile (log file is located at /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295)

ERROR: Logfile of failure stored in: /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295

Log data follows:

| DEBUG: Executing shell function do_compile

| Copying DTB

| 8MQ/8MM boot binary build

| Copy ddr_firmware: lpddr4_pmu_train_1d_imem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M

| Copy ddr_firmware: lpddr4_pmu_train_1d_dmem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M

| Copy ddr_firmware: lpddr4_pmu_train_2d_imem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M

| Copy ddr_firmware: lpddr4_pmu_train_2d_dmem.bin from /opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart -> /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/git/iMX8M

| cp: cannot stat '/opt/yocto-dev/build_poky/tmp/deploy/images/imx8mq-var-dart/imx-boot-tools/bl31-imx8mq.bin': No such file or directory

| WARNING: exit code 1 from a shell command.

| ERROR: Function failed: do_compile (log file is located at /opt/yocto-dev/build_poky/tmp/work/imx8mq_var_dart-poky-linux/imx-boot/0.2-r0/temp/log.do_compile.14295)

ERROR: Task (/opt/yocto-dev/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-bsp/imx-mkimage/imx-boot_0.2.bb:do_compile) failed with exit code '1'

By just switching my DISTRO to 'poky' in local.conf, it builds without error.

There are several things that surprise me about this error:
1. I find it quite strange that these ddr_firmwares are copied from the deploy directory to the working directory of imx-boot. I would expect that to be the other way around.
2. The file bl31-imx8mq.bin is not in the imx-boot-tools folder, even after a successful build with DISTRO='poky'. (Maybe it was there during build and was just removed afterwards?)

From my point of view it looks like the set of files that get put into imx-boot-tools/ is dependant on the DISTRO value? When using DISTRO='poky' the correct set is placed and copied. When using DISTRO='poky-mydist' the files that are placed into the folder are not the files that are supposed to be copied from there, hence the error.

Am I interpreting this situation correctly?
Is there an error in my poky-mydist distribution?
Is that something that needs to be fixed in the recipe for imx-boot? Or can I somehow configure poky-mydist.conf to be treated exactly like poky.conf?

Thanks in advance
Stefan 

-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Hi,
I have encountered a curious problem when trying to create my own poky-based distribution.
My distribution poky-mydist.conf in conf/distro/ of my own layer:

require conf/distro/poky.conf

DISTRO = "poky-mydist"

DISTRO_NAME = "Poky my dist (Custom Project Distro)"

DISTROOVERRIDES = "poky:poky-mydist"

 

DISTRO_FEATURES += "ppp"

On Wed, 2020-04-08 at 04:01 +0000, pokybuild@...
wrote:

A build flagged for QA (yocto-3.1.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2


Build hash information:

bitbake: 4618da2094189e4d814b7d65672cb65c86c0626a
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: bd539ea962ee285eb71053583e3c17fa166fc610
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: 1795f30d8ab73d35710ca99064c51190dc84853e
poky: 5d47cdf448b6cff5bb7cc5b0ba0426b8235ec478

There were two failures in this build due to collect-results failing. I
fixed the missing dependency on that autobuilder worker (there was
already an open bug but it wasn't fixed yet) and reran the collections
scripts so the results were added and handled.

Cheers,

Richard

Hi,
I try use SDL2 without X11 only with kmsdrm on stm32mp1 device. but I get error:  "KMSDRM not available".

I try the same on Rpi3 and its works.

I see that there is no kmsdrm in pkg-config and there is no anywhere libdrm.pc, is it required ?.

Should I build SDL on device ? if yes, how can I found link to source to use "apt-get build-dep libsdl2"

Regards,
Adrian

On Wed, 2020-04-08 at 01:14 +0000, Jain, Sangeeta wrote:

Hi Richard,

Thanks for update on
https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1
Unfortunately, I didn't received any mail for 3.1.rc1 or rc2 build
notification.
Looks like automated mail has some issues.

I will now start the QA on
https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2/

Thanks,
Sangeeta

-----Original Message-----
From: yocto@... <yocto@...>
On Behalf
Of Richard Purdie
Sent: Wednesday, 8 April, 2020 5:05 AM
To: Poky Build User <pokybuild@...>;
yocto@...
Cc: otavio@...; yi.zhao@...; Sangal, Apoorv
<apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>;
Chan,
Aaron Chun Yew <aaron.chun.yew.chan@...>;
akuster808@...;
sjolley.yp.pm@...; Jain, Sangeeta <sangeeta.jain@...>
Subject: Re: [yocto] QA notification for completed autobuilder
build (yocto-
3.1.rc1)

Thanks.

For reference you can see you're included in the Cc: list above so I'm
not sure why you aren't getting email. I'll ask Michael to look into
that.

Cheers,

Richard

Hi,

I am running Yocto built Linux on an ARM device, it takes about more
than 1 minutes to boot from NAND and kernel, any good strategy to
reduce the ARM device booting time? I can think of cutting down
unnecessary configures in kernel.

Thank you.

Kind regards,

- jh

Hi Richard,

Thanks for update on https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1
Unfortunately, I didn't received any mail for 3.1.rc1 or rc2 build notification.
Looks like automated mail has some issues.

I will now start the QA on https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc2/

Thanks,
Sangeeta

On Mon, 2020-04-06 at 22:53 +0000, Poky Build User wrote:

A build flagged for QA (yocto-3.1.rc1) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.1.rc1

I haven't see any "started QA" email about this yet.

We have had some issues with rc1 reported by people so given that and
the above, I'm going to abort rc1 and build rc2.

Cheers,

Richard

My guess is that your busybox isn't configured to produce mdev. Run "bitbake -c menuconfig busybox" and enable it (and save the config fragment for later)

--
Mike Looijmans

On 30-03-2020 05:08, Raghu Icecraft Software Trainings via Lists.Yoctoproject.Org wrote:

Hi,
  I have some general idea on makefile in C, C++ environment.
Related to my Yocto project having a very tough time in getting my makefile ready on shape after almost every development change.
Is there any specific Troubleshooting based guidance available some where ?
I have also tried looking for old posts in this group.
Please suggest if I have to post this question, somewhere else.

For anything more advanced than one or two C files, avoid handcrafting makefiles and use autotools or cmake.

A helloworld makefile that takes "helloworld.c" or "helloworld.cpp" and creates an executable can be as simple as this:


helloworld: helloworld.o


And that's it. Notice the total absence of compiler and linker invocations, your environment already knows how to do that. Adding more to this makefile will usually only make it worse...

On 2020-03-29 11:08 p.m., Raghu Icecraft Software Trainings wrote:

Hi,
  I have some general idea on makefile in C, C++ environment.
Related to my Yocto project having a very tough time in getting my makefile ready on shape after almost every development change.
Is there any specific Troubleshooting based guidance available some where ?
I have also tried looking for old posts in this group.
Please suggest if I have to post this question, somewhere else.

Did anyone reply off list?

Did you have a look at using the SDK and tips in:

https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-adding-makefile-only-software


Also, here's a simple recipe example from the Wind River docs:
https://docs.windriver.com/bundle/Wind_River_Linux_Platform_Developers_Guide_CD/page/mmo1403548803429.html
you should be able to make that work with just oe-core/poky.

If you're still having trouble, post a example Makefile
for 'hello-world' and perhaps someone will help you out.

../Randy

--
# Randy MacLeod
# Wind River Linux

On Mon, Apr 6, 2020 at 3:34 PM Patrick Doyle <wpdster@...> wrote:

I have a recipe that looks something like this (I'm simplifying a bit here):

SRC_URI += "${EXTERNAL_URL}"

do_compile() {
do -something -with $(basename ${EXTERNAL_URL} .ext)
}

where EXTERNAL_URL is supplied in the environment when invoking
Bitbake (and is whitelisted in the environment).

The problem is, if that URL has HTTP escapes in it, they get decoded
by the fetcher, and the file in ${WORKDIR} no longer looks like
$(basename ${EXTERNAL_URL}).

Never mind. I found it. I did something like:

EXTERNAL_FILE="${@bb.fetch.decodeurl(d.getVar('EXTERNAL_URL',True))[2]}"
do_compile() {
do -something-with $(basename ${EXTERNAL_URL})
}

I would still be happy to learn of a better way to have done this.

--wpd

I have a recipe that looks something like this (I'm simplifying a bit here):

SRC_URI += "${EXTERNAL_URL}"

do_compile() {
do -something -with $(basename ${EXTERNAL_URL} .ext)
}

where EXTERNAL_URL is supplied in the environment when invoking
Bitbake (and is whitelisted in the environment).

The problem is, if that URL has HTTP escapes in it, they get decoded
by the fetcher, and the file in ${WORKDIR} no longer looks like
$(basename ${EXTERNAL_URL}).

Is there any way to invoke a URL decoder on a variable within bitbake?
Is there any way to determine what the filename was of a file that was
downloaded?
Is there any better way to do this?

Thanks for any tips you can provide.

--wpd