yocto@lists.yoctoproject.org

Re: Using bitbake with external SDK #sdk #zeus #toolchain

Khem Raj

On Thu, Sep 23, 2021 at 6:46 AM <enrico.buffoli1994@...> wrote:

Hello,

It has been 2 years that i'm using the yocto project to build the image for an embedded system on IMX8M.
Now the system basic image is done outside and i receive the SDK.
All the additional packages that i was installing with my yocto project are missing because i receive the standard os image.
Is there a way to use the SDK that i receive to build the additional packages with bitbake?
if its eSDK then you can, with standard application SDK not so much.

Best regards

Re: googletest shared library

Khem Raj

#54819

look into package-split/ directory inside googletest build area and
see how things changes when you use SOLIBS option. I wonder why its
ignoring .h files

Show quoted text

On Thu, Sep 23, 2021 at 6:36 AM Lijun Chen <lijchen@...> wrote:

Hi,


If I switch to the default setting of the googletest recipe, the header files are included in the SDK image. However, the libgtest libraries are static.

Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the SDK.


Is there a way to change the library to dynamic and keep the header files? i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip the do_package_qa part to avoid the QA issue due to un-versioned library?


Thanks,

Lijun



________________________________
From: yocto@... <yocto@...> on behalf of Lijun Chen <lijchen@...>
Sent: Wednesday, September 22, 2021 1:45 PM
To: Khem Raj; yocto@...
Subject: Re: [yocto] googletest shared library


Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are still not showing up.

Thanks,

________________________________
From: Khem Raj <raj.khem@...>
Sent: Wednesday, September 22, 2021 11:28:05 AM
To: Lijun Chen; yocto@...
Subject: Re: [yocto] googletest shared library

The .h files will be in dev pkg in this case googletest-dev
what happens if you add googletest to TOOLCHAIN_TARGET_TASK

On 9/22/21 6:18 AM, Lijun Chen wrote:
Hi,


Now I included googletest to the IMAGE_INSTALL in my image file, and
built both board image and SDK image. I can see libgtest.so is available
in both images. However, gtest/gtest.h is a not present in SDK. How do I
add the header files to the SDK image? Looks the following lines affect
that?

SOLIBS = ".so"
FILES_SOLIBSDEV = ""

Thanks,
Lijun

------------------------------------------------------------------------
*From:* yocto@... <yocto@...> on
behalf of Lijun Chen <lijchen@...>
*Sent:* Tuesday, September 21, 2021 3:50 PM
*To:* Konrad Weihmann; yocto@...
*Subject:* Re: [yocto] googletest shared library

Thanks Konrad. That worked.

------------------------------------------------------------------------
*From:* Konrad Weihmann <kweihmann@...>
*Sent:* Tuesday, September 21, 2021 10:26:19 AM
*To:* Lijun Chen; yocto@...
*Subject:* Re: [yocto] googletest shared library

On 21.09.21 16:18, Lijun Chen wrote:
Hi,

I would like to include libgtest.so into my Yocto image. I added
googletest to IMAGE_INSTALL and added the following line to
sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:

EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "


The shared libraries were built successfully. However, there are errors
in do_package_qc as following:


ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
-dev package googletest-dev contains non-symlink .so
'/usr/lib/libgtest_main.so'
-dev package googletest-dev contains non-symlink .so
'/usr/lib/libgmock_main.so'
-dev package googletest-dev contains non-symlink .so
'/usr/lib/libgtest.so' [dev-elf]
ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors.
Please consider fixing them.https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$
<https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$>

(and the next lines) might give you a hint what to do in this case.
Although one could also consider that's something that needs to be fixed
in the installation script of googletest, as versioned libraries are the
expected default



Any idea to fix this?


Thanks,

Lijun


------------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.



------------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
------------------------------------------------------------------------
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.



________________________________
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
________________________________
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: Minutes: Yocto Project Weekly Triage Meeting 9/23/2021

Richard Purdie

#54818

On Thu, 2021-09-23 at 11:40 -0400, Trevor Gamblin wrote:

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage
Attendees: Alex, Bruce, Kiran, Randy, Richard, Ross, Saul, Stephen, Steve, Trevor
ARs:
- Steve to review failure logs for 14557 and post any that might be useful
- Richard to have a look at bug 11801

I did look at it. It was using a modified oe-selftest with threading instead of multiprocess. We're not using that so I closed it.

Cheers,

Richard

gcov support for target in Yocto

Lijun Chen

#54817

Hi,

Anybody knows how to enable gcov support for the target in Yocto?

Thanks,

Lijun

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: [ptest-runner][PATCH 3/3] utils.c: add system data collection when a test gets stuck.

Alexander Kanavin

#54816

Not sure what happened here, I published the patches in https://github.com/kanavin/ptest-runner2

Alex

Show quoted text

On Thu, 23 Sept 2021 at 18:33, Anibal Limon <anibal.limon@...> wrote:

Hi Alex,

Do you have a repo/branch for this patch?.

I'm having issues applying...

...
alimon@blackbox:~/upstream/ptest-runner2$ git am -3 ~/Downloads/\[ptest-runner\]\[PATCH\ 3_3\]\ utils.c_\ add\ system\ data\ collection\ when\ a\ test\ gets\ stuck..eml
Applying: utils.c: add system data collection when a test gets stuck.
error: sha1 information is lacking or useless (utils.c).
error: could not build fake ancestor
Patch failed at 0001 utils.c: add system data collection when a test gets stuck.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
...

Regards,
Anibal

On Thu, 16 Sept 2021 at 07:46, Alexander Kanavin <alex.kanavin@...> wrote:
Currently, ptest-runner simply kills the offending test without further ado,
which is not at all helpful when trying to figure out why it happens
(especially if such hangs are intermittent and rare). There's now a script
that gets executed before killing the test, so ideas on what to have in it
are welcome.

Signed-off-by: Alexander Kanavin <alex@...>
---
Makefile | 2 +-
ptest-runner-collect-system-data | 5 +++++
utils.c | 24 ++++++++++++++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
create mode 100755 ptest-runner-collect-system-data

diff --git a/Makefile b/Makefile
index a6372de..168cf5a 100644
--- a/Makefile
+++ b/Makefile
@@ -43,7 +43,7 @@ $(TEST_EXECUTABLE): $(TEST_OBJECTS)
$(CC) $(LDFLAGS) $(TEST_OBJECTS) -o $@ $(TEST_LIBSTATIC) $(TEST_LDFLAGS)

check: $(TEST_EXECUTABLE)
- ./$(TEST_EXECUTABLE) -d $(TEST_DATA)
+ PATH=.:$(PATH) ./$(TEST_EXECUTABLE) -d $(TEST_DATA)

.c.o:
$(CC) $(CFLAGS) -c $< -o $@
diff --git a/ptest-runner-collect-system-data b/ptest-runner-collect-system-data
new file mode 100755
index 0000000..5bfeaf3
--- /dev/null
+++ b/ptest-runner-collect-system-data
@@ -0,0 +1,5 @@
+#!/bin/sh
+# Other ideas on what to do when a ptest gets stuck welcome.
+pstree -a -l
+df
+free
diff --git a/utils.c b/utils.c
index 58c3aa1..a67ac11 100644
--- a/utils.c
+++ b/utils.c
@@ -281,6 +281,27 @@ close_fds(void)
}
}

+static void
+collect_system_state(FILE* fout)
+{
+ char *cmd = "ptest-runner-collect-system-data";
+
+ char buf[1024];
+ FILE *fp;
+
+ if ((fp = popen(cmd, "r")) == NULL) {
+ fprintf(fout, "Error opening pipe!\n");
+ }
+
+ while (fgets(buf, 1024, fp) != NULL) {
+ fprintf(fout, "%s", buf);
+ }
+
+ if(pclose(fp)) {
+ fprintf(fout, "Command not found or exited with error status\n");
+ }
+}
+
static void *
read_child(void *arg)
{
@@ -313,6 +334,9 @@ read_child(void *arg)
}

} else if (r == 0) {
+ // no output from the test after a timeout; the test is stuck, so collect
+ // as much data from the system as possible and kill the test
+ collect_system_state(_child_reader.fps[0]);
_child_reader.timeouted = 1;
kill(-_child_reader.pid, SIGKILL);
}
--
2.33.0

Re: [ptest-runner][PATCH 3/3] utils.c: add system data collection when a test gets stuck.

Anibal Limon

#54815

Hi Alex,

Do you have a repo/branch for this patch?.

I'm having issues applying...

...

alimon@blackbox:~/upstream/ptest-runner2$ git am -3 ~/Downloads/\[ptest-runner\]\[PATCH\ 3_3\]\ utils.c_\ add\ system\ data\ collection\ when\ a\ test\ gets\ stuck..eml
Applying: utils.c: add system data collection when a test gets stuck.
error: sha1 information is lacking or useless (utils.c).
error: could not build fake ancestor
Patch failed at 0001 utils.c: add system data collection when a test gets stuck.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

...

Regards,

Anibal

Show quoted text

On Thu, 16 Sept 2021 at 07:46, Alexander Kanavin <alex.kanavin@...> wrote:

Currently, ptest-runner simply kills the offending test without further ado,
which is not at all helpful when trying to figure out why it happens
(especially if such hangs are intermittent and rare). There's now a script
that gets executed before killing the test, so ideas on what to have in it
are welcome.

Signed-off-by: Alexander Kanavin <alex@...>
---
Makefile | 2 +-
ptest-runner-collect-system-data | 5 +++++
utils.c | 24 ++++++++++++++++++++++++
3 files changed, 30 insertions(+), 1 deletion(-)
create mode 100755 ptest-runner-collect-system-data

diff --git a/Makefile b/Makefile
index a6372de..168cf5a 100644
--- a/Makefile
+++ b/Makefile
@@ -43,7 +43,7 @@ $(TEST_EXECUTABLE): $(TEST_OBJECTS)
$(CC) $(LDFLAGS) $(TEST_OBJECTS) -o $@ $(TEST_LIBSTATIC) $(TEST_LDFLAGS)

check: $(TEST_EXECUTABLE)
- ./$(TEST_EXECUTABLE) -d $(TEST_DATA)
+ PATH=.:$(PATH) ./$(TEST_EXECUTABLE) -d $(TEST_DATA)

.c.o:
$(CC) $(CFLAGS) -c $< -o $@
diff --git a/ptest-runner-collect-system-data b/ptest-runner-collect-system-data
new file mode 100755
index 0000000..5bfeaf3
--- /dev/null
+++ b/ptest-runner-collect-system-data
@@ -0,0 +1,5 @@
+#!/bin/sh
+# Other ideas on what to do when a ptest gets stuck welcome.
+pstree -a -l
+df
+free
diff --git a/utils.c b/utils.c
index 58c3aa1..a67ac11 100644
--- a/utils.c
+++ b/utils.c
@@ -281,6 +281,27 @@ close_fds(void)
}
}

+static void
+collect_system_state(FILE* fout)
+{
+ char *cmd = "ptest-runner-collect-system-data";
+
+ char buf[1024];
+ FILE *fp;
+
+ if ((fp = popen(cmd, "r")) == NULL) {
+ fprintf(fout, "Error opening pipe!\n");
+ }
+
+ while (fgets(buf, 1024, fp) != NULL) {
+ fprintf(fout, "%s", buf);
+ }
+
+ if(pclose(fp)) {
+ fprintf(fout, "Command not found or exited with error status\n");
+ }
+}
+
static void *
read_child(void *arg)
{
@@ -313,6 +334,9 @@ read_child(void *arg)
}

} else if (r == 0) {
+ // no output from the test after a timeout; the test is stuck, so collect
+ // as much data from the system as possible and kill the test
+ collect_system_state(_child_reader.fps[0]);
_child_reader.timeouted = 1;
kill(-_child_reader.pid, SIGKILL);
}
--
2.33.0

Re: [PATCH v2 ptest-runner 2/2] main: Do not return number of failed tests when calling ptest-runner

Anibal Limon

#54814

On Mon, 20 Sept 2021 at 04:23, Alexander Kanavin <alex.kanavin@...> wrote:

I think we might be having an 'unresponsive maintainer' situation? How can Anibal be reached?

I was OOO for futher you can find me with nickname alimon at #yocto at Libera.

Alex

On Mon, 20 Sept 2021 at 11:19, ?ukasz Majewski <lukma@...> wrote:
Hi Anibal,

> Hi Anibal,
>
> > Up till now ptest-runner2 returns number of failed tests with its
> > exit status code. Such use case is not recommended [1] and may cause
> > issues when there are more than 256 tests to be executed.
> >
> > To alleviate this issue the number of total tests with number of
> > failed ones is printed before exit. To be more specific - failure of
> > tests (one or more) causes ptest-runner to provide exit code of 1.
> >
> > One can test this change with executing:
> > ./ptest-runner -d tests/data fail
>
> Gentle ping on this patch.
>

Gentle ping on this patch.

Is it OK to be applied?

Applied,

Thanks,

Anibal

> >
> > Links:
> > [1] -
> > https://www.gnu.org/software/libc/manual/html_node/Exit-Status.html
> >
> > Signed-off-by: Lukasz Majewski <lukma@...>
> > ---
> > Changes for v2:
> > - When number of failed tests is N, the ptest-runner returns value
> > of 1 to indicate error in the execution
> > ---
> > main.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/main.c b/main.c
> > index 890bc6a..bcec844 100644
> > --- a/main.c
> > +++ b/main.c
> > @@ -220,6 +220,9 @@ main(int argc, char *argv[])
> > ptest_list_remove(run, opts.exclude[i], 1);
> >
> > rc = run_ptests(run, opts, argv[0], stdout, stderr);
> > + fprintf(stdout, "TOTAL: %d FAIL: %d\n",
> > ptest_list_length(run), rc);
> > + if (rc > 0)
> > + rc = 1;
> >
> > ptest_list_free_all(&run);
> >
>
>
>
>
> Best regards,
>
> Lukasz Majewski
>
> --
>
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email:
> lukma@...

Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@...

[meta-security][PATCH] dmverity: Make use of DATA_BLOCK_SIZE variable in initrdscript.

Paulo Neves

#54813

From: Christer Fletcher <christer.fletcher@...>

DATA_BLOCK_SIZE variable was set in dm-verity-img.bbclass at build
time but the initrdscript was not updated to pass the DATA_BLOCK_SIZE
to the veritysetup. Now the functionality is complete.

Signed-off-by: Paulo Neves <paulo.neves1@...>
---
 recipes-core/initrdscripts/initramfs-framework-dm/dmverity | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/recipes-core/initrdscripts/initramfs-framework-dm/dmverity b/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
index 888052c..c815940 100644
--- a/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
+++ b/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
@@ -6,6 +6,7 @@ dmverity_enabled() {
 
 dmverity_run() {
     DATA_SIZE="__not_set__"
+    DATA_BLOCK_SIZE="__not_set__"
     ROOT_HASH="__not_set__"
 
     . /usr/share/misc/dm-verity.env
@@ -49,7 +50,7 @@ dmverity_run() {
     done
 
     veritysetup \
-        --data-block-size=1024 \
+        --data-block-size=${DATA_BLOCK_SIZE} \
         --hash-offset=${DATA_SIZE} \
         create rootfs \
         ${RDEV} \
-- 
2.25.1

Minutes: Yocto Project Weekly Triage Meeting 9/23/2021

Trevor Gamblin

#54812

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alex, Bruce, Kiran, Randy, Richard, Ross, Saul, Stephen, Steve, Trevor

ARs:

- Steve to review failure logs for 14557 and post any that might be useful

- Richard to have a look at bug 11801

Notes:

- (carried over) Steve encountered build failures such as the one in https://errors.yoctoproject.org/Errors/Details/593109/ when attempting to run dunfell builds with the PARALLEL_MAKE load averaging added. WR is testing/investigating on internal Autobuilder instance - Trevor is still planning on looking into this!

Medium+ 3.4 Unassigned Enhancements/Bugs: 68 (No change)

Medium+ 3.5 Unassigned Enhancements/Bugs: 10 (No change)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (Last week 38)

AB-INT Bugs: 54 (Last week 49)

"stack smashing detected" when building aarch64 kernel

Rasmus Villemoes

#54811

I've recently started getting an internal compiler error when building
an aarch64 kernel. It only happens once in a while, and re-running the
task usually just succeeds, so I don't know how to reproduce or trigger
this at will.

Two examples:

===
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gm20b.o
  CC [M]  drivers/net/ethernet/mellanox/mlx5/core/rl.o
  CC [M]  drivers/gpu/drm/nouveau/nvkm/subdev/fb/gp100.o
*** stack smashing detected ***: <unknown> terminated
In file included from .../kernel-source/arch/arm64/include/asm/atomic.h:15,
                 from .../kernel-source/include/linux/atomic.h:7,
                 from
.../kernel-source/include/asm-generic/bitops/atomic.h:5,
                 from .../kernel-source/arch/arm64/include/asm/bitops.h:26,
                 from .../kernel-source/include/linux/bitops.h:29,
                 from .../kernel-source/include/linux/kernel.h:12,
                 from .../kernel-source/include/linux/uio.h:8,
                 from .../kernel-source/include/linux/socket.h:8,
                 from .../kernel-source/include/uapi/linux/if.h:25,
                 from .../kernel-source/net/mac80211/led.c:7:
.../kernel-source/include/net/inet_sock.h: In function 'inet_sk_state_load':
.../kernel-source/arch/arm64/include/asm/barrier.h:114:8: internal
compiler error: Aborted
  114 |  union { __unqual_scalar_typeof(*p) __val; char __c[1]; } __u; \
      |        ^
.../kernel-source/include/asm-generic/barrier.h:142:29: note: in
expansion of macro '__smp_load_acquire'
  142 | #define smp_load_acquire(p) __smp_load_acquire(p)
      |                             ^~~~~~~~~~~~~~~~~~
.../kernel-source/include/net/inet_sock.h:312:9: note: in expansion of
macro 'smp_load_acquire'
  312 |  return smp_load_acquire(&sk->sk_state);
      |         ^~~~~~~~~~~~~~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
.../kernel-source/scripts/Makefile.build:279: recipe for target
'net/mac80211/led.o' failed
make[3]: *** [net/mac80211/led.o] Error 1
make[3]: *** Waiting for unfinished jobs....
  CC [M]  drivers/net/ethernet/mellanox/mlx5/core/lag.o
===
  CC [M]  drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o
  CC [M]  drivers/gpu/drm/drm_modeset_helper.o
  CC [M]  drivers/gpu/drm/drm_scdc_helper.o
*** stack smashing detected ***: <unknown> terminated
In file included from
.../kernel-source/include/linux/regulator/consumer.h:35,
                 from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvif/os.h:27,
                 from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/os.h:4,
                 from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/oclass.h:3,
                 from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/device.h:4,
                 from
.../kernel-source/drivers/gpu/drm/nouveau/include/nvkm/core/subdev.h:4,
                 from
.../kernel-source/drivers/gpu/drm/nouveau/nvkm/nvfw/ls.c:22:
.../kernel-source/include/linux/suspend.h:364:36: internal compiler
error: Aborted
  364 | extern void mark_free_pages(struct zone *zone);
      |                                    ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
.../kernel-source/scripts/Makefile.build:280: recipe for target
'drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o' failed
make[5]: *** [drivers/gpu/drm/nouveau/nvkm/nvfw/ls.o] Error 1
make[5]: *** Waiting for unfinished jobs....
  CC [M]  drivers/gpu/drm/drm_gem_framebuffer_helper.o
===

This is with hardknott, aarch64-oe-linux-gcc (GCC) 10.2.0, building
5.10.* kernels (5.10.45 and 5.10.65 in the cases above IIRC). The build
is visiting drivers/gpu/drm/ in both cases, but in the former case it's
not actually a TU in there that fails, but one in net/, so I'm not even
sure it it has to do with something peculiar to the drivers/gpu/drm/
modules.

Has anyone seem something like this, or any ideas for figuring out
what's going on?

Rasmus

Re: googletest shared library

Lijun Chen

#54810

I tried INSANE_SKIP_${PN} += "dev-elf" and "dev-so", still got the QA error:

ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
-dev package googletest-dev contains non-symlink .so '/usr/lib/libgtest_main.so'
-dev package googletest-dev contains non-symlink .so '/usr/lib/libgmock_main.so'
-dev package googletest-dev contains non-symlink .so '/usr/lib/libgtest.so' [dev-elf]
ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: Logfile of failure stored in: /home/lijchen/hdd/ivdp/yocto/imx8/imx-yocto-bsp-Hardknott/build-imx8qmmek/tmp/work/cortexa72-cortexa53-crypto-poky-linux/googletest/1.10.0-r0/temp/log.do_package_qa.24701
ERROR: Task (/home/lijchen/hdd/ivdp/yocto/imx8/imx-yocto-bsp-Hardknott/sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:do_package_qa) failed with exit code '1'

I also tried adding " -DCMAKE_INSTALL_PREFIX=/usr/local" to EXTRA_OEMAKE, and got the following error:

ERROR: googletest-1.10.0-r0 do_package: QA Issue: googletest: Files/directories were installed but not shipped in any package:
/usr/local/include
/usr/local/lib/libgmock.so
/usr/local/lib/libgtest_main.so
/usr/local/lib/libgmock_main.so
/usr/local/lib/libgtest.so
/usr/local/lib/cmake
/usr/local/lib/pkgconfig
/usr/local/lib/cmake/GTest
/usr/local/lib/cmake/GTest/GTestTargets.cmake
/usr/local/lib/cmake/GTest/GTestConfigVersion.cmake
/usr/local/lib/cmake/GTest/GTestConfig.cmake
/usr/local/lib/cmake/GTest/GTestTargets-noconfig.cmake
/usr/local/lib/pkgconfig/gtest_main.pc
/usr/local/lib/pkgconfig/gtest.pc
/usr/local/lib/pkgconfig/gmock_main.pc
/usr/local/lib/pkgconfig/gmock.pc
/usr/local/include/gtest
/usr/local/include/gmock
/usr/local/include/gtest/gtest_prod.h
/usr/local/include/gtest/gtest-test-part.h
/usr/local/include/gtest/gtest_pred_impl.h
/usr/local/include/gtest/gtest-matchers.h
/usr/local/include/gtest/gtest-printers.h
/usr/local/include/gtest/gtest.h
/usr/local/include/gtest/gtest-param-test.h
/usr/local/include/gtest/gtest-death-test.h
/usr/local/include/gtest/gtest-typed-test.h
/usr/local/include/gtest/gtest-message.h
/usr/local/include/gtest/gtest-spi.h
/usr/local/include/gtest/internal
/usr/local/include/gtest/internal/gtest-death-test-internal.h
/usr/local/include/gtest/internal/gtest-filepath.h
/usr/local/include/gtest/internal/gtest-param-util.h
/usr/local/include/gtest/internal/gtest-string.h
/usr/local/include/gtest/internal/gtest-type-util.h
/usr/local/include/gtest/internal/gtest-internal.h
/usr/local/include/gtest/internal/gtest-type-util.h.pump
/usr/local/include/gtest/internal/gtest-port-arch.h
/usr/local/include/gtest/internal/gtest-port.h
/usr/local/include/gtest/internal/custom
/usr/local/include/gtest/internal/custom/gtest-printers.h
/usr/local/include/gtest/internal/custom/gtest.h
/usr/local/include/gtest/internal/custom/README.md
/usr/local/include/gtest/internal/custom/gtest-port.h
/usr/local/include/gmock/gmock-function-mocker.h
/usr/local/include/gmock/gmock-generated-function-mockers.h
/usr/local/include/gmock/gmock-generated-actions.h.pump
/usr/local/include/gmock/gmock-matchers.h
/usr/local/include/gmock/gmock-generated-matchers.h
/usr/local/include/gmock/gmock-more-matchers.h
/usr/local/include/gmock/gmock.h
/usr/local/include/gmock/gmock-generated-actions.h
/usr/local/include/gmock/gmock-nice-strict.h
/usr/local/include/gmock/gmock-spec-builders.h
/usr/local/include/gmock/gmock-more-actions.h
/usr/local/include/gmock/gmock-generated-function-mockers.h.pump
/usr/local/include/gmock/gmock-cardinalities.h
/usr/local/include/gmock/gmock-actions.h
/usr/local/include/gmock/gmock-generated-matchers.h.pump
/usr/local/include/gmock/internal
/usr/local/include/gmock/internal/gmock-port.h
/usr/local/include/gmock/internal/gmock-pp.h
/usr/local/include/gmock/internal/gmock-internal-utils.h
/usr/local/include/gmock/internal/custom
/usr/local/include/gmock/internal/custom/gmock-port.h
/usr/local/include/gmock/internal/custom/gmock-generated-actions.h.pump
/usr/local/include/gmock/internal/custom/gmock-matchers.h
/usr/local/include/gmock/internal/custom/gmock-generated-actions.h
/usr/local/include/gmock/internal/custom/README.md
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
googletest: 69 installed and not shipped files. [installed-vs-shipped]
ERROR: googletest-1.10.0-r0 do_package: Fatal QA errors found, failing task.

Show quoted text

From: Federico Pellegrin <fede@...>
Sent: Thursday, September 23, 2021 10:27:39 AM
To: Lijun Chen
Cc: yocto@...
Subject: Re: [yocto] googletest shared library

Hi,

To skip the QA you can use:

INSANE_SKIP_${PN} += "dev-elf"

(or any QA part you'd like to skip, ie. dev-elf or dev-so ...)

Cheers,

Federico

Il giorno gio 23 set 2021 alle ore 15:33 Lijun Chen <lijchen@...> ha scritto:

Hi,

If I switch to the default setting of the googletest recipe, the header files are included in the SDK image. However, the libgtest libraries are static.

Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the SDK.

Is there a way to change the library to dynamic and keep the header files? i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip the do_package_qa part to avoid the QA issue due to un-versioned library?

Thanks,

Lijun

From: yocto@... <yocto@...> on behalf of Lijun Chen <lijchen@...>
Sent: Wednesday, September 22, 2021 1:45 PM
To: Khem Raj; yocto@...
Subject: Re: [yocto] googletest shared library

Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are still not showing up.

Thanks,

From: Khem Raj <raj.khem@...>
Sent: Wednesday, September 22, 2021 11:28:05 AM
To: Lijun Chen; yocto@...
Subject: Re: [yocto] googletest shared library

The .h files will be in dev pkg in this case googletest-dev
what happens if you add googletest to TOOLCHAIN_TARGET_TASK

On 9/22/21 6:18 AM, Lijun Chen wrote:
> Hi,
>
>
> Now I included googletest to the IMAGE_INSTALL in my image file, and
> built both board image and SDK image. I can see libgtest.so is available
> in both images. However, gtest/gtest.h is a not present in SDK. How do I
> add the header files to the SDK image? Looks the following lines affect
> that?
>
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> Thanks,
> Lijun
>
> ------------------------------------------------------------------------
> *From:* yocto@... <yocto@...> on
> behalf of Lijun Chen <lijchen@...>
> *Sent:* Tuesday, September 21, 2021 3:50 PM
> *To:* Konrad Weihmann; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> Thanks Konrad. That worked.
>
> ------------------------------------------------------------------------
> *From:* Konrad Weihmann <kweihmann@...>
> *Sent:* Tuesday, September 21, 2021 10:26:19 AM
> *To:* Lijun Chen; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> On 21.09.21 16:18, Lijun Chen wrote:
>> Hi,
>>
>> I would like to include libgtest.so into my Yocto image. I added
>> googletest to IMAGE_INSTALL and added the following line to
>> sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:
>>
>> EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
>>
>>
>> The shared libraries were built successfully. However, there are errors
>> in do_package_qc as following:
>>
>>
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
>> googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgmock_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest.so' [dev-elf]
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors.
>> Please consider fixing them.
>
> https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$
> <https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$>
>
> (and the next lines) might give you a hint what to do in this case.
> Although one could also consider that's something that needs to be fixed
> in the installation script of googletest, as versioned libraries are the
> expected default
>
>>
>>
>> Any idea to fix this?
>>
>>
>> Thanks,
>>
>> Lijun
>>
>>
>> ------------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
>>
>>
>>
>>
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
>
>

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: googletest shared library

Federico Pellegrin

#54809

Hi,

To skip the QA you can use:

INSANE_SKIP_${PN} += "dev-elf"

(or any QA part you'd like to skip, ie. dev-elf or dev-so ...)

Cheers,

Federico

Show quoted text

Il giorno gio 23 set 2021 alle ore 15:33 Lijun Chen <lijchen@...> ha scritto:

Hi,

If I switch to the default setting of the googletest recipe, the header files are included in the SDK image. However, the libgtest libraries are static.

Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the SDK.

Is there a way to change the library to dynamic and keep the header files? i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip the do_package_qa part to avoid the QA issue due to un-versioned library?

Thanks,

Lijun

From: yocto@... <yocto@...> on behalf of Lijun Chen <lijchen@...>
Sent: Wednesday, September 22, 2021 1:45 PM
To: Khem Raj; yocto@...
Subject: Re: [yocto] googletest shared library

Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are still not showing up.

Thanks,

From: Khem Raj <raj.khem@...>
Sent: Wednesday, September 22, 2021 11:28:05 AM
To: Lijun Chen; yocto@...
Subject: Re: [yocto] googletest shared library

The .h files will be in dev pkg in this case googletest-dev
what happens if you add googletest to TOOLCHAIN_TARGET_TASK

On 9/22/21 6:18 AM, Lijun Chen wrote:
> Hi,
>
>
> Now I included googletest to the IMAGE_INSTALL in my image file, and
> built both board image and SDK image. I can see libgtest.so is available
> in both images. However, gtest/gtest.h is a not present in SDK. How do I
> add the header files to the SDK image? Looks the following lines affect
> that?
>
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> Thanks,
> Lijun
>
> ------------------------------------------------------------------------
> *From:* yocto@... <yocto@...> on
> behalf of Lijun Chen <lijchen@...>
> *Sent:* Tuesday, September 21, 2021 3:50 PM
> *To:* Konrad Weihmann; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> Thanks Konrad. That worked.
>
> ------------------------------------------------------------------------
> *From:* Konrad Weihmann <kweihmann@...>
> *Sent:* Tuesday, September 21, 2021 10:26:19 AM
> *To:* Lijun Chen; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> On 21.09.21 16:18, Lijun Chen wrote:
>> Hi,
>>
>> I would like to include libgtest.so into my Yocto image. I added
>> googletest to IMAGE_INSTALL and added the following line to
>> sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:
>>
>> EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
>>
>>
>> The shared libraries were built successfully. However, there are errors
>> in do_package_qc as following:
>>
>>
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
>> googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgmock_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest.so' [dev-elf]
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors.
>> Please consider fixing them.
>
> https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$
> <https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$>
>
> (and the next lines) might give you a hint what to do in this case.
> Although one could also consider that's something that needs to be fixed
> in the installation script of googletest, as versioned libraries are the
> expected default
>
>>
>>
>> Any idea to fix this?
>>
>>
>> Thanks,
>>
>> Lijun
>>
>>
>> ------------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
>>
>>
>>
>>
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
>
>

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Using bitbake with external SDK #sdk #zeus #toolchain

enrico.buffoli1994@...

#54808

Hello,

It has been 2 years that i'm using the yocto project to build the image for an embedded system on IMX8M.
Now the system basic image is done outside and i receive the SDK.
All the additional packages that i was installing with my yocto project are missing because i receive the standard os image.
Is there a way to use the SDK that i receive to build the additional packages with bitbake?

Best regards

Re: googletest shared library

Lijun Chen

#54807

Hi,

If I switch to the default setting of the googletest recipe, the header files are included in the SDK image. However, the libgtest libraries are static.

Looks FILES_SOLIBSDEV = "" disables googletest-dev to be included in the SDK.

Is there a way to change the library to dynamic and keep the header files? i.e. just add EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON " but skip the do_package_qa part to avoid the QA issue due to un-versioned library?

Thanks,

Lijun

Show quoted text

From: yocto@... <yocto@...> on behalf of Lijun Chen <lijchen@...>
Sent: Wednesday, September 22, 2021 1:45 PM
To: Khem Raj; yocto@...
Subject: Re: [yocto] googletest shared library

Tried adding googletest to TOOLCHAIN_TARGET_TASK. The gtest .h files are still not showing up.

Thanks,

From: Khem Raj <raj.khem@...>
Sent: Wednesday, September 22, 2021 11:28:05 AM
To: Lijun Chen; yocto@...
Subject: Re: [yocto] googletest shared library

The .h files will be in dev pkg in this case googletest-dev
what happens if you add googletest to TOOLCHAIN_TARGET_TASK

On 9/22/21 6:18 AM, Lijun Chen wrote:
> Hi,
>
>
> Now I included googletest to the IMAGE_INSTALL in my image file, and
> built both board image and SDK image. I can see libgtest.so is available
> in both images. However, gtest/gtest.h is a not present in SDK. How do I
> add the header files to the SDK image? Looks the following lines affect
> that?
>
> SOLIBS = ".so"
> FILES_SOLIBSDEV = ""
>
> Thanks,
> Lijun
>
> ------------------------------------------------------------------------
> *From:* yocto@... <yocto@...> on
> behalf of Lijun Chen <lijchen@...>
> *Sent:* Tuesday, September 21, 2021 3:50 PM
> *To:* Konrad Weihmann; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> Thanks Konrad. That worked.
>
> ------------------------------------------------------------------------
> *From:* Konrad Weihmann <kweihmann@...>
> *Sent:* Tuesday, September 21, 2021 10:26:19 AM
> *To:* Lijun Chen; yocto@...
> *Subject:* Re: [yocto] googletest shared library
>
> On 21.09.21 16:18, Lijun Chen wrote:
>> Hi,
>>
>> I would like to include libgtest.so into my Yocto image. I added
>> googletest to IMAGE_INSTALL and added the following line to
>> sources/meta-openembedded/meta-oe/recipes-test/googletest/googletest_git.bb:
>>
>> EXTRA_OECMAKE = "-DBUILD_SHARED_LIBS=ON "
>>
>>
>> The shared libraries were built successfully. However, there are errors
>> in do_package_qc as following:
>>
>>
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA Issue: -dev package
>> googletest-dev contains non-symlink .so '/usr/lib/libgmock.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgmock_main.so'
>> -dev package googletest-dev contains non-symlink .so
>> '/usr/lib/libgtest.so' [dev-elf]
>> ERROR: googletest-1.10.0-r0 do_package_qa: QA run found fatal errors.
>> Please consider fixing them.
>
> https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$
> <https://urldefense.com/v3/__http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-graphics/spir/spirv-tools_2021.2.bb*n34__;Iw!!COg3wY07Hnb7!4NI6d6tXUoxCQFleF-343dfbdFGnkZnqrYRVg3nYTCBoGJTY9-K0NANM4iMsNNleww$>
>
> (and the next lines) might give you a hint what to do in this case.
> Although one could also consider that's something that needs to be fixed
> in the installation script of googletest, as versioned libraries are the
> expected default
>
>>
>>
>> Any idea to fix this?
>>
>>
>> Thanks,
>>
>> Lijun
>>
>>
>> ------------------------------------------------------------------------
>> This transmission (including any attachments) may contain confidential
>> information, privileged material (including material protected by the
>> solicitor-client or other applicable privileges), or constitute
>> non-public information. Any use of this information by anyone other than
>> the intended recipient is prohibited. If you have received this
>> transmission in error, please immediately reply to the sender and delete
>> this information from your system. Use, dissemination, distribution, or
>> reproduction of this transmission by unintended recipients is not
>> authorized and may be unlawful.
>>
>>
>>
>>
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute
> non-public information. Any use of this information by anyone other than
> the intended recipient is prohibited. If you have received this
> transmission in error, please immediately reply to the sender and delete
> this information from your system. Use, dissemination, distribution, or
> reproduction of this transmission by unintended recipients is not
> authorized and may be unlawful.
>
>
>
>

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Re: [meta-rockchip][PATCH 2/2] rockchip-wic.inc: dont let wic edit fstab by default

Trevor Woerner

#54806

On Wed 2021-09-22 @ 09:09:50 PM, Markus Volk wrote:
---
 conf/machine/include/rockchip-wic.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
 	SPL_BINARY \
 	UBOOT_SUFFIX \
 	"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"Thank you for your patch. Could you please include your Signed-off-by line?

Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Trevor Woerner

#54805

On Wed 2021-09-22 @ 08:49:43 PM, Markus Volk wrote:
Hi,Hi Markus, thanks for your report. I appreciate the feedback!

with this change my rock-pi-4 doesnt boot up and falls to emergency shell
because wic includes wrong devices into fstab. For some reason it assumes
/dev/sda1.The next thing, literally, on my TODO list was to investigate why this is
happening (and fix it). I had noticed it a while back and have been wondering
what is injecting those incorrect lines at the end of our fstab. Thanks for
the patch!

I was able to fix this for my machine by using uuid for all
partitions.Curious. I boot tested my patch on multiple boards and I've built and booted
numerous images on my rock-pi-4b and rock64 boards in the last day or so since
I applied the patch. I'll try some "clean" builds and see if that makes a
difference. I don't doubt your report (especially since Khem confirmed it),
I'd just like to know for myself what's different.

I wonder if just applying your 2nd patch would be enough (i.e. the one that
removes the /dev/sda* lines from /etc/fstab)? It's odd that the first 6
entries in the wic file would need UUIDs since it's the SoC's ROM firmware
that uses them, and I'm pretty sure the Rockchip firmware isn't using UUIDs
(my guess is it's just blindly grabbing whatever it finds at specific
offsets). The things stored in those partitions are u-boot related bits (atf,
spl, the u-boot binary itself) so by the time Linux starts, those things are
already "behind" us. I can't see how adding UUIDs to the partitions holding
u-boot would affect how the kernel finds the root partition (?).

Are you using poky or a distro other than "nodistro"? Perhaps other
layers/distros are affecting the build?

Thanks and best regards,
	Trevor

[meta-rockchip][PATCH 1/2] rockchip.wks: use uuid for all partitions

Markus Volk

#54804

My rock pi 4 refused to boot with the latest changes because there are fa=
lse entries
written to fstab. Fix this by using uuid for all partitions
---
 wic/rockchip.wks | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
 #   boot        32768           229376
 #   root        262144          -           (suggested)
=20
-part loader1    --offset 32     --fixed-size 4000K            --source r=
awcopy                                                 --sourceparams=3D"=
file=3D${SPL_BINARY}"
-part reserved1  --offset 4032   --fixed-size 64K
-part reserved2  --offset 4096   --fixed-size 4096K
-part loader2    --offset 8192   --fixed-size 4096K            --source r=
awcopy                                                 --sourceparams=3D"=
file=3Du-boot.${UBOOT_SUFFIX}"
-part atf        --offset 12288  --fixed-size 4096K
-part /boot      --offset 16384  --size       114688K --active --source b=
ootimg-partition --fstype=3Dvfat --label boot            --sourceparams=3D=
"loader=3Du-boot"
-part /                                                        --source r=
ootfs            --fstype=3Dext4 --label root --use-uuid
+part loader1	--offset 32 --fixed-size 4000K --source rawcopy --sourcepar=
ams=3D"file=3D${SPL_BINARY}" --use-uuid
+part reserved1	--offset 4032 --fixed-size 64K --use-uuid
+part reserved2	--offset 4096 --fixed-size 4096K --use-uuid
+part loader2	--offset 8192 --fixed-size 4096K --source rawcopy --sourcep=
arams=3D"file=3Du-boot.${UBOOT_SUFFIX}" --use-uuid
+part atf	--offset 12288 --fixed-size 4096K --use-uuid
+part /boot	--offset 16384 --size 114688K --active --source bootimg-parti=
tion --fstype=3Dvfat --label boot --sourceparams=3D"loader=3Du-boot" --us=
e-uuid
+part /		--source rootfs --fstype=3Dext4 --label root --use-uuid
=20
-bootloader --ptable gpt --append=3D"console=3Dtty1 console=3D${RK_CONSOL=
E_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=3Dext4 init=3D/sbin/init"
+bootloader	--ptable gpt --append=3D"console=3Dtty1 console=3D${RK_CONSOL=
E_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=3Dext4 init=3D/sbin/init"
--=20
2.25.1

[meta-rockchip][PATCH 2/2] rockchip-wic.inc: dont let wic edit fstab by default

Markus Volk

#54803

---
 conf/machine/include/rockchip-wic.inc | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include=
/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append =3D " \
 	SPL_BINARY \
 	UBOOT_SUFFIX \
 	"
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?=3D "--no-fstab-update"
--=20
2.25.1

Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Khem Raj

#54802

On 9/22/21 11:49 AM, Markus Volk wrote:
Hi,
with this change my rock-pi-4 doesnt boot up and falls to emergency shell because wic includes wrong devices into fstab. For some reason it assumes /dev/sda1. I was able to fix this for my machine by using uuid for all partitions.
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
  #   boot        32768           229376
  #   root        262144          -           (suggested)
-part loader1    --offset 32     --fixed-size 4000K --source rawcopy --sourceparams="file=${SPL_BINARY}"
-part reserved1  --offset 4032   --fixed-size 64K
-part reserved2  --offset 4096   --fixed-size 4096K
-part loader2    --offset 8192   --fixed-size 4096K --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
-part atf        --offset 12288  --fixed-size 4096K
-part /boot      --offset 16384  --size       114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
-part / --source rootfs            --fstype=ext4 --label root --use-uuid
+part loader1   --offset 32 --fixed-size 4000K --source rawcopy --sourceparams="file=${SPL_BINARY}" --use-uuid
+part reserved1 --offset 4032 --fixed-size 64K --use-uuid
+part reserved2 --offset 4096 --fixed-size 4096K --use-uuid
+part loader2   --offset 8192 --fixed-size 4096K --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" --use-uuid
+part atf       --offset 12288 --fixed-size 4096K --use-uuid
+part /boot     --offset 16384 --size 114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot" --use-uuid
+part /         --source rootfs --fstype=ext4 --label root --use-uuid
-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"
+bootloader     --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"
In addition i added an option that avoids editing fstab by wic at all since the image also boots without mounting /boot, but i guess this is just a matter of taste.
diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
         SPL_BINARY \
         UBOOT_SUFFIX \
         "
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"
yes was seeing same. Can you turn this into a patch and send?

Am 18.09.21 um 00:01 schrieb Trevor Woerner:
Recent upstream kernel changes have made the mmc probing order unpredictable.
Therefore, boards with both an emmc and sdmmc interface aren't guaranteed to
boot with a hard-coded root device selected.

For example, on the rock64, with linux-yocto 5.10.y, using the uSD card (i.e.
the sdmmc interface) about 50% of the time the boot would succeed, and roughly
50% of the time it wouldn't:

	...
	[    0.612233] Waiting for root device /dev/mmcblk1p7...
	[    0.634551] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
	[    0.639064] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ di)
	[    0.640007] mmc0: new high speed SDXC card at address 5048
	[    0.641176] mmcblk0: mmc0:5048 SD64G 58.0 GiB
	[    0.647610] random: fast init done
	[    0.648279] GPT:Primary header thinks Alt. header is not at the end of the disk.
	[    0.648941] GPT:376479 != 121634815
	[    0.649252] GPT:Alternate GPT header not at the end of the disk.
	[    0.649796] GPT:376479 != 121634815
	[    0.650106] GPT: Use GNU Parted to correct GPT errors.
	[    0.650598]  mmcblk0: p1 p2 p3 p4 p5 p6 p7

NOTE the discrepancy between the kernel waiting for device /dev/mmcblk1p7,
which comes from the hard-coded kernel cmdline, and the kernel probing putting
the sdmmc on mmcblk0.

With linux-yocto 5.13.y on the rock64 using the uSD card the board would never
boot, the sdmmc always appears on mmcblk0.

Instead of simply changing the hard-coded root device (i.e. from mmcblk0 to
mmcblk1) switch to using partition UUIDs instead. Hard-coding the boot device
would work with 5.13.y but would fail 50% of the time with 5.10.y; who knows
what other kernels will do?

In any case, switching to UUIDs works regardless of board, kernel, or
available mmc interfaces.

Boot tested on:
- rock64
- nanopi-m4-2gb
- tinker-board
- rock-pi-e
- rock-pi-4b

Signed-off-by: Trevor Woerner<twoerner@...>
---
  conf/machine/include/nanopi-m4.inc    |  2 --
  conf/machine/include/rock-pi-4.inc    |  2 --
  conf/machine/include/rockchip-wic.inc |  4 ----
  conf/machine/rock64.conf              |  3 ---
  conf/machine/tinker-board-s.conf      |  2 --
  conf/machine/vyasa-rk3288.conf        |  2 --
  wic/rockchip.wks                      | 16 ++++++++--------
  7 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index ac6479d..3870b51 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -7,5 +7,3 @@ MACHINE_FEATURES += "usbhost serial"
  KMACHINE = "nanopi-m4"
  KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4.dtb"
-
-RK_BOOT_DEVICE = "mmcblk1"
diff --git a/conf/machine/include/rock-pi-4.inc b/conf/machine/include/rock-pi-4.inc
index b6fb3dd..0a86846 100644
--- a/conf/machine/include/rock-pi-4.inc
+++ b/conf/machine/include/rock-pi-4.inc
@@ -3,6 +3,4 @@ MACHINEOVERRIDES =. "rock-pi-4:"
  require conf/machine/include/rk3399.inc
  -RK_BOOT_DEVICE = "mmcblk1"
-
  MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index b5939f7..15010a0 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -20,11 +20,7 @@ IMAGE_BOOT_FILES = " \
  RK_CONSOLE_BAUD ?="${@d.getVar('SERIAL_CONSOLES').split(';')[0]}"
  RK_CONSOLE_DEVICE ?="${@d.getVar('SERIAL_CONSOLES').split(';')[1].split()[0]}"
  -# boot device (sd-card/emmc)
-RK_BOOT_DEVICE ??= "mmcblk0"
-
  WICVARS:append = " \
-	RK_BOOT_DEVICE \
  	RK_CONSOLE_BAUD \
  	RK_CONSOLE_DEVICE \
  	SPL_BINARY \
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
index 21755a8..fa75a51 100644
--- a/conf/machine/rock64.conf
+++ b/conf/machine/rock64.conf
@@ -12,7 +12,4 @@ MACHINE_FEATURES += "usbhost serial"
  UBOOT_MACHINE = "rock64-rk3328_defconfig"
  KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
  -# set to mmcblk0 for booting from optional eMMC
-RK_BOOT_DEVICE ?= "mmcblk1"
-
  KBUILD_DEFCONFIG = "defconfig"
diff --git a/conf/machine/tinker-board-s.conf b/conf/machine/tinker-board-s.conf
index 9f44f2f..870b9bc 100644
--- a/conf/machine/tinker-board-s.conf
+++ b/conf/machine/tinker-board-s.conf
@@ -9,5 +9,3 @@ require conf/machine/include/tinker.inc
  KERNEL_DEVICETREE = "rk3288-tinker-s.dtb"
  UBOOT_MACHINE = "tinker-s-rk3288_defconfig"
-
-RK_BOOT_DEVICE ?= "mmcblk1"
diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
index 9ad1ed4..5b44257 100644
--- a/conf/machine/vyasa-rk3288.conf
+++ b/conf/machine/vyasa-rk3288.conf
@@ -13,5 +13,3 @@ KERNEL_DEVICETREE = "rk3288-vyasa.dtb"
  KERNEL_EXTRA_ARGS += "LOADADDR=0x02000000"
  UBOOT_MACHINE = "vyasa-rk3288_defconfig"
-
-RK_BOOT_DEVICE = "mmcblk2"
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index eedae0d..5ee276b 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
  #   boot        32768           229376
  #   root        262144          -           (suggested)
  -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.${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
+part loader1    --offset 32     --fixed-size 4000K            --source rawcopy                                                 --sourceparams="file=${SPL_BINARY}"
+part reserved1  --offset 4032   --fixed-size 64K
+part reserved2  --offset 4096   --fixed-size 4096K
+part loader2    --offset 8192   --fixed-size 4096K            --source rawcopy                                                 --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
+part atf        --offset 12288  --fixed-size 4096K
+part /boot      --offset 16384  --size       114688K --active --source bootimg-partition --fstype=vfat --label boot            --sourceparams="loader=u-boot"
+part /                                                        --source rootfs            --fstype=ext4 --label root --use-uuid
  -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"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"

Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device

Markus Volk

#54801

Hi,

with this change my rock-pi-4 doesnt boot up and falls to emergency shell because wic includes wrong devices into fstab. For some reason it assumes /dev/sda1. I was able to fix this for my machine by using uuid for all partitions.

diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index 5ee276b..90bdb27 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
#   boot        32768           229376
#   root        262144          -           (suggested)

-part loader1    --offset 32     --fixed-size 4000K            --source rawcopy                                                 --sourceparams="file=${SPL_BINARY}"
-part reserved1 --offset 4032   --fixed-size 64K
-part reserved2 --offset 4096   --fixed-size 4096K
-part loader2    --offset 8192   --fixed-size 4096K            --source rawcopy                                                 --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
-part atf        --offset 12288 --fixed-size 4096K
-part /boot      --offset 16384 --size       114688K --active --source bootimg-partition --fstype=vfat --label boot            --sourceparams="loader=u-boot"
-part /                                                        --source rootfs            --fstype=ext4 --label root --use-uuid
+part loader1   --offset 32 --fixed-size 4000K --source rawcopy --sourceparams="file=${SPL_BINARY}" --use-uuid
+part reserved1 --offset 4032 --fixed-size 64K --use-uuid
+part reserved2 --offset 4096 --fixed-size 4096K --use-uuid
+part loader2   --offset 8192 --fixed-size 4096K --source rawcopy --sourceparams="file=u-boot.${UBOOT_SUFFIX}" --use-uuid
+part atf       --offset 12288 --fixed-size 4096K --use-uuid
+part /boot     --offset 16384 --size 114688K --active --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot" --use-uuid
+part /         --source rootfs --fstype=ext4 --label root --use-uuid

-bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"
+bootloader     --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"

In addition i added an option that avoids editing fstab by wic at all since the image also boots without mounting /boot, but i guess this is just a matter of taste.

diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index 15010a0..30b0d57 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -26,3 +26,6 @@ WICVARS:append = " \
        SPL_BINARY \
        UBOOT_SUFFIX \
        "
+
+# Do not update fstab file while creating wic images
+WIC_CREATE_EXTRA_ARGS ?= "--no-fstab-update"

Am 18.09.21 um 00:01 schrieb Trevor Woerner:

Show quoted text

Recent upstream kernel changes have made the mmc probing order unpredictable.
Therefore, boards with both an emmc and sdmmc interface aren't guaranteed to
boot with a hard-coded root device selected.

For example, on the rock64, with linux-yocto 5.10.y, using the uSD card (i.e.
the sdmmc interface) about 50% of the time the boot would succeed, and roughly
50% of the time it wouldn't:

	...
	[    0.612233] Waiting for root device /dev/mmcblk1p7...
	[    0.634551] mmc_host mmc1: Bus speed (slot 0) = 300000Hz (slot req 300000Hz, actual 300000HZ div = 0)
	[    0.639064] mmc_host mmc0: Bus speed (slot 0) = 50000000Hz (slot req 50000000Hz, actual 50000000HZ di)
	[    0.640007] mmc0: new high speed SDXC card at address 5048
	[    0.641176] mmcblk0: mmc0:5048 SD64G 58.0 GiB
	[    0.647610] random: fast init done
	[    0.648279] GPT:Primary header thinks Alt. header is not at the end of the disk.
	[    0.648941] GPT:376479 != 121634815
	[    0.649252] GPT:Alternate GPT header not at the end of the disk.
	[    0.649796] GPT:376479 != 121634815
	[    0.650106] GPT: Use GNU Parted to correct GPT errors.
	[    0.650598]  mmcblk0: p1 p2 p3 p4 p5 p6 p7

NOTE the discrepancy between the kernel waiting for device /dev/mmcblk1p7,
which comes from the hard-coded kernel cmdline, and the kernel probing putting
the sdmmc on mmcblk0.

With linux-yocto 5.13.y on the rock64 using the uSD card the board would never
boot, the sdmmc always appears on mmcblk0.

Instead of simply changing the hard-coded root device (i.e. from mmcblk0 to
mmcblk1) switch to using partition UUIDs instead. Hard-coding the boot device
would work with 5.13.y but would fail 50% of the time with 5.10.y; who knows
what other kernels will do?

In any case, switching to UUIDs works regardless of board, kernel, or
available mmc interfaces.

Boot tested on:
- rock64
- nanopi-m4-2gb
- tinker-board
- rock-pi-e
- rock-pi-4b

Signed-off-by: Trevor Woerner <twoerner@...>
---
 conf/machine/include/nanopi-m4.inc    |  2 --
 conf/machine/include/rock-pi-4.inc    |  2 --
 conf/machine/include/rockchip-wic.inc |  4 ----
 conf/machine/rock64.conf              |  3 ---
 conf/machine/tinker-board-s.conf      |  2 --
 conf/machine/vyasa-rk3288.conf        |  2 --
 wic/rockchip.wks                      | 16 ++++++++--------
 7 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index ac6479d..3870b51 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -7,5 +7,3 @@ MACHINE_FEATURES += "usbhost serial"
 
 KMACHINE = "nanopi-m4"
 KERNEL_DEVICETREE = "rockchip/rk3399-nanopi-m4.dtb"
-
-RK_BOOT_DEVICE = "mmcblk1"
diff --git a/conf/machine/include/rock-pi-4.inc b/conf/machine/include/rock-pi-4.inc
index b6fb3dd..0a86846 100644
--- a/conf/machine/include/rock-pi-4.inc
+++ b/conf/machine/include/rock-pi-4.inc
@@ -3,6 +3,4 @@ MACHINEOVERRIDES =. "rock-pi-4:"
 
 require conf/machine/include/rk3399.inc
 
-RK_BOOT_DEVICE = "mmcblk1"
-
 MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include/rockchip-wic.inc
index b5939f7..15010a0 100644
--- a/conf/machine/include/rockchip-wic.inc
+++ b/conf/machine/include/rockchip-wic.inc
@@ -20,11 +20,7 @@ IMAGE_BOOT_FILES = " \
 RK_CONSOLE_BAUD ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[0]}"
 RK_CONSOLE_DEVICE ?= "${@d.getVar('SERIAL_CONSOLES').split(';')[1].split()[0]}"
 
-# boot device (sd-card/emmc)
-RK_BOOT_DEVICE ??= "mmcblk0"
-
 WICVARS:append = " \
-	RK_BOOT_DEVICE \
 	RK_CONSOLE_BAUD \
 	RK_CONSOLE_DEVICE \
 	SPL_BINARY \
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
index 21755a8..fa75a51 100644
--- a/conf/machine/rock64.conf
+++ b/conf/machine/rock64.conf
@@ -12,7 +12,4 @@ MACHINE_FEATURES += "usbhost serial"
 UBOOT_MACHINE = "rock64-rk3328_defconfig"
 KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
 
-# set to mmcblk0 for booting from optional eMMC
-RK_BOOT_DEVICE ?= "mmcblk1"
-
 KBUILD_DEFCONFIG = "defconfig"
diff --git a/conf/machine/tinker-board-s.conf b/conf/machine/tinker-board-s.conf
index 9f44f2f..870b9bc 100644
--- a/conf/machine/tinker-board-s.conf
+++ b/conf/machine/tinker-board-s.conf
@@ -9,5 +9,3 @@ require conf/machine/include/tinker.inc
 
 KERNEL_DEVICETREE = "rk3288-tinker-s.dtb"
 UBOOT_MACHINE = "tinker-s-rk3288_defconfig"
-
-RK_BOOT_DEVICE ?= "mmcblk1"
diff --git a/conf/machine/vyasa-rk3288.conf b/conf/machine/vyasa-rk3288.conf
index 9ad1ed4..5b44257 100644
--- a/conf/machine/vyasa-rk3288.conf
+++ b/conf/machine/vyasa-rk3288.conf
@@ -13,5 +13,3 @@ KERNEL_DEVICETREE = "rk3288-vyasa.dtb"
 KERNEL_EXTRA_ARGS += "LOADADDR=0x02000000"
 
 UBOOT_MACHINE = "vyasa-rk3288_defconfig"
-
-RK_BOOT_DEVICE = "mmcblk2"
diff --git a/wic/rockchip.wks b/wic/rockchip.wks
index eedae0d..5ee276b 100644
--- a/wic/rockchip.wks
+++ b/wic/rockchip.wks
@@ -15,12 +15,12 @@
 #   boot        32768           229376
 #   root        262144          -           (suggested)
 
-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.${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
+part loader1    --offset 32     --fixed-size 4000K            --source rawcopy                                                 --sourceparams="file=${SPL_BINARY}"
+part reserved1  --offset 4032   --fixed-size 64K
+part reserved2  --offset 4096   --fixed-size 4096K
+part loader2    --offset 8192   --fixed-size 4096K            --source rawcopy                                                 --sourceparams="file=u-boot.${UBOOT_SUFFIX}"
+part atf        --offset 12288  --fixed-size 4096K
+part /boot      --offset 16384  --size       114688K --active --source bootimg-partition --fstype=vfat --label boot            --sourceparams="loader=u-boot"
+part /                                                        --source rootfs            --fstype=ext4 --label root --use-uuid
 
-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"
+bootloader --ptable gpt --append="console=tty1 console=${RK_CONSOLE_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=ext4 init=/sbin/init"