|
[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
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:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
[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:
Ways to contribute:
YP 3.4 Milestone Dates:
Planned upcoming dot releases:
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: 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
-- - 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: 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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Re: Yocto build isnot Booting up on board zc702
#gatesgarth
#linux
#yocto
Leon Woestenberg
Hello,
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:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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.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,
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
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- /media/vmnrtc/Drive/poky/meta- /media/vmnrtc/Drive/poky/meta- /media/vmnrtc/Drive/poky/meta- /media/vmnrtc/Drive/poky/meta- /media/vmnrtc/Drive/poky/meta- /media/vmnrtc/Drive/poky/meta- /media/vmnrtc/Drive/poky/ " MY files in image directories
boot.bin
boot.bin-zc702-zynq7 boot.bin-zc702-zynq7-v2020.01- boot.scr core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- core-image-minimal-zc702- modules--5.4+git0+62ea514294- modules-zc702-zynq7.tgz pxeboot pxelinux.cfg u-boot.elf u-boot.img u-boot-xlnx-AUTOINC+ u-boot-xlnx-initial-env u-boot-xlnx-initial-env-zc702- u-boot-xlnx-initial-env-zc702- u-boot-zc702-zynq7.elf u-boot-zc702-zynq7.img u-boot-zc702-zynq7-v2020.01- u-boot-zynq-scr--1.0-r0.scr uEnv.txt uImage uImage--5.4+git0+62ea514294- uImage-zc702-zynq7.bin zImage zImage--5.4+git0+62ea514294- zImage-zc702-zynq7.bin zynq-zc702--5.4+git0+ 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:
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
M+ & H bugs with Milestone Movements WW26
Stephen Jolley
All,
Thanks,
Stephen K. Jolley Yocto Project Program Manager ( Cell: (208) 244-4460 * Email: sjolley.yp.pm@...
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Enhancements/Bugs closed WW26!
Stephen Jolley
All,
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,
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
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||