Date   

[meta-security][PATCH 0/7] YCL cleanups

Armin Kuster
 

This series superceeds the privious set to help
pass the check-layer scrip.

Armin Kuster (7):
meta-security: add sanity check
meta-security/recipe-kernel: use sanity check
linux-yocto-dev: drop bbappend
meta-tpm: add layer sanity check
meta-tpm/linux-yocto: use sanity support
meta-integrity: add sanity check
meta-integrity/recipe-kernel: use sanity check

README | 18 ++++++++++++++++++
classes/sanity-meta-security.bbclass | 10 ++++++++++
conf/layer.conf | 4 ++++
meta-integrity/README.md | 18 +++++++++++++++++-
.../classes/sanity-meta-integrity.bbclass | 10 ++++++++++
meta-integrity/conf/layer.conf | 4 ++++
.../recipes-kernel/linux/linux-%.bbappend | 6 +-----
.../recipes-kernel/linux/linux_ima.inc | 5 +++++
meta-tpm/README | 19 +++++++++++++++++++
meta-tpm/classes/sanity-meta-tpm.bbclass | 10 ++++++++++
meta-tpm/conf/layer.conf | 4 ++++
.../linux/linux-yocto_5.%.bbappend | 18 +-----------------
.../recipes-kernel/linux/linux-yocto_tpm.inc | 17 +++++++++++++++++
recipes-kernel/linux/linux-yocto_5.%.bbappend | 4 +---
...-dev.bbappend => linux-yocto_security.inc} | 0
15 files changed, 121 insertions(+), 26 deletions(-)
create mode 100644 classes/sanity-meta-security.bbclass
create mode 100644 meta-integrity/classes/sanity-meta-integrity.bbclass
create mode 100644 meta-integrity/recipes-kernel/linux/linux_ima.inc
create mode 100644 meta-tpm/classes/sanity-meta-tpm.bbclass
create mode 100644 meta-tpm/recipes-kernel/linux/linux-yocto_tpm.inc
rename recipes-kernel/linux/{linux-yocto-dev.bbappend => linux-yocto_security.inc} (100%)

--
2.25.1


Re: bitbake controlling memory use

Gmane Admin
 

Op 14-04-2021 om 06:59 schreef Richard Purdie:
On Tue, 2021-04-13 at 21:14 -0400, Randy MacLeod wrote:
On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:
make already has -l option for limiting new instances if load average is
too high, so it's only natural to add a RAM limiter too.

   -l [N], --load-average[=N], --max-load[=N]
                               Don't start multiple jobs unless load is
below N.

In any case, patches welcome :)
During today's Yocto technical call (1),
we talked about approaches to limiting the system load and avoiding
swap and/or OOM events. Here's what (little!) i recall from the
discussion, 9 busy hours later.

In the short run, instead of independently maintaining changes to
configurations to limit parallelism or xz memory usage, etc, we
could develop an optional common include file where such limits
are shared across the community.

In the longer run, changes to how bitbake schedules work may be needed.

Richard says that there was a make/build server idea and maybe even a
patch from a while ago. It may be in one of his poky-contrib branches.
I took a few minutes to look but nothing popped up. A set of keywords to
search for might help me find it.
http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237
Cheers,
Richard
I like the idea. Unfortunately the patch doesn't apply to Gatesgarth, so I couldn't test it. Any chance you would be doing a refresh?


Re: Is it a bug or it does not support device tree /delete-node/?

Quentin Schulz
 

Hi,

On June 5, 2021 12:43:19 AM UTC, JH <jupiter.hce@...> wrote:
Hi,

I am building following imx6ulz-kobs.dts file to a dtb in zeus:

$ cat imx6ulz-kobs.dts

#include "imx6ulz.dts"

/{
model = "customized imx6ull";
compatible = "fsl,imx6ull";
};

&gpmi {
/delete-node/ fsl,use-minimum-ecc;
};

The building process was fine, but that fsl,use-minimum-ecc in dtb was
not deleted, is it a bug or it does not support /delete-node/?
fsl,use-minimum-ecc is a property not a node, you need to use /delete-property/ instead, c.f. https://devicetree-specification.readthedocs.io/en/latest/chapter6-source-language.html?highlight=delete-property#node-and-property-definitions.

Cheers,
Quentin


Is it a bug or it does not support device tree /delete-node/?

JH
 

Hi,

I am building following imx6ulz-kobs.dts file to a dtb in zeus:

$ cat imx6ulz-kobs.dts

#include "imx6ulz.dts"

/{
model = "customized imx6ull";
compatible = "fsl,imx6ull";
};

&gpmi {
/delete-node/ fsl,use-minimum-ecc;
};

The building process was fine, but that fsl,use-minimum-ecc in dtb was
not deleted, is it a bug or it does not support /delete-node/?

Thank you.

- jupiter


Re: Can the Linux kernel reuse the barebox device tree? #kernel

Bruce Ashfield
 

On Fri, Jun 4, 2021 at 5:00 AM <florian.kauer@...> wrote:

Hi,
I made the following observation in my custom Yocto system:
The device tree loaded by the Linux kernel is one that is only available in the barebox directory, but not available in the kernel sources. In fact, it is quite similar, but I made some changes to it in the device tree provided to the kernel. Especially the machine model that is shown during kernel boot is a string that can only be found in the compiled barebox image, but not in the dtb files (where I can find the correct machine model string) or anywhere else in the compilation results. But also other messages indicate that the wrong device tree is loaded.

It was correct before, and I am not really sure what triggered that (just upgraded from zeus, but it might or might not be triggered by that) and I wouldn't expect that anyone could guess what I have done wrong without debugging my setup in depth. But, my general question is: Is there any mechanism that could explain such a behavior? Any configuration that means "extract the device tree from the bootloader" or something similar?
In your upgrade, did the bootloader/initramfs/kernel version change ?
The passing of the device tree to the kernel is (commonly) part of the
bootflow, so changes to any of the components in that flow could cause
the different device tree usage you are seeing.

The bbclass and recipes involved wouldn't have been packaging up the
barebox tree and pulling it into the kernel in zeus, so while it isn't
impossible, it isn't likely to be in the build or packaging changes.

Bruce

Greetings,
Florian


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


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Fri, Jun 4, 2021 at 8:37 AM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@...> wrote:

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield <bruce.ashfield@...> wrote:

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.
I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.
Apologies on this, I see in the follow up email you did mention the
layerindex .. I read completely over that, and had to search up the
warning myself. (my fault, not yours).


That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.
This point still stands though :D

Bruce


Bruce


Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

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


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



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


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Fri, Jun 4, 2021 at 8:27 AM Bruce Ashfield <bruce.ashfield@...> wrote:

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.
I took a quick look, is this warning coming from the layer index ?
That would be important information to convey when sending changes
like this.

That being said, it is a longer fix to get that warning changed, and
I'd rather not break the index, so I dropped to only the last two
releases.

But I do recommend that the layer index be changed (if that is the
cause of the warning), since we shouldn't be adapting to the index ..
it should be adapting to layers.

Bruce


Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

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


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


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Thu, Jun 3, 2021 at 11:35 PM Kai <kai.kang@...> wrote:

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show
warning:

WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott:
length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch
master, please?
Nope. It is compatible with those releases, so they need to stay. I
see no valid reason to be limited to a certain number of characters.


Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?
That is just as arbitrary, I'll keep it as-is.

Bruce


Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux

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


Re: [meta-gplv2][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

On 6/4/21 2:49 PM, kai wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Please ignore it according to Martin's comment in oe-devel list.

Regards,
Kai


Signed-off-by: Kai Kang <kai.kang@...>
---
 conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"
 
 LAYERDEPENDS_gplv2 = "core"
 
-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"
 
 LICENSE_PATH += "${LAYERDIR}/licenses"
 




-- 
Kai Kang
Wind River Linux


Can the Linux kernel reuse the barebox device tree? #kernel

florian.kauer@...
 

Hi,
I made the following observation in my custom Yocto system:
The device tree loaded by the Linux kernel is one that is only available in the barebox directory, but not available in the kernel sources. In fact, it is quite similar, but I made some changes to it in the device tree provided to the kernel. Especially the machine model that is shown during kernel boot is a string that can only be found in the compiled barebox image, but not in the dtb files (where I can find the correct machine model string) or anywhere else in the compilation results. But also other messages indicate that the wrong device tree is loaded.

It was correct before, and I am not really sure what triggered that (just upgraded from zeus, but it might or might not be triggered by that) and I wouldn't expect that anyone could guess what I have done wrong without debugging my setup in depth. But, my general question is: Is there any mechanism that could explain such a behavior? Any configuration that means "extract the device tree from the bootloader" or something similar?

Greetings,
Florian


[meta-openssl102-fips][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

From: Kai Kang <kai.kang@...>

There is no hardknott branch yet, so keep 'hardknott' rather than
replace it.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 01026f0..27ddad6 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two-fips = "5"

LAYERVERSION_meta-openssl-one-zero-two-fips = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two-fips = "hardknott honister"

LAYERPATH_meta-openssl-one-zero-two-fips = "${LAYERDIR}"

--
2.17.1


[meta-gplv2][PATCH] layer.conf: set honister in LAYERSERIES_COMPAT

kai
 

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 9fc797a..3abe6b5 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -14,7 +14,7 @@ LAYERVERSION_gplv2 = "1"

LAYERDEPENDS_gplv2 = "core"

-LAYERSERIES_COMPAT_gplv2 = "hardknott"
+LAYERSERIES_COMPAT_gplv2 = "honister"

LICENSE_PATH += "${LAYERDIR}/licenses"

--
2.17.1


[meta-openssl102][PATCH] layer.conf: support honister

kai
 

From: Kai Kang <kai.kang@...>

There is no hardknott branch yet, so keep 'hardknott' rather than
replace it.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 4ea1009..ce7f99b 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -10,7 +10,7 @@ BBFILE_PRIORITY_meta-openssl-one-zero-two = "5"

LAYERVERSION_meta-openssl-one-zero-two = "1"

-LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "hardknott"
+LAYERSERIES_COMPAT_meta-openssl-one-zero-two = "hardknott honister"

LAYERDEPENDS_meta-openssl-one-zero-two = " \
core \
--
2.17.1


[linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: dspi: fsl: fix dspi transfer hang issue

Zhantao Tang
 

Hi Bruce,


There is an patch to fix dspi hang issue.

Would you please help to merge this patch into linux-ycoto kernel, v5.10, branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx?


Thanks,
Zhantao


[PATCH] drivers: dspi: fsl: fix dspi transfer hang issue

Zhantao Tang
 

On NXP S32G RDB2, there is an sja1110 switch, which can be accessed
using dspi interface, but if users use the following commands to test
the switch, the board will hang there.

$ echo 30 > /sys/class/gpio/export
$ echo out > /sys/class/gpio/gpio30/direction
$ echo 0 > /sys/class/gpio/gpio30/value
$ echo -n -e '\x02\x00\x00\x00\x00\x00\x00\x00' | spi-pipe -d /dev/spidev5.1 -b 4 | hexdump -C

The reason is that, the dspi driver wrongly sets the HALT flag in
the register, and the while loop will run forever, so the board hang
there. This patch is to fix this issue.

Signed-off-by: Zhantao Tang <zhantao.tang@...>
---
drivers/spi/spi-fsl-dspi.c | 10 ++--------
1 file changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index 063cf4a60ed3..c20cce466bf7 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -965,10 +965,8 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
dspi->progress = 0;

regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_HALT, SPI_MCR_HALT);
- while (regmap_read(dspi->regmap, SPI_SR, &val) >= 0 &&
- val & SPI_SR_TXRXS)
- ;
+ SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF,
+ SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);

spi_take_timestamp_pre(dspi->ctlr, dspi->cur_transfer,
dspi->progress, !dspi->irq);
@@ -987,10 +985,6 @@ static int dspi_transfer_one_message(struct spi_controller *ctlr,
} while (status == -EINPROGRESS);
}
}
- regmap_update_bits(dspi->regmap, SPI_MCR,
- SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF |
- SPI_MCR_HALT,
- SPI_MCR_CLR_TXF | SPI_MCR_CLR_RXF);
if (status)
break;

--
2.25.1


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

kai
 

On 6/4/21 11:22 AM, Bruce Ashfield wrote:
On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:
From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.
Hi Bruce,

Thanks. I have seen your commits.

But 3 items in LAYERSERIES_COMPAT_realtime will cause layer index show warning:

  WARNING: YPCompatibleVersion.name: dunfell gatesgarth hardknott: length 28 exceeds maximum (25), truncating

Could we only keep the latest LAYERSERIES_CORENAMES (honister) in branch master, please?

Or it set in oe-core's layer.conf:

LAYERSERIES_CORENAMES = "hardknott honister"

we just align with it to keep the latest 2, please?

Regards,
Kai


Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1
--
Kai Kang
Wind River Linux


Re: [meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

Bruce Ashfield
 

On Thu, Jun 3, 2021 at 11:06 PM <kai.kang@...> wrote:

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.
I had added this back in April, but apparently didn't push the change.

I also noticed that I've been updating the wrong branch with compatibility.

That should all be fixed now.

Bruce

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1

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


[meta-realtime][PATCH] layer.conf: set LAYERSERIES_COMPAT with honister

kai
 

From: Kai Kang <kai.kang@...>

Replace hardknott with honister in layer.conf which aligns with
oe-core.

Signed-off-by: Kai Kang <kai.kang@...>
---
conf/layer.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index 007f578..8ae67ba 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -15,6 +15,6 @@ BBFILE_PRIORITY_realtime = "5"
# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_realtime = "1"
-LAYERSERIES_COMPAT_realtime = "hardknott"
+LAYERSERIES_COMPAT_realtime = "honister"
LAYERDEPENDS_realtime = "core openembedded-layer"
LAYERRECOMMENDS_realtime = "meta-realtime-dl (= 3.2)"
--
2.17.1


#bitbake bitbake fails when build for sqlcipher on AM335x #bitbake

shrinivasnh@...
 

I am following steps mentioned below link to create Kernel and u-boot for AM335x starter kit
 
http://software-dl.ti.com/processor-sdk-linux/esd/docs/latest/linux/Overview_Building_the_SDK.html
Its building correctly.

Now I am using the meta-webos-master layer which has sqlcipher to be addedto the Linux kernel, I am getting errrors durig the build itself
The error is as below
========================
/AM335x/prj/tisdk/build$ MACHINE=am335x-evm bitbake arago-base-tisdk-image
ERROR: Unable to start bitbake server (None)
ERROR: Server log for this session (/home/appdev-426043/AM335x/prj/tisdk/build/bitbake-cookerdaemon.log):
--- Starting bitbake server pid 19434 at 2021-06-03 19:52:05.846548 ---
WARNING: Layer meta-processor-sdk should set LAYERSERIES_COMPAT_meta-processor-sdk in its conf/layer.conf file to list the core layer names it is compatible with.
WARNING: Layer meta-webos should set LAYERSERIES_COMPAT_meta-webos in its conf/layer.conf file to list the core layer names it is compatible with.
ERROR: ParseError at /home/appdev-426043/AM335x/prj/tisdk/sources/meta-arago/meta-webos-master/classes/package.bbclass:52: Could not inherit file classes/prserv.bbclass
 
Request help or pointers to resolve  the issue


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: June 3, 2021

Randy MacLeod
 

Attendees: Sakib, Alex, Richard, Saul, Randy

1. Sakib is working on using procpath (1) to generate full-system process summary that is specific to bitbake builds and perhaps even
YP AB.

The basic idea is to take a single run of top and convert it to something easier to quicly understand (see (4) below).


We are interested in procpath since screen scraping the top output
is likely error prone. Richard is concerned that
using python and this module will be quite inefficent compared to what
top does. That's a valid concern but we believe and will prove that
the module and top are both just accessing the same data in /proc.
Stay tuned.


2. Tony and Randy have a work-around of using taskset for the valgrind
races. We will have a patch to use taskset of the list of 'racey'
valgrind tests. We think it has gotten worse when we added 'smp'
to qemu. There are similar VG bug reports from 5
years ago so we may have to carry the work-around for some time.


3. Add logging to runqemu when qemu fails.

a. Run ps (or top) to see what's happening on the host.
b. collect qemu logs
In this example:

https://autobuilder.yoctoproject.org/typhoon/#/builders/101/builds/2386/steps/12/logs/stdio
there should be a log file unde:

/home/pokybuild/yocto-worker/qemux86-alt/build/build/tmp/work/qemux86-poky-linux/core-image-sato-sdk/1.0-r0/temp

but s/temp/testimage/ and logs should be under there.

Note that the logs may not always be there so check and
make that clear with a warning when one is missing.
This now is Sakib's top priority for the week.


4. Regarding a LTP test that fails because mkdir failed...
This is described in an email (2) from Richard with the subject:
Re: [swat] qemux86-64 ltp kernel panic

Alex is going to use gcore (3) to get a core file for the qemu process
and try to figure out what is crazy in the qemu guest kernel.

Did that work Alex?
Where are the core file and related symbols?

5. As a general remark, we are overloading the systems but
we don't want to scale back too much.

In the cases wehre qemu failed to copy in 120 seconds,
what has generally be going on is lots of builds involving:
llvm, kea, webkit or two, musl world build.
The load average goes over 300 but as you'd expect most jobs
are sleeping.
We think the biggest step forward on this is the job server that
Trevor is going to start working on that.

There are a few knobs that we can adjust to reduce the maximum load:
- Number of build in parallel - currently 3
- parallel make - currently 16, could drop to 12 but
dropping below say 8 would reduce the test system throughput too much.
- bb number of threads - number of bitbake tasks.

Many times this results in a RCU stall and things go off the rails.


If anyone else is interested in helping, please let me know.
More next week.


--
# Randy MacLeod
# Wind River Linux


1) https://heptapod.host/saajns/procpath
2) https://lists.yoctoproject.org/g/swat/message/156
3) https://www.linux.org/docs/man1/gcore.html

4)

If I hack up a sed pipeline and run it on the entire latency-full.log, I get:

$ cat /tmp/latency-full.log | grep -v "^NOTE:" | \
cut -c 69- | cut -d" " -f 1 | grep -v "\[" | \
sed -e 's|/home/pokybuild/yocto-worker/|/~/|' | \
sed -e 's|/build/build/tmp/work/core2-64-poky-linux/| .../tmp/pklin/... |g' | \
sed -e 's|/recipe-sysroot-native/usr/bin/x86_64-poky-linux/../../libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/| .../gcc-foo/... |' | \
sed -e 's|/build/build/tmp/work/core2-32-poky-linux/| .../pklin32/... |' | \
grep -v "^$" | \
sort | uniq -c | sort -n | tail -30

42 /~/meta-oe .../tmp/pklin/... vulkan-cts/1.2.6.0-r0 .../gcc-foo/... 11.1.0/as
42 /~/meta-oe .../tmp/pklin/... vulkan-cts/1.2.6.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++
43 as
43 top
44 tar
45 cmake
45 ninja
50 /~/reproducible-ubuntu/build/build-st-38234/reproducibleB/tmp/work/qemux86_64-poky-linux/linux-yocto/5.4.119+gitAUTOINC+9e2546ab8d_8997f66300-r0 .../gcc-foo/... 9.3.0/cc1
58 bitbake-server
58 /lib/systemd/systemd
58 (sd-pam)
65 /~/pkgman-non-rpm/build/build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo
90 /~/pkgman-non-rpm/build/build/tmp/work/qemux86-poky-linux/linux-yocto/5.4.119+gitAUTOINC+9e2546ab8d_8997f66300-r0/recipe-sysroot-native/usr/bin/i686-poky-linux/../../libexec/i686-poky-linux/gcc/i686-poky-linux/9.3.0/cc1
97 /~/meta-oe .../tmp/pklin/... opengl-es-cts/3.2.7.0-r0 .../gcc-foo/... 11.1.0/cc1plus
98 /~/meta-oe .../tmp/pklin/... opengl-es-cts/3.2.7.0-r0 .../gcc-foo/... 11.1.0/as
102 /~/meta-oe .../tmp/pklin/... opengl-es-cts/3.2.7.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux/x86_64-poky-linux-g++
112 /~/meta-oe .../tmp/pklin/... mongodb/4.4.5+4.4.6-rc0-r0 .../gcc-foo/... 11.1.0/cc1plus
113 /~/meta-oe .../tmp/pklin/... mongodb/4.4.5+4.4.6-rc0-r0 .../gcc-foo/... 11.1.0/as
116 /usr/bin/python3
141 i686-poky-linux-gcc
151 /~/meta-oe .../tmp/pklin/... nodejs/14.16.1-r0 .../gcc-foo/... 11.1.0/cc1plus
153 /~/meta-oe .../tmp/pklin/... nodejs/14.16.1-r0 .../gcc-foo/... 11.1.0/as
154 sh
209 x86_64-poky-linux-gcc
313 x86_64-poky-linux-g++
345 /~/meta-oe/build/build/tmp/sysroots-components/x86_64/pseudo-native/usr/bin/pseudo
476 /bin/bash
629 make
1130 python3
1331 /bin/sh

the 'one cmd' lines such as, 'make, python3, /bin/sh, tar lines clearly need more context.

There's more work to do cleaning up some 'noise' but does
anyone want anything else in the first version?

Trevor pointed me at:
https://heptapod.host/saajns/procpath
that we might useful but I haven't played with it yet.

A quick simple filter is likely a better starting point.

4081 - 4100 of 57804