Date   

Re: #golang: go fetches dependencies in compile phase

Konrad Weihmann <kweihmann@...>
 

Well AFAIK your observation is correct, go-mod.bbclass doesn't work a in BB_NO_NETWORK-safe manner.
What you could do is to provide all the dependencies manually and add them via DEPENDS, which is grant the behavior expected.

The bad thing about go is that chances of circular dependencies of go modules are relatively high.

I've also seen a few approaches using vendoring to escape this, but I'm afraid none of the code is pretty well tested nor publicly available.

If you'd ask me, I would go the long painful road of providing each required go module as a recipe of it's own and inject it into the final recipe - this also makes it pretty visible what you're pulling into your build in terms of licensing a.s.o.

On 09.04.21 15:53, Juergen Landwehr wrote:
Hi,
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
This is not allowed in our project setup and kind of contradicts the Yocto paradigmn of having a fetch and a compile phase.
Is there a way to avoid this or some other solution that we could use?
Thanks,
Jürgen


#golang: go fetches dependencies in compile phase

Juergen Landwehr
 

Hi,
 
we are developing an application in go and use the "go-mod" bb-class from poky. This works fine.
 
However, the problem is, that the dependencies in go.mod are now fetched in the compile phase and not in the fetch phase.
 
This is not allowed in our project setup and kind of contradicts the Yocto paradigmn of having a fetch and a compile phase.
 
Is there a way to avoid this or some other solution that we could use?
 
Thanks,
 
Jürgen


pycoral recipe

Marek Belisko
 

Hi,

Just want to ask if anyone working/can share a recipe for a pycoral
package (https://github.com/google-coral/pycoral). I have some
barebone but seems not straightforward. It's using bazel build system
and as I understand it needs to add some patch for adding yocto
compiler otherwise it fails with:

Error in which: Program argument of which() may not contains a / or a
\ ('arm-poky-linux-gnueabi-gcc -mthumb -mfpu=neon-vfpv4
-mfloat-abi=hard -mcpu=cortex-a7 -fstack-protector-strong
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security
--sysroot=/home/test/recipe-sysroot' given)

Any suggestions?

Thanks and regards,

marek

--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com


[meta-security][PATCH 2/2] Define secure images with parsec-service and parsec-tool included and add the images into gitlab CI

Anton Antonov
 

From: Anton Antonov <anton.antonov@...>

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
.gitlab-ci.yml | 25 +++++++++++++++++++++++++
kas/kas-security-parsec.yml | 21 +++++++++++++++++++++
kas/qemuarm-parsec.yml | 6 ++++++
kas/qemuarm64-parsec.yml | 6 ++++++
kas/qemuppc-parsec.yml | 6 ++++++
kas/qemux86-64-parsec.yml | 6 ++++++
kas/qemux86-parsec.yml | 6 ++++++
7 files changed, 76 insertions(+)
create mode 100644 kas/kas-security-parsec.yml
create mode 100644 kas/qemuarm-parsec.yml
create mode 100644 kas/qemuarm64-parsec.yml
create mode 100644 kas/qemuppc-parsec.yml
create mode 100644 kas/qemux86-64-parsec.yml
create mode 100644 kas/qemux86-parsec.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 1442239..323285a 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -151,3 +151,28 @@ qemux86-test:
script:
- kas build --target security-test-image kas/$CI_JOB_NAME.yml
- kas build -c testimage --target security-test-image kas/$CI_JOB_NAME.yml
+
+qemux86-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemux86-64-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemuarm-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemuarm-64-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
+
+qemuppc-parsec:
+ extends: .build
+ script:
+ - kas build --target security-build-image kas/$CI_JOB_NAME.yml
diff --git a/kas/kas-security-parsec.yml b/kas/kas-security-parsec.yml
new file mode 100644
index 0000000..6152f0c
--- /dev/null
+++ b/kas/kas-security-parsec.yml
@@ -0,0 +1,21 @@
+header:
+ version: 9
+ includes:
+ - kas-security-base.yml
+
+repos:
+ meta-security:
+ layers:
+ meta-parsec:
+
+ meta-rust:
+ url: https://github.com/meta-rust/meta-rust.git
+ refspec: master
+
+ meta-clang:
+ url: https://github.com/kraj/meta-clang.git
+ refspec: master
+
+local_conf_header:
+ meta-parsec: |
+ IMAGE_INSTALL_append = " parsec-service parsec-tool"
diff --git a/kas/qemuarm-parsec.yml b/kas/qemuarm-parsec.yml
new file mode 100644
index 0000000..cef2818
--- /dev/null
+++ b/kas/qemuarm-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemuarm
diff --git a/kas/qemuarm64-parsec.yml b/kas/qemuarm64-parsec.yml
new file mode 100644
index 0000000..9b593bc
--- /dev/null
+++ b/kas/qemuarm64-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemuarm64
diff --git a/kas/qemuppc-parsec.yml b/kas/qemuppc-parsec.yml
new file mode 100644
index 0000000..1176d13
--- /dev/null
+++ b/kas/qemuppc-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemuppc
diff --git a/kas/qemux86-64-parsec.yml b/kas/qemux86-64-parsec.yml
new file mode 100644
index 0000000..ec39c14
--- /dev/null
+++ b/kas/qemux86-64-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemux86-64
diff --git a/kas/qemux86-parsec.yml b/kas/qemux86-parsec.yml
new file mode 100644
index 0000000..370947d
--- /dev/null
+++ b/kas/qemux86-parsec.yml
@@ -0,0 +1,6 @@
+header:
+ version: 8
+ includes:
+ - kas-security-parsec.yml
+
+machine: qemux86
--
2.20.1


[meta-security][PATCH 1/2] Add meta-parsec layer into meta-security.

Anton Antonov
 

From: Anton Antonov <anton.antonov@...>

The layer contains recipes for Parsec service version 0.7.0 and parsec-tool version 0.3.0. The Parsec service is built with all supported providers and deployed with the MbedCrypto provider enabled. Both systemd and sysv-init are supported.

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
meta-parsec/README.md | 186 ++++++++++++++++++
meta-parsec/conf/layer.conf | 14 ++
.../parsec-service/files/cryptoki.patch | 18 ++
.../parsec-service/files/parsec-tmpfiles.conf | 2 +
.../parsec-service/files/parsec_init | 63 ++++++
.../parsec-service/files/systemd.patch | 19 ++
.../parsec-service/parsec-service_0.7.0.bb | 67 +++++++
.../parsec-service/parsec-service_0.7.0.inc | 147 ++++++++++++++
.../parsec-tool/parsec-tool_0.3.0.bb | 18 ++
.../parsec-tool/parsec-tool_0.3.0.inc | 127 ++++++++++++
10 files changed, 661 insertions(+)
create mode 100644 meta-parsec/README.md
create mode 100644 meta-parsec/conf/layer.conf
create mode 100644 meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch
create mode 100644 meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf
create mode 100755 meta-parsec/recipes-parsec/parsec-service/files/parsec_init
create mode 100644 meta-parsec/recipes-parsec/parsec-service/files/systemd.patch
create mode 100644 meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
create mode 100644 meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc
create mode 100644 meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
create mode 100644 meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc

diff --git a/meta-parsec/README.md b/meta-parsec/README.md
new file mode 100644
index 0000000..a2736b6
--- /dev/null
+++ b/meta-parsec/README.md
@@ -0,0 +1,186 @@
+meta-parsec layer
+==============
+
+This layer contains recipes for the Parsec service with Mbed-Crypto,
+Pkcs11 and TPM providers and parsec tools.
+
+Dependencies
+============
+
+This layer depends on:
+
+ URI: git://git.openembedded.org/meta-openembedded
+ branch: master
+ revision: HEAD
+ prio: default
+
+ URI git://git.yoctoproject.org/meta-security
+ branch: master
+ revision: HEAD
+ prio: default
+
+ URI https://github.com/meta-rust/meta-rust.git
+ branch: master
+ revision: HEAD
+ prio: default
+
+ URI https://github.com/kraj/meta-clang.git
+ branch: master
+ revision: HEAD
+ prio: default
+
+Adding the meta-parsec layer to your build
+==========================================
+
+In order to use this layer, you need to make the build system aware of it.
+
+You can add it to the build system by adding the
+location of the meta-parsec layer to bblayers.conf, along with any
+other layers needed. e.g.:
+
+ BBLAYERS ?= " \
+ /path/to/yocto/meta \
+ /path/to/yocto/meta-yocto \
+ /path/to/yocto/meta-yocto-bsp \
+ /path/to/meta-openembedded/meta-oe \
+ /path/to/meta-openembedded/meta-python \
+ /path/to/meta-rust \
+ /path/to/meta-clang \
+ /path/to/meta-security/meta-tpm \
+ /path/to/meta-security/meta-parsec \
+ "
+
+To include the Parsec service into your image add following into the
+local.conf:
+
+ IMAGE_INSTALL_append = " parsec-service"
+
+ The Parsec service will be deployed into the image built with all the supported
+providers and with the default config file from the Parsec repository:
+https://github.com/parallaxsecond/parsec/blob/main/config.toml
+ The default Parsec service config file contains the MbedCrypto provider
+enabled. The config file needs to be updated to use the Parsec service
+with other providers like TPM or PKCS11. The required procedures are
+covered in Parsec documentation.
+https://parallaxsecond.github.io/parsec-book/
+
+Updating recipes
+================
+
+ The parsec-service and parsec-tool recipes use include files with lists
+of all rust crates required. This allows bitbake to fetch all the necessary
+dependent crates, as well as a pegged version of the crates.io index,
+to ensure maximum reproducibility.
+ It's recommended to use cargo-bitbake to generate include files for new
+versions of parsec recipes.
+https://github.com/meta-rust/cargo-bitbake
+
+ When you have crago-bitbake built:
+1. Checkout the required version of parsec repository.
+2. Run cargo-bitbake inside the repository. It will produce a BB file.
+3. Create a new include file with SRC_URI and LIC_FILES_CHKSUM from the BB file.
+
+Manual testing with runqemu
+===========================
+
+ This layer also contains a recipe for pasec-tool which can be used for
+manual testing of the Parsec service:
+
+ IMAGE_INSTALL_append += " parsec-tools"
+
+ There are a series of Parsec Demo videos showing how to use parsec-tool
+to test the Parsec service base functionality:
+https://www.youtube.com/watch?v=ido0CyUdMHM&list=PLKjl7IFAwc4S7WQqqphCsyy6DPDxJ2Skg&index=4
+
+ You can use runqemu to start a VM with a built image file and run
+manual tests with parsec-tool.
+
+1. MbedCrypto provider
+ The default Parsec service config file contains the MbedCrypto provider
+enabled. No changes required for manual testing.
+
+2. PKCS11 provider
+ The Software HSM can be used for manual testing of the provider by
+including it into your test image:
+
+ IMAGE_INSTALL_append += " softhsm"
+
+Inside the running VM:
+- Stop Parsec
+```bash
+systemctl stop parsec
+```
+- Initialise a token and notice the result slot number
+```bash
+softhsm2-util --init-token --slot 0 --label "Parsec Service" --pin 123456 --so-pin 123456
+```
+- Change the token ownership:
+```bash
+for d in /var/lib/softhsm/tokens/*; do chown -R parsec $d; done
+```
+- Enable the PKCS11 provider and update its parameters in the Parsec config file
+/etc/parsec/config.toml
+```
+library_path = "/usr/lib/softhsm/libsofthsm2.so"
+slot_number = <slot number>
+user_pin = "123456"
+```
+- Start Parsec
+```bash
+systemctl start parsec
+```
+
+3. TPM provider
+ The IBM Software TPM service can be used for manual testing of the provider by
+including it into your test image:
+
+ IMAGE_INSTALL_append += " ibmswtpm2 tpm2-tools libtss2 libtss2-tcti-mssim"
+
+Inside the running VM:
+- Stop Parsec
+```bash
+systemctl stop parsec
+```
+- Start and configure the Software TPM server
+```bash
+ /usr/bin/tpm_server &
+ sleep 5
+ /usr/bin/tpm2_startup -c -T mssim
+ /usr/bin/tpm2_changeauth -c owner tpm_pass
+```
+- Enable the TPM provider and update its parameters in the Parsec config file
+/etc/parsec/config.toml
+```
+tcti = "mssim"
+owner_hierarchy_auth = "hex:74706d5f70617373"
+```
+- Start Parsec
+```bash
+systemctl start parsec
+```
+
+Maintenance
+-----------
+
+Send pull requests, patches, comments or questions to yocto@...
+
+When sending single patches, please using something like:
+'git send-email -1 --to yocto@... --subject-prefix=meta-parsec][PATCH'
+
+These values can be set as defaults for this repository:
+
+$ git config sendemail.to yocto@...
+$ git config format.subjectPrefix meta-parsec][PATCH
+
+Now you can just do 'git send-email origin/master' to send all local patches.
+
+Maintainers: Anton Antonov <Anton.Antonov@...>
+ Armin Kuster <akuster808@...>
+
+
+License
+=======
+
+All metadata is MIT licensed unless otherwise stated. Source code included
+in tree for individual recipes is under the LICENSE stated in each recipe
+(.bb file) unless otherwise stated.
diff --git a/meta-parsec/conf/layer.conf b/meta-parsec/conf/layer.conf
new file mode 100644
index 0000000..2d4aa12
--- /dev/null
+++ b/meta-parsec/conf/layer.conf
@@ -0,0 +1,14 @@
+# We have a conf and classes directory, add to BBPATH
+BBPATH .= ":${LAYERDIR}"
+
+# We have a recipes directory, add to BBFILES
+BBFILES += "${LAYERDIR}/recipes*/*/*.bb ${LAYERDIR}/recipes*/*/*.bbappend"
+
+BBFILE_COLLECTIONS += "parsec-layer"
+BBFILE_PATTERN_parsec-layer = "^${LAYERDIR}/"
+BBFILE_PRIORITY_parsec-layer = "5"
+
+LAYERSERIES_COMPAT_parsec-layer = "hardknott gatesgarth"
+
+LAYERDEPENDS_parsec-layer = "core rust-layer clang-layer tpm-layer"
+BBLAYERS_LAYERINDEX_NAME_parsec-layer = "meta-parsec"
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch b/meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch
new file mode 100644
index 0000000..c234479
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/cryptoki.patch
@@ -0,0 +1,18 @@
+
+Use cryptoki v0.1.1 which supports the "generate-bindings" feature
+required for building Parsec service 0.7.0 in Yocto.
+
+Signed-off-by: Anton Antonov <Anton.Antonov@...>
+Upstream-Status: Submitted
+
+--- a/Cargo.toml 2021-04-01 10:29:50.333687763 +0100
++++ b/Cargo.toml 2021-04-01 10:27:13.051860002 +0100
+@@ -37,7 +37,7 @@
+ version = "1.3.1"
+
+ [dependencies.cryptoki]
+-version = "0.1.0"
++version = "0.1.1"
+ features = ["psa-crypto-conversions"]
+ optional = true
+
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf b/meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf
new file mode 100644
index 0000000..fe576a2
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/parsec-tmpfiles.conf
@@ -0,0 +1,2 @@
+#Type Path Mode User Group Age Argument
+d /run/parsec 755 parsec parsec - -
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/parsec_init b/meta-parsec/recipes-parsec/parsec-service/files/parsec_init
new file mode 100755
index 0000000..58a2897
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/parsec_init
@@ -0,0 +1,63 @@
+#! /bin/sh -e
+
+# ------------------------------------------------------------------------------
+# Copyright (c) 2021, Arm Limited, All Rights Reserved
+# SPDX-License-Identifier: Apache-2.0
+#
+# Licensed under the Apache License, Version 2.0 (the "License"); you may
+# not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+# ------------------------------------------------------------------------------
+
+# Parsec Service SysV init script
+
+test -x /usr/libexec/parsec/parsec || exit 0
+
+case "$1" in
+ start)
+ echo -n "Starting Parsec daemon: "
+ if [ ! -f /etc/parsec/config.toml ]; then
+ echo "There is no Parsec service configuration file."
+ else
+ if [ ! -d /run/parsec ]; then
+ mkdir /run/parsec
+ chown parsec:parsec /run/parsec
+ chmod 755 /run/parsec
+ fi
+ # start-stop-daemon used in poky busybox doesn't support
+ # '--chdir' parameter. So, let's do it manually
+ cd /var/lib/parsec
+ RUST_LOG=info start-stop-daemon --oknodo --start --background \
+ --chuid parsec:parsec --exec /usr/libexec/parsec/parsec \
+ -- --config /etc/parsec/config.toml
+ echo "parsec."
+ fi
+ ;;
+ stop)
+ echo -n "Stopping Parsec daemon: "
+ start-stop-daemon --oknodo --stop --exec /usr/libexec/parsec/parsec
+ echo "parsec."
+ ;;
+ reload)
+ echo -n "Reloading Parsec daemon: "
+ start-stop-daemon --stop --signal SIGHUP --exec /usr/libexec/parsec/parsec
+ echo "parsec."
+ ;;
+ restart|force-reload)
+ $0 stop
+ $0 start
+ ;;
+ *)
+ echo "Usage: /etc/init.d/parsec {start|stop|restart|reload|force-reload}"
+ exit 1
+esac
+
+exit 0
diff --git a/meta-parsec/recipes-parsec/parsec-service/files/systemd.patch b/meta-parsec/recipes-parsec/parsec-service/files/systemd.patch
new file mode 100644
index 0000000..c01ff06
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/files/systemd.patch
@@ -0,0 +1,19 @@
+
+Run the Parsec service as parsec user in /var/lib/parsec/ working directory.
+
+Signed-off-by: Anton Antonov <Anton.Antonov@...>
+Upstream-Status: Inappropriate [deployment configuration]
+
+--- a/systemd-daemon/parsec.service 2021-03-28 18:34:18.703196235 +0100
++++ b/systemd-daemon/parsec.service 2021-03-28 18:35:14.279830299 +0100
+@@ -3,7 +3,9 @@
+ Documentation=https://parallaxsecond.github.io/parsec-book/parsec_service/install_parsec_linux.html
+
+ [Service]
+-WorkingDirectory=/home/parsec/
++User=parsec
++Group=parsec
++WorkingDirectory=/var/lib/parsec/
+ ExecStart=/usr/libexec/parsec/parsec --config /etc/parsec/config.toml
+
+ [Install]
diff --git a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
new file mode 100644
index 0000000..b3f7b21
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.bb
@@ -0,0 +1,67 @@
+SUMMARY = "Platform AbstRaction for SECurity Daemon"
+HOMEPAGE = "https://github.com/parallaxsecond/parsec"
+LICENSE = "Apache-2.0"
+
+inherit cargo
+
+SRC_URI += "crate://crates.io/parsec-service/${PV} \
+ file://parsec_init \
+ file://systemd.patch \
+ file://parsec-tmpfiles.conf \
+"
+
+DEPENDS = "clang-native tpm2-tss"
+INSANE_SKIP_${PN} += "dev-deps"
+
+CARGO_BUILD_FLAGS += " --features all-providers,cryptoki/generate-bindings,tss-esapi/generate-bindings"
+
+inherit systemd
+SYSTEMD_SERVICE_${PN} = "parsec.service"
+
+inherit update-rc.d
+INITSCRIPT_NAME = "parsec"
+
+# A local file can be defined in build/local.conf
+# The file should also be included into SRC_URI then
+PARSEC_CONFIG ?= "${S}/config.toml"
+
+do_install_append () {
+ # Binaries
+ install -d -m 700 -o parsec -g parsec "${D}${libexecdir}/parsec"
+ install -m 700 -o parsec -g parsec "${WORKDIR}/build/target/${CARGO_TARGET_SUBDIR}/parsec" ${D}${libexecdir}/parsec/parsec
+
+ # Config file
+ install -d -m 700 -o parsec -g parsec "${D}${sysconfdir}/parsec"
+ install -m 400 -o parsec -g parsec "${PARSEC_CONFIG}" ${D}${sysconfdir}/parsec/config.toml
+
+ # Data dir
+ install -d -m 700 -o parsec -g parsec "${D}${localstatedir}/lib/parsec"
+
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'true', 'false', d)}; then
+ install -d ${D}${systemd_unitdir}/system
+ install -m 644 ${S}/systemd-daemon/parsec.service ${D}${systemd_unitdir}/system
+
+ install -d ${D}${libdir}/tmpfiles.d
+ install -m 644 ${WORKDIR}/parsec-tmpfiles.conf ${D}${libdir}/tmpfiles.d
+ fi
+
+ if ${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit', 'true', 'false', d)}; then
+ install -d ${D}${sysconfdir}/init.d
+ install -m 755 ${WORKDIR}/parsec_init ${D}${sysconfdir}/init.d/parsec
+ fi
+}
+
+inherit useradd
+USERADD_PACKAGES = "${PN}"
+USERADD_PARAM_${PN} = "-r -g parsec -s /bin/false -d ${localstatedir}/lib/parsec parsec"
+GROUPADD_PARAM_${PN} = "-r parsec"
+
+FILES_${PN} += " \
+ ${sysconfdir}/parsec/config.toml \
+ ${libexecdir}/parsec/parsec \
+ ${systemd_unitdir}/system/parsec.service \
+ ${libdir}/tmpfiles.d/parsec-tmpfiles.conf \
+ ${sysconfdir}/init.d/parsec \
+"
+
+require parsec-service_${PV}.inc
diff --git a/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc
new file mode 100644
index 0000000..59a47f9
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-service/parsec-service_0.7.0.inc
@@ -0,0 +1,147 @@
+# This file is created from parsec-service repository Cargo.lock using cargo-bitbake tool
+
+SRC_URI += " \
+ crate://crates.io/aho-corasick/0.7.15 \
+ crate://crates.io/ansi_term/0.11.0 \
+ crate://crates.io/anyhow/1.0.38 \
+ crate://crates.io/atty/0.2.14 \
+ crate://crates.io/autocfg/1.0.1 \
+ crate://crates.io/base64/0.12.3 \
+ crate://crates.io/base64/0.13.0 \
+ crate://crates.io/bincode/1.3.2 \
+ crate://crates.io/bindgen/0.56.0 \
+ crate://crates.io/bindgen/0.57.0 \
+ crate://crates.io/bitfield/0.13.2 \
+ crate://crates.io/bitflags/1.2.1 \
+ crate://crates.io/byteorder/1.3.4 \
+ crate://crates.io/bytes/0.5.6 \
+ crate://crates.io/bytes/1.0.1 \
+ crate://crates.io/cc/1.0.67 \
+ crate://crates.io/cexpr/0.4.0 \
+ crate://crates.io/cfg-if/1.0.0 \
+ crate://crates.io/clang-sys/1.1.1 \
+ crate://crates.io/clap/2.33.3 \
+ crate://crates.io/cmake/0.1.45 \
+ crate://crates.io/cryptoauthlib-sys/0.1.0 \
+ crate://crates.io/cryptoki-sys/0.1.1 \
+ crate://crates.io/cryptoki/0.1.1 \
+ crate://crates.io/derivative/2.2.0 \
+ crate://crates.io/either/1.6.1 \
+ crate://crates.io/enumflags2/0.6.4 \
+ crate://crates.io/enumflags2_derive/0.6.4 \
+ crate://crates.io/env_logger/0.8.3 \
+ crate://crates.io/fixedbitset/0.2.0 \
+ crate://crates.io/getrandom/0.2.2 \
+ crate://crates.io/glob/0.3.0 \
+ crate://crates.io/hashbrown/0.9.1 \
+ crate://crates.io/heck/0.3.2 \
+ crate://crates.io/hermit-abi/0.1.18 \
+ crate://crates.io/hex/0.4.3 \
+ crate://crates.io/hostname-validator/1.0.0 \
+ crate://crates.io/humantime/2.1.0 \
+ crate://crates.io/indexmap/1.6.2 \
+ crate://crates.io/itertools/0.8.2 \
+ crate://crates.io/itertools/0.9.0 \
+ crate://crates.io/lazy_static/1.4.0 \
+ crate://crates.io/lazycell/1.3.0 \
+ crate://crates.io/libc/0.2.89 \
+ crate://crates.io/libloading/0.7.0 \
+ crate://crates.io/log/0.4.14 \
+ crate://crates.io/mbox/0.5.0 \
+ crate://crates.io/memchr/2.3.4 \
+ crate://crates.io/multimap/0.8.3 \
+ crate://crates.io/nom/5.1.2 \
+ crate://crates.io/num-bigint/0.3.2 \
+ crate://crates.io/num-complex/0.3.1 \
+ crate://crates.io/num-derive/0.3.3 \
+ crate://crates.io/num-integer/0.1.44 \
+ crate://crates.io/num-iter/0.1.42 \
+ crate://crates.io/num-rational/0.3.2 \
+ crate://crates.io/num-traits/0.2.14 \
+ crate://crates.io/num/0.3.1 \
+ crate://crates.io/num_cpus/1.13.0 \
+ crate://crates.io/oid/0.1.1 \
+ crate://crates.io/parsec-interface/0.24.0 \
+ crate://crates.io/peeking_take_while/0.1.2 \
+ crate://crates.io/petgraph/0.5.1 \
+ crate://crates.io/picky-asn1-der/0.2.4 \
+ crate://crates.io/picky-asn1-x509/0.4.0 \
+ crate://crates.io/picky-asn1/0.3.1 \
+ crate://crates.io/pkg-config/0.3.19 \
+ crate://crates.io/ppv-lite86/0.2.10 \
+ crate://crates.io/proc-macro-error-attr/1.0.4 \
+ crate://crates.io/proc-macro-error/1.0.4 \
+ crate://crates.io/proc-macro2/1.0.24 \
+ crate://crates.io/prost-build/0.6.1 \
+ crate://crates.io/prost-build/0.7.0 \
+ crate://crates.io/prost-derive/0.6.1 \
+ crate://crates.io/prost-derive/0.7.0 \
+ crate://crates.io/prost-types/0.6.1 \
+ crate://crates.io/prost-types/0.7.0 \
+ crate://crates.io/prost/0.6.1 \
+ crate://crates.io/prost/0.7.0 \
+ crate://crates.io/psa-crypto-sys/0.8.0 \
+ crate://crates.io/psa-crypto/0.8.0 \
+ crate://crates.io/quote/1.0.9 \
+ crate://crates.io/rand/0.8.3 \
+ crate://crates.io/rand_chacha/0.3.0 \
+ crate://crates.io/rand_core/0.6.2 \
+ crate://crates.io/rand_hc/0.3.0 \
+ crate://crates.io/redox_syscall/0.2.5 \
+ crate://crates.io/regex-syntax/0.6.23 \
+ crate://crates.io/regex/1.4.5 \
+ crate://crates.io/remove_dir_all/0.5.3 \
+ crate://crates.io/rust-cryptoauthlib/0.1.0 \
+ crate://crates.io/rustc-hash/1.1.0 \
+ crate://crates.io/rustc_version/0.2.3 \
+ crate://crates.io/same-file/1.0.6 \
+ crate://crates.io/sd-notify/0.2.0 \
+ crate://crates.io/secrecy/0.7.0 \
+ crate://crates.io/semver-parser/0.7.0 \
+ crate://crates.io/semver/0.9.0 \
+ crate://crates.io/serde/1.0.124 \
+ crate://crates.io/serde_bytes/0.11.5 \
+ crate://crates.io/serde_derive/1.0.124 \
+ crate://crates.io/shlex/0.1.1 \
+ crate://crates.io/signal-hook-registry/1.3.0 \
+ crate://crates.io/signal-hook/0.3.7 \
+ crate://crates.io/stable_deref_trait/1.2.0 \
+ crate://crates.io/strsim/0.8.0 \
+ crate://crates.io/structopt-derive/0.4.14 \
+ crate://crates.io/structopt/0.3.21 \
+ crate://crates.io/strum_macros/0.19.4 \
+ crate://crates.io/syn/1.0.64 \
+ crate://crates.io/synstructure/0.12.4 \
+ crate://crates.io/tempfile/3.2.0 \
+ crate://crates.io/termcolor/1.1.2 \
+ crate://crates.io/textwrap/0.11.0 \
+ crate://crates.io/thiserror-impl/1.0.24 \
+ crate://crates.io/thiserror/1.0.24 \
+ crate://crates.io/threadpool/1.8.1 \
+ crate://crates.io/toml/0.5.8 \
+ crate://crates.io/tss-esapi-sys/0.1.0 \
+ crate://crates.io/tss-esapi/5.0.0 \
+ crate://crates.io/unicode-segmentation/1.7.1 \
+ crate://crates.io/unicode-width/0.1.8 \
+ crate://crates.io/unicode-xid/0.2.1 \
+ crate://crates.io/users/0.11.0 \
+ crate://crates.io/uuid/0.8.2 \
+ crate://crates.io/vec_map/0.8.2 \
+ crate://crates.io/version/3.0.0 \
+ crate://crates.io/version_check/0.9.3 \
+ crate://crates.io/walkdir/2.3.1 \
+ crate://crates.io/wasi/0.10.2+wasi-snapshot-preview1 \
+ crate://crates.io/which/3.1.1 \
+ crate://crates.io/which/4.0.2 \
+ crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi-util/0.1.5 \
+ crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi/0.3.9 \
+ crate://crates.io/zeroize/1.2.0 \
+ crate://crates.io/zeroize_derive/1.0.1 \
+ file://cryptoki.patch \
+"
+
+LIC_FILES_CHKSUM = " \
+ file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57 \
+"
diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
new file mode 100644
index 0000000..939e771
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.bb
@@ -0,0 +1,18 @@
+SUMMARY = "Parsec Command Line Interface"
+HOMEPAGE = "https://github.com/parallaxsecond/parsec-tool"
+LICENSE = "Apache-2.0"
+
+inherit cargo
+
+SRC_URI += "crate://crates.io/parsec-tool/${PV} \
+"
+
+DEPENDS = "clang-native"
+INSANE_SKIP_${PN} += "dev-deps"
+
+do_install() {
+ install -d ${D}/${bindir}
+ install -m 755 "${B}/target/${TARGET_SYS}/release/parsec-tool" "${D}${bindir}/parsec-tool"
+}
+
+require parsec-tool_${PV}.inc
diff --git a/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc
new file mode 100644
index 0000000..9560dcf
--- /dev/null
+++ b/meta-parsec/recipes-parsec/parsec-tool/parsec-tool_0.3.0.inc
@@ -0,0 +1,127 @@
+# This file is created from parsec-tool repository Cargo.lock using cargo-bitbake tool
+
+SRC_URI += " \
+ crate://crates.io/aho-corasick/0.7.15 \
+ crate://crates.io/ansi_term/0.11.0 \
+ crate://crates.io/ansi_term/0.12.1 \
+ crate://crates.io/anyhow/1.0.38 \
+ crate://crates.io/atty/0.2.14 \
+ crate://crates.io/autocfg/1.0.1 \
+ crate://crates.io/base64/0.13.0 \
+ crate://crates.io/bincode/1.3.1 \
+ crate://crates.io/bitflags/1.2.1 \
+ crate://crates.io/block-buffer/0.9.0 \
+ crate://crates.io/byteorder/1.4.2 \
+ crate://crates.io/bytes/0.5.6 \
+ crate://crates.io/cc/1.0.66 \
+ crate://crates.io/cfg-if/1.0.0 \
+ crate://crates.io/clap/2.33.3 \
+ crate://crates.io/clap/3.0.0-beta.2 \
+ crate://crates.io/clap_derive/3.0.0-beta.2 \
+ crate://crates.io/cmake/0.1.45 \
+ crate://crates.io/cpuid-bool/0.1.2 \
+ crate://crates.io/derivative/2.2.0 \
+ crate://crates.io/digest/0.9.0 \
+ crate://crates.io/either/1.6.1 \
+ crate://crates.io/env_logger/0.8.3 \
+ crate://crates.io/fixedbitset/0.2.0 \
+ crate://crates.io/form_urlencoded/1.0.0 \
+ crate://crates.io/generic-array/0.14.4 \
+ crate://crates.io/getrandom/0.2.2 \
+ crate://crates.io/hashbrown/0.9.1 \
+ crate://crates.io/heck/0.3.2 \
+ crate://crates.io/hermit-abi/0.1.18 \
+ crate://crates.io/humantime/2.1.0 \
+ crate://crates.io/idna/0.2.1 \
+ crate://crates.io/indexmap/1.6.1 \
+ crate://crates.io/itertools/0.8.2 \
+ crate://crates.io/lazy_static/1.4.0 \
+ crate://crates.io/libc/0.2.86 \
+ crate://crates.io/log/0.4.14 \
+ crate://crates.io/matches/0.1.8 \
+ crate://crates.io/memchr/2.3.4 \
+ crate://crates.io/multimap/0.8.2 \
+ crate://crates.io/num-bigint/0.3.1 \
+ crate://crates.io/num-complex/0.3.1 \
+ crate://crates.io/num-derive/0.3.3 \
+ crate://crates.io/num-integer/0.1.44 \
+ crate://crates.io/num-iter/0.1.42 \
+ crate://crates.io/num-rational/0.3.2 \
+ crate://crates.io/num-traits/0.2.14 \
+ crate://crates.io/num/0.3.1 \
+ crate://crates.io/oid/0.1.1 \
+ crate://crates.io/once_cell/1.5.2 \
+ crate://crates.io/opaque-debug/0.3.0 \
+ crate://crates.io/os_str_bytes/2.4.0 \
+ crate://crates.io/parsec-client/0.12.0 \
+ crate://crates.io/parsec-interface/0.24.0 \
+ crate://crates.io/pem/0.8.3 \
+ crate://crates.io/percent-encoding/2.1.0 \
+ crate://crates.io/petgraph/0.5.1 \
+ crate://crates.io/picky-asn1-der/0.2.4 \
+ crate://crates.io/picky-asn1/0.3.1 \
+ crate://crates.io/ppv-lite86/0.2.10 \
+ crate://crates.io/proc-macro-error-attr/1.0.4 \
+ crate://crates.io/proc-macro-error/1.0.4 \
+ crate://crates.io/proc-macro2/1.0.24 \
+ crate://crates.io/prost-build/0.6.1 \
+ crate://crates.io/prost-derive/0.6.1 \
+ crate://crates.io/prost-types/0.6.1 \
+ crate://crates.io/prost/0.6.1 \
+ crate://crates.io/psa-crypto-sys/0.8.0 \
+ crate://crates.io/psa-crypto/0.8.0 \
+ crate://crates.io/quote/1.0.9 \
+ crate://crates.io/rand/0.8.3 \
+ crate://crates.io/rand_chacha/0.3.0 \
+ crate://crates.io/rand_core/0.6.2 \
+ crate://crates.io/rand_hc/0.3.0 \
+ crate://crates.io/redox_syscall/0.2.5 \
+ crate://crates.io/regex-syntax/0.6.22 \
+ crate://crates.io/regex/1.4.3 \
+ crate://crates.io/remove_dir_all/0.5.3 \
+ crate://crates.io/same-file/1.0.6 \
+ crate://crates.io/secrecy/0.7.0 \
+ crate://crates.io/serde/1.0.123 \
+ crate://crates.io/serde_bytes/0.11.5 \
+ crate://crates.io/serde_derive/1.0.123 \
+ crate://crates.io/sha2/0.9.3 \
+ crate://crates.io/strsim/0.10.0 \
+ crate://crates.io/strsim/0.8.0 \
+ crate://crates.io/structopt-derive/0.4.14 \
+ crate://crates.io/structopt/0.3.21 \
+ crate://crates.io/syn/1.0.60 \
+ crate://crates.io/synstructure/0.12.4 \
+ crate://crates.io/tempfile/3.2.0 \
+ crate://crates.io/termcolor/1.1.2 \
+ crate://crates.io/textwrap/0.11.0 \
+ crate://crates.io/textwrap/0.12.1 \
+ crate://crates.io/thiserror-impl/1.0.23 \
+ crate://crates.io/thiserror/1.0.23 \
+ crate://crates.io/thread_local/1.1.3 \
+ crate://crates.io/tinyvec/1.1.1 \
+ crate://crates.io/tinyvec_macros/0.1.0 \
+ crate://crates.io/typenum/1.12.0 \
+ crate://crates.io/unicode-bidi/0.3.4 \
+ crate://crates.io/unicode-normalization/0.1.17 \
+ crate://crates.io/unicode-segmentation/1.7.1 \
+ crate://crates.io/unicode-width/0.1.8 \
+ crate://crates.io/unicode-xid/0.2.1 \
+ crate://crates.io/url/2.2.0 \
+ crate://crates.io/users/0.10.0 \
+ crate://crates.io/uuid/0.8.2 \
+ crate://crates.io/vec_map/0.8.2 \
+ crate://crates.io/version_check/0.9.2 \
+ crate://crates.io/walkdir/2.3.1 \
+ crate://crates.io/wasi/0.10.2+wasi-snapshot-preview1 \
+ crate://crates.io/which/3.1.1 \
+ crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi-util/0.1.5 \
+ crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
+ crate://crates.io/winapi/0.3.9 \
+ crate://crates.io/zeroize/1.2.0 \
+ crate://crates.io/zeroize_derive/1.0.1 \
+"
+
+LIC_FILES_CHKSUM = " \
+ file://LICENSE;md5=3b83ef96387f14655fc854ddc3c6bd57 \
+"
--
2.20.1


[meta-security][PATCH] initramfs-framework-ima: introduce IMA_FORCE

Ming Liu <liu.ming50@...>
 

From: Ming Liu <liu.ming50@...>

Introduce IMA_FORCE to allow the IMA policy be applied forcely even
'no_ima' boot parameter is available.

This ensures the end users have a way to disable 'no_ima' support if
they want to, because it may expose a security risk if an attacker can
find a way to change kernel arguments, it will easily bypass rootfs
authenticity checks.

Signed-off-by: Sergio Prado <sergio.prado@...>
Signed-off-by: Ming Liu <liu.ming50@...>
---
.../initrdscripts/initramfs-framework-ima.bb | 5 +++++
.../initrdscripts/initramfs-framework-ima/ima | 9 +++++++--
2 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framewor=
k-ima.bb b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-=
ima.bb
index 77f6f7c..6471c53 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.b=
b
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima.b=
b
@@ -14,6 +14,9 @@ LIC_FILES_CHKSUM =3D "file://${COREBASE}/meta/COPYING.M=
IT;md5=3D3da9cfbcb788c80a0384
# to this recipe can just point towards one of its own files.
IMA_POLICY ?=3D "ima-policy-hashed"
=20
+# Force proceed IMA procedure even 'no_ima' boot parameter is available.
+IMA_FORCE ?=3D "false"
+
SRC_URI =3D " file://ima"
=20
inherit features_check
@@ -23,6 +26,8 @@ do_install () {
install -d ${D}/${sysconfdir}/ima
install -d ${D}/init.d
install ${WORKDIR}/ima ${D}/init.d/20-ima
+
+ sed -i "s/@@FORCE_IMA@@/${IMA_FORCE}/g" ${D}/init.d/20-ima
}
=20
FILES_${PN} =3D "/init.d ${sysconfdir}"
diff --git a/meta-integrity/recipes-core/initrdscripts/initramfs-framewor=
k-ima/ima b/meta-integrity/recipes-core/initrdscripts/initramfs-framework=
-ima/ima
index cff26a3..8971494 100644
--- a/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/i=
ma
+++ b/meta-integrity/recipes-core/initrdscripts/initramfs-framework-ima/i=
ma
@@ -2,11 +2,16 @@
#
# Loads IMA policy into the kernel.
=20
+force_ima=3D@@FORCE_IMA@@
+
ima_enabled() {
- if [ "$bootparam_no_ima" =3D "true" ]; then
+ if [ "$force_ima" =3D "true" ]; then
+ return 0
+ elif [ "$bootparam_no_ima" =3D "true" ]; then
return 1
+ else
+ return 0
fi
- return 0
}
=20
ima_run() {
--=20
2.29.0


Re: [meta-rockchip][PATCH v2] trusted-firmware-a: use 1500000 baud for serial console

Trevor Woerner
 

Tested with rock-pi-4b and applied to master.
Thanks!


Re: esdk issue using gatesgarth sources

Khem Raj
 

can you post detailed log

On 4/8/21 12:56 AM, sateesh m wrote:
Hi Guys,
               I am trying to build  core-image-base using gatesgarth sources to generate esdk. But i am facing issue with opensbi_0.8.bb:do_fetch failed with exit code 'setscene whitelist'. can anybody help me to fix this issue.
Regards,
Sateesh


esdk issue using gatesgarth sources

sateesh m
 

Hi Guys,

               I am trying to build  core-image-base using gatesgarth sources to generate esdk. But i am facing issue with opensbi_0.8.bb:do_fetch failed with exit code 'setscene whitelist'. can anybody help me to fix this issue. 


Regards,
Sateesh


[meta-rockchip][PATCH v2] trusted-firmware-a: use 1500000 baud for serial console

Yann Dirson
 

From: Yann Dirson <yann@...>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificial=
ly
separated for emphasis:

[20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
[20210406-175438.135956] Channel 0: DDR3, 933MHz
[20210406-175438.236974] BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS=3D1 Die=
BW=3D16 Size=3D1024MB
[20210406-175438.237000] Channel 1: DDR3, 933MHz
[20210406-175438.237004] BW=3D32 Col=3D10 Bk=3D8 CS0 Row=3D15 CS=3D1 Die=
BW=3D16 Size=3D1024MB
[20210406-175438.237008] 256B stride
[20210406-175438.237012] Trying to boot from BOOTROM
[20210406-175438.237015] Returning to boot ROM...
[20210406-175438.237018]
[20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +000=
0)
[20210406-175438.573431] Trying to boot from MMC1

[20210406-175438.589254] NOTICE: BL31: v2.3():v2.3-dirty
[20210406-175440.534055] NOTICE: BL31: Built : 15:56:43, Apr 20 2020

[20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
[20210406-175441.393429]
[20210406-175441.393433] SoC: Rockchip rk3399

Signed-off-by: Yann Dirson <yann@...>
---
.../files/serial-console-baudrate.patch | 36 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 5 +++
2 files changed, 41 insertions(+)
create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-b=
audrate.patch

Changes in v2:
- added Upstream-Status tag

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate=
.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.pat=
ch
new file mode 100644
index 0000000..2d6e9bf
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,36 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@...>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+Upstream-Status: Inappropriate[other]
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce6=
2.
+Main reason for that change stated in https://developer.trustedfirmware.=
org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.
+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk=
3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**********************************************************************=
****
+ * UART related constants
+ **********************************************************************=
****/
+-#define RK3399_BAUDRATE 115200
++#define RK3399_BAUDRATE 1500000
+ #define RK3399_UART_CLOCK 24000000
+=20
+ /**********************************************************************=
********
+--=20
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend=
b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 =3D " virtual/arm-none-eabi-gcc-nat=
ive"
=20
COMPATIBLE_MACHINE_append_rk3399 =3D "|rk3399"
COMPATIBLE_MACHINE_append_rk3328 =3D "|rk3328"
+
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+SRC_URI +=3D "\
+ file://serial-console-baudrate.patch \
+"
--=20
2.30.2


Re: [PATCH yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list

Nicolas Dechesne
 



On Wed, Apr 7, 2021 at 10:16 AM Nicolas Dechesne <nicolas.dechesne@...> wrote:
hey!

On Wed, Apr 7, 2021 at 9:31 AM Quentin Schulz <foss@...> wrote:
Hi Michael,

On April 6, 2021 10:58:20 PM UTC, Michael Halstead <mhalstead@...> wrote:
>All new releases are Sphinx ready so we exclude old tags and build for
>all the rest.

Thanks for starting this!
 
>
>Signed-off-by: Michael Halstead <mhalstead@...>
>---
> scripts/run-docs-build | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
>diff --git a/scripts/run-docs-build b/scripts/run-docs-build
>index 910f03d..13df34a 100755
>--- a/scripts/run-docs-build
>+++ b/scripts/run-docs-build
>@@ -7,6 +7,7 @@ ypdocs=$2/documentation/
> bbdocs=$3/doc/
> docs_buildtools=/srv/autobuilder/autobuilder.yoctoproject.org/pub/buildtools/x86_64-buildtools-docs-nativesdk-standalone-3.2+snapshot-20201105.sh
> outputdir=$builddir/output
>+excluded_tags="yocto-3.1.4 yocto-3.1.3 yocto-3.1.2 yocto-3.1.1 yocto-3.1 yocto-3.0.1 yocto-3.0 yocto-2.6.4 yocto-2.6.3 yocto-2.7.1 yocto-2.6.2 yocto-2.7 yocto-2.6.1 yocto-2.6 yocto-2.5.2 yocto-2.5.1 yocto-2.4.4 yocto-2.4.3 yocto-2.5 yocto-2.3.4 yocto-1.0.2 yocto-1.1.2 yocto-1.2.2 yocto-1.2.1 yocto-1.3 yocto-1.3.1 yocto-1.3.2 yocto-1.4.3 yocto-1.4.2 yocto-1.4.1 yocto-1.4 yocto-2.1.3 yocto-2.4.2 yocto-2.1.1 yocto-2.1.2 yocto-2.0.3 yocto-1.8.2 yocto-2.2.3 yocto-2.4.1 yocto-2.3.3 yocto-2.3.2 yocto-2.4 yocto-2.2.2 yocto-2.3.1 yocto-2.3 yocto-2.2.1 yocto-2.0.2 yocto-2.2 yocto-2.1 yocto-2.0.1 yocto-2.0 yocto-1.8.1 yocto-1.7.3 yocto-1.6.3 yocto-1.7.2 yocto-1.8 yocto-1.5.1"
>
>
> cd $builddir
>@@ -77,13 +78,18 @@ for branch in dunfell gatesgarth hardknott; do
> done
>
> # Yocto Project releases/tags
>-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do
>+cd $ypdocs
>+for tag in $(git tag -l  |grep 'yocto-' |sort); do

IIUC the man page,
git tag --list 'yocto-*' | sort

sort -V is even better since it does "natural sort of (version) numbers within text", let's get ready for 3.10 ;) 
 
And using -V, how about something along these lines:

v_sphinx='yocto-3.1.5'
for v in $(git tag --list 'yocto-*'); do
    first=$(printf '%s\n%s' $v $v_sphinx | sort -V | head -n1)
    if [ "$first" = "$v_sphinx" ]; then
        echo "Yocto $v uses Sphinx!"
    fi
done

and it outputs the following when I run it locally:

Yocto yocto-3.1.5 uses Sphinx!
Yocto yocto-3.1.6 uses Sphinx!
Yocto yocto-3.2 uses Sphinx!
Yocto yocto-3.2.1 uses Sphinx!
Yocto yocto-3.2.2 uses Sphinx!
Yocto yocto-3.2.3 uses Sphinx!



would be doing the same thing as the one command with grep above.
Discovered it recently so just wanted to share.

I guess this is something we can also do for bitbake Sphinx documentation?

yes.

Well, in fact no , we shouldn't, is a short answer ;) 

Here is the long answer.. 

For bitbake and YP, we currently publish: master, master-next and 'stable' branches (e.g. 1.46, 1.48, 1.50 for bitbake dunfell, gatesgarth, hardknott for YP). Then we also publish YP releases (and point releases), e.g. 3.1.5 and beyond, but  we don't publish anything for releases/point release of bitbake, At least just yet. And it's a 'bug'. Since the YP docs includes links (with intersphinx)  to bitbake docs, then when we look at a master, master-next or any branches on docs.yp.org, then the links are correct. for example if you look at

vs

this page has links to bitbake and it points respectively to:
and

Which is correct. 

[Side note: I've noticed that the hardknott page is wrong, since
I will send a patch for that]

Now if we look at a YP release, such as 
it has this link:

which is not correct, since it links to a bitbake 'branch' docs build, and not a bitbake 'release' docs build. 


 

Removed the git context inadvertently but, is =~ some bash built-in? I don't know what's the shebang on top but maybe we want to force it to bash since I'm not sure it's POSIX "compliant" anymore? 

It is bash already. 
 

Reviewed-by: Quentin Schulz <foss@...>

Thanks,
Quentin


Re: No significant diff b/w qemux86 and qemuarm poky build of core-image-minimal

Khem Raj
 

On Tue, Mar 30, 2021 at 2:20 PM Khem Raj <raj.khem@...> wrote:



On 3/30/21 1:48 PM, Ross Burton wrote:
On Tue, 30 Mar 2021 at 20:41, Khem Raj <raj.khem@...> wrote:
Thanks for this infor Randy, really appreciated, I think I will also
look at the h/w angle.
Khem: if you can reproduce this on demand with a clean build (ie
oe-init-build-env with a clean build directory, just set DL_DIR) then
enabling buildstats would give some interesting metrics.
buildstats-diff can compare two build runs and tell you what the
differences are.
yeah this is doing world build of not only core but several other layers
included a usual build takes around 10 hrs for this machine config, I am
planning to

1. Collect build stats
2. buiid another qemu machine on this VM

it could very well be rotting hardware underneath the VM.
To close the loop, it turned out to be the case that CPU performance
on VM has deteriorated
which stress-ng showed. The VM has been rebuilt and everything seems
to be holding fine now.
Thanks for your help and chiming in.

Ross


[PATCH v2 yocto-autobuilder-helper] run-docs-build: build from tags dynamically instead of static list

Michael Halstead
 

Build Sphinx docs for all versions newer than yocto-3.1.5 inclusive.
Integrate suggestions from Quentin Schulz and Nicolas Dechesne.

Signed-off-by: Michael Halstead <mhalstead@...>
---
scripts/run-docs-build | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/scripts/run-docs-build b/scripts/run-docs-build
index 910f03d..52bd567 100755
--- a/scripts/run-docs-build
+++ b/scripts/run-docs-build
@@ -77,13 +77,19 @@ for branch in dunfell gatesgarth hardknott; do
done

# Yocto Project releases/tags
-for tag in 3.1.5 3.1.6 3.2 3.2.1 3.2.2 3.2.3; do
- cd $ypdocs
- git checkout yocto-$tag
- make clean
- make publish
- mkdir $outputdir/$tag
- cp -r ./_build/final/* $outputdir/$tag
+v_sphinx='yocto-3.1.5' #This and newer versions have Sphinx docs.
+cd $ypdocs
+for tag in $(git tag --list 'yocto-*'); do
+ first=$(printf '%s\n%s' $tag $v_sphinx | sort --version-sort | head -n1)
+ if [ "$first" = "$v_sphinx" ]; then
+ cd $ypdocs
+ git checkout $tag
+ make clean
+ make publish
+ version=$(echo $tag | cut -c7-)
+ mkdir $outputdir/$version
+ cp -r ./_build/final/* $outputdir/$version
+ fi
done

# Update switchers.js with the copy from master ypdocs
--
2.30.2


Yocto Project Summit - registration open

Trevor Woerner
 

Registration is now open for the upcoming Yocto Project Summit!!

details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
CfP: https://pretalx.com/yocto-project-summit-2021/cfp
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

PS: Don't forget to get in your talk proposals! The CfP closes April 25th


Yocto Technical Team Minutes, Engineering Sync, for April 6, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for April 6, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
CfP: https://pretalx.com/yocto-project-summit-2021/cfp
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolley, Richard Purdie, Steve Sakoman, Peter
Kjellerstedt, Armin Kuster, Scott Murray, Michael Halstead, Bruce Ashfield,
Saul Wold, Joshua Watt, Jon Mason, Jan-Simon Möller, Randy MacLeod, Paul
Barker, Denys Dmytriyenko, Rob Wolley, sakib.sajal@windriver, Tim Orling,
Ross Burton, Philip Ballister, Daiane Angolini, Trevor Gamblin, Alejandro H

== notes ==
- close to building 3.3-rc1
- still need changelog, migration guide, release notes, etc
- released 3.2.3
- change to allow qemu to run from tmpfs
- can’t use cgroups
- lots of version upgrades, need to wait for 3.4
- ~50 intermittent AB issues
- planning doc available for 3.4

== general ==
RP: still thinking about what to do with docs for 3.3, still need to wait on
changelog, migration, release notes before we can release


RP: lots of I/O copying the qemu images before starting up the tests, causing
some of the timeouts, therefore the move to running from tmpfs


Bruce: there are some perf-tests things missing from master-next
RP: oops, missed it


SteveS: is the tmpfs something we want to backport to dunfell
RP: ultimately yes. low risk. but give it time on the AB first before merging.
should be a nice simple change


StephenJ: we were supposed to do a 3.1.7 last week but there wasn’t anything
for it
SteveS: i didn’t want to get in the way of master releases. there is another
bitbake change that i’d like to get in too, but we can do that anytime
StephenJ: we’ll want it behind the master release, but it should come out
sometime this month. i also have 3.1.8, 3.1.9, and 3.1.10 in the planning
docs, as milestones
RP: we’ll get 3.3 build, then we can do the next 3.1.y after that


PaulB: prserv modernization (async-io json-rpc startup/shutdown readonly-mode)
i’ve now got all that done, oe-selftest is passing, bitbake self-test
is passing. still have another day of tidying up. should it be sent as an
RFC?
RP: it’s good timing. i think it’s 3.4 material and it’s a good time to
put it out there (see 3.4 planning doc).
RP: PaulG also put out some patches to make the fetcher more efficient
regarding kernel fetching which also sounds like 3.4 material. master-next
is where i’m putting 3.4 things for now.
PaulB: i think they’re all bitbake patches, and there’s one oe-core patch.
for the RFC i’ll just send it all together and we can split them up later
JPEW: can you CC me please
PaulB: np


Randy: memory-resident bitbake as the default?
RP: i’d like to see it, but depends on whether we can get all the bugs
worked out before. the blocker was that enabling it for oe-selftest causes
carnage. we need to figure out why, it shouldn’t cause any issues, but
it does. once we can get oe-selftest working then i’m game for enabling
it by default and simply fixing anything that comes up. this change
retrofits bitbake to do something it wasn’t designed to do. there’s
some assumption somewhere that’s being violated that we don’t know
RP: the tmpfs change i just made is a good example of showing you how to
change every test
TrevorG: re doc change, i submitted a v2 (thanks MichaelO for review) and
added instructions. i think we want something added to the -dev manual?
RP: yes, we now have a doc person and we want to cover the AB in the test
manual. the test manual we currently have is just a start, mostly
pointers, but i’d like to see it expanded
TimO: i’d like to add a ptest for python or ptest for perl section too to
the test manual


RP: re AB-int. can we list out what’s in the I/O queue that the kernel is
processing? i’m guessing not (security reasons) but it would be great if
it could. in the past we’ve listed out processes that are occurring when
failures occur; that allowed us to identify an issue with building webkit,
but there’s only so much a process listing will give us and there are
other stats we should look at at failure time
Randy: yes, we’ve looked at a bunch of stuff, but most of them need root
permissions
RP: if the tools are standard then we can give access to those tools to the
poky builder user
RP: with more tooling we’ll probably see a lot of these qemu startup issues
and we’ll probably also see lots of bitbake timeout (60s no response)
issues. iow, a large set of issues, i’m hoping, will condense down to a
handful of issues. there was also a libgomp issue that JPEW was seeing,
but even after that fix we’re still seeing the AB-int issues


TimO: patchwork. have we looked at upgrading to a newer version
MichaelH: i’m trying to get a -dev version working, i’d like to pull you
in (TimO) to help if you’re available
TimO: yes, that’d be great
RP: MichaelH is setting up a -dev instance of patchwork to see if we can get a
bunch of things working (i.e. integrate with AB, integrate with testing,
etc) to see if this is viable
TimO: my analysis (from last year) was that the ozlabs one was really old, but
the freedesktop.org patchwork version is better
MichaelH: and in the past year it looks like the ozlabs one has pulled in all
the things from fd.o and is now, in fact, ahead of the ozlabs one. so
that’s the one that i’ve been working with (i.e. ozlabs)
RP: i think the new system is a lot easier to work with, it seems easier to
pull patches in


ScottM: (to Armin) moving libseccomp to meta-oe. maybe we should move it right
to oe-core?
Armin: it can go anywhere. Khem had an issue with it.
TimO: i think there are some things in meta-virt that need it
ScottM: i have some customers that need it, i always enable it, i used it with
systemd
Bruce: i debugged a k3s issue for ~3 months that turned out to be a libseccomp
issue, so it seems “needed” in most virt setups
RP: we need to be known as being able to support virtualization and handling
these sorts of issues for our users, so i’m open to taking it in oe-core
<Armin agrees to prepare a patch for oe-core>
RP: i can take something like that in master-next for now, even though master
isn’t open yet for new things. there are a bunch of things that we need
to consider moving to oe-core (this (seccomp), rust, etc) so now’s a
good time to have these discussions
PaulB: i’m for it, i’ve bumped up against some issues that could use these
things


Bruce: there are some virt recipes that try to download things in do_compile,
and that’s not a good thing
ScottM: there was a presentation doing this at the last conference
PaulB: maybe we should think about disabling network access during compile?


Armin: rustc in a devshell? mine always segfaults
Randy: depends on the args passed to rustc. can’t remember off the top of my
head.
Armin: segfault with stackX. sounds like the file issue like we were having
with pseudo. version 7 is going to need clang, so i want to get this done
first.


TimO: there’s talk of using rust for device drivers in the kernel, anyone
using any or planning on using any?
Randy: probably in upcoming kernels
TimO: we’ll need to figure out how to do that
Randy: we’ll have to figure that out when the time comes


RP: any other 3.4 issues?
TimO: recipetool for perl (which i’m working on). also ptest/pytest plugin
to make ptest output generic and consistent
RossB: another discussion to talk about changing the ptest output? it’d be
nice to migrate to a more structured, common format
TimO: <agree>
RP: i think this could be something that is added piece-meal, it doesn’t
have to be invasive, or all-or-nothing
Saul: i’m hoping to get the qmp stuff figured out for 3.4


RP: ptest-runner, anibal found and fixed some issues which i’ve pulled into
the next build. i don’t think they’ll cause anything to blow up
Randy: fixes in ptest-runner are pretty important
RP: i also upgraded diffoscope since it was causing hangs. they release every
week, so the release numbers increase rapidly, but the changes are small


TimO: RossB and i talked about upgrading matchbox to wayland, but i doubt
that’ll land for 3.4
RP: there are lots of changes in this area
ScottM: i’m interested too. maybe use libwayland
TimO: yes, that’s what we were thinking
RP: it’s a good time to start planning and thinking about it, maybe 3.4 or
3.5
JPEW: i looked at posh (phone gnome shell) advantage is that it can run any
gnome application unmodified, but it does need a lot of dependencies
TrevorG: i was looking at that too recently and thought it was good. i looked
at a competitor that didn’t do as well
JPEW: you need everything to build gnome-3 but then don't end up building
gnome 3 ;-)


Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Trevor Woerner
 

On Wed, Apr 7, 2021 at 9:27 AM Joshua Watt <jpewhacker@...> wrote:
Please add Upstream-Status:
https://wiki.yoctoproject.org/wiki/Best_Known_Methods_(BKMs)_for_Package_Updating#Patch_Upstreaming


Re: [meta-rockchip][PATCH] trusted-firmware-a: use 1500000 baud for serial console

Joshua Watt
 


On 4/6/21 6:47 PM, Yann Dirson wrote:
From: Yann Dirson <yann@...>

TF-A runs between two u-boot stages which both uses 1500000 baud, it
just makes no sense to use the same UART at a different rate.

Here is a sample session with the successive stages, with TF-A artificially
separated for emphasis:

 [20210406-175438.135934] U-Boot TPL 2021.01 (Jan 11 2021 - 18:11:43)
 [20210406-175438.135956] Channel 0: DDR3, 933MHz
 [20210406-175438.236974] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
 [20210406-175438.237000] Channel 1: DDR3, 933MHz
 [20210406-175438.237004] BW=32 Col=10 Bk=8 CS0 Row=15 CS=1 Die BW=16 Size=1024MB
 [20210406-175438.237008] 256B stride
 [20210406-175438.237012] Trying to boot from BOOTROM
 [20210406-175438.237015] Returning to boot ROM...
 [20210406-175438.237018]
 [20210406-175438.573394] U-Boot SPL 2021.01 (Jan 11 2021 - 18:11:43 +0000)
 [20210406-175438.573431] Trying to boot from MMC1

 [20210406-175438.589254] NOTICE:  BL31: v2.3():v2.3-dirty
 [20210406-175440.534055] NOTICE:  BL31: Built : 15:56:43, Apr 20 2020

 [20210406-175441.393423] U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
 [20210406-175441.393429]
 [20210406-175441.393433] SoC: Rockchip rk3399

Very good. TF-A should work "out of the box" in meta-rockchip, so I think changing it's baudrate to 1500000 makes sense at this point (at least until u-boot can pass the DTB)


Signed-off-by: Yann Dirson <yann@...>
---
 .../files/serial-console-baudrate.patch       | 35 +++++++++++++++++++
 .../trusted-firmware-a_%.bbappend             |  5 +++
 2 files changed, 40 insertions(+)
 create mode 100644 recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch

diff --git a/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
new file mode 100644
index 0000000..10b5a2b
--- /dev/null
+++ b/recipes-bsp/trusted-firmware-a/files/serial-console-baudrate.patch
@@ -0,0 +1,35 @@
+From 840d6b6420e1fd8cdf6e4de7fa58a6f8de151622 Mon Sep 17 00:00:00 2001
+From: Yann Dirson <yann@...>
+Date: Tue, 6 Apr 2021 17:28:45 +0200
+Subject: [PATCH] Set serial console baudrate back to 1500000.
+
+TF-A runs between two u-boot stages which both uses 1500000 baud, it
+just makes no sense to use the same UART at a different rate.
+
+This effectively reverts part of 0c05748bdebfad9fa43a80962186438bb8fbce62.
+Main reason for that change stated in https://developer.trustedfirmware.org/T762
+is ChromeOS compatibility.
+
+Looks like this patch may become unnecessary in the future, when
+u-boot and TF-A get to communicate this value.

Please add Upstream-Status:


+
+---
+ plat/rockchip/rk3399/rk3399_def.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/plat/rockchip/rk3399/rk3399_def.h b/plat/rockchip/rk3399/rk3399_def.h
+index ba83242eb..8d6ecfbe6 100644
+--- a/plat/rockchip/rk3399/rk3399_def.h
++++ b/plat/rockchip/rk3399/rk3399_def.h
+@@ -17,7 +17,7 @@
+ /**************************************************************************
+  * UART related constants
+  **************************************************************************/
+-#define RK3399_BAUDRATE			115200
++#define RK3399_BAUDRATE			1500000
+ #define RK3399_UART_CLOCK		24000000
+ 
+ /******************************************************************************
+-- 
+2.30.2
+
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 442dee8..1942c17 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -4,3 +4,8 @@ DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"
 
 COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
 COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+SRC_URI += "\
+    file://serial-console-baudrate.patch \
+"




QA notification for completed autobuilder build (yocto-3.3.rc2)

Pokybuild User <pokybuild@...>
 

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


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


Build hash information:

bitbake: a1848a481e36b729c8e4130c394b1d462d4b488a
meta-arm: 219fd34b7676ffedd1a1ad3626ec4337391975f4
meta-gplv2: 9e119f333cc8f53bd3cf64326f826dbc6ce3db0f
meta-intel: 01cfc99a8f960917433a8a46b41bb4febb5b1993
meta-kernel: 29329d7cacc71595cecfdd05a455a0cfb164564d
meta-mingw: 422b96cb2b6116442be1f40dfb5bd77447d1219e
oecore: 14241ed09f9ed317045cf75a6d08416d3579bb8d
poky: e1839b58ebe05242a52fe050aa9a08140136aa0a



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


Re: #yocto #sdk -XILINX/vivado dependencies #yocto #sdk

Monsees, Steven C (US)
 

No the vivado module sets up key variables, the lib path, and the include paths for building Xilinx low level drivers built into bootapp/kernel...

I need to be able to include these components in actual SDK build...

Steve

-----Original Message-----
From: Khem Raj <raj.khem@...>
Sent: Tuesday, April 6, 2021 4:28 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto #sdk -XILINX/vivado dependencies

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


there is KERNEL_MODULE_AUTOLOAD which could be used to load modules on boot, don't know if that suffices to what you need but worth looking into.

On Tue, Apr 6, 2021 at 12:47 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:



Working with zeus, aarch64, with Xilinx vivado dependencies…

Kerenl image and bootapp build and run correctly, need to be able to
build EXT SDK,,,



How do I incorporate the dependencies of the low level Xilinx FPGA support (i.e. “vivado”) into the Ext SDK build env ?



Is there a way to build in support so that the “module load” command would be usable from the “.conf” or the env-setup script, (i.e. “module load vivado…” ?



Thanks,

Steve






[meta-security][PATCH] Use libest "main" branch instead of "master".

Anton Antonov
 

This patch fixes the issue:

WARNING: libest-3.2.0-r0 do_fetch: Failed to fetch URL git://github.com/cisco/libest, attempting MIRRORS if available
ERROR: libest-3.2.0-r0 do_fetch: Fetcher failure: Unable to find revision 4ca02c6d7540f2b1bcea278a4fbe373daac7103b in branch master even from upstream
ERROR: libest-3.2.0-r0 do_fetch: Fetcher failure for URL: 'git://github.com/cisco/libest'. Unable to fetch URL from any source.

Signed-off-by: Anton Antonov <Anton.Antonov@...>
---
recipes-security/libest/libest_3.2.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/libest/libest_3.2.0.bb b/recipes-security/libest/libest_3.2.0.bb
index f993bd6..5b6dc99 100644
--- a/recipes-security/libest/libest_3.2.0.bb
+++ b/recipes-security/libest/libest_3.2.0.bb
@@ -6,7 +6,7 @@ LICENSE = "OpenSSL"
LIC_FILES_CHKSUM = "file://LICENSE;md5=ecb78acde8e3b795de8ef6b61aed5885"

SRCREV = "4ca02c6d7540f2b1bcea278a4fbe373daac7103b"
-SRC_URI = "git://github.com/cisco/libest"
+SRC_URI = "git://github.com/cisco/libest;branch=main"

DEPENDS = "openssl"

--
2.20.1

4781 - 4800 of 57813