Date   

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

Trevor Woerner
 

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
 

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
 

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
 

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

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
 

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:

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"




[WIC] bootimg-partition plugin

Rudolf J Streif
 

A not so well-known feature of the WIC bootimg-partition plugin is that it can install files into different partitions. For that the variable IMAGE_BOOT_FILES has to be defined as one of the following:

IMAGE_BOOT_FILES_label-<partlabel> = "..."

IMAGE_BOOT_FILES_uuid-<partuuid> = "..."

The plugin will then use either the partition label or the partition uuid from the WKS file "part" directive to look up the correct file list variable.

This code snippet from the plugin (poky/scripts/lib/wic/plugins/source/bootimg-partition.py) is supposed to do the trick:

 50         boot_files = None
 51         for (fmt, id) in (("_uuid-%s", part.uuid), ("_label-%s", part.label), (None, None)):
 52             if fmt:
 53                 var = fmt % id
 54             else:
 55                 var = ""
 56
 57             print('var: ', var)
 58
 59             boot_files = get_bitbake_var("IMAGE_BOOT_FILES" + var)
 60             if boot_files is not None:
 61                 break

<<<<<

However, the function get_bitbake_var() from poky/scripts/lib/wic/misc.py uses the the WIC environment which is created from the WICVARS variable by the poky/meta/classes/image_types_wic.bbclass. WICVARS is defined at the beginning of the class and contains all bitbake variables relevant to WIC. It of course includes the plain IMAGE_BOOT_FILES. When the class creates the environment (do_rootfs_wicenv) is simply splits WICVARS and looks up the variables one-by-one in the DataSmart dictionary (d.getVar(<varname>). Since this is a key lookup it will not match any variables for IMAGE_BOOT_FILES_label-<partlabel> and/or IMAGE_BOOT_FILES_uuid-<partuuid>.

For this to work there should be a lookup in DataSmart that supports getVar() with a wildcard or "starts with". I am not all into the details of DataSmart and maybe there is something like this already and I just don't know about it. Hence the question here before I start hacking a kludge into the image_types_wic class.

Thanks,

Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: googletest shared library

Lijun Chen
 

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: Permission denied with NFS shared download and sstate-cache

Richard Purdie
 

On Wed, 2021-09-22 at 09:51 -0700, Khem Raj wrote:
On Wed, Sep 22, 2021 at 9:47 AM Bel Hadj Salem Talel <bhstalel@...> wrote:

Hi All,

I have a server that's holding downloads and sstate-cache.

I have a docker-compose file with nfs server that exposes the dowloads/sstate-cache volume.

When I mount that in my PC and set the path into DL_DIR and SSTATE_DIR, I get this error :

---------------
ERROR: grub-efi-native-2.04-r0 do_configure: Build of do_configure failed
ERROR: grub-efi-native-2.04-r0 do_configure: Traceback (most recent call last):
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/build.py", line 644, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/build.py", line 618, in _exec_task
event.fire(TaskSucceeded(task, fn, logfn, localdata), localdata)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 215, in fire
fire_class_handlers(event, d)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 122, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 94, in execute_handler
ret = handler(event)
File "/home/talel/Desktop/YoctoWork/sources/poky/meta/classes/sstate.bbclass", line 1094, in sstate_eventhandler
bb.siggen.dump_this_task(sstatepkg + '_' + taskname + ".tgz" ".siginfo", d)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/siggen.py", line 648, in dump_this_task
bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile:" + referencestamp)
File "/home/talel/Desktop/YoctoWork/sources/poky/meta/lib/oe/sstatesig.py", line 202, in dump_sigtask
super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn, task, stampbase, runtime)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/siggen.py", line 362, in dump_sigtask
fd, tmpfile = tempfile.mkstemp(dir=os.path.dirname(sigfile), prefix="sigtask.")
File "/usr/lib/python3.8/tempfile.py", line 470, in mkstemp
return _mkstemp_inner(dir, prefix, suffix, flags, output_type)
File "/usr/lib/python3.8/tempfile.py", line 389, in _mkstemp_inner
fd = _os.open(file, flags, 0o600)
its trying to create the file with 0600 mask. I wonder whats your
global umask set to. and perhaps the user is not same when bitbake it
running ?
The file is being created with python's tempfile function which will make it
secure. Secure in this context means 00600...

I suspect you're right that creating a file securely here with this permissions
likely can't work.

Cheers,

Richard


[PATCH yocto-autobuilder-helper] scripts/collect-results: publish everything in tmp/log/oeqa

Alexander Kanavin
 

From: Alexander Kanavin <alex@...>

In addition to the testresult json, testimage class now also
provides task logs and qemu console output (splitted into
folders by image name to avoid clutter), which can be useful
for debugging test failures or even checking qemu test runs
when failures did not happen.

Rather than duplicate specific file/folder names, let's copy all
that is available, and define what is published in the testimage
class itself.

[YOCTO #14518]

Signed-off-by: Alexander Kanavin <alex@...>
Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
scripts/collect-results | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/scripts/collect-results b/scripts/collect-results
index 93834d6..3663330 100755
--- a/scripts/collect-results
+++ b/scripts/collect-results
@@ -3,11 +3,9 @@ WORKDIR=$1
DEST=$2
target=$3

-RESFILE=$WORKDIR/tmp/log/oeqa/testresults.json
-
-if [ -e $RESFILE ]; then
- mkdir -p $DEST/$target
- cp $WORKDIR/tmp/log/oeqa/testresults.json $DEST/$target/
+mkdir -p $DEST
+if [ -e $WORKDIR/tmp/log/oeqa/ ]; then
+ cp -rf $WORKDIR/tmp/log/oeqa/ $DEST/$target
fi

if [ -e $WORKDIR/buildhistory ]; then
--
2.31.1


Re: Permission denied with NFS shared download and sstate-cache

Khem Raj
 

On Wed, Sep 22, 2021 at 9:47 AM Bel Hadj Salem Talel <bhstalel@...> wrote:

Hi All,

I have a server that's holding downloads and sstate-cache.

I have a docker-compose file with nfs server that exposes the dowloads/sstate-cache volume.

When I mount that in my PC and set the path into DL_DIR and SSTATE_DIR, I get this error :

---------------
ERROR: grub-efi-native-2.04-r0 do_configure: Build of do_configure failed
ERROR: grub-efi-native-2.04-r0 do_configure: Traceback (most recent call last):
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/build.py", line 644, in exec_task
return _exec_task(fn, task, d, quieterr)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/build.py", line 618, in _exec_task
event.fire(TaskSucceeded(task, fn, logfn, localdata), localdata)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 215, in fire
fire_class_handlers(event, d)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 122, in fire_class_handlers
execute_handler(name, handler, event, d)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 94, in execute_handler
ret = handler(event)
File "/home/talel/Desktop/YoctoWork/sources/poky/meta/classes/sstate.bbclass", line 1094, in sstate_eventhandler
bb.siggen.dump_this_task(sstatepkg + '_' + taskname + ".tgz" ".siginfo", d)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/siggen.py", line 648, in dump_this_task
bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile:" + referencestamp)
File "/home/talel/Desktop/YoctoWork/sources/poky/meta/lib/oe/sstatesig.py", line 202, in dump_sigtask
super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn, task, stampbase, runtime)
File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/siggen.py", line 362, in dump_sigtask
fd, tmpfile = tempfile.mkstemp(dir=os.path.dirname(sigfile), prefix="sigtask.")
File "/usr/lib/python3.8/tempfile.py", line 470, in mkstemp
return _mkstemp_inner(dir, prefix, suffix, flags, output_type)
File "/usr/lib/python3.8/tempfile.py", line 389, in _mkstemp_inner
fd = _os.open(file, flags, 0o600)
its trying to create the file with 0600 mask. I wonder whats your
global umask set to. and perhaps the user is not same when bitbake it
running ?

PermissionError: [Errno 13] Permission denied: '/home/talel/Desktop/YoctoShare/tethys-cache/ubuntu-20.04/dd/sigtask.dgjx7ngq'

ERROR: Task (virtual:native:/home/talel/Desktop/YoctoWork/sources/poky/meta/recipes-bsp/grub/grub-efi_2.04.bb:do_configure) failed with exit code '1'
---------------

I can modify the mounted folder by creating a directory or a file, but it fails with yocto.

How can I solve the issue?

Thanks,
Talel


Permission denied with NFS shared download and sstate-cache

Bel Hadj Salem Talel <bhstalel@...>
 

Hi All,

I have a server that's holding downloads and sstate-cache.

I have a docker-compose file with nfs server that exposes the dowloads/sstate-cache volume.

When I mount that in my PC and set the path into DL_DIR and SSTATE_DIR, I get this error :

---------------
ERROR: grub-efi-native-2.04-r0 do_configure: Build of do_configure failed
ERROR: grub-efi-native-2.04-r0 do_configure: Traceback (most recent call last):
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/build.py", line 644, in exec_task
    return _exec_task(fn, task, d, quieterr)
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/build.py", line 618, in _exec_task
    event.fire(TaskSucceeded(task, fn, logfn, localdata), localdata)
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 215, in fire
    fire_class_handlers(event, d)
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 122, in fire_class_handlers
    execute_handler(name, handler, event, d)
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/event.py", line 94, in execute_handler
    ret = handler(event)
  File "/home/talel/Desktop/YoctoWork/sources/poky/meta/classes/sstate.bbclass", line 1094, in sstate_eventhandler
    bb.siggen.dump_this_task(sstatepkg + '_' + taskname + ".tgz" ".siginfo", d)
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/siggen.py", line 648, in dump_this_task
    bb.parse.siggen.dump_sigtask(fn, task, outfile, "customfile:" + referencestamp)
  File "/home/talel/Desktop/YoctoWork/sources/poky/meta/lib/oe/sstatesig.py", line 202, in dump_sigtask
    super(bb.siggen.SignatureGeneratorBasicHash, self).dump_sigtask(fn, task, stampbase, runtime)
  File "/home/talel/Desktop/YoctoWork/sources/poky/bitbake/lib/bb/siggen.py", line 362, in dump_sigtask
    fd, tmpfile = tempfile.mkstemp(dir=os.path.dirname(sigfile), prefix="sigtask.")
  File "/usr/lib/python3.8/tempfile.py", line 470, in mkstemp
    return _mkstemp_inner(dir, prefix, suffix, flags, output_type)
  File "/usr/lib/python3.8/tempfile.py", line 389, in _mkstemp_inner
    fd = _os.open(file, flags, 0o600)
PermissionError: [Errno 13] Permission denied: '/home/talel/Desktop/YoctoShare/tethys-cache/ubuntu-20.04/dd/sigtask.dgjx7ngq'

ERROR: Task (virtual:native:/home/talel/Desktop/YoctoWork/sources/poky/meta/recipes-bsp/grub/grub-efi_2.04.bb:do_configure) failed with exit code '1'
---------------

I can modify the mounted folder by creating a directory or a file, but it fails with yocto.

How can I solve the issue?

Thanks,
Talel


Re: googletest shared library

Khem Raj
 

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.


[PATCH][dunfell] config.json: Ensure BB_HASHSERVE is set in SDKs to auto

Steve Sakoman
 

From: Richard Purdie <richard.purdie@...>

Signed-off-by: Richard Purdie <richard.purdie@...>
(cherry picked from commit 4689763b513521fc70cca576b88035de240a3ba6)
Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 571ddae..fa475e3 100644
--- a/config.json
+++ b/config.json
@@ -31,7 +31,7 @@
"DLDIR" : "DL_DIR = '${BASE_SHAREDDIR}/current_sources'",
"SSTATEDIR" : ["SSTATE_DIR ?= '${BASE_SHAREDDIR}/pub/sstate-dunfell'"],
"SSTATEDIR_RELEASE" : ["SSTATE_MIRRORS += 'file://.* file://${BASE_SHAREDDIR}/pub/sstate-dunfell/PATH'", "SSTATE_DIR ?= '${BASE_PUBLISHDIR}/sstate/@RELEASENUM@'"],
- "SDKEXTRAS" : ["SSTATE_MIRRORS += '\\", "file://.* http://sstate.yoctoproject.org/dev/@RELEASENUM@PATH;downloadfilename=PATH'"],
+ "SDKEXTRAS" : ["SSTATE_MIRRORS += '\\", "file://.* http://sstate.yoctoproject.org/dev/@RELEASENUM@PATH;downloadfilename=PATH'", "BB_HASHSERVE = 'auto'"],
"BUILDINFO" : false,
"BUILDHISTORY" : false,
"BUILDINFOVARS" : ["INHERIT += 'image-buildinfo'", "IMAGE_BUILDINFO_VARS_append = ' IMAGE_BASENAME IMAGE_NAME'"],
--
2.25.1


Re: googletest shared library

Lijun Chen
 

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$ 
(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.


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

Teoh, Jay Shen
 

Hi all,

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

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

1 new issue found

BUG id:14557 - oe_syslog.SyslogTestConfig.test_syslog_startup_config failure

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

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Thursday, 16 September, 2021 2:36 PM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.11.rc2)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.11.rc2


Build hash information:

bitbake: c2a3bda3a29e12472ef7862e424ea1552fab2959
meta-agl: 60344efa7a50dc2548fc4b5d68b5ad4d60c4023a
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: c5164c1a795c21f7caccc3b68bb2e81a55bddb0e
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 6837552365d3cac5f8044a5ae910aa874435f766
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 2e7e98cd0cb82db214b13224c71134b9335a719b
oecore: c7d2281eb6cda9c1637c20b3540b142073bca235
poky: 74b22db6879b388d700f61e08cb3f239cf940d18



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







Re: Switch to a different Python3 version

Richard Purdie
 

On Tue, 2021-09-21 at 20:00 +0000, Lijun Chen wrote:
Hi,

Currently we are building a Yocto image based on Hardknott release, which
includes python 3.9.4. Due to a App constraint, we have to downgrade Python3
to 3.8. I tried copying over 3.8.5 bb file andassociated poky/meta/recipes-
devtools/python/python3/ folder, but the building failed. What is the best way
to switch/downgrade python3 version?
Hard to say without understanding how it failed. What was the error?

You probably need to match python3 and python3-native versions but I don't know
if you did.

Cheers,

Richard


Re: Switch to a different Python3 version

Alexander Kanavin
 

The best way is to fix the app. Such major downgrades are firmly uncharted territory, and aren't supported. If you have errors, you need to figure out yourself how to fix them - but if you provide the logs, we can try to help.

Alex


On Tue, 21 Sept 2021 at 22:00, Lijun Chen <lijchen@...> wrote:

Hi,


Currently we are building a Yocto image based on Hardknott release, which includes python 3.9.4. Due to a App constraint, we have to downgrade Python3 to 3.8. I tried copying over 3.8.5 bb file and associated poky/meta/recipes-devtools/python/python3/ folder, but the building failed. What is the best way to switch/downgrade python3 version?


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.




Switch to a different Python3 version

Lijun Chen
 

Hi,


Currently we are building a Yocto image based on Hardknott release, which includes python 3.9.4. Due to a App constraint, we have to downgrade Python3 to 3.8. I tried copying over 3.8.5 bb file and associated poky/meta/recipes-devtools/python/python3/ folder, but the building failed. What is the best way to switch/downgrade python3 version?


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: googletest shared library

Lijun Chen
 

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$ 
(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.

3021 - 3040 of 57790