|
[meta-security][PATCH 0/7] YCL cleanups
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: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?On 2021-04-11 12:19 p.m., Alexander Kanavin wrote:http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wipqueue4&id=d66a327fb6189db5de8bc489859235dcba306237make already has -l option for limiting new instances if load average isDuring today's Yocto technical call (1),
|
|
|
|
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,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:
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, -- - 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: 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). This point still stands though :D Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Re: [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:
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
-- - 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:
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. That is just as arbitrary, I'll keep it as-is. Bruce
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
|
Re: [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, 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:Hi Bruce,From: Kai Kang <kai.kang@...>I had added this back in April, but apparently didn't push the change. 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 -- 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:
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@...> -- - 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
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.
|
|
|