Date   

[meta-mingw] [PATCH] libidn2: package all files

Samuli Piippo
 

Include .def files to the -dev package to fix QA Issue: nativesdk-libidn2:
Files/directories were installed but not shipped in any package.

Signed-off-by: Samuli Piippo <samuli.piippo@...>
---
recipes-extended/libidn/libidn2_%.bbappend | 1 +
1 file changed, 1 insertion(+)
create mode 100644 recipes-extended/libidn/libidn2_%.bbappend

diff --git a/recipes-extended/libidn/libidn2_%.bbappend b/recipes-extended/libidn/libidn2_%.bbappend
new file mode 100644
index 0000000..275886d
--- /dev/null
+++ b/recipes-extended/libidn/libidn2_%.bbappend
@@ -0,0 +1 @@
+FILES_${PN}-dev_append_mingw32 = " ${libdir}/*.def"
--
2.25.1


Launching script at the very end of the image process

Cardaillac, Yann
 

Hi yall,

 

I’m switching from buildroot to yocto and trying to figure out how to do the equivalent of a POST_BUILD_SCRIPT.

 

Indeed I want to format the images built in a specific format for latter use and CI needs.

 

I’ve made a recipe (.inc) that I’m able to access directly doing so:

 

bitbake ycn-image -c release_ycn

 

To give a bit more context here’s how I’ve made it :

 

File ycn-image.bb:

 

SUMMARY = "Ycn image"

 

require recipes-core/images/core-image-base.bb

inherit package-list

 

require ycn-release.inc

 

File ycn-release.inc:

 

do_release_ycn() {

}

addtask release_ycn after do_image_complete after do_deploy_kernelmodules

 

I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success since it wasn’t running at the proper moment.

 

If you happen to have any leads on the subject please don’t hesitate to share!

 

Best regards,

 

Yann


[meta-gplv2] [PATCH] coreutils_6.9.bb: Fix build with glibc 2.34

Khem Raj
 

Signed-off-by: Khem Raj <raj.khem@...>
---
...-includes-for-glibc-2.34-portability.patch | 39 +++++++++++++++++++
recipes-core/coreutils/coreutils_6.9.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644 recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch

diff --git a/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch b/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
new file mode 100644
index 0000000..0d9b5e2
--- /dev/null
+++ b/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
@@ -0,0 +1,39 @@
+From e241a55767c4eaac7d14c412d880037cb6d2ee33 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 29 Jun 2021 22:43:16 -0700
+Subject: [PATCH] sort.c: Reorder includes for glibc 2.34 portability
+
+With glibc 2.34 config.h will include stdlib.h and that would disable
+sys/wait.h to include needed definitions from bits/waitflags.h since
+_STDLIB_H would have been defined already and sys/wait.h would think
+these paths are included already, this is fixed with newer gnulib and
+configure so this is to get this old version to compile with latest
+glibc headers
+
+Upstream-Status: Inappropriate [OE-Specific]
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ src/sort.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/sort.c b/src/sort.c
+index 58ca66a..48b22c8 100644
+--- a/src/sort.c
++++ b/src/sort.c
+@@ -21,11 +21,11 @@
+
+ Ørn E. Hansen added NLS support in 1997. */
+
++#include <sys/types.h>
++#include <sys/wait.h>
+ #include <config.h>
+
+ #include <getopt.h>
+-#include <sys/types.h>
+-#include <sys/wait.h>
+ #include <signal.h>
+ #include "system.h"
+ #include "argmatch.h"
+--
+2.32.0
+
diff --git a/recipes-core/coreutils/coreutils_6.9.bb b/recipes-core/coreutils/coreutils_6.9.bb
index 42b4f3c..69e5489 100644
--- a/recipes-core/coreutils/coreutils_6.9.bb
+++ b/recipes-core/coreutils/coreutils_6.9.bb
@@ -27,6 +27,7 @@ SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.bz2 \
file://no-man.patch \
file://build-don-t-need-charset.alias-when-building-for-mus.patch \
file://no-su.patch \
+ file://0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch \
"

SRC_URI[md5sum] = "c9607d8495f16e98906e7ed2d9751a06"
--
2.32.0


Re: Problem with YOCTO Dunfell and host Fedora 33

Zoran
 

Hello to everyone,

Mguentner fixed the cmake issue:
https://github.com/mguentner/cannelloni/issues/35

With this patch:
https://github.com/mguentner/cannelloni/commit/125a7c72e4bcbbf580aeb6ee03e25ed0540be217

So I also reinstated the old cannelloni recipe with:
https://github.com/ZoranStojsavljevic/meta-socketcan/commit/b79e35425b72ba1caf90404a953235a43202e16f

Zee
_______

On Fri, May 21, 2021 at 7:55 AM Zoran via lists.yoctoproject.org
<zoran.stojsavljevic=gmail.com@...> wrote:

Hello Joel,

Thank you for the tips. Really helpful, appreciated very much.

I spent some time this morning investigating this issue, and to find
the culprit.

Here are my findings, which resulted in a cannelloni.bb recipe change
(according to what you wrote).

The fix submitted is in recipe:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb

The last cannelloni version which works is:
https://github.com/mguentner/cannelloni/commit/0bd7e27db35bdef361226882ae04205504f7b2f4

The culprit introducing the cmake errors is this one:
https://github.com/mguentner/cannelloni/commit/d01dd1dc745914d129b1f4da2074e282253246af

And, the issue recorded with Maximilian Guentner's cannelloni repo:
https://github.com/mguentner/cannelloni/issues/35

Thank you again,
Zoran
_______

On Thu, May 20, 2021 at 4:48 PM Joel Winarske <joel.winarske@...> wrote:

Hi Zoran,

Your cannelloni recipe is set to autorev, meaning it's not locked to a commit. So when something changes upstream you have to manage it.

Chances are Canelloni introduced a CMake change which is overwriting (opposed to appending) one or more variables required for cross compiling. Perhaps try to cross compile (not a host build) Canelloni by itself without Yocto involved. Once that's sorted, then reintroduce yocto.


Joel


On Thu, May 20, 2021, 6:58 AM Zoran <zoran.stojsavljevic@...> wrote:

Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______




[meta-openssl102-fips][PATCH] openssh: refresh patches for 8.6p1

Yi Zhao
 

Refresh patches:
0001-openssh-8.6p1-fips.patch
0001-conditional-enable-fips-mode.patch

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../0001-conditional-enable-fips-mode.patch | 38 +++++++------
...ps.patch => 0001-openssh-8.6p1-fips.patch} | 55 ++++++++++---------
recipes-connectivity/openssh/openssh_fips.inc | 2 +-
3 files changed, 50 insertions(+), 45 deletions(-)
rename recipes-connectivity/openssh/openssh/{0001-openssh-8.4p1-fips.patch => 0001-openssh-8.6p1-fips.patch} (92%)

diff --git a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
index 9fd19c0..9bec7d7 100644
--- a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
+++ b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -1,4 +1,4 @@
-From 48888de317391522186c6ae24a8d6d7d7add2673 Mon Sep 17 00:00:00 2001
+From 1696484c2a06e2ec095d748d2155eb8206dd850b Mon Sep 17 00:00:00 2001
From: Hongxu Jia <hongxu.jia@...>
Date: Sat, 21 Dec 2019 13:03:23 +0800
Subject: [PATCH] conditional enable fips mode
@@ -14,11 +14,12 @@ The ssh_malloc_init function is removed in openssh 8.1p1, we need to
insert ssh_enable_fips_mode function to main function for all
applications.

+Rebase to 8.6p1
Signed-off-by: Yi Zhao <yi.zhao@...>
---
sftp-server-main.c | 1 +
sftp-server.c | 1 +
- sftp.c | 1 +
+ sftp.c | 2 ++
ssh-add.c | 1 +
ssh-agent.c | 1 +
ssh-keygen.c | 1 +
@@ -29,7 +30,7 @@ Signed-off-by: Yi Zhao <yi.zhao@...>
sshd.c | 1 +
xmalloc.c | 20 ++++++++++++++++++++
xmalloc.h | 1 +
- 13 files changed, 32 insertions(+)
+ 13 files changed, 33 insertions(+)

diff --git a/sftp-server-main.c b/sftp-server-main.c
index 06566d3..a10566d 100644
@@ -44,10 +45,10 @@ index 06566d3..a10566d 100644
sanitise_stdfd();

diff --git a/sftp-server.c b/sftp-server.c
-index 7300900..42da9d7 100644
+index 838f048..8a8d87b 100644
--- a/sftp-server.c
+++ b/sftp-server.c
-@@ -1616,6 +1616,7 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
+@@ -1656,6 +1656,7 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
extern char *optarg;
extern char *__progname;

@@ -56,19 +57,20 @@ index 7300900..42da9d7 100644
log_init(__progname, log_level, log_facility, log_stderr);

diff --git a/sftp.c b/sftp.c
-index fb3c08d..85b9b67 100644
+index 3f46c55..e9c8f1d 100644
--- a/sftp.c
+++ b/sftp.c
-@@ -2345,6 +2345,7 @@ main(int argc, char **argv)
- size_t num_requests = DEFAULT_NUM_REQUESTS;
+@@ -2342,6 +2342,8 @@ main(int argc, char **argv)
+ size_t num_requests = 0;
long long limit_kbps = 0;

+ ssh_enable_fips_mode();
++
/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
sanitise_stdfd();
msetlocale();
diff --git a/ssh-add.c b/ssh-add.c
-index 7edb9f9..c75f85b 100644
+index 92192fc..4ed14cd 100644
--- a/ssh-add.c
+++ b/ssh-add.c
@@ -667,6 +667,7 @@ main(int argc, char **argv)
@@ -80,7 +82,7 @@ index 7edb9f9..c75f85b 100644
sanitise_stdfd();

diff --git a/ssh-agent.c b/ssh-agent.c
-index 58fe6dd..9018a7c 100644
+index 48a47d4..8a0d7a2 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -1388,6 +1388,7 @@ main(int ac, char **av)
@@ -92,7 +94,7 @@ index 58fe6dd..9018a7c 100644
sanitise_stdfd();

diff --git a/ssh-keygen.c b/ssh-keygen.c
-index 6451584..246caa1 100644
+index fc73943..cdb45a9 100644
--- a/ssh-keygen.c
+++ b/ssh-keygen.c
@@ -3153,6 +3153,7 @@ main(int argc, char **argv)
@@ -140,7 +142,7 @@ index a9a6fe3..3c76f70 100644
seed_rng();
TAILQ_INIT(&pkcs11_keylist);
diff --git a/ssh.c b/ssh.c
-index 729d87a..ab78b53 100644
+index a6e7642..8f91534 100644
--- a/ssh.c
+++ b/ssh.c
@@ -650,6 +650,7 @@ main(int ac, char **av)
@@ -152,10 +154,10 @@ index 729d87a..ab78b53 100644
sanitise_stdfd();

diff --git a/sshd.c b/sshd.c
-index fee4703..07faf7b 100644
+index b2ab001..8112d2c 100644
--- a/sshd.c
+++ b/sshd.c
-@@ -1534,6 +1534,7 @@ main(int ac, char **av)
+@@ -1535,6 +1535,7 @@ main(int ac, char **av)
Authctxt *authctxt;
struct connection_info *connection_info = NULL;

@@ -199,13 +201,13 @@ index b48d33b..456a063 100644
+ }
+}
diff --git a/xmalloc.h b/xmalloc.h
-index abaf7ad..b3b1c8c 100644
+index a6b8d23..18fe756 100644
--- a/xmalloc.h
+++ b/xmalloc.h
-@@ -26,3 +26,4 @@ int xasprintf(char **, const char *, ...)
- __attribute__((__nonnull__ (2)));
+@@ -25,3 +25,4 @@ int xasprintf(char **, const char *, ...)
+ __attribute__((__format__ (printf, 2, 3))) __attribute__((__nonnull__ (2)));
int xvasprintf(char **, const char *, va_list)
- __attribute__((__nonnull__ (2)));
+ __attribute__((__nonnull__ (2)));
+void ssh_enable_fips_mode(void);
--
2.17.1
diff --git a/recipes-connectivity/openssh/openssh/0001-openssh-8.4p1-fips.patch b/recipes-connectivity/openssh/openssh/0001-openssh-8.6p1-fips.patch
similarity index 92%
rename from recipes-connectivity/openssh/openssh/0001-openssh-8.4p1-fips.patch
rename to recipes-connectivity/openssh/openssh/0001-openssh-8.6p1-fips.patch
index 10687ff..ff1b5dc 100644
--- a/recipes-connectivity/openssh/openssh/0001-openssh-8.4p1-fips.patch
+++ b/recipes-connectivity/openssh/openssh/0001-openssh-8.6p1-fips.patch
@@ -1,7 +1,7 @@
-From 0452f9dc4acf90b8d7ac6ddf6ebbe455d202ce54 Mon Sep 17 00:00:00 2001
+From 064c5cafa532166058a5cc694c4398ed2aaae8d1 Mon Sep 17 00:00:00 2001
From: Hongxu Jia <hongxu.jia@...>
Date: Sat, 21 Dec 2019 11:45:38 +0800
-Subject: [PATCH] openssh 8.4p1 fips
+Subject: [PATCH] openssh 8.6p1 fips

Port openssh-7.7p1-fips.patch from Fedora
https://src.fedoraproject.org/rpms/openssh.git
@@ -19,6 +19,9 @@ Port openssh-7.7p1-fips.patch from Fedora
https://src.fedoraproject.org/rpms/openssh.git
(commit: fbd5f1bee2e2cdc7b1b47f4604b8347d8c3ed63f)

+Signed-off-by: Yi Zhao <yi.zhao@...>
+
+Rebase to 8.6p1
Signed-off-by: Yi Zhao <yi.zhao@...>
---
Makefile.in | 14 +++++++-------
@@ -38,10 +41,10 @@ Signed-off-by: Yi Zhao <yi.zhao@...>
14 files changed, 171 insertions(+), 20 deletions(-)

diff --git a/Makefile.in b/Makefile.in
-index e3cd296..bf53fb0 100644
+index b749206..ee58570 100644
--- a/Makefile.in
+++ b/Makefile.in
-@@ -204,25 +204,25 @@ libssh.a: $(LIBSSH_OBJS)
+@@ -205,25 +205,25 @@ libssh.a: $(LIBSSH_OBJS)
$(RANLIB) $@

ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
@@ -73,7 +76,7 @@ index e3cd296..bf53fb0 100644

ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a $(P11HELPER_OBJS)
$(LD) -o $@ $(P11HELPER_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
-@@ -231,7 +231,7 @@ ssh-sk-helper$(EXEEXT): $(LIBCOMPAT) libssh.a $(SKHELPER_OBJS)
+@@ -232,7 +232,7 @@ ssh-sk-helper$(EXEEXT): $(LIBCOMPAT) libssh.a $(SKHELPER_OBJS)
$(LD) -o $@ $(SKHELPER_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS) $(LIBFIDO2)

ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHKEYSCAN_OBJS)
@@ -97,10 +100,10 @@ index 32771f2..74fac3b 100644
return (&aes_ctr);
}
diff --git a/dh.c b/dh.c
-index b5bb35e..676f893 100644
+index ce2eb47..c038961 100644
--- a/dh.c
+++ b/dh.c
-@@ -152,6 +152,12 @@ choose_dh(int min, int wantbits, int max)
+@@ -164,6 +164,12 @@ choose_dh(int min, int wantbits, int max)
int best, bestcount, which, linenum;
struct dhgroup dhg;

@@ -110,10 +113,10 @@ index b5bb35e..676f893 100644
+ return (dh_new_group_fallback(max));
+ }
+
- if ((f = fopen(_PATH_DH_MODULI, "r")) == NULL) {
+ if ((f = fopen(get_moduli_filename(), "r")) == NULL) {
logit("WARNING: could not open %s (%s), using fixed modulus",
- _PATH_DH_MODULI, strerror(errno));
-@@ -489,4 +495,38 @@ dh_estimate(int bits)
+ get_moduli_filename(), strerror(errno));
+@@ -502,4 +508,38 @@ dh_estimate(int bits)
return 8192;
}

@@ -153,7 +156,7 @@ index b5bb35e..676f893 100644
+
#endif /* WITH_OPENSSL */
diff --git a/dh.h b/dh.h
-index 5d6df62..54c7aa2 100644
+index c6326a3..e51e292 100644
--- a/dh.h
+++ b/dh.h
@@ -45,6 +45,7 @@ DH *dh_new_group_fallback(int);
@@ -163,9 +166,9 @@ index 5d6df62..54c7aa2 100644
+int dh_is_known_group(const DH *);

u_int dh_estimate(int);
-
+ void dh_set_moduli_file(const char *);
diff --git a/kex.c b/kex.c
-index 30425ab..1250f42 100644
+index 709a0ec..c4ac65f 100644
--- a/kex.c
+++ b/kex.c
@@ -165,7 +165,10 @@ kex_names_valid(const char *names)
@@ -257,7 +260,7 @@ index f03b7df..57b8779 100644
#define SSH_ALLOWED_CA_SIGALGS \
"ssh-ed25519," \
diff --git a/readconf.c b/readconf.c
-index 724974b..870a654 100644
+index 0f27652..6311bd1 100644
--- a/readconf.c
+++ b/readconf.c
@@ -2475,11 +2475,16 @@ fill_default_options(Options * options)
@@ -283,10 +286,10 @@ index 724974b..870a654 100644
do { \
if ((r = kex_assemble_names(&options->what, \
diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
-index d8dc712..c6e62e4 100644
+index 798b24b..bbc2380 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
-@@ -157,6 +157,9 @@ static const struct sock_filter preauth_insns[] = {
+@@ -160,6 +160,9 @@ static const struct sock_filter preauth_insns[] = {
#ifdef __NR_open
SC_DENY(__NR_open, EACCES),
#endif
@@ -297,7 +300,7 @@ index d8dc712..c6e62e4 100644
SC_DENY(__NR_openat, EACCES),
#endif
diff --git a/servconf.c b/servconf.c
-index 9695583..98f6303 100644
+index 4d1910f..4502fef 100644
--- a/servconf.c
+++ b/servconf.c
@@ -218,11 +218,16 @@ assemble_algorithms(ServerOptions *o)
@@ -323,7 +326,7 @@ index 9695583..98f6303 100644
do { \
if ((r = kex_assemble_names(&o->what, defaults, all)) != 0) \
diff --git a/ssh-keygen.c b/ssh-keygen.c
-index cfb5f11..6451584 100644
+index 027c6db..fc73943 100644
--- a/ssh-keygen.c
+++ b/ssh-keygen.c
@@ -205,6 +205,12 @@ type_bits_valid(int type, const char *name, u_int32_t *bitsp)
@@ -359,7 +362,7 @@ index cfb5f11..6451584 100644
error("Could not save your private key in %s: %s",
prv_tmp, strerror(errno));
diff --git a/ssh.c b/ssh.c
-index 53330da..729d87a 100644
+index 35b6b51..a6e7642 100644
--- a/ssh.c
+++ b/ssh.c
@@ -77,6 +77,8 @@
@@ -400,7 +403,7 @@ index 53330da..729d87a 100644
if (options.sk_provider != NULL && *options.sk_provider == '$' &&
strlen(options.sk_provider) > 1) {
diff --git a/sshd.c b/sshd.c
-index eff4778..fee4703 100644
+index 8918eb2..b2ab001 100644
--- a/sshd.c
+++ b/sshd.c
@@ -66,6 +66,7 @@
@@ -420,7 +423,7 @@ index eff4778..fee4703 100644
#include "openbsd-compat/openssl-compat.h"
#endif

-@@ -1536,6 +1539,18 @@ main(int ac, char **av)
+@@ -1537,6 +1540,18 @@ main(int ac, char **av)
#endif
__progname = ssh_get_progname(av[0]);

@@ -439,7 +442,7 @@ index eff4778..fee4703 100644
/* Save argv. Duplicate so setproctitle emulation doesn't clobber it */
saved_argc = ac;
rexec_argc = ac;
-@@ -2017,6 +2032,10 @@ main(int ac, char **av)
+@@ -2023,6 +2038,10 @@ main(int ac, char **av)
/* Reinitialize the log (because of the fork above). */
log_init(__progname, options.log_level, options.log_facility, log_stderr);

@@ -447,11 +450,11 @@ index eff4778..fee4703 100644
+ logit("FIPS mode initialized");
+ }
+
- /* Chdir to the root directory so that the current disk can be
- unmounted if desired. */
- if (chdir("/") == -1)
+ /*
+ * Chdir to the root directory so that the current disk can be
+ * unmounted if desired.
diff --git a/sshkey.c b/sshkey.c
-index b25c59a..8fcfe22 100644
+index e92709d..5bd4fa9 100644
--- a/sshkey.c
+++ b/sshkey.c
@@ -34,6 +34,7 @@
diff --git a/recipes-connectivity/openssh/openssh_fips.inc b/recipes-connectivity/openssh/openssh_fips.inc
index 194a6f4..efba8db 100644
--- a/recipes-connectivity/openssh/openssh_fips.inc
+++ b/recipes-connectivity/openssh/openssh_fips.inc
@@ -6,7 +6,7 @@ DEPENDS += " \
RRECOMMENDS_${PN}-sshd_remove = "rng-tools"

SRC_URI += " \
- file://0001-openssh-8.4p1-fips.patch \
+ file://0001-openssh-8.6p1-fips.patch \
file://0001-conditional-enable-fips-mode.patch \
file://openssh-6.6p1-ctr-cavstest.patch \
file://openssh-6.7p1-kdf-cavs.patch \
--
2.25.1


Yocto Technical Team Minutes, Engineering Sync, for June 29 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for June 29 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Steve Sakoman, Joshua Watt, Jon Mason, Tony
Tascioglu, Richard Purdie, Scott Murray, Armin Kuster, Paul Barker, Tim
Orling, Alejandro H, Bruce Ashfield, Randy MacLeod, Denys Dmytriyenko

== notes ==
- 3.1.9 (dunfell) through QA awaiting release approval, no blockers
- 3.4 m1 (honister) released
- identified an RCU stall hang that’s been causing some of our AB-INT issues. closed a couple of AB-INT bugs as a result, but found some more
- prserv rewrite using asyncio is stuck on AB hangs when tested on larger scale
- ARM-specific ltp hang issue (bug 14460, https://bugzilla.yoctoproject.org/show_bug.cgi?id=14460)
- multiconfig needs simpler test cases
- about 50% of AB issues are ptest-related

== general ==
RP: the RCU fix is awesome, significantly fixed AB-INT issues


PaulB: (summary) prserv code updated to asycio, it works for me on my home
machine, but then we see failures when that code is run on the AB. bitbake
hangs, probably in the shutdown path. i have been able to reproduce it
at home. works with python3.6 but seems to fail with python3.8 (from
buildtools). we’re using asyncio and multiprocessing in various modules
and it’s unclear how well they play together. there might be issues wrt
to which system gets initiated first and when forking occurs
JPEW: buildtools tarball only?
PaulB: i need to check the matrix of what’s running native vs what’s from
the buildtools
JPEW: you’re mixing asyncio and multiprocessing?
PaulB: yes
JPEW: doesn’t that do a fork/exec itself? just to be clear: you’re
init’ing asyncio first, then forking?
PaulB: yes, that’s what other parts of the code are doing too. maybe we
should fork first, then call start_tcp_server(), then start the asyncio?
JPEW: server or client?
PaulB: server, but that’s in bitbake. there’s no clear docs on how these
things would work together
JPEW: the AB uses hash equiv server but it’s running on its own, so i’m
not sure what code paths are used
PaulB: yes, RP and i discussed that and we know that code path is not being
used
JPEW: so what happens? what are you seeing?
PaulB: it gets so far through the test suite then the bitbake server stops.
we see the keepalive messages but no other output. RP got stuff installed
and did some dumps. it looks to be prserver-export functionality related.
bitbake is finished and is run successfully, but stalled in tring to
shutdown bitbake 
RP: for example in one case we saw 57 zombie threads, the 58th is stuck in
a client side asyncio call to prserv. we tried killing the prserv, so
we’re not sure if it’s hung. then we found it waiting on the socket
(which was already closed)
PaulB: and if we sent sigint to the process, it’s not waiting
RP: we had backtrace issues which we’ve fixed. but there’s this hang. some
tests failed early with python3.8, but then an oeselftest failed. one of
the parsers was stuck in this prserv call
PaulB: we should take a look through prserv.bbclass to see what’s also done.
we could look at the args used and check for parse completed events
RP: hashserv vs prserv: hashserv is called in its own context but prserv is
called from within the parser threads
PaulB: yes, back to the issue of the init-vs-fork timing
JPEW: i would expect that’s an issue. have them init in each thread. are
they threads or processes?
RP: can’t remember. i think processes, but not sure
JPEW: that seems something to try. i would guess setting up asyncio then
forking wouldn’t work over that boundary. so have each parser thread
setup their asyncio separately
PaulB: we can run builds quite happily. the build works, but then when i try
the prserv-export that’s where it falls over
RP: in the parse thread
PaulB: it’s also queried in do_package, and that seems fine
JPEW: i think asyncio in python is an abstraction around some OS primitive,
but it’s configurable so it’s possible the one being put in the
buildtools tarballs (from wherever it’s being built) isn’t properly
setup for the actual machine on which it’s run. if we could dump the
config then we’lll probably see that it’s not using the proper backend
PaulB: i think there’s just a linux one and a windows one
JPEW: okay, maybe it’s something else
RP: i think the async init is key
PaulB: i think asyncio has a good reputation of working. on stackoverflow
there are other instances/questions of people mixing asyncio with threads
and none of them have definitive answers. so there must be caveats that
the docs don’t address. most users of asyncio are basing their entire
software on it, whereas we’re just using it in one piece and mixing it
with everything else. we have some good leads here, i’ll do a writeup
and send my latest patches (there’s a new read-only patch)
RP: JPEW if you could look at the patches, specifically the shutdown paths
that would be great. has anyone else expressed interest?
ScottM: I’ll be taking a look, as part of AGL. it’s on my short list


PaulB: there’s a patch series that Khem has forwarded, python linter fixes,
i think we need more discussion on it. ideally we should be testing this
with every commit, otherwise we end up with these massive linter patches
that mess up the repo history
JPEW: i’m a big fan of automatic linters/formatters, but it has to be
automated
TimO: me too. not sure how it’ll work for a large group like this
PaulB: having these flag days is really bad for breaking “git blame” etc
RP: bad implications for LTS. some changes i like, some i’m less keen on
PaulB: if there’s some agreement, then we could add a linter config file to
the project so we’re all using the same thing
RP: we are running the pylint stuff on the AB, i’m blanking on where the
config file is
Bruce: i usually do that
RP: we do some of this stuff in oe-core (pylint script) but was only
configured to show errors, but nobody is even looking at those now
Bruce: i looked at the github link, this is a “throw oever the wall”
patch. there isn’t going to be any updates (“i only do github pull
requests, could you please forward this to the list”)
TrevorW: do we have a checkpatch.sh script?
RP: we had something, but nobody is considering/using it
TrevorW: if the patch doesn’t pass, it doesn’t get applied. so it should
be up to the submitter to fix
PaulB: the check tools we have aren’t easy to run locally
RP: it should be. if we had something would someone maintain it?
TrevorW: i tried a long time ago to create such a tool but there are
significant differences between (for example) the formatting between YP
and OE so how can a tool be created?
RP: yes there are some conflicts, but there is also a lot of agreement, so
let’s focus on the agreed-upon things first. i think the only issue is
tabs vs spaces
TrevorW: i think there was also an ordering issue
RP: yes, but ordering is not irrelevant. changing the order can change the
behaviour, so we can’t enforce ordering
Armin: there is an ordering styleguide
TimO: some linters are too aggressive


RP: JPEW: how did the SBOM plugfest go?
JPEW: it went well. gave us an idea of how compatible we are. i don’t think
we’re too far off. i think there’s another one coming up. i think
they’re going to be a plugfest every 3 months or so until momentum goes
down. i’ll go to the next one. i have some patches, we are compatible
but there are some things we can change. it was interesting to see the
issues of the community at large. but we’re lucky because we have all
the data (whereas other projects don’t, necessarily) i believe one of
our outstanding issues is that license strings need a sync, but that’s
for another time. i think our mappings might be bad.
RP: i’d be interested in a list of the ones that aren’t valid
JPEW: i can track that down


RP: i liked the compression patch series, it failed in testing but i think a
small tweak will fix it


TrevorW: tomorrow is the OEHH
https://www.openembedded.org/wiki/Happy_Hours


Bruce: we’re starting to shape up for -m2. 5.13 kernels added. 5.4 dropped
from master but will send rev updates for dunfell for 5.4
RP: so just as we got 5.10 working, we’ll drop it
Bruce: we’ve been testing with -dev a lot (ARM64 needs awk). i think we’ll
add 5.13, then let all 3 sit there for a while, then drop 5.10. 5.13 has
been tested a lot more than most


TrevorW: has there been a resolution wrt to the new operator discussion?
RP: no. i think there are more invasive things that need to be done with some
existing operators.
TrevorW: so the new operator is a go? it’s going in?
RP: not sure yet, more experiments needed
ScottM: at the end of the day we’re talking about 1 person’s issue with 1
BSP. is this a generic issue to warrant such a move?
RP: i think many people have hit it, but worked around it. so i think there is
an architectural problem that needs a wider discussion
ScottM: i think there’s more value in the changes to += and _append than
adding a new operator
RP: i think we need both. that’s why i’ve deferred. i need to do more
experiments
ScottM: could we do a flag day, or a carry-over for say 1 year. do we have a
process for that
RP: we don’t have a process, the TSC would have to come up with a plan for
it. it would be specific for this case


Yocto Project Status WW26`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.1.9 has been through QA and is awaiting release approval, no blocking issues were identified.
  • YP 3.4 M1 was released.
  • Significantly for the project, we have now identified a kernel hang caused from RCU stalls which has been plaguing our autobuilder testing for months. The issue is still open in upstream mainline kernels but there is a patch queued in the rcu tree for it. Since applying this patch to linux-yocto, our builds have been noticeably greener and more stable. We have closed out many of the related AB-INT bugs and will be creating new ones for any remaining issues as they occur since it is hard to tell some other bugs apart from the RCU issue.
  • The prserv rewrite to use asyncio is stuck on autobuilder hangs when testing at larger scale. We’d welcome help from anyone with more details asyncio knowledge/experience as it is looking like the new code isn’t entirely stable in python 3.5/3.6 and may have “at exit” issues, as well as perhaps issues mixing async io code on the client side with multiprocessing during parsing.
  • There does still seem to be an arm specific LTP hang reading /proc/kmsg now tracked by bug 14460.
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • Intermittent autobuilder issues continue to occur, about 50% of the open issues are now ptest failures and the rest are various other races or timeouts. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 is released
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.9 is under review
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


pyqtwebengine recipe problem

Bel Hadj Salem Talel <bhstalel@...>
 

Hi All,

I want to make a recipe for python3-pyqt5 and python3-pyqtwebengine, 
the problem is that the source doe does not contain setup.py , it contains project.py and configure.py.

Is there a solution for this so that it works with setuptools and pypi ?

Thanks,
Talel


Re: Would COMPATIBLE_IMAGE make sense?

Bruce Ashfield
 

On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
<jester@...> wrote:

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
I was thinking about my issue described here [1], and discovered the
variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
use to stop recipes from being built for machines (/hosts) with which
the recipes are not compatible". And so I wondered if it would make
sense to add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers
(say `first-project-image` and `second-project-image`), and in each of
those layers I create `.bbappends` to configure some packages. Typically
`hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because
`second-project-image` is part of my bblayers.conf, then the
hostapd_%.bbappend from `second-project-image` is used and may have an
impact on `first-project-image`, which I don't want. I really want this
bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that
`first-project-image` and `second-project-image` are two different
projects, and build them from two different BUILDDIRs. The thing I don't
like here is that all the packages are therefore downloaded and built
twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
of `first-project-image`, I would set "COMPATIBLE_IMAGE =
'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
'second-project-image'". So that I could still share a BUILDDIR between
different projects.
Yocto chant #1 applies: "Recipe data is local, configuration data is
global." Means: the recipe does not see at all which image it is being
built for. So it also can't react to it - you can't check a variable
against something you do not even see.

How bad of an idea is that?
It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images,
because that actually what they mean to do: you change the ABI/API of
the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
derivatives, so its all there already. It just cannot be triggered from
the image, because, well.. see first pragraph of the answer.
I was also going to suggest distros.

And also, if the concern really is about builds reusing downloads,
etc, then by all means configure those different distro builds to
share download and sstate directories.

Bruce


Greetz

Thanks in advance,
Jonas

[1]: https://stackoverflow.com/questions/68167244/image-specific-layers
<https://stackoverflow.com/questions/68167244/image-specific-layers>





--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Would COMPATIBLE_IMAGE make sense?

Erik Boto
 

On Tue, Jun 29, 2021 at 8:41 AM Josef Holzmayr
<jester@...> wrote:

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
I was thinking about my issue described here [1], and discovered the
variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
use to stop recipes from being built for machines (/hosts) with which
the recipes are not compatible". And so I wondered if it would make
sense to add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers
(say `first-project-image` and `second-project-image`), and in each of
those layers I create `.bbappends` to configure some packages. Typically
`hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because
`second-project-image` is part of my bblayers.conf, then the
hostapd_%.bbappend from `second-project-image` is used and may have an
impact on `first-project-image`, which I don't want. I really want this
bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that
`first-project-image` and `second-project-image` are two different
projects, and build them from two different BUILDDIRs. The thing I don't
like here is that all the packages are therefore downloaded and built
twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
of `first-project-image`, I would set "COMPATIBLE_IMAGE =
'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
'second-project-image'". So that I could still share a BUILDDIR between
different projects.
Yocto chant #1 applies: "Recipe data is local, configuration data is
global." Means: the recipe does not see at all which image it is being
built for. So it also can't react to it - you can't check a variable
against something you do not even see.

How bad of an idea is that?
It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images,
because that actually what they mean to do: you change the ABI/API of
the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
derivatives, so its all there already. It just cannot be triggered from
the image, because, well.. see first pragraph of the answer.
I agree with everything Josef said, but just wanted to add that if
it's just different
configurations needed for different images it might be easier to just
put the configs
into separate packages and install the right package in the respective image.

So configuration for first-project-image goes into <somepackage>-foo, and the
config for second-project-image goes into <somepackage>-bar. Then the image
would add the correct configuration package.

This only works for the simple cases, and if you really need to change the way
a package is built the DISTRO way is better.

Erik


Greetz

Thanks in advance,
Jonas

[1]: https://stackoverflow.com/questions/68167244/image-specific-layers
<https://stackoverflow.com/questions/68167244/image-specific-layers>





Re: Yocto build isnot Booting up on board zc702 #gatesgarth #linux #yocto

Leon Woestenberg
 

Hello,


i have tried to build yocto image. And it compiled successfully without any error but when am trying to BOOT them it didnt prompt any error message
what should i do to BOOT my yocto build image on zc702 board
What is your output from the ZC702 (USB) serial console?


I had similar issue on ZCU102 and debugged my issue:

"the U-Boot not showing anything I have debugged to be an issue where
DEVICE_TREE does not propagate from the BitBake recipe into the U-Boot
build (both for upstream and Xilinx). I have reported this on
meta-xilinx but will make it a separate bug report."

I can imagine the same problem would occur on ZC702 (single-core Zynq).

I have posted a few messages with meta-xilinx in the subject on how I
had to bring Yocto to the ZCU102.

Regards,

Leon.


--
Leon Woestenberg
leon@...
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Jun 29, 2021 at 8:02 AM shoaib akhtar
<m.shoaibakhtar98@...> wrote:




i have tried to build yocto image. And it compiled successfully without any error but when am trying to BOOT them it didnt prompt any error message my BBlayer.conf is shown below

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/media/vmnrtc/Drive/poky/meta \
/media/vmnrtc/Drive/poky/meta-poky \
/media/vmnrtc/Drive/poky/meta-yocto-bsp \
/media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-bsp \
/media/vmnrtc/Drive/poky/meta-openembedded/meta-oe \
/media/vmnrtc/Drive/poky/meta-openembedded/meta-python \
/media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-standalone \
/media/vmnrtc/Drive/poky/meta-xilinx-tools \
/media/vmnrtc/Drive/poky/build/meta-networking \
"

MY files in image directories


boot.bin
boot.bin-zc702-zynq7
boot.bin-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
boot.scr
core-image-minimal-zc702-zynq7-20210629031233.qemuboot.conf
core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio
core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio.gz.u-boot
core-image-minimal-zc702-zynq7-20210629031233.rootfs.manifest
core-image-minimal-zc702-zynq7-20210629031233.rootfs.tar.gz
core-image-minimal-zc702-zynq7-20210629031233.testdata.json
core-image-minimal-zc702-zynq7.cpio
core-image-minimal-zc702-zynq7.cpio.gz.u-boot
core-image-minimal-zc702-zynq7.manifest
core-image-minimal-zc702-zynq7.qemuboot.conf
core-image-minimal-zc702-zynq7.tar.gz
core-image-minimal-zc702-zynq7.testdata.json
modules--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.tgz
modules-zc702-zynq7.tgz
pxeboot
pxelinux.cfg
u-boot.elf
u-boot.img
u-boot-xlnx-AUTOINC+bb4660c33a.elf
u-boot-xlnx-initial-env
u-boot-xlnx-initial-env-zc702-zynq7
u-boot-xlnx-initial-env-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
u-boot-zc702-zynq7.elf
u-boot-zc702-zynq7.img
u-boot-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0.img
u-boot-zynq-scr--1.0-r0.scr
uEnv.txt
uImage
uImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
uImage-zc702-zynq7.bin
zImage
zImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
zImage-zc702-zynq7.bin
zynq-zc702--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.dtb
zynq-zc702.dtb
zynq-zc702-zc702-zynq7.dtb



what should i do to BOOT my yocto build image on zc702 board




Re: Would COMPATIBLE_IMAGE make sense?

Josef Holzmayr
 

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
I was thinking about my issue described here [1], and discovered the variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use to stop recipes from being built for machines (/hosts) with which the recipes are not compatible". And so I wondered if it would make sense to add COMPATIBLE_IMAGE, for a similar purpose.
Let me explain my issue: I define different images in different layers (say `first-project-image` and `second-project-image`), and in each of those layers I create `.bbappends` to configure some packages. Typically `hostapd` is used by both images, but with a different config file.
The thing is that when I run `bitbake first-project-image`, because `second-project-image` is part of my bblayers.conf, then the hostapd_%.bbappend from `second-project-image` is used and may have an impact on `first-project-image`, which I don't want. I really want this bbappend to only affect the image `second-project-image`.
One way I can see to deal with that is to realize that `first-project-image` and `second-project-image` are two different projects, and build them from two different BUILDDIRs. The thing I don't like here is that all the packages are therefore downloaded and built twice, which seems like a loss of time and space.
That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend of `first-project-image`, I would set "COMPATIBLE_IMAGE = 'first-project-image'", and similarly for "COMPATIBLE_IMAGE = 'second-project-image'". So that I could still share a BUILDDIR between different projects.
Yocto chant #1 applies: "Recipe data is local, configuration data is global." Means: the recipe does not see at all which image it is being built for. So it also can't react to it - you can't check a variable against something you do not even see.

How bad of an idea is that?
It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images, because that actually what they mean to do: you change the ABI/API of the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO derivatives, so its all there already. It just cannot be triggered from the image, because, well.. see first pragraph of the answer.

Greetz

Thanks in advance,
Jonas
[1]: https://stackoverflow.com/questions/68167244/image-specific-layers <https://stackoverflow.com/questions/68167244/image-specific-layers>


Yocto build isnot Booting up on board zc702 #gatesgarth #linux #yocto

shoaib akhtar
 

i have tried to build yocto image.  And it compiled successfully without any error but when am trying to BOOT them it didnt prompt any error message my BBlayer.conf is shown below
 
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
  /media/vmnrtc/Drive/poky/meta \
  /media/vmnrtc/Drive/poky/meta-poky \
  /media/vmnrtc/Drive/poky/meta-yocto-bsp \
  /media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-bsp \
  /media/vmnrtc/Drive/poky/meta-openembedded/meta-oe \
  /media/vmnrtc/Drive/poky/meta-openembedded/meta-python \
  /media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-standalone \
  /media/vmnrtc/Drive/poky/meta-xilinx-tools \
  /media/vmnrtc/Drive/poky/build/meta-networking \
  "

MY files in image directories
 
 
boot.bin
boot.bin-zc702-zynq7
boot.bin-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
boot.scr
core-image-minimal-zc702-zynq7-20210629031233.qemuboot.conf
core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio
core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio.gz.u-boot
core-image-minimal-zc702-zynq7-20210629031233.rootfs.manifest
core-image-minimal-zc702-zynq7-20210629031233.rootfs.tar.gz
core-image-minimal-zc702-zynq7-20210629031233.testdata.json
core-image-minimal-zc702-zynq7.cpio
core-image-minimal-zc702-zynq7.cpio.gz.u-boot
core-image-minimal-zc702-zynq7.manifest
core-image-minimal-zc702-zynq7.qemuboot.conf
core-image-minimal-zc702-zynq7.tar.gz
core-image-minimal-zc702-zynq7.testdata.json
modules--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.tgz
modules-zc702-zynq7.tgz
pxeboot
pxelinux.cfg
u-boot.elf
u-boot.img
u-boot-xlnx-AUTOINC+bb4660c33a.elf
u-boot-xlnx-initial-env
u-boot-xlnx-initial-env-zc702-zynq7
u-boot-xlnx-initial-env-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
u-boot-zc702-zynq7.elf
u-boot-zc702-zynq7.img
u-boot-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0.img
u-boot-zynq-scr--1.0-r0.scr
uEnv.txt
uImage
uImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
uImage-zc702-zynq7.bin
zImage
zImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
zImage-zc702-zynq7.bin
zynq-zc702--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.dtb
zynq-zc702.dtb
zynq-zc702-zc702-zynq7.dtb
 
 
 
what should i do to BOOT my yocto build image on zc702 board
 
   
   
 


Re: Would COMPATIBLE_IMAGE make sense?

Frederic Martinsons <frederic.martinsons@...>
 

Hello, instead of creating a new variable (don't sure of its possible usefulness), you can use BBMASK or review dependencies between your layer

PS: I did a similar answer on your stackoverflow question.

On Tue, 29 Jun 2021 at 01:29, Jonas Vautherin <jonas.vautherin@...> wrote:
I was thinking about my issue described here [1], and discovered the variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use to stop recipes from being built for machines (/hosts) with which the recipes are not compatible". And so I wondered if it would make sense to add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers (say `first-project-image` and `second-project-image`), and in each of those layers I create `.bbappends` to configure some packages. Typically `hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because `second-project-image` is part of my bblayers.conf, then the hostapd_%.bbappend from `second-project-image` is used and may have an impact on `first-project-image`, which I don't want. I really want this bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that `first-project-image` and `second-project-image` are two different projects, and build them from two different BUILDDIRs. The thing I don't like here is that all the packages are therefore downloaded and built twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend of `first-project-image`, I would set "COMPATIBLE_IMAGE = 'first-project-image'", and similarly for "COMPATIBLE_IMAGE = 'second-project-image'". So that I could still share a BUILDDIR between different projects.

How bad of an idea is that?

Thanks in advance,
Jonas





M+ & H bugs with Milestone Movements WW26

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW26 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

6428

Improve the ability to isolate changes that have caused a rebuild

randy.macleod@...

unassigned@...

3.99

3.4 M2

 

11361

oe-build-perf-test: monitor system resource utilization

randy.macleod@...

sakib.sajal@...

3.99

3.4 M3

 

12279

enhance manifest not found warning

kai.kang@...

kai.kang@...

3.4 M1

3.4 M4

 

12342

lib32-core-image-sato -ctestimage failed due to wrong package names

randy.macleod@...

unassigned@...

3.4 M4

3.4 M3

 

 

kai.kang@...

unassigned@...

3.4 M1

3.4 M4

 

13025

WIC image install support

kexin.hao@...

kexin.hao@...

3.4 M1

3.5

 

14099

PACKAGE_EXCLUDE not removing packages when PACKAGE_CLASSES = "package_deb"

randy.macleod@...

unassigned@...

3.4 M1

3.4 M3

 

14125

busybox wget ssl is exposed to MitM attack due to CVE-2018-1000500

randy.macleod@...

shachar@...

3.4 M1

3.4 M2

 

14163

libevent arm ptest intermittent failure

randy.macleod@...

yf3yu@...

3.4 M1

3.4 M2

 

14244

util-linux script:_size ptest failure

randy.macleod@...

unassigned@...

3.4 M4

3.4 M3

 

 

kai.kang@...

unassigned@...

3.4 M1

3.4 M4

 

14339

bitbake generates zombie Parser processes (hard to reproduce)

randy.macleod@...

randy.macleod@...

3.4 M1

3.4 M3

 

14434

[3.4 M1] dmesg: proc: Bad value for 'hidepid' with poky-altcfg distro

yi.zhao@...

yi.zhao@...

3.4 M2

0.0.0

 

14444

[multilib] lib32-core-image-minimal -c populate_sdk failure on dunfell

randy.macleod@...

raj.khem@...

3.4

3.4 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW26!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

3

bruce.ashfield@...

1

Grand Total

4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW26 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 86 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

richard.purdie@...

32

ross@...

31

michael.opdenacker@...

26

david.reyna@...

22

bruce.ashfield@...

21

JPEWhacker@...

12

bluelightning@...

12

akuster808@...

12

sakib.sajal@...

11

timothy.t.orling@...

11

trevor.gamblin@...

11

tony.tascioglu@...

9

randy.macleod@...

9

kai.kang@...

7

raj.khem@...

6

Qi.Chen@...

6

hongxu.jia@...

6

mingli.yu@...

6

yi.zhao@...

5

chee.yang.lee@...

5

alexandre.belloni@...

4

mostthingsweb@...

3

mshah@...

2

ydirson@...

2

pokylinux@...

2

jaewon@...

2

yf3yu@...

2

alejandro@...

2

mister_rs@...

1

jon.mason@...

1

devendra.tewari@...

1

Martin.Jansa@...

1

shachar@...

1

thomas.perrot@...

1

john.kaldas.enpj@...

1

kexin.hao@...

1

diego.sueiro@...

1

open.source@...

1

mhalstead@...

1

naveen.kumar.saini@...

1

stacygaikovaia@...

1

kergoth@...

1

yoctoproject@...

1

liezhi.yang@...

1

nicolas.dechesne@...

1

jeanmarie.lemetayer@...

1

douglas.royds@...

1

aehs29@...

1

mark.hatle@...

1

matthewzmd@...

1

saul.wold@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


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 349 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.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

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

 


Would COMPATIBLE_IMAGE make sense?

Jonas Vautherin
 

I was thinking about my issue described here [1], and discovered the variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use to stop recipes from being built for machines (/hosts) with which the recipes are not compatible". And so I wondered if it would make sense to add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers (say `first-project-image` and `second-project-image`), and in each of those layers I create `.bbappends` to configure some packages. Typically `hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because `second-project-image` is part of my bblayers.conf, then the hostapd_%.bbappend from `second-project-image` is used and may have an impact on `first-project-image`, which I don't want. I really want this bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that `first-project-image` and `second-project-image` are two different projects, and build them from two different BUILDDIRs. The thing I don't like here is that all the packages are therefore downloaded and built twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend of `first-project-image`, I would set "COMPATIBLE_IMAGE = 'first-project-image'", and similarly for "COMPATIBLE_IMAGE = 'second-project-image'". So that I could still share a BUILDDIR between different projects.

How bad of an idea is that?

Thanks in advance,
Jonas


[meta-rockchip][PATCH 3/3] wic/wks cleanup

Trevor Woerner
 

By exporting a couple more variables the wks file for every rockchip device
can be built from one template instead of having separate wks files for each
board and platform.

The following BSP variables were checked before and after this change to make
sure they remained valid/sensible:
- WKS_FILE
- UBOOT_SUFFIX
- SPL_BINARY
- IMAGE_FSTYPES

Built-tested for every MACHINE in this BSP.

Run-tested on the following devices to ensure they continue to boot correctly
to a cmdline (core-image-base):
- tinker-board
- rock-pi-e
- rock-pi-4b
- rock64
- nanopi-m4-2gb

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/firefly-rk3288.conf | 2 --
conf/machine/include/nanopi-m4.inc | 1 -
conf/machine/include/rk3288.inc | 3 +--
conf/machine/include/rk3328.inc | 1 -
conf/machine/include/rk3399.inc | 2 --
conf/machine/include/rock-pi-4.inc | 1 -
conf/machine/include/rockchip-wic.inc | 5 +++++
conf/machine/include/tinker.inc | 2 --
conf/machine/rock-pi-e.conf | 2 --
conf/machine/rock64.conf | 2 --
conf/machine/vyasa-rk3288.conf | 1 -
wic/firefly-rk3288.wks | 7 -------
wic/rk3288-boot.wks | 24 ------------------------
wic/rk3399-boot.wks | 24 ------------------------
wic/rock-pi-4.wks | 7 -------
wic/rock-pi-e.wks | 4 ----
wic/{rk3328-boot.wks => rockchip.wks} | 9 ++++++---
wic/tinker-board.wks | 8 --------
wic/vyasa-rk3288.wks | 8 --------
19 files changed, 12 insertions(+), 101 deletions(-)
delete mode 100644 wic/firefly-rk3288.wks
delete mode 100644 wic/rk3288-boot.wks
delete mode 100644 wic/rk3399-boot.wks
delete mode 100644 wic/rock-pi-4.wks
delete mode 100644 wic/rock-pi-e.wks
rename wic/{rk3328-boot.wks => rockchip.wks} (64%)
delete mode 100644 wic/tinker-board.wks
delete mode 100644 wic/vyasa-rk3288.wks

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 138e840..3270bb9 100644
--- a/conf/machine/firefly-rk3288.conf
+++ b/conf/machine/firefly-rk3288.conf
@@ -11,5 +11,3 @@ require conf/machine/include/rockchip-wic.inc

KERNEL_DEVICETREE = "rk3288-firefly.dtb"
UBOOT_MACHINE = "firefly-rk3288_defconfig"
-
-WKS_FILE ?= "firefly-rk3288.wks"
diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index b5251a1..ac6479d 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -9,4 +9,3 @@ KMACHINE = "nanopi-m4"
KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4.dtb"

RK_BOOT_DEVICE = "mmcblk1"
-WKS_FILE ?= "rock-pi-4.wks"
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a109f26..6b5f70a 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -13,5 +13,4 @@ KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"

PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
-SPL_BINARY ?= "idbloader.img"
-
+UBOOT_SUFFIX ?= "bin"
diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
index b0cafb5..70261a0 100644
--- a/conf/machine/include/rk3328.inc
+++ b/conf/machine/include/rk3328.inc
@@ -21,4 +21,3 @@ UBOOT_SUFFIX ?= "itb"
UBOOT_ENTRYPOINT ?= "0x06000000"

PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
-SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 79e83e2..3fc712f 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -21,5 +21,3 @@ UBOOT_SUFFIX ?= "itb"
UBOOT_ENTRYPOINT ?= "0x06000000"

PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
-SPL_BINARY ?= "idbloader.img"
-
diff --git a/conf/machine/include/rock-pi-4.inc b/conf/machine/include/rock-pi-4.inc
index 92fc330..b6fb3dd 100644
--- a/conf/machine/include/rock-pi-4.inc
+++ b/conf/machine/include/rock-pi-4.inc
@@ -4,6 +4,5 @@ MACHINEOVERRIDES =. "rock-pi-4:"
require conf/machine/include/rk3399.inc

RK_BOOT_DEVICE = "mmcblk1"
-WKS_FILE ?= "rock-pi-4.wks"

MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 0ee8c0e..61d9f3d 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -1,6 +1,9 @@
# common meta-rockchip wic/wks items

+SPL_BINARY ?= "idbloader.img"
+
IMAGE_FSTYPES += "wic wic.bmap"
+WKS_FILE = "rockchip.wks"
WKS_FILE_DEPENDS ?= " \
mtools-native \
dosfstools-native \
@@ -24,4 +27,6 @@ WICVARS_append = " \
RK_BOOT_DEVICE \
RK_CONSOLE_BAUD \
RK_CONSOLE_DEVICE \
+ SPL_BINARY \
+ UBOOT_SUFFIX \
"
diff --git a/conf/machine/include/tinker.inc b/conf/machine/include/tinker.inc
index eaeb564..2d05bef 100644
--- a/conf/machine/include/tinker.inc
+++ b/conf/machine/include/tinker.inc
@@ -1,4 +1,2 @@
require conf/machine/include/rk3288.inc
require conf/machine/include/rockchip-wic.inc
-
-WKS_FILE ?= "tinker-board.wks"
diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf
index 3fdbb5e..7afe143 100644
--- a/conf/machine/rock-pi-e.conf
+++ b/conf/machine/rock-pi-e.conf
@@ -13,5 +13,3 @@ MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"

PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"
-
-WKS_FILE = "rock-pi-e.wks"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
index 93e68e0..21755a8 100644
--- a/conf/machine/rock64.conf
+++ b/conf/machine/rock64.conf
@@ -15,6 +15,4 @@ KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
# set to mmcblk0 for booting from optional eMMC
RK_BOOT_DEVICE ?= "mmcblk1"

-WKS_FILE ?= "rock-pi-e.wks"
-
KBUILD_DEFCONFIG = "defconfig"
diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
index 3e1f395..9ad1ed4 100644
--- a/conf/machine/vyasa-rk3288.conf
+++ b/conf/machine/vyasa-rk3288.conf
@@ -15,4 +15,3 @@ KERNEL_EXTRA_ARGS += "LOADADDR=0x02000000"
UBOOT_MACHINE = "vyasa-rk3288_defconfig"

RK_BOOT_DEVICE = "mmcblk2"
-WKS_FILE ?= "vyasa-rk3288.wks"
diff --git a/wic/firefly-rk3288.wks b/wic/firefly-rk3288.wks
deleted file mode 100644
index 7b14d1f..0000000
--- a/wic/firefly-rk3288.wks
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-
-include rk3288-boot.wks
-part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
-
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/rk3288-boot.wks b/wic/rk3288-boot.wks
deleted file mode 100644
index e4d30cc..0000000
--- a/wic/rk3288-boot.wks
+++ /dev/null
@@ -1,24 +0,0 @@
-# Copyright (C) 2020 Garmin Ltd. or its subsidiaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-#
-# Disk layout
-# Note that the reference documentation refers to 512 byte disk sectors, but
-# wic uses 1KB blocks
-#
-# Partition Start Sector Number of Sectors
-# loader1 64 8000
-# reserved1 8064 128
-# reserved2 8192 8192
-# loader2 16384 8192
-# atf 24576 8192
-# boot 32768 229376
-# root 262144 - (suggested)
-#
-
-part loader1 --offset 32 --fixed-size 4000K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
-part reserved1 --offset 4032 --fixed-size 64K --ondisk ${RK_BOOT_DEVICE}
-part reserved2 --offset 4096 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
-part loader2 --offset 8192 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.bin"
-part atf --offset 12288 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
-part /boot --offset 16384 --size 114688K --active --ondisk ${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
-
diff --git a/wic/rk3399-boot.wks b/wic/rk3399-boot.wks
deleted file mode 100644
index 8a65179..0000000
--- a/wic/rk3399-boot.wks
+++ /dev/null
@@ -1,24 +0,0 @@
-# Copyright (C) 2020 Garmin Ltd. or its subsidiaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-#
-# Disk layout
-# Note that the reference documentation refers to 512 byte disk sectors, but
-# wic uses 1KB blocks
-#
-# Partition Start Sector Number of Sectors
-# loader1 64 8000
-# reserved1 8064 128
-# reserved2 8192 8192
-# loader2 16384 8192
-# atf 24576 8192
-# boot 32768 229376
-# root 262144 - (suggested)
-#
-
-part loader1 --offset 32 --fixed-size 4000K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
-part reserved1 --offset 4032 --fixed-size 64K --ondisk ${RK_BOOT_DEVICE}
-part reserved2 --offset 4096 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
-part loader2 --offset 8192 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.itb"
-part atf --offset 12288 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
-part /boot --offset 16384 --size 114688K --active --ondisk ${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
-
diff --git a/wic/rock-pi-4.wks b/wic/rock-pi-4.wks
deleted file mode 100644
index 5c02e9f..0000000
--- a/wic/rock-pi-4.wks
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright (C) 2020 Garmin Ltd. or its subsidiaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-
-include rk3399-boot.wks
-part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
-
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/rock-pi-e.wks b/wic/rock-pi-e.wks
deleted file mode 100644
index 9c10d90..0000000
--- a/wic/rock-pi-e.wks
+++ /dev/null
@@ -1,4 +0,0 @@
-include rk3328-boot.wks
-part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
-
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/rk3328-boot.wks b/wic/rockchip.wks
similarity index 64%
rename from wic/rk3328-boot.wks
rename to wic/rockchip.wks
index 194145b..eedae0d 100644
--- a/wic/rk3328-boot.wks
+++ b/wic/rockchip.wks
@@ -1,3 +1,4 @@
+# Copyright (C) 2019,2020 Garmin Ltd. or its subsidiaries
# Copyright (C) 2021 Trevor Woerner
# Released under the MIT license (see COPYING.MIT for the terms)
#
@@ -13,11 +14,13 @@
# atf 24576 8192
# boot 32768 229376
# root 262144 - (suggested)
-#

-part loader1 --offset 32 --fixed-size 4000K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
+part loader1 --offset 32 --fixed-size 4000K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=${SPL_BINARY}"
part reserved1 --offset 4032 --fixed-size 64K --ondisk ${RK_BOOT_DEVICE}
part reserved2 --offset 4096 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
-part loader2 --offset 8192 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.itb"
+part loader2 --offset 8192 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
part atf --offset 12288 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
part /boot --offset 16384 --size 114688K --active --ondisk ${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
+part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/tinker-board.wks b/wic/tinker-board.wks
deleted file mode 100644
index 00ae820..0000000
--- a/wic/tinker-board.wks
+++ /dev/null
@@ -1,8 +0,0 @@
-# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-
-include rk3288-boot.wks
-
-part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
-
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
diff --git a/wic/vyasa-rk3288.wks b/wic/vyasa-rk3288.wks
deleted file mode 100644
index 5346fbd..0000000
--- a/wic/vyasa-rk3288.wks
+++ /dev/null
@@ -1,8 +0,0 @@
-# Copyright (C) 2019 Garmin Ltd. or its subsidiaries
-# Released under the MIT license (see COPYING.MIT for the terms)
-
-include rk3288-boot.wks
-part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
-
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
-
--
2.30.0.rc0

3361 - 3380 of 57338