#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
can you post detailed log
toggle quoted messageShow quoted text
On 4/8/21 12:56 AM, sateesh m wrote:
Hi Guys,
|
|
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
On Wed, Apr 7, 2021 at 10:16 AM Nicolas Dechesne <nicolas.dechesne@...> wrote:
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 and the following link 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.
|
|
Re: No significant diff b/w qemux86 and qemuarm poky build of core-image-minimal
On Tue, Mar 30, 2021 at 2:20 PM Khem Raj <raj.khem@...> wrote:
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@...
|
|
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...
toggle quoted messageShow quoted text
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:
|
|
[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
|
|
dpkg-scanpackages from my recipe
Mauro Ziliani
Hi all. I'd like to use dpkg-scanpackages inside my recipe The recipe copies some deb package into my folder ${D}/myfolder Then I'd like to apply dpkg-scanpackages to ${D}/myfolder I miss last step. Running dpkg-scanpackages ${D}/myfolder ends with and error. Dpkg.pm missing How can I "install" Dpkg.pm so I can use dpkg-scanpackages directly from my recipe? Best regards, MZ
|
|