Date   

Re: Would COMPATIBLE_IMAGE make sense?

Josef Holzmayr
 

Howdy!

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

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

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

Greetz

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


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

shoaib akhtar
 

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

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

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

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


Re: Would COMPATIBLE_IMAGE make sense?

Frederic Martinsons <frederic.martinsons@...>
 

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

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

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

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

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

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

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

How bad of an idea is that?

Thanks in advance,
Jonas





M+ & H bugs with Milestone Movements WW26

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

6428

Improve the ability to isolate changes that have caused a rebuild

randy.macleod@...

unassigned@...

3.99

3.4 M2

 

11361

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

randy.macleod@...

sakib.sajal@...

3.99

3.4 M3

 

12279

enhance manifest not found warning

kai.kang@...

kai.kang@...

3.4 M1

3.4 M4

 

12342

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

randy.macleod@...

unassigned@...

3.4 M4

3.4 M3

 

 

kai.kang@...

unassigned@...

3.4 M1

3.4 M4

 

13025

WIC image install support

kexin.hao@...

kexin.hao@...

3.4 M1

3.5

 

14099

PACKAGE_EXCLUDE not removing packages when PACKAGE_CLASSES = "package_deb"

randy.macleod@...

unassigned@...

3.4 M1

3.4 M3

 

14125

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

randy.macleod@...

shachar@...

3.4 M1

3.4 M2

 

14163

libevent arm ptest intermittent failure

randy.macleod@...

yf3yu@...

3.4 M1

3.4 M2

 

14244

util-linux script:_size ptest failure

randy.macleod@...

unassigned@...

3.4 M4

3.4 M3

 

 

kai.kang@...

unassigned@...

3.4 M1

3.4 M4

 

14339

bitbake generates zombie Parser processes (hard to reproduce)

randy.macleod@...

randy.macleod@...

3.4 M1

3.4 M3

 

14434

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

yi.zhao@...

yi.zhao@...

3.4 M2

0.0.0

 

14444

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

randy.macleod@...

raj.khem@...

3.4

3.4 M2

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW26!

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

3

bruce.ashfield@...

1

Grand Total

4

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

32

ross@...

31

michael.opdenacker@...

26

david.reyna@...

22

bruce.ashfield@...

21

JPEWhacker@...

12

bluelightning@...

12

akuster808@...

12

sakib.sajal@...

11

timothy.t.orling@...

11

trevor.gamblin@...

11

tony.tascioglu@...

9

randy.macleod@...

9

kai.kang@...

7

raj.khem@...

6

Qi.Chen@...

6

hongxu.jia@...

6

mingli.yu@...

6

yi.zhao@...

5

chee.yang.lee@...

5

alexandre.belloni@...

4

mostthingsweb@...

3

mshah@...

2

ydirson@...

2

pokylinux@...

2

jaewon@...

2

yf3yu@...

2

alejandro@...

2

mister_rs@...

1

jon.mason@...

1

devendra.tewari@...

1

Martin.Jansa@...

1

shachar@...

1

thomas.perrot@...

1

john.kaldas.enpj@...

1

kexin.hao@...

1

diego.sueiro@...

1

open.source@...

1

mhalstead@...

1

naveen.kumar.saini@...

1

stacygaikovaia@...

1

kergoth@...

1

yoctoproject@...

1

liezhi.yang@...

1

nicolas.dechesne@...

1

jeanmarie.lemetayer@...

1

douglas.royds@...

1

aehs29@...

1

mark.hatle@...

1

matthewzmd@...

1

saul.wold@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Would COMPATIBLE_IMAGE make sense?

Jonas Vautherin
 

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

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

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

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

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

How bad of an idea is that?

Thanks in advance,
Jonas


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

Trevor Woerner
 

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

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

Built-tested for every MACHINE in this BSP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


[meta-rockchip][PATCH 2/3] IMAGE_FSTYPES: remove ext4

Trevor Woerner
 

The ext4 IMAGE_FSTYPES does not need to be mentioned explicitly. It will be
automatically generated in cases where it is needed.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index b41c523..0666119 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -22,4 +22,3 @@ XSERVER = " \

# misc
SERIAL_CONSOLES ?= "1500000;ttyS2"
-IMAGE_FSTYPES += "ext4"
--
2.30.0.rc0


[meta-rockchip][PATCH 1/3] conf/machine/include/nanopi-m4.inc: add full include path

Trevor Woerner
 

Specify the full include path to the rk3399.inc file.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/nanopi-m4.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index 7ca91db..b5251a1 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -1,7 +1,7 @@
# Copyright (C) 2021 Blade SAS
# Common definitions for all NanoPi M4 RK3399 board variants

-require rk3399.inc
+require conf/machine/include/rk3399.inc

MACHINE_FEATURES += "usbhost serial"

--
2.30.0.rc0


Re: [meta-rockchip][PATCH] conf/machine/include/rockchip-wic.inc: create

Trevor Woerner
 

On Fri 2021-06-25 @ 09:54:46 AM, Trevor Woerner via lists.yoctoproject.org wrote:
Create a conf/machine/include/rockchip-wic.inc file to contain all the common
wic/wks things for easy inclusion by any MACHINEs that use wic for their image
creation.

NOTE: the wic image type of rock-pi-e changed from "wic.xz" to "wic" which
matches all the other meta-rockchip MACHINEs that use wic

The following variables were checked before and after to make sure they remain
correct/sensible:
- IMAGE_FSTYPES
- WKS_FILE_DEPENDS
- IMAGE_BOOT_FILES
- RK_CONSOLE_BAUD
- RK_CONSOLE_DEVICE
- RK_BOOT_DEVICE
- SERIAL_CONSOLES
- WICVARS

Build-tested for all currently-defined MACHINEs.

Boot-tested on the following boards to make sure they continue to boot to a
console correctly (core-image-base):
- tinker-board
- rock64
- rock-pi-4b
- rock-pi-e
- nanopi-m4-2gb

Signed-off-by: Trevor Woerner <twoerner@...>
Applied to meta-rockchip master.


Re: [OE-core] Hardknott (GCC10) Compiler Issues

Zoran
 

The target system should be independent of buildtools version and the target
system should also be binary reproducible so if that were changing through
changing buildtools tarball, that would be worrying in itself.
Even better, the rootfs built by YOCTO could be used, but anyone can
build U-Boot and kernel outside of the YOCTO, using their own cross
compilers (I use Fedora 33 ARM cross compilers, since my Linux host is
Fedora 33).

Then to install all the different components on the SDcard for the
target system.

And see if the issue repeats itself...

Zee
_______

On Mon, Jun 28, 2021 at 2:49 PM Richard Purdie
<richard.purdie@...> wrote:

On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote:
All,

Please accept my apologies in advance for the detailed submission. I think
it is warranted in this case.

There is something... "odd" about the GCC 10 compiler that is delivered with
Hardknott. I am still chasing it down, so I am not yet ready to declare a
root cause or submit a bug, but I am posting what I have now in case anyone
has some insights to offer.
The issue you describe does sound strange. I was a little unclear about exactly
which combinations were passing/failing. Are you saying that some versions of
buildtools let the system work but some do not? We now have gcc 11 in master
so it would be interesting to know how things worked there and if any
regression was fixed.

I have also heard reports of issues with bison segfaulting from other sources
but I don't have anything I can point to specifically about it.

The target system should be independent of buildtools version and the target
system should also be binary reproducible so if that were changing through
changing buildtools tarball, that would be worrying in itself.

P.P.S. For the sake of completeness, I had to add the following files to the buildtools-extended
sysroot to fully complete the build of our images:

/usr/include/magic.h -> util-linux "more" command requires this.
/usr/include/zstd.h -> I do not recall which recipe required this.
/usr/bin/free -> The OpenJDK 8 build scripts need this.
/usr/include/sys/* -> openjdk-8-native
/lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build without this. I am not a fan of the
lack of error checking in the binutils build...
/usr/include/sensors/error.h and sensors.h -> mesa-native
/usr/include/zstd_errors.h -> qemu-system-native
It is great to have this list, outside the non-jdk issues are probably issues we
should look at fixing in OE-Core. Do you mean binutils above for the dir command?

Cheers,




Re: [OE-core] Hardknott (GCC10) Compiler Issues

Zoran
 

At least seems that GCC 10.2 is not the cause of the problem for my
cannelloni recipe issue:

https://github.com/mguentner/cannelloni/issues/35

The same error repeats itself with GCC 11.2 (in hardknott).

The issue is most probably optimizing GCC switches and Include paths
in further cannelloni commits (after release 1.0.0, which compiles
with both 10.2 and 11.1 fine).

Best Regards,
Zee
_______

On Mon, Jun 28, 2021 at 2:49 PM Richard Purdie
<richard.purdie@...> wrote:

On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote:
All,

Please accept my apologies in advance for the detailed submission. I think
it is warranted in this case.

There is something... "odd" about the GCC 10 compiler that is delivered with
Hardknott. I am still chasing it down, so I am not yet ready to declare a
root cause or submit a bug, but I am posting what I have now in case anyone
has some insights to offer.
The issue you describe does sound strange. I was a little unclear about exactly
which combinations were passing/failing. Are you saying that some versions of
buildtools let the system work but some do not? We now have gcc 11 in master
so it would be interesting to know how things worked there and if any
regression was fixed.

I have also heard reports of issues with bison segfaulting from other sources
but I don't have anything I can point to specifically about it.

The target system should be independent of buildtools version and the target
system should also be binary reproducible so if that were changing through
changing buildtools tarball, that would be worrying in itself.

P.P.S. For the sake of completeness, I had to add the following files to the buildtools-extended
sysroot to fully complete the build of our images:

/usr/include/magic.h -> util-linux "more" command requires this.
/usr/include/zstd.h -> I do not recall which recipe required this.
/usr/bin/free -> The OpenJDK 8 build scripts need this.
/usr/include/sys/* -> openjdk-8-native
/lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build without this. I am not a fan of the
lack of error checking in the binutils build...
/usr/include/sensors/error.h and sensors.h -> mesa-native
/usr/include/zstd_errors.h -> qemu-system-native
It is great to have this list, outside the non-jdk issues are probably issues we
should look at fixing in OE-Core. Do you mean binutils above for the dir command?

Cheers,




Re: [OE-core] Hardknott (GCC10) Compiler Issues

Richard Purdie
 

On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote:
All,

Please accept my apologies in advance for the detailed submission. I think 
it is warranted in this case.

There is something... "odd" about the GCC 10 compiler that is delivered with 
Hardknott. I am still chasing it down, so I am not yet ready to declare a 
root cause or submit a bug, but I am posting what I have now in case anyone 
has some insights to offer.
The issue you describe does sound strange. I was a little unclear about exactly
which combinations were passing/failing. Are you saying that some versions of 
buildtools let the system work but some do not? We now have gcc 11 in master 
so it would be interesting to know how things worked there and if any 
regression was fixed.

I have also heard reports of issues with bison segfaulting from other sources
but I don't have anything I can point to specifically about it.

The target system should be independent of buildtools version and the target
system should also be binary reproducible so if that were changing through
changing buildtools tarball, that would be worrying in itself.

P.P.S. For the sake of completeness, I had to add the following files to the buildtools-extended
sysroot to fully complete the build of our images:

/usr/include/magic.h -> util-linux "more" command requires this.
/usr/include/zstd.h -> I do not recall which recipe required this.
/usr/bin/free -> The OpenJDK 8 build scripts need this.
/usr/include/sys/* -> openjdk-8-native
/lib/libcap.so.2 -> The binutils "dir" command quietly breaks the build without this. I am not a fan of the
                            lack of error checking in the binutils build...
/usr/include/sensors/error.h and sensors.h -> mesa-native
/usr/include/zstd_errors.h -> qemu-system-native
It is great to have this list, outside the non-jdk issues are probably issues we 
should look at fixing in OE-Core. Do you mean binutils above for the dir command?

Cheers,


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

Sangeeta Jain
 

Hello all,

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

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

No new issue found.

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Wednesday, 23 June, 2021 12:33 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.9.rc1)


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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.9.rc1


Build hash information:

bitbake: 0e0af15b84e07e6763300dcd092b980086b9b9c4
meta-arm: 59974ccd5f1368b2a1c621ba3efd6d2c44c126dd
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: d8bf86ae6288ae520b8ddd7209a0b448b9693f48
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4
poky: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf



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







[meta-security][PATCH 4/4] initramfs-framework: rename files dir

Armin Kuster
 

Fixes:
ERROR: initramfs-framework-1.0-r4 do_fetch: Fetcher failure for URL: 'file://dmverity'. Unable to fetch URL from any source.

Signed-off-by: Armin Kuster <akuster808@...>
---
.../{initramfs-framework => initramfs-framework-dm}/dmverity | 0
recipes-core/initrdscripts/initramfs-framework.inc | 2 +-
2 files changed, 1 insertion(+), 1 deletion(-)
rename recipes-core/initrdscripts/{initramfs-framework => initramfs-framework-dm}/dmverity (100%)

diff --git a/recipes-core/initrdscripts/initramfs-framework/dmverity b/recipes-core/initrdscripts/initramfs-framework-dm/dmverity
similarity index 100%
rename from recipes-core/initrdscripts/initramfs-framework/dmverity
rename to recipes-core/initrdscripts/initramfs-framework-dm/dmverity
diff --git a/recipes-core/initrdscripts/initramfs-framework.inc b/recipes-core/initrdscripts/initramfs-framework.inc
index dad9c96..12010bf 100644
--- a/recipes-core/initrdscripts/initramfs-framework.inc
+++ b/recipes-core/initrdscripts/initramfs-framework.inc
@@ -1,4 +1,4 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+FILESEXTRAPATHS_prepend := "${THISDIR}/initramfs-framework-dm:"

SRC_URI_append = "\
file://dmverity \
--
2.17.1


[meta-security][PATCH 3/4] packagegroup-core-security: add sshguard

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index e7b6d9b..8e06f30 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -40,6 +40,7 @@ RDEPENDS_packagegroup-security-utils = "\
softhsm \
libest \
opendnssec \
+ sshguard \
${@bb.utils.contains_any("TUNE_FEATURES", "riscv32 ", "", " libseccomp",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pam", "sssd google-authenticator-libpam", "",d)} \
${@bb.utils.contains("DISTRO_FEATURES", "pax", "pax-utils packctl", "",d)} \
--
2.17.1


[meta-security][PATCH 2/4] ssshgaurd: add packaage

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-security/sshguard/sshguard_2.4.2.bb | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 recipes-security/sshguard/sshguard_2.4.2.bb

diff --git a/recipes-security/sshguard/sshguard_2.4.2.bb b/recipes-security/sshguard/sshguard_2.4.2.bb
new file mode 100644
index 0000000..bd7f979
--- /dev/null
+++ b/recipes-security/sshguard/sshguard_2.4.2.bb
@@ -0,0 +1,11 @@
+SUMARRY=" Intelligently block brute-force attacks by aggregating system logs "
+HOMEPAGE = "https://www.sshguard.net/"
+LIC_FILES_CHKSUM = "file://COPYING;md5=47a33fc98cd20713882c4d822a57bf4d"
+LICENSE = "BSD-1-Clause"
+
+
+SRC_URI="https://sourceforge.net/projects/sshguard/files/sshguard/${PV}/sshguard-${PV}.tar.gz"
+
+SRC_URI[sha256sum] = "2770b776e5ea70a9bedfec4fd84d57400afa927f0f7522870d2dcbbe1ace37e8"
+
+inherit autotools-brokensep
--
2.17.1


[meta-security][PATCH 1/4] initramfs-framework: fix typo in conditional

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/initrdscripts/initramfs-framework_1.0.bbappend | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
index dc74e01..f5d476e 100644
--- a/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
+++ b/recipes-core/initrdscripts/initramfs-framework_1.0.bbappend
@@ -1 +1 @@
-require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity', 'initramfs-framework.inc', '', d)}
+require ${@bb.utils.contains('IMAGE_CLASSES', 'dm-verity-img', 'initramfs-framework.inc', '', d)}
--
2.17.1

3421 - 3440 of 57387