Date   

Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 396 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.4”, “3.5, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Not getting login screen for xfce desktop #bitbake

@prashant2314
 

I'm building xfce4 desktop based yocto image,I'm using poky-hardknott bsp, Image is booting fine but I'm not getting login screen for the user I'm adding,
I've tried may things but no luck,
if some have any idea please help me resolve this.

Thanks and Reagrds.


Re: Software Port

Ross Burton <ross@...>
 

On Sat, 18 Dec 2021 at 21:12, rashmi pisal via lists.yoctoproject.org
<rashmipisal=yahoo.com@...> wrote:
We are planning to use an IMX8 processor and wondering if I can modify the existing embedded Linux distribution created using YoctoProject to accommodate the new hardware changes, or I will have to make the latest image from scratch?
It depends on how much RPi-specific software is being used, but
changing MACHINE from raspberrypi3 to the relevant BSP for your IMX8
board would be a start. It's entirely possibly that is all you need
to change.

Ross


Re: do_rootfs: Taskhash mismatch due to BUILDNAME containing automatic date

Jesper Åhman
 

Hello and thank you for your reply.

according to my understanding BUILDNAME should not be used like that since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake.
That explains why the same approach works in an older Yocto project that I have for another machine.

Judging from that if you would set 'BUILDNAME = "my_Image_0.0.1_${DATE}"' the warning likely will go away.
Unfortunately, that did not make any difference. The same error is still there.

There must be some way of doing this, right?
Or are there some other approach available, to do about the same thing?
I mainly want to set /etc/version to something useful.

Best regards,


-----Ursprungligt meddelande-----
Från: Konrad Weihmann <kweihmann@...>
Skickat: den 17 december 2021 12:19
Till: Jesper Åhman <jesper.ahman@...>; yocto@...
Ämne: Re: [yocto] do_rootfs: Taskhash mismatch due to BUILDNAME containing automatic date

Hi,

according to my understanding BUILDNAME should not be used like that since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake.

The variable should contain only references to other automatically determined variables (default = ds.setVar("BUILDNAME", "${DATE}${TIME}")

Judging from that if you would set 'BUILDNAME = "my_Image_0.0.1_${DATE}"' the warning likely will go away.

Please keep in mind that these inline functions (esp in early stages of the parsing process, like machine.conf) are not expanded.
Which explains the seen behavior.

On 17.12.21 11:35, Jesper.Ahman@... wrote:
Hello,

In my machine config, I have set buildname using:
BUILDNAME = "my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}"
In order to get a timestamp (date) in each build name.

Although, this causes some error messages when building the rootfs:
/ERROR: When reparsing
/home/buildserver/fsl/sources/meta-freescale-distro/recipes-fsl/images
/fsl-image-multimedia-full.bb:do_rootfs,
the basehash value changed from
6b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e to
cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed. The
metadata is not deterministic and this needs to be fixed./
/ERROR: The following commands may help:/
/ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Snone/
/ERROR: Then:/
/ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Sprintdiff/

I ran the suggested commands and found the following:
/Task fsl-image-multimedia-full:do_rootfs couldn't be used from the
cache because:/ /  We need hash
066153e1a8d8ad0e8025f6409dbac96c277e6300541356b077f1823f195ef19c,
closest matching task was
040147cd35d17688668c7435633fd8ff25d8cf7425a93d35efdd7799a47bdc85/
/  basehash changed from
cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed to
61b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e/
/  Variable BUILDNAME value changed from 'my_Image_0.0.1_20211214' to
'my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}'
/
So when /${@time.strftime('%Y%m%d',time.gmtime())}' /is converted to
the actual date, it messes with Yocto.
The build succeeds anyway, but it's quite annoying having a load of
error messages on each build.

How can these errors be avoided?

I found in the Yocto FAQ:
/This is often something time-related e.g. a timestamp which is
calculated every time an expression is expanded. The solution is to
ensure the value is calculated once per build and then the expression
expands to the same value for the duration of the build.

/Which sounds somewhat right, but the issue here is not that the value
is changed due to recalculation (the date rarely changes during a
build) but the expansion of the expression itself (from Pyhton code
into its result).

Running Yocto Dunfell.




#systemd Weston service restarting timeout on dunfell branch #systemd

Duy
 

Hi,

In 3.1.12, I noticed weston service type was changed to Nofity. This make weston service cannot be restarted by "systemctl restart weston@root" command. The service is then timeout and fail.

Investigating systemd unit document, it seems that the notification message is required for a notify unit to finish its launch. So I tried to add this command to /usr/bin/weston-start script:
systemd-notify --ready
The service can be restart normally. Is it considered a bug? Or do we have any workaround?


echo and read shell script functions in post install script doesn't display messages #armv6

sanjaycvr35412@...
 

I have to execute a script to setup static IP address of the ARM board. This I need to do it on first boot of the Yocto Linux. I wrote post install script to do it, but it doesn't print interactive messages to user asking for IP address, netmask, gateway etc. i.e. it doesn't print echo and read messages.
I need to run this script only once on first boot of the ARM board.
Kindly suggest me a way to display echo/read messages to make setup script more interactive. 


Re: [dunfell] hidden files/folders in WORKDIR

Randy MacLeod
 

On 2021-12-15 2:22 p.m., Joel Winarske wrote:
I'm finding that if I create files/folders (prefixed with '.') in WORKDIR, they don't get cleaned up with INHERIT += "rm_work".
Is this a feature or a bug?
I think it's an oversight that doesn't affect many people.

The rm_work code for WORKDIR is:

http://cgit.openembedded.org/openembedded-core/tree/meta/classes/rm_work.bbclass#n97

cd ${WORKDIR}

for dir in *

do

# Retain only logs and other files in temp, safely ignore

# failures of removing pseudo folers on NFS2/3 server.

if [ $dir = 'pseudo' ]; then

rm -rf -- $dir 2> /dev/null || true

elif ! echo "$excludes" | grep -q -w "$dir"; then

rm -rf -- $dir

fi

done


so you can see that if you want to submit a patch to remove .FOO files,
you'd have to change the glob and exclude . and ..
The comment seems to justify doing that.


I guess one question is how common is it for 'dot' files to be there
and have people come to rely on the fact that rm_work doesn't remove them.

See some analysis below if you're interested but I think it's sensible
to also remove 'dot' files. Wait a day or so to see if anyone has a
use case that would be a problem and if not, could you send a patch?

Btw:
WORKDIR docs:
http://docs.yoctoproject.org/ref-manual/variables.html?highlight=workdir#term-WORKDIR
say that:
"This directory is located within the TMPDIR directory structure and is specific to the recipe being built and the system for which it is being built. "
so that seems to give you carte blanche!

and there's no restriction given in the rm_work docs either:
http://docs.yoctoproject.org/ref-manual/classes.html#ref-classes-rm-work


../Randy


In a build that I have on hand:

# how many files could be cleaned up?
$ ls -d tmp-glibc/work/core2-64-wrs-linux/*/*/[a-Z]* | wc -l

2887


# how many of them are 'dot' files?
$ ls -d tmp-glibc/work/core2-64-wrs-linux/*/*/.[a-Z]* | wc -l

1


# What's the file:
$ ls -d tmp-glibc/work/core2-64-wrs-linux/*/*/.[a-Z]*

tmp-glibc/work/core2-64-wrs-linux/usleep/1.0-r0/.pc


# .pc files are usually stored in a subdirectory like:
# tmp-glibc/work/core2-64-wrs-linux/m4/1.4.19-r0/m4-1.4.19/.pc
# how many 'proper' .pc files are there just out of curiousity?
$ ls -d tmp-glibc/work/core2-64-wrs-linux/*/*/*/.pc | wc -l

79


# Let's look at usleep:
$ ls tmp-glibc/work/core2-64-wrs-linux/usleep/1.0-r0

configure.sstate deploy-rpms image packages-split pkgdata-pdata-input recipe-sysroot sstate-install-deploy_source_date_epoch usleep usleep.spec

COPYING deploy-source-date-epoch license-destdir patches pkgdata-sysroot recipe-sysroot-native sstate-install-populate_lic usleep.1

debugsources.list GPLv2.patch package pkgdata pseudo source-date-epoch temp usleep.c


Ah it has the source in WORKDIR, that seem odd but it's a simple recipe with the source
provided in the recipe:
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-core/usleep/usleep_1.0.bb?h=master

# Let's clean it:

$ bitbake -c rm_work usleep


$ ls -a tmp-glibc/work/core2-64-wrs-linux/usleep/1.0-r0

. .. .pc temp


$ bitbake -c patch usleep
$ echo $?
0

so that works and it seems there's no harm done.
--
# Randy MacLeod
# Wind River Linux


Re: Software Port Rpi3 -> iMX8

Randy MacLeod
 

On 2021-12-18 4:12 p.m., rashmi pisal via lists.yoctoproject.org wrote:
Hi Team,
Hi,

Welcome to the Yocto community.

I am working on a project facing a supply chain issue and need to move away from the rasperrypi3 module.
We are planning to use an IMX8 processor and wondering if I can modify the existing embedded Linux distribution created using YoctoProject to accommodate the new hardware changes, or I will have to make the latest image from scratch?
Right now, I am entirely lost, so any help is greatly appreciated.

It's hard to say without more information.
Can you tell us what layers and versions from the Yocto Project you are using?
Can you share or describe the local changes that you have made?

Certainly many layers are largely independent of the BSP so unless someone
in your organization has broken the levels of abstraction in many places,
it may not be so much work to migrate to an iMX8 board.


../Randy

Thanks,

--
# Randy MacLeod
# Wind River Linux


Re: Questions about shared sstate, dl_dir, buildhistory_dir

Richard Purdie
 

On Fri, 2021-12-17 at 09:42 -0800, Rusty Howell wrote:
Related to this topic of setting up a cluster of build nodes: 
https://lists.yoctoproject.org/g/yocto/topic/85515144

We have multiple build nodes right now configured to use a shared SSTATE cache
and shared PR server. We are building four MACHINE types. Build jobs are
randomly assigned, so any node can build the image for any MACHINE type.
In order to maintain a proper package feed for long term, we are backing up the
PR server database regularly. 

I still have these questions though.

* Do we need to also backup anything in BUILDHISTORY_DIR?

* Do we need to share anything in BUILDHISTORY_DIR?
Buildhistory has an "auto commit" mode where it can commit each build into the
history repository.

On the autobuilder there is some support code which before starting a build,
checks out a git repo and then at the end of building the appropriate targets,
pushes it back. It understands master always moves forward and master-next is
rebased. You can see some of it here:

https://git.yoctoproject.org/yocto-autobuilder-helper/tree/scripts/utils.py#n200

configuration is in config.json in that repo. You don't have to do this, it just
lets you track changes historically. I wish we made better use of that data.

If ends up here:

https://git.yoctoproject.org/poky-buildhistory/

* I often see people recommend using SSTATE_MIRROR.  What are the pros/cons to
using a SSTATE_MIRROR vs all nodes using a shared SSTATE_DIR?
SSTATE_MIRROR works well as a remote you pull from but you usually can't write
to them. SSTATE_DIR you can write to.



* Can/should DL_DIR be shared across build nodes?
Yes and yes. We do on the autobuilder.

* Should the nodes use a remote/shared BBSERVER?
No, BBSERVER is not useful in the context of a cluster. The "Server" in bitbake
is the thing running the build and you want that where the work is being done.

* I have also seen someone mention a "hash equivalence server" that can also
accelerate builds. Is that an old term for the PR_server?
No, it is a new service and you should look it up. If the output of a task is
found to be the same, it allows build artefacts that were built previously to be
reused instead of creating new ones.

* BB_SIGNATURE_HANDLER - I see there are some options to tweak in
BB_SIGNATIRE_WHITELIST.  Are there common tweaks to these vars are generally
beneficial?  I image the defaults are the best.
I'd stick to the defaults. We'd change them if there were good things to do
here, unless you want to make interesting experiments.

Cheers,

Richard


Software Port

rashmi pisal
 

Hi Team,

 
I am working on a project facing a supply chain issue and need to move away from the rasperrypi3 module.

 

 

We are planning to use an IMX8 processor and wondering if I can modify the existing embedded Linux distribution created using YoctoProject to accommodate the new hardware changes, or I will have to make the latest image from scratch?

 

Right now, I am entirely lost, so any help is greatly appreciated.

 

 

Thanks,


Software Post

rashmi pisal
 

Hi Team,

 
I am working on a project facing a supply chain issue and need to move away from the rasperrypi3 module.

 

 

We are planning to use an IMX8 processor and wondering if I can modify the existing embedded Linux distribution created using YoctoProject to accommodate the new hardware changes, or I will have to make the latest image from scratch?

 

Right now, I am entirely lost, so any help is greatly appreciated.

 

 

Thanks,


Re: [meta-rockchip][PATCH v3] trusted-firmware-a: replace baudrate with the one specified in machine conf

Trevor Woerner
 

On Fri 2021-12-17 @ 12:30:47 PM, Quentin Schulz wrote:
From: Quentin Schulz <quentin.schulz@...>

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+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 10 +++++-
2 files changed, 9 insertions(+), 37 deletions(-)
delete mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
Applied to meta-rockchip master. Thanks!


Re: [meta-rockchip][PATCH v3] trusted-firmware-a: replace baudrate with the one specified in machine conf

Khem Raj
 

On Fri, Dec 17, 2021 at 3:31 AM Quentin Schulz <foss+yocto@...> wrote:

From: Quentin Schulz <quentin.schulz@...>

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+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 10 +++++-
2 files changed, 9 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://developer.trustedfirmware.org/T762
-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 513cea1..31024ce 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.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 \
@@ -19,3 +18,12 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_baudrate() {
+ :
+}
+
+fixup_baudrate:rk3399() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_baudrate"
lgtm. Thanks

--
2.33.1


Questions about shared sstate, dl_dir, buildhistory_dir

Rusty Howell
 

Related to this topic of setting up a cluster of build nodes:  https://lists.yoctoproject.org/g/yocto/topic/85515144

We have multiple build nodes right now configured to use a shared SSTATE cache and shared PR server. We are building four MACHINE types. Build jobs are randomly assigned, so any node can build the image for any MACHINE type.
In order to maintain a proper package feed for long term, we are backing up the PR server database regularly. 

I still have these questions though.

* Do we need to also backup anything in BUILDHISTORY_DIR?

* Do we need to share anything in BUILDHISTORY_DIR?

* I often see people recommend using SSTATE_MIRROR.  What are the pros/cons to using a SSTATE_MIRROR vs all nodes using a shared SSTATE_DIR?

* Can/should DL_DIR be shared across build nodes?

* Should the nodes use a remote/shared BBSERVER?

* I have also seen someone mention a "hash equivalence server" that can also accelerate builds. Is that an old term for the PR_server?

* BB_SIGNATURE_HANDLER - I see there are some options to tweak in BB_SIGNATIRE_WHITELIST.  Are there common tweaks to these vars are generally beneficial?  I image the defaults are the best.

Thanks for your time.
Rusty


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)

Teoh, Jay Shen
 

Hello everyone,

This is the full report for yocto-3.5_M1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults

======= Summary ========
No high milestone defects.

one issue found

Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case failure

======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Sunday, 12 December, 2021 6:49 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.5_M1.rc2)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.5_M1.rc2


Build hash information:

bitbake: 1ecc1d9424877df89fcda2f23c306998998a65ff
meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
meta-arm: d446f7f80bf61e9cf05843e8ef4bc5473f936118
meta-aws: 8893e0cd4c0981eeda941eaa9ad2eb9359670502
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: aa8482af7b286f8fe8f7aae648938d4ebf0283c5
meta-mingw: 992fb40bdbfe9fe60f815aac46e04c58963918b5
meta-openembedded: ba6a16cdca661b2d5251df243dc19bda0e8db651
oecore: 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b
poky: 65c94ca3196e5ef3344a469fea8e30444f2e967a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







[meta-rockchip][PATCH v3] trusted-firmware-a: replace baudrate with the one specified in machine conf

Quentin Schulz
 

From: Quentin Schulz <quentin.schulz@...>

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+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
.../files/serial-console-baudrate.patch | 36 -------------------
.../trusted-firmware-a_%.bbappend | 10 +++++-
2 files changed, 9 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://developer.trustedfirmware.org/T762
-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 513cea1..31024ce 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -7,7 +7,6 @@ COMPATIBLE_MACHINE:append:rk3328 = "|rk3328"

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"
SRC_URI += "\
- file://serial-console-baudrate.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 \
@@ -19,3 +18,12 @@ SRC_URI += "\
# this needs fixing until then use gcc
TOOLCHAIN:rk3399 = "gcc"

+fixup_baudrate() {
+ :
+}
+
+fixup_baudrate:rk3399() {
+ sed -i "s/#define RK3399_BAUDRATE\s\+.*/#define RK3399_BAUDRATE ${RK_CONSOLE_BAUD}/" ${S}/plat/rockchip/rk3399/rk3399_def.h
+}
+
+do_patch[postfuncs] += "fixup_baudrate"
--
2.33.1


Re: do_rootfs: Taskhash mismatch due to BUILDNAME containing automatic date

Konrad Weihmann <kweihmann@...>
 

Hi,

according to my understanding BUILDNAME should not be used like that since f85f1ef24e59c0c058f96f0dfa82e50969fd580b in bitbake.

The variable should contain only references to other automatically determined variables (default = ds.setVar("BUILDNAME", "${DATE}${TIME}")

Judging from that if you would set 'BUILDNAME = "my_Image_0.0.1_${DATE}"' the warning likely will go away.

Please keep in mind that these inline functions (esp in early stages of the parsing process, like machine.conf) are not expanded.
Which explains the seen behavior.

On 17.12.21 11:35, Jesper.Ahman@... wrote:
Hello,
In my machine config, I have set buildname using:
BUILDNAME = "my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}"
In order to get a timestamp (date) in each build name.
Although, this causes some error messages when building the rootfs:
/ERROR: When reparsing /home/buildserver/fsl/sources/meta-freescale-distro/recipes-fsl/images/fsl-image-multimedia-full.bb:do_rootfs, the basehash value changed from 6b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e to cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed. The metadata is not deterministic and this needs to be fixed./
/ERROR: The following commands may help:/
/ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Snone/
/ERROR: Then:/
/ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Sprintdiff/
I ran the suggested commands and found the following:
/Task fsl-image-multimedia-full:do_rootfs couldn't be used from the cache because:/
/  We need hash 066153e1a8d8ad0e8025f6409dbac96c277e6300541356b077f1823f195ef19c, closest matching task was 040147cd35d17688668c7435633fd8ff25d8cf7425a93d35efdd7799a47bdc85/
/  basehash changed from cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed to 61b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e/
/  Variable BUILDNAME value changed from 'my_Image_0.0.1_20211214' to 'my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}'
/
So when /${@time.strftime('%Y%m%d',time.gmtime())}' /is converted to the actual date, it messes with Yocto.
The build succeeds anyway, but it's quite annoying having a load of error messages on each build.
How can these errors be avoided?
I found in the Yocto FAQ:
/This is often something time-related e.g. a timestamp which is calculated every time an expression is expanded. The solution is to ensure the value is calculated once per build and then the expression expands to the same value for the duration of the build.
/Which sounds somewhat right, but the issue here is not that the value is changed due to recalculation (the date rarely changes during a build) but the expansion of the expression itself (from Pyhton code into its result).
Running Yocto Dunfell.


do_rootfs: Taskhash mismatch due to BUILDNAME containing automatic date

Jesper Åhman
 

Hello,

In my machine config, I have set buildname using:
BUILDNAME = "my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}"
In order to get a timestamp (date) in each build name.

Although, this causes some error messages when building the rootfs:
ERROR: When reparsing /home/buildserver/fsl/sources/meta-freescale-distro/recipes-fsl/images/fsl-image-multimedia-full.bb:do_rootfs, the basehash value changed from 6b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e to cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Snone
ERROR: Then:
ERROR: $ bitbake fsl-image-multimedia-full -cdo_rootfs -Sprintdiff

I ran the suggested commands and found the following:
Task fsl-image-multimedia-full:do_rootfs couldn't be used from the cache because:
  We need hash 066153e1a8d8ad0e8025f6409dbac96c277e6300541356b077f1823f195ef19c, closest matching task was 040147cd35d17688668c7435633fd8ff25d8cf7425a93d35efdd7799a47bdc85
  basehash changed from cbd5de79b73a1bc4dd02024bafd1e5c29d4baa8f43617c37eb8f5fc57ed738ed to 61b1226a9fe10f08dd4f2fe634944a53cf03f7699a8553a9cc346c097027b24e
  Variable BUILDNAME value changed from 'my_Image_0.0.1_20211214' to 'my_Image_0.0.1_${@time.strftime('%Y%m%d',time.gmtime())}'

So when ${@time.strftime('%Y%m%d',time.gmtime())}' is converted to the actual date, it messes with Yocto.
The build succeeds anyway, but it's quite annoying having a load of error messages on each build.

How can these errors be avoided?

I found in the Yocto FAQ:
This is often something time-related e.g. a timestamp which is calculated every time an expression is expanded. The solution is to ensure the value is calculated once per build and then the expression expands to the same value for the duration of the build.

Which sounds somewhat right, but the issue here is not that the value is changed due to recalculation (the date rarely changes during a build) but the expansion of the expression itself (from Pyhton code into its result).

Running Yocto Dunfell.


Re: [meta-security][PATCH] dm-verity-img.bbclass: Fix wrong override syntax for CONVERSION_DEPENDS

Kristian Klausen <kristian@...>
 

On Fri, Dec 17, 2021 at 10:06:06 +0000, Jose Quaresma wrote:
Kristian Klausen via lists.yoctoproject.org <kristian=
klausen.dk@...> escreveu no dia sexta, 17/12/2021 à(s)
09:55:

CONVERSION_DEPENDS hasn't been converted to the new syntax.

Fixes: a23ceef ("dm-verity-img.bbclass: more overided fixups")

Signed-off-by: Kristian Klausen <kristian@...>
---
This should also be backported to honister.

classes/dm-verity-img.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index 0b6d053..93f667d 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -67,7 +67,7 @@ VERITY_TYPES = "ext2.verity ext3.verity ext4.verity
btrfs.verity"
IMAGE_TYPES += "${VERITY_TYPES}"
CONVERSIONTYPES += "verity"
CONVERSION_CMD:verity = "verity_setup ${type}"
-CONVERSION_DEPENDS:verity = "cryptsetup-native"
+CONVERSION_DEPENDS_verity = "cryptsetup-native"
This syntax don't work anymore with oe-core master branch
(resend as I forgot to CC the list)

Are you sure? This was tested with the honister branch, but the code is
the same[1].

[1] https://git.openembedded.org/openembedded-core/tree/meta/classes/image_types.bbclass#n40



python __anonymous() {
verity_image = d.getVar('DM_VERITY_IMAGE')
--
2.34.1




--
Best regards,

José Quaresma



Re: [meta-security][PATCH] dm-verity-img.bbclass: Fix wrong override syntax for CONVERSION_DEPENDS

Jose Quaresma
 



Kristian Klausen via lists.yoctoproject.org <kristian=klausen.dk@...> escreveu no dia sexta, 17/12/2021 à(s) 09:55:
CONVERSION_DEPENDS hasn't been converted to the new syntax.

Fixes: a23ceef ("dm-verity-img.bbclass: more overided fixups")

Signed-off-by: Kristian Klausen <kristian@...>
---
This should also be backported to honister.

 classes/dm-verity-img.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/dm-verity-img.bbclass b/classes/dm-verity-img.bbclass
index 0b6d053..93f667d 100644
--- a/classes/dm-verity-img.bbclass
+++ b/classes/dm-verity-img.bbclass
@@ -67,7 +67,7 @@ VERITY_TYPES = "ext2.verity ext3.verity ext4.verity btrfs.verity"
 IMAGE_TYPES += "${VERITY_TYPES}"
 CONVERSIONTYPES += "verity"
 CONVERSION_CMD:verity = "verity_setup ${type}"
-CONVERSION_DEPENDS:verity = "cryptsetup-native"
+CONVERSION_DEPENDS_verity = "cryptsetup-native"

This syntax don't work anymore with oe-core master branch


 python __anonymous() {
     verity_image = d.getVar('DM_VERITY_IMAGE')
--
2.34.1






--
Best regards,

José Quaresma

2181 - 2200 of 57761