Hi Team,
 
               I am facing a problem libsdl2 while building the core-image-base. Can anybody know this please suggest me. 

--
Regards,
Sateesh

On Mon, Dec 13, 2021 at 6:21 PM Rusty Howell <rustyhowell@...> wrote:

We are building our software with a Yocto SDK we created against our imx8m board. We would like to be able to execute unit tests (C++ tests written in Google Test) quickly without having to copy our unittest binaries over to an actual imx board to execute them. For sanity, we are also building our linux distro for MACHINE=qemux86-64 and beaglebone-yocto. So we have SDKs for imx8m, qemux86-64 and beaglebone-yocto.

Is there a MACHINE type that we could build that would be suitable for executing compiled C++ google test binaries directly on Ubuntu 18.04 or 20.04?

I think using qemux86-64 might be your best bet, its fairly automated
with runqemu script
all you would need to do is package up the gtests as ptest package with a runner

Thanks

On Fri 2021-12-10 @ 11:15:56 AM, Trevor Woerner via lists.yoctoproject.org wrote:

On Fri 2021-12-10 @ 03:50:19 PM, Quentin Schulz wrote:

Hi Trevor,

On Fri, Dec 10, 2021 at 09:43:39AM -0500, Trevor Woerner wrote:

On Thu 2021-11-11 @ 06:00:02 PM, Quentin Schulz wrote:

Not all Rockchip boards have their console running at 1500000 baud in
U-Boot and the kernel. Such is the case for puma-haikou RK3399-based
SoM+Carrierboard.

In order to prepare for the addition of puma-haikou to meta-rockchip,
let's replace the baudrate in TF-A by the one defined in the machine
conf file in the RK_CONSOLE_BAUD variable.

Cc: Quentin Schulz <foss@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 7 +++-
2 files changed, 6 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
deleted file mode 100644
index 2d6e9bf..0000000
--- a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
-From: Yann Dirson <yann@...>
-Date: Tue, 6 Apr 2021 17:28:45 +0200
-Subject: [PATCH] Set serial console baudrate back to 1500000.
-Upstream-Status: Inappropriate[other]
-
-TF-A runs between two u-boot stages which both uses 1500000 baud, it
-just makes no sense to use the same UART at a different rate.
-
-This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
-Main reason for that change stated in https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.trustedfirmware.org_T762&d=DwIBaQ&c=_sEr5x9kUWhuk4_nFwjJtA&r=LYjLexDn7rXIzVmkNPvw5ymA1XTSqHGq8yBP6m6qZZ4njZguQhZhkI_-172IIy1t&m=TULURVxAXuoOr1qm-lWPJ4RyXC82jen1-RFqhySvz2ZLazQ8DA84GQ7T4MccEcQp&s=7WhFJXuPJAZq8RxczqF3HrMD5JqRZdJ8MyMU9iEnq44&e=
-is ChromeOS compatibility.
-
-Looks like this patch may become unnecessary in the future, when
-u-boot and TF-A get to communicate this value.
-
----
- plat/rockchip/rk3399/rk3399_def.h | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
-index ba83242eb..8d6ecfbe6 100644
---- a/plat/rockchip/rk3399/rk3399_def.h
-+++ b/plat/rockchip/rk3399/rk3399_def.h
-@@ -17,7 +17,7 @@
- /**************************************************************************
- * UART related constants
- **************************************************************************/
--#define RK3399_BAUDRATE 115200
-+#define RK3399_BAUDRATE 1500000
- #define RK3399_UART_CLOCK 24000000
-
- /******************************************************************************
---
-2.30.2
-
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index f7777a7..0d06c44 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,9 +7,14 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.patch \
file://0001-Fix-build-with-gcc-11.patch \
file://0001-dram-Fix-build-with-gcc-11.patch \
file://0001-plat_macros.S-Use-compatible-.asciz-asm-directive.patch \
file://0001-pmu-Do-not-mark-already-defined-functions-as-weak.patch \
"
+
+fixup_rk3399_baudrate() {
+ sed -i "s/#define RK3399_BAUDRATE 115200/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}

This looks fragile to me, any change in the number of spaces/tabs and this
line will stop working. Thankfully the symbol RK3399_BAUDRATE only appears
once in this file! That will allow us to do something like the following
instead:

sed '/RK3399_BAUDRATE.*/RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/d'

Would
sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE plep/" ${S}/plat/rockchip/rk3399/rk3399_def.h

work for you?
This makes sure that only RK3399_BAUDRATE definition will be changed, no
comment, no RK3399_BAUDRATE_OTHER_VAR or RK3399_BAUDRATE being used in
code/other constant in this file.

Sounds good.

Am I correct in thinking a v2 is coming (or did it get swallowed up by my mail
client)?

Otherwise, I can just fixup your v2 and apply it if you wish?

On Sat 2021-12-11 @ 08:55:43 AM, Trevor Woerner wrote:

The _virtual notation is not an override. These syntax "fixes" need to be
reverted.

In the case of the kernel override, when it was added, the rock-pi-e needed
the latest kernel (linux-yocto-dev) but now the default linux-yocto kernel
will suffice. So this mistake actually switched the rock-pi-e from
linux-yocto-dev back to linux-yocto inadvertently but at a time when
linux-yocto-dev was no longer required.

In the case of the bootloader overrides, u-boot was always the default, so
these overrides were always redundant.

Therefore, in the end, simply removing these overrides is the best way
forward (considering these aren't doing anything, and the builds are working
fine regardless).

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rk3288.inc | 1 -
conf/machine/include/rk3328.inc | 2 --
conf/machine/include/rk3399.inc | 2 --
conf/machine/include/rockchip-defaults.inc | 1 -
conf/machine/rock-pi-e.conf | 2 --
5 files changed, 8 deletions(-)

Applied to meta-rockchip, master.

Hi Quentin/Khem,

On Mon 2021-12-13 @ 09:35:53 AM, Khem Raj wrote:

On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:

On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

I apologize for not reviewing this patch in a timely manner; I'm sorry for the
frustration it caused.

Would this have been solved by (me) creating a honister branch? I usually
don't create a release branch until openembedded-core moves, but this looks
like it was a case where master and the latest branch diverged?

If so, would that still be useful?

Best regards,
Trevor

On Mon, Dec 13, 2021 at 9:18 AM Quentin Schulz <foss+yocto@...> wrote:

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:

On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less
of a problem. Version specific patching will set a different preset for the
layer to carry unexcercised patches

We need this patch for honister 3.4 but what I meant is that even though it's not needed for honister >= 3.4.1, I'm still interested in what the policy should be. Especially what we should have done between 3.4 and 3.4.1, before the latter was released.

I understand the precedent it creates but also, it's a bit sad for a "BSP" layer to have some support broken between Yocto releases.

I agree with you that broken is not good as it was for sometime, but
now with the latest supported release in 3.4 series ( which is 3.4.1)
things should be good.

Cheers,
Quentin

Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:

On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:

On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <

raj.khem@...> wrote:

On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:

On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:

On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the

Ethernet

MAC

controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in

v5.15)

which is provided here and applied to linux-yocto source

tree if

linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because

Honister 3.4

has linux-yocto v5.14.9 and Honister 3.4.1 will have at

least

linux-yocto v5.14.14.

Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4

v5.14.14 is already fixed. The only release currently is 3.4

and I hit

that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've

seen

people running behind dot releases.
What's bothering you?

once dot release is out then thats whats maintained not the

original

release since they are incremental.
the anon python to apply a patch. Can you explain why we want to

patch

applied this way ?

I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch

If you could explain what's *really* bothering you, I could try to

find a proper explanation or agree with you but it's a bit too vague to me
right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the

latest and only release of Honister?

meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.

meta-rockchip is the BSP layer for Rockchip based devices, if not

there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to

people asking instead of having this patch in? Obviously you could tell
them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1
once it's out but having this patch in avoid those questions.

I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this

patch either but Ethernet is quite critical on boards which don't have WiFi
for example. I don't have anything better to suggest to fix this in the
*latest* release.

Update to latest honister branch or wait for 3.4.1, would be my

suggestion.

Cheers
Quentin

Cheers,
Quentin

Hi José,

On December 13, 2021 12:26:29 PM GMT+01:00, "Cardenas Jose Antonio (JCARDENA)" <joseantonio.cardenas@...> wrote:

Hi all.

I have added a recipe to BBMASK to skip the processing of this recipe for now, but when I try to compile the image i get ERROR: Nothing RPROVIDES <recipe> error. It's like I should say to yocto to reparse all recipes but I don't find the way to do it without remove the build directory and build again.

The issue is that you masked a recipe whose packages are required by other recipes packages. Find where the RDEPENDS is set for this recipe package and remove the package which depends on that recipe package from your image (usually, don't include it), or break the dependency chain there by removing the RDEPENDS.

Hope this helps,
Cheers,
Quentin

Regards.
José

Hi Léon,

On December 13, 2021 3:40:05 PM GMT+01:00, "Beek, Léon van de" <l.v.d.beek@...> wrote:

Dear all,

Currently I have created an image which upon boot mounts my rootfs as readonly in an overlay with my data partition. I set out to change the FS type of my rootfs to something that is actuall read-only like squashfs, however I am getting a kernel panic whenever I boot saying:

"Not syncing: vfs: Unable to mount root fs on unknown-blick(179,2)"

The steps I took to convert to a read-only rootfs:

* Change -fstype in .wks file to squashfs
* Changed IMAGE_FSTYPE= "squashfs wic.bz2", in local.conf, however I do not believe this is necessary actually

Did you check that your kernel actually supports squashfs as rootfs? There is a Kconfig option for it IIRC.

Are there steps I am missing? I believe that IMAGE_FEATURE = "read-only-rootfs" should not be necessary as I am mounting the rootfs in an overlay before starting /sbin/init , but I might be wrong.

Since it's an image feature, it's not going to impact anything outside of the image recipe but I don't know exactly what this is doing from memory.

Cheers,
Quentin

Kind regards,

Léon van de Beek

Hi Khem,

On December 13, 2021 4:04:03 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:

On Mon, Dec 13, 2021 at 1:00 AM Quentin Schulz <
quentin.schulz@...> wrote:

Hi Trevor,

Gentle ping :)

Honister 3.4.1 being out it's less of an issue but the question remains
at least for settling on a policy :)

Do we still need this patch ? I think now that dot release is out it’s less
of a problem. Version specific patching will set a different preset for the
layer to carry unexcercised patches

We need this patch for honister 3.4 but what I meant is that even though it's not needed for honister >= 3.4.1, I'm still interested in what the policy should be. Especially what we should have done between 3.4 and 3.4.1, before the latter was released.

I understand the precedent it creates but also, it's a bit sad for a "BSP" layer to have some support broken between Yocto releases.

Cheers,
Quentin

Cheers,
Quentin

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:

On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:

On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <

raj.khem@...> wrote:

On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:

On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:

On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the

Ethernet

MAC

controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in

v5.15)

which is provided here and applied to linux-yocto source

tree if

linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because

Honister 3.4

has linux-yocto v5.14.9 and Honister 3.4.1 will have at

least

linux-yocto v5.14.14.

Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4

v5.14.14 is already fixed. The only release currently is 3.4

and I hit

that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've

seen

people running behind dot releases.
What's bothering you?

once dot release is out then thats whats maintained not the

original

release since they are incremental.
the anon python to apply a patch. Can you explain why we want to

patch

applied this way ?

I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch

If you could explain what's *really* bothering you, I could try to

find a proper explanation or agree with you but it's a bit too vague to me
right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the

latest and only release of Honister?

meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.

meta-rockchip is the BSP layer for Rockchip based devices, if not

there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to

people asking instead of having this patch in? Obviously you could tell
them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1
once it's out but having this patch in avoid those questions.

I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this

patch either but Ethernet is quite critical on boards which don't have WiFi
for example. I don't have anything better to suggest to fix this in the
*latest* release.

Update to latest honister branch or wait for 3.4.1, would be my

suggestion.

Cheers
Quentin

Cheers,
Quentin

ping

This is done regularly by the overall AB maintenance tooling, and erasing
build artifacts makes it difficult to find out what went wrong
when it does.

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/run-auh | 5 -----
1 file changed, 5 deletions(-)

diff --git a/scripts/run-auh b/scripts/run-auh
index 7a9ab70..656bedd 100755
--- a/scripts/run-auh
+++ b/scripts/run-auh
@@ -24,9 +24,4 @@ git checkout -B tmp-auh-upgrades origin/master
source $poky_dir/oe-init-build-env $build_dir
$auh_dir/upgrade-helper.py -e all

-# clean up to avoid the disk filling up
-rm -rf $build_dir/tmp/
-rm -rf $build_dir/workspace/sources/*
-find $sstate_dir -atime +10 -delete
-
popd
--
2.33.1