Date   

[meta-rockchip][PATCH] rock-pi-e: add

Trevor Woerner
 

Add support for Radxa's ROCK Pi E device
https://wiki.radxa.com/RockpiE

It's a great surprise to find upstream U-Boot and the Linux kernel already
provide support for this board! On the kernel side this support was
added in 5.11. However, that support is so new that even linux-yocto-dev
(which is based on 5.11) doesn't include the commits that add support
for this board yet. As a result I've added a custom Linux kernel recipe
(linux-stable-bleeding) which should, in time, become unnecessary.

Signed-off-by: Trevor Woerner <twoerner@gmail.com>
---
conf/machine/rock-pi-e.conf | 42 +++++++++++++++++++
.../trusted-firmware-a_%.bbappend | 2 +-
recipes-bsp/u-boot/u-boot%.bbappend | 2 +
.../linux/linux-stable-bleeding_5.11.bb | 18 ++++++++
recipes-kernel/linux/linux-yocto-dev.bbappend | 2 +-
wic/rk3328-boot.wks | 23 ++++++++++
wic/rock-pi-e.wks | 4 ++
7 files changed, 91 insertions(+), 2 deletions(-)
create mode 100644 conf/machine/rock-pi-e.conf
create mode 100644 recipes-kernel/linux/linux-stable-bleeding_5.11.bb
create mode 100644 wic/rk3328-boot.wks
create mode 100644 wic/rock-pi-e.wks

diff --git a/conf/machine/rock-pi-e.conf b/conf/machine/rock-pi-e.conf
new file mode 100644
index 0000000..035a950
--- /dev/null
+++ b/conf/machine/rock-pi-e.conf
@@ -0,0 +1,42 @@
+#@TYPE: Machine
+#@NAME: ROCK Pi E rk3328
+#@DESCRIPTION: ROCK Pi E is a Rockchip RK3328-based SBC by Radxa. E is for Ethernets.
+#https://wiki.radxa.com/RockpiE
+
+MACHINEOVERRIDES =. "rock-pi-e:"
+SOC_FAMILY = "rk3328"
+DEFAULTTUNE = "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+PREFERRED_PROVIDER_virtual/kernel = "linux-stable-bleeding"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock-pi-e.dtb"
+KBUILD_DEFCONFIG = "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_MACHINE = "rock-pi-e-rk3328_defconfig"
+UBOOT_SUFFIX = "itb"
+UBOOT_ENTRYPOINT = "0x06000000"
+PREFERRED_PROVIDER_virtual/bootloader = "u-boot"
+SPL_BINARY = "idbloader.img"
+
+WKS_FILE = "rock-pi-e.wks"
+IMAGE_FSTYPES += "wic.xz wic.bmap"
+WKS_FILE_DEPENDS = " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= " \
+ ${KERNEL_IMAGETYPE} \
+ "
+
+SERIAL_CONSOLES = "1500000;ttyS2"
diff --git a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
index 2374205..442dee8 100644
--- a/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
+++ b/recipes-bsp/trusted-firmware-a/trusted-firmware-a_%.bbappend
@@ -3,4 +3,4 @@
DEPENDS_append_rk3399 = " virtual/arm-none-eabi-gcc-native"

COMPATIBLE_MACHINE_append_rk3399 = "|rk3399"
-
+COMPATIBLE_MACHINE_append_rk3328 = "|rk3328"
diff --git a/recipes-bsp/u-boot/u-boot%.bbappend b/recipes-bsp/u-boot/u-boot%.bbappend
index 042507d..95c019d 100644
--- a/recipes-bsp/u-boot/u-boot%.bbappend
+++ b/recipes-bsp/u-boot/u-boot%.bbappend
@@ -9,6 +9,8 @@ ATF_DEPENDS ??= ""

EXTRA_OEMAKE_append_rk3399 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3399.elf"
ATF_DEPENDS_rk3399 = " virtual/trusted-firmware-a:do_deploy"
+EXTRA_OEMAKE_append_rk3328 = " BL31=${DEPLOY_DIR_IMAGE}/bl31-rk3328.elf"
+ATF_DEPENDS_rk3328 = " virtual/trusted-firmware-a:do_deploy"

do_compile[depends] .= "${ATF_DEPENDS}"

diff --git a/recipes-kernel/linux/linux-stable-bleeding_5.11.bb b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
new file mode 100644
index 0000000..dce537d
--- /dev/null
+++ b/recipes-kernel/linux/linux-stable-bleeding_5.11.bb
@@ -0,0 +1,18 @@
+# the rock-pi-e is very new
+# it's exciting that support has already been added upstream
+# but it's so new that even linux-yocto-dev doesn't have it yet
+#
+# in time we should see the need for this recipe going away
+
+inherit kernel
+require recipes-kernel/linux/linux-yocto.inc
+
+LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
+
+SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git"
+SRCREV = "c03c21ba6f4e95e406a1a7b4c34ef334b977c194"
+LINUX_VERSION = "5.11"
+LINUX_VERSION_EXTENSION = ""
+PV = "${LINUX_VERSION}"
+
+COMPATIBLE_MACHINE = "(rock-pi-e)"
diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kernel/linux/linux-yocto-dev.bbappend
index 2f498d9..a85b85e 100644
--- a/recipes-kernel/linux/linux-yocto-dev.bbappend
+++ b/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -1 +1 @@
-COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288|rock-pi-e"
diff --git a/wic/rk3328-boot.wks b/wic/rk3328-boot.wks
new file mode 100644
index 0000000..194145b
--- /dev/null
+++ b/wic/rk3328-boot.wks
@@ -0,0 +1,23 @@
+# Copyright (C) 2021 Trevor Woerner
+# Released under the MIT license (see COPYING.MIT for the terms)
+#
+# Disk layout
+# Note that the reference documentation refers to 512 byte disk sectors, but
+# wic uses 1KB blocks
+#
+# Partition Start Sector Number of Sectors
+# loader1 64 8000
+# reserved1 8064 128
+# reserved2 8192 8192
+# loader2 16384 8192
+# atf 24576 8192
+# boot 32768 229376
+# root 262144 - (suggested)
+#
+
+part loader1 --offset 32 --fixed-size 4000K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=idbloader.img"
+part reserved1 --offset 4032 --fixed-size 64K --ondisk ${RK_BOOT_DEVICE}
+part reserved2 --offset 4096 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
+part loader2 --offset 8192 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE} --source rawcopy --sourceparams="file=u-boot.itb"
+part atf --offset 12288 --fixed-size 4096K --ondisk ${RK_BOOT_DEVICE}
+part /boot --offset 16384 --size 114688K --active --ondisk ${RK_BOOT_DEVICE} --source bootimg-partition --fstype=vfat --label boot --sourceparams="loader=u-boot"
diff --git a/wic/rock-pi-e.wks b/wic/rock-pi-e.wks
new file mode 100644
index 0000000..97f84d1
--- /dev/null
+++ b/wic/rock-pi-e.wks
@@ -0,0 +1,4 @@
+include rk3328-boot.wks
+part / --ondisk ${RK_BOOT_DEVICE} --source rootfs --fstype=ext4 --label root
+
+bootloader --ptable gpt --append="console=tty1 console=ttyS2,1500000n8 rw root=/dev/${RK_BOOT_DEVICE}p7 rootfstype=ext4 init=/sbin/init"
--
2.30.0.rc0


Re: [External] Re: [yocto] Yocto- Apache2 build guide

Randy MacLeod
 

On 2021-02-24 10:37 p.m., D, Sharmila wrote:
Hi MacLeod,
Thanks for your e-mail.
Yes, without apach2 I am able to build the core-image-minimal successfully. The issue is only when I add apache2 in IMAGE_INSTALL.
I am using TI processor SDK and I have setup the arago based yocto environment based on TI user guide.
version is THUD.
Do you need any further details about the setup?
Please provide me the steps to include apache2 package into my final image.
Looking forward to hearing from you at your earliest convenience.
Hello Sharmila,

If you can reproduce the problem with only the oe-core/poly + meta-openembedded layers then perhaps someone on this list can help you.
Otherwise, you should contact the people who provided the
TI processor SDK.

By the way, Thud is EOL in the YP community:
https://wiki.yoctoproject.org/wiki/Releases
but commercial vendors do have longer support cycles
so hopefully TI can help you out.

../Randy
With Best Regards,
Sharmila D
-----Original Message-----
From: Randy MacLeod <randy.macleod@windriver.com>
Sent: Thursday, February 25, 2021 12:08 AM
To: D, Sharmila <Sharmila.D@Honeywell.com>; yocto@lists.yoctoproject.org
Subject: [External] Re: [yocto] Yocto- Apache2 build guide
On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
Hi,

I am trying to enable httpd package into my yocto build, steps I
followed is as below

1. Added below layer in bblayer.conf file

sources/meta-openembedded/meta-webserver

2. Added below line in local.conf file

IMAGE_INSTALL_append = "apache2"

The yocto build using bitbake core-image-minimal gives below error

WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst
returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of
['busybox'] have failed. If the intention is to defer them to first
boot, then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in
/home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl
138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs
.2937
ERROR: Task
(/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-co
re/images/core-image-minimal.bb:do_rootfs)
failed with exit code '1'

Please provide the solution for the same
Hi Sharmila,
This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?
Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases
../Randy


With Best Regards,

Sharmila D



--
# Randy MacLeod
# Wind River Linux

--
# Randy MacLeod
# Wind River Linux


Yocto Technical Team Minutes/Engineering Sync for Feb 23, 2021

Trevor Woerner
 

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

== 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, Scott Murray, Armin Kuster, Michael
Halstead, Steve Sakoman, Richard Purdie, Randy MacLeod, Saul Wold, Jon
Mason, Joshua Watt, Paul Barker, Tim Orling, Mark Morton, John Kaldas,
Alejandro H, Ross Burton

== notes ==
- 3.2.2 passed QA clean, awaiting final approval from TSC
- 3.1.6 built and in QA
- 1 week before -m3 should be built (feature freeze for 3.3)
- adding RPM to reproducibility, still needs some work
- recipe maintainers: please review the patches we’re carrying (push
upstream as many as possible)
- glibc 2.33 issue should be resolved with latest pseudo
- AUH patches are now merged or queued, few of the failures handled
- AB issue list is at record high (not good)

== general ==
RP: can’t get stable test results out of AB on master


RP: would be nice to get RPM reproducibility issues ironed out, but there are
some epoch issues to work through which messes up diffoscope
RP: was surprised to see how bad the interactive response is on the cmdline on
the builders. it seems like an I/O bottleneck
Randy: mostly I/O to SSDs?
RP: i believe so
RP: it was immediately after a build had been started. so it could be related
to downloads or sstate fetching. how much sstate did you expect that build
to be reusing?
SteveS: version bumps to conman, kernel… yea that could lead to a lot of
rebuilds
Michael: we’ve been optimizing for throughput for a while. on some other
build systems we leave some overhead available for cmdline interactivity.
should we start to do that with the YP AB?
RP: i think it would have to be backed off by a significant amount to get that
breathing space. so maybe yes, but we’d have to look at it to see what
to backoff and by how much. looking through the build i see that 77% was
pulled from sstate (therefore pulling data off the NAS, then extracting
it).
Randy: and that’s not coordinated at all, if there are 100 items, then 100
threads?
RP: but limited by BB_THREADS
JPEW: run by buildbot? maybe we could use cgroups?
RP: i don’t think it’s CPU bound, the CPU was 50% idle when the cmdline
was very slow
MichaelH: sometimes we see that when the system isn’t healthy, i wonder if
it’s isolated to specific machines?
RP: on the CentOS machine, a command took over 5 minutes to complete. then
tried debian, same thing. then logged into the fedora machine and was
able to do stuff. but it didn’t seem isolated to any machines, it
seemed localized in time (i.e. right after a build had been started),
then dropped off. so i feel that it might be related to the initial build
startup, probably related to sstate pulling/extraction
Randy: could also limit I/O using cgroups
RP: we do use IOnice for parts of the build (2.1 and 2.7)
Michael: translation: class 2 priority 1; class 2 priority 7
Alejandro: are these sharing any hardware
RP: they’re all connected to the NAS
Michael: and they’re 100% dedicated to this work
RP: i don’t think this is a network bottleneck, i think this is sstate extraction
JPEW: maybe a different compression algorithm? gzip is notoriously slow
RP: wouldn’t that make it worse?
JPEW: does each AB have their own mirror
RP: it’s all done over NFS
JPEW: network bandwidth should be lower than local unzipping/extraction bandwidth?
Alejandro: could we try different I/O scheduling?
RP: don’t know

RP: had a look at patches. 1,300 patches in oe-core, ~600 in pending the rest
are submitted or not appropriate. some of these are 10 years or older,
do we still need them? i sent 2 upstream and was told it wasn’t needed
anymore (problem fixed in other ways). there’s also one in valgrind that
looks similar (different fix upstream) and not needed.
Ross: if some people could try to do 1 a day that would be a huge help
RP: lots of patches related to reproducibility
JPEW: the big issue with perf is that it uses bison (which needs patches)

PaulB: read-only mode for PR server. i’ve been working on it, but it’s 1
big patch. there’s code to handle daemonizing and forking which in hash
server is using the python mutli-processing. we also want to use the
same RPC mechanisms that python is using. are those good lines along which
to break the patches down?
RP: that sounds perfect
PaulB: it was easier to bash on it all together, then go back and break it up
into digestible chunks
RP: it’s 10 year old code, so i’m not surprised
PaulB: i’ve broken out a part that uses JSON RPC, then use that for the
server
RP: sounds good to me
JPEW: me too
RP: scaling that code under python2 was a challenge. glad to see this moving
forward

RP: Randy posted rust patch set. felt it couldn’t be merged in this form
(too many patches)
Randy: do you want the history squashed?
RP: that was my feeling
Randy: i’ve been working on it bit by bit as stuff happens upstream which
leads to lots of little commits. but i can reorg by logical group and
squash the log
RP: yes. in one case there were lots of commits to the rust version, then in
the end you end up with 2
Randy: someone from MS worked on getting the sdk stuff working
RP: given that next Monday is the feature freeze, let’s get the patched out
sooner, and worry about the sdk later
Randy: ok. last remaining issue is the pre-fetcher but i don’t know much
about it. looked at PaulB’s patches
PaulB: there are 3 methods floating around, i’ve focused on one of them that
i like
1. doing the download ahead of time in do_fetch()
2. let rust-bin do the downloads itself in do_compile() which i don’t like
3. haven’t looked at the last one yet
PaulB: i like 1 because it asks rust to output a cargo which the fetcher can
then act on
Randy: doesn’t rely on crates?
PaulB: i think it relies on crates for things that it can’t resolve. however
Andreas’ approach relies on getting bitbake to understand cargo-toml
file, not sure if that’s a good approach
Randy: are there any lessons with Go that we can use?
Scott: Bruce would be a good one to talk to
PaulB: my understanding with Go is that the code tends to all be placed
together in the git repository, so the fetch side is a little simpler
Randy: so given the approach we’re using is there anything that needs to be
added
PaulB: it needs testing
Randy: i have a team working on testing the rust compiler itself. they can
successfully execute 2/3 of the tests now (of which 99.9% pass). i have
a reproducibility test for rust hello world, but it takes a long time to
run. any tests you’re thinking of?
PaulB: fetcher tests. if you have a “crate://” in a URL, just making sure
it gets translated correctly to make sure it doesn’t bitrot
Randy: is that an -m3 or -m4 activity
RP: if we’ll get it in -m4 for sure we can wait until then. in oe-core
we’d want some sort of hello world (make sure compiler works and we can
run the binaries)
Randy: we have that already
RP: both for cross-compiling and target. then reproducibility tests. i’m
happy to build them up, as long as there’s a roadmap. for -m3 i think we
should get the baseline rust set and the crate fetcher
PaulB: crate fetcher overrides the wget fetcher and makes sure everything gets
put in the right place. so it just needs a couple test cases; a map of
inputs to outputs. i’ll resubmit the patch and include a list of tests
that we need to add
RP: if someone could reply to Andreas and let him know what’s going on and
why we’re going in a slightly different direction than the work he’s
submitted
PaulB: the fundamental unit is the recipe. devtool is the place for some of
the functionality not bitbake
Randy: building rust hello world works for all glibc qemu targets but some
breakage with musl (risc-v and powerpc) i think Khem is working on the
risc-v one. will that hold things up?
RP: no
PaulB: i have some slightly larger rust packages (larger than hello world)
that i think will test things a little more thoroughly, e.g. ripgrep
Randy: we’re testing that one already. should we add it to oe-core?
RP: it would be good to have something in oe-core to do testing
Randy: i think hello world would be good enough for oe-core and leave larger
tests for other layers
PaulB: there are rust things in oe-core (librsvg, etc) so i think oe-core will
have good test things already in them without having to add recipes just
for testing’s sake
Randy: things also seem to work well on ARM builders
Ross: yes, things are on-target

TrevorW: started work on 2021 YP conference. conversation moved to
conferences@lists.yoctoproject.org if you want to follow along or help

RP: fetch, workdir, can’t clean up workdir, config changes but can’t
cleanup. maybe we should fetch to a special dir and then just symlink
PaulB: would it be recipe-specific
RP: yes, it would be under $WORKDIR
PaulB: would make the archiver easier
TimO: there are a number of Go modules that don’t cleanup properly so maybe
this would help
ScottM: there are lots recipes that do post-processing on files in $WORKDIR
before moving them to the artifacts directory, so there could be breakage
there
PaulB: can we do it first thing next release
RP: we’ll give it a try and see
TrevorW: i think a lot of BSP layers will be affected
RP: i think there’s a lot of chance a lot of things (not just BSPs) will be
affected
ScottM: there are some BSP things that will be affected, but in AGL we’re
doing a lot of $WORKDIR manipulations that aren’t necessarily BSP
related as well
(several): overall it sounds like a good idea and a good cleanup to try


Re: BB_HASHBASE_WHITELIST

Monsees, Steven C (US)
 

Thanks, will try it out...

-----Original Message-----
From: Quentin Schulz <quentin.schulz@streamunlimited.com>
Sent: Thursday, February 25, 2021 8:42 AM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] BB_HASHBASE_WHITELIST

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.


On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST " ?

I tried to do : BB_HASHBASE_WHITELIST += "BB_TRACE" in my local.conf but it ended up replacing existing list with just "BB_TRACE"...
In local.conf, one usually wants to use _append instead of += since local.conf is parsed pretty early, += will override current values set with ?= or ??=. It might also be overridden if = is used in recipes/conf files.

Cheers,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


Re: BB_HASHBASE_WHITELIST

Quentin Schulz
 

On Thu, Feb 25, 2021 at 01:37:18PM +0000, Monsees, Steven C (US) via lists.yoctoproject.org wrote:

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST " ?

I tried to do : BB_HASHBASE_WHITELIST += "BB_TRACE" in my local.conf but it ended up replacing existing list with just "BB_TRACE"...
In local.conf, one usually wants to use _append instead of += since
local.conf is parsed pretty early, += will override current values set
with ?= or ??=. It might also be overridden if = is used in recipes/conf
files.

Cheers,
Quentin
--
StreamUnlimited Engineering GmbH
High Tech Campus Vienna, Gutheil-Schoder-Gasse 10, 1100 Vienna, Austria
Fax: +43 1 667 20 02 4401
quentin.schulz@streamunlimited.com, www.streamunlimited.com


BB_HASHBASE_WHITELIST

Monsees, Steven C (US)
 

 

Where and when is it appropriate to add to/modify BB_HASHBASE_WHITELIST “ ?

 

I tried to do : BB_HASHBASE_WHITELIST += “BB_TRACE” in my local.conf but it ended up replacing existing list with just “BB_TRACE”…

 

 

basewhitelist changed from '{'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'LICENSE_PATH', 'BB_WORKERCONTEXT', 'BB_HASHSERVE', 'BB_UNIHASH', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'SDKPKGSUFFIX', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'PRSERV_HOST', 'CCACHE_DIR', 'PRSERV_LOCKDOWN', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'PATH', 'SSTATE_DIR', 'PKGDATA_DIR'}' to '{'BB_TRACE'}'

changed items: {'TERM', 'FILESPATH', 'CCACHE', 'COREBASE', 'BBPATH', 'STAMPS_DIR', 'EXTERNAL_TOOLCHAIN', 'LOGNAME', 'FILESEXTRAPATHS', 'CCACHE_NOHASHDIR', 'BB_WORKERCONTEXT', 'LICENSE_PATH', 'BB_UNIHASH', 'BB_HASHSERVE', 'HOME', 'DL_DIR', 'SSTATE_HASHEQUIV_OWNER', 'PRSERV_DUMPDIR', 'PATH', 'WORKDIR', 'SSTATE_PKGARCH', 'SSTATE_HASHEQUIV_METHOD', 'SSTATE_DIR', 'PRSERV_HOST', 'CCACHE_DIR', 'STAGING_DIR_TARGET', 'STAGING_DIR_HOST', 'PWD', 'USER', 'STAMPCLEAN', 'BUILD_ARCH', 'BBSERVER', 'BB_LIMITEDDEPS', 'SSTATE_HASHEQUIV_REPORT_TASKDATA', 'TMPDIR', 'SHELL', 'THISDIR', 'DEPLOY_DIR', 'BB_TRACE', 'PRSERV_DUMPFILE', 'ERROR_QA', 'WARN_QA', 'FILE_DIRNAME', 'extend_recipe_sysroot', 'CCACHE_TOP_DIR', 'PARALLEL_MAKE', 'FILE', 'BB_TASKHASH', 'SDKPKGSUFFIX', 'PRSERV_LOCKDOWN', 'PKGDATA_DIR'}

 

Thanks,

Steve


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

Sangeeta Jain
 

Hi all,

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

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

no new issue found

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@lists.yoctoproject.org <qa-build-
notification@lists.yoctoproject.org> On Behalf Of Pokybuild User
Sent: Tuesday, 23 February, 2021 6:48 AM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.1.6.rc1)


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


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


Build hash information:

bitbake: fa94374baea75a94e3a488126ca7d8e241a77acd
meta-arm: 02c660521619ddb7a9495d65403aaa2636747ce8
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 4bd62a7e154b8c9e8a114f452d3b062d8d058118
meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
oecore: a8debddd6cbdd70db74e096d72f97fbee008ee63
poky: a13bda44fcda4e79e9aed39ca1495eabecb6a7b7



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







Re: Yocto- Apache2 build guide

Randy MacLeod
 

On 2021-02-24 5:04 a.m., D, Sharmila via lists.yoctoproject.org wrote:
Hi,
I am trying to enable httpd package into my yocto build, steps I followed is as below
1. Added below layer in bblayer.conf file
sources/meta-openembedded/meta-webserver
2. Added below line in local.conf file
IMAGE_INSTALL_append = "apache2"
The yocto build using bitbake core-image-minimal gives below error
WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.2937
ERROR: Task (/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'
Please provide the solution for the same
Hi Sharmila,

This doesn't appear to be related to adding apache.
Are you able to build core-image-minimal without adding apache2?

Can you provide detailed steps wrt what layers and HEAD commits for each layer you are using? Ideally, you'd reproduce on a supported release or
on master. That's Dunfell/3.1 or later:
https://wiki.yoctoproject.org/wiki/Releases

../Randy

With Best Regards,
Sharmila D

--
# Randy MacLeod
# Wind River Linux


Re: [meta-security] [PATCH V2 0/8] Some fixes for IMA/EVM

Armin Kuster
 

merged

On 2/20/21 4:18 AM, liu.ming50@gmail.com wrote:
From: Ming Liu <liu.ming50@gmail.com>

Changes in patch set V2:

1 Split patches as suggested by Dmitry Baryshkov.

Ming Liu (8):
ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
initramfs-framework-ima: fix a wrong path
ima-evm-keys: add recipe
initramfs-framework-ima: RDEPENDS on ima-evm-keys
meta: refactor IMA/EVM sign rootfs
README.md: update according to the refactoring in
ima-evm-rootfs.bbclass
initramfs-framework-ima: let ima_enabled return 0
ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic

meta-integrity/README.md | 4 ++-
meta-integrity/classes/ima-evm-rootfs.bbclass | 33 +++++++++----------
.../initrdscripts/initramfs-framework-ima.bb | 2 +-
.../initrdscripts/initramfs-framework-ima/ima | 3 +-
.../ima-evm-keys/ima-evm-keys_1.0.bb | 16 +++++++++
.../ima-evm-utils/ima-evm-utils_git.bb | 1 +
6 files changed, 38 insertions(+), 21 deletions(-)
create mode 100644 meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb


Multi-planar API support in g_webcam

Sheraz Ali
 

Hi All,

I wanted to know whether g_webcam supports multi-planar API.

--
Thanks and Regards
Sheraz Ali Shah


Re: #yocto #sdk #yocto #sdk

Monsees, Steven C (US)
 

Thanks again, these utilities make it much easier to understand and correct the issues...

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Tuesday, February 23, 2021 3:42 PM
To: Khem Raj <raj.khem@gmail.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk

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.



Thanks, will go through it...

-----Original Message-----
From: Khem Raj <raj.khem@gmail.com>
Sent: Tuesday, February 23, 2021 2:30 PM
To: Monsees, Steven C (US) <steven.monsees@baesystems.com>
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] #yocto #sdk

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.


https://wiki.yoctoproject.org/wiki/TipsAndTricks/Understanding_what_changed_(diffsigs_etc)

On Tue, Feb 23, 2021 at 10:03 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@lists.yoctoproject.org> wrote:



I am trying to understand the warnings/error as seen below…



Building for zeus…



Built kernel image clean updated my SSTATE_MIRRORS directory with the state_cache generated.

Rebuilt my image clean again using SSTATE_MIRRORS

Image builds clean and behaves correctly when booted…



I then build the SDK, my SSTATE_MIRRORS is defined in sdk-extra.conf,
and does properly show up in local.conf (checked after failure)

Building extended SDK has no issues.



But on install I see the following warnings and the error at the end…

I am not sure what is causing the issue here…



What would cause issues like this ?, and why ?



WARNING: The initscripts:do_install sig is computed to be
375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but
the sig is locked to
40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in
SIGGEN_LOCKEDSIGS_t-corei7-64



There isn’t much in the documentation on this or SIGGEN…

What would be the best/proper approach to resolve issues like this ?



Thanks,

Steve



10:44 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> bitbake
sbcb-defaultfs-full -c populate_sdk_ext

Loading cache: 100%
|#####################################################################
#################| Time: 0:00:00

Loaded 3645 entries from dependency cache.

NOTE: Resolving any missing task queue dependencies



Build Configuration:

BB_VERSION = "1.44.0"

BUILD_SYS = "x86_64-linux"

NATIVELSBSTRING = "rhel-7.9"

TARGET_SYS = "x86_64-poky-linux"

MACHINE = "sbcb-default"

DISTRO = "limws"

DISTRO_VERSION = "3.0.4"

TUNE_FEATURES = "m64 corei7"

TARGET_FPU = ""

meta

meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"

meta-perl

meta-python

meta-filesystems

meta-networking

meta-initramfs

meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"

meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"

meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"

meta-intel = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"



Initialising tasks: 100%
|#####################################################################
############| Time: 0:00:04

Checking sstate mirror object availability: 100%
|#########################################################| Time:
0:00:00

Sstate summary: Wanted 566 Found 298 Missed 268 Current 1794 (52%
match, 88% complete)

NOTE: Executing Tasks

NOTE: Setscene tasks completed

NOTE: Tasks Summary: Attempted 6669 tasks of which 5861 didn't need to be rerun and all succeeded.

11:59 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default> cd
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/depl
oy/sdk

11:59 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/depl
oy/sdk>ls

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.host.mani
fest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.sh

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.target.ma
nifest

limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.testdata.
json

x86_64-buildtools-nativesdk-standalone-3.0.4.host.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.sh

x86_64-buildtools-nativesdk-standalone-3.0.4.target.manifest

x86_64-buildtools-nativesdk-standalone-3.0.4.testdata.json

11:59 smonsees@yix490016
/disk0/scratch/smonsees/yocto/workspace_3/builds/sbcb-default/tmp/depl
oy/sdk>./limws-glibc-x86_64-aiox_orange-corei7-64-toolchain-ext-3.0.4.
sh

LIMWS (BAE LIMWS base distro) Extensible SDK installer version 3.0.4

====================================================================

Enter target directory for SDK (default: ~/limws_sdk):
/disk0/scratch/smonsees/testSDK

You are about to install the SDK to "/disk0/scratch/smonsees/testSDK".
Proceed [Y/n]? Y

Extracting
SDK...................................................................
...........done

Setting it up...

Extracting buildtools...

Preparing build system...

Parsing recipes: 100%
|#####################################################################
###############| Time: 0:01:32

Initialising tasks: 100%
|#####################################################################
############| Time: 0:00:04

Checking sstate mirror object availability: 100%
|#########################################################| Time:
0:00:03

WARNING: The initscripts:do_install sig is computed to be
375d3c24b574b83fb04dc079fb52dd5e3a0ac31ed265acece2bb689f72f9adfa, but
the sig is locked to
40f5d2ac4affab9c60691714590ca00f30130ad2f5dc79f53aaf774957e1d927 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The linux-intel:do_compile sig is computed to be
9898137f78ba37d2fcf7df5a7b7a5dd0e5ddcbc7ce7ade89905bf5132a005a99, but
the sig is locked to
06c08387009f9808044e03144d1fa0b984be9f4ad64251e688503c2dabdf5b7c in
SIGGEN_LOCKEDSIGS_t-corei7-64-intel-common

The imagerecv:do_compile sig is computed to be
644b002b181f27a407c33cc69cfc790201f1b48c4d7783c062d53c247d5704a5, but
the sig is locked to
a74b10cfc4bad050ca98549b3df41fcd0fa986e08c14e05db44b0227d0b90a0a in
SIGGEN_LOCKEDSIGS_t-sbcb-default

The tpm2-tss:do_configure sig is computed to be
04cf4c8e1424a46467a43620214fc3a5304863f5cbb662b5b26a5b82d792586f, but
the sig is locked to
ec4b02e1e3b1796883093be2aca63ec5e51df3dc14b9179be6f86f2675b3fa53 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The efitools:do_compile sig is computed to be
c2e6dc60a7b8b2414b3761fe4966e031901144e3d32eed60bd580cc46e9b5358, but
the sig is locked to
327fbae2aa4a419554ede6847fcc7c367da018e5e9d907a0051e68df5a5a2063 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_configure sig is computed to be
8a5cfb349fa84ca524bf680a922d0e1781f5dc9e0b5e0f6e0b135ea88e3f8fa1, but
the sig is locked to
8d2bf2edd3194e44de0143088e68703c02a88032bb089ef0a4600f7528695362 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_compile sig is computed to be
819f7700a7f611335b8a5e4f8243623c4f01b187f197aa19cd034383af17b41b, but
the sig is locked to
822db696400b5a788fbcc0e80f1fe242bd58cab992ff196efac191444d7b3b99 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_install sig is computed to be
f2f8cb58b07a350eefd41af13e1156abd85659b1865dc278238277d9230e2e3f, but
the sig is locked to
9e1ca795df7d73347f0efeeac54c24f1004d59011b97262207e1055f771ee95c in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_populate_sysroot sig is computed to be
ca8fe144be00929f3c42cb36b809a06b85d70c4f9fa1c0f6fd67b07af84d17a1, but
the sig is locked to
2a41afd838cdac669dd99deefdc530c5d503329fb1fae2fb3641b490a2bbec8a in
SIGGEN_LOCKEDSIGS_t-corei7-64

The monkeysphere:do_package sig is computed to be
29a5daea524a219c5216b5d76447160d006e7db633e38c7d1ade6b599eb6c2ab, but
the sig is locked to
2b2cef367c44399221b07f14facff9b1ae598ccc272c4b98ddfc4b08009fc090 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_configure sig is computed to be
613844241ce15b245abe2fb9306415616c72553e943183307b3496f85637345e, but
the sig is locked to
68a818acd3281e28bd57efcd449a0bac0ffaa2733fcb02f6b28b2fe31d36e835 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_compile sig is computed to be
8b37e4a0e6ec0068b7dda0eccd1e32577daedf248f1c3e71f82f6454d3e4338d, but
the sig is locked to
6f291a0f9ba59f355d9a88d646f72bf99a001f862b310e5e435e8b406632b6b4 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_install sig is computed to be
3a20f56cc04551f13378e9e596daa5eebc385ca965ebdf18adacfa7ef94c9018, but
the sig is locked to
8fc761f8bf0215ea2fb9609037a5df0c7e2ad6dd9253555ea5f492b7068e7bff in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_populate_sysroot sig is computed to be
97d2f34ef4b40fe8e324c04346ad0cdf22cde6cc774f336400797cb6a483d08c, but
the sig is locked to
93700035bc1a42b4f7e5f05ef30d4bc6fdf2abc0dd1f707b2e745ceed25d5770 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The signature:do_package sig is computed to be
f59f3584026d4acf71d4300a18ff4bf05c0f3e3b42c2d5264af9be63820a0386, but
the sig is locked to
bdc6003bbd7a42a83e9a6a7ebe691e93a9744ae96c664d8656907a15af84be1c in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_clean_grub sig is computed to be
17c62b3df5a57ee4cbd0e7abf1284a5d499ba4c814aaded564a24085b9fd326c, but
the sig is locked to
c8835ffb27e0d97b332dddad3fb83bdb849a267a8a0fa7142e66a76696c910ff in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_configure sig is computed to be
a6dfb6cd633432b36b818b63fd6e06e086d189b62cd7fc6370c4e66e9668fa1d, but
the sig is locked to
194602954bb4993b85397aeb06557d10ff14b15d52a321389cdbb0139d2ce34c in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_compile sig is computed to be
583800a58ca2e602d50b4e23485774e8b681f79bf48a1a854b71264a0ddcb733, but
the sig is locked to
e642b6c931bda1d51bc5394596cdacce7099875d1e873b39849607e03972c5b9 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_mkimage sig is computed to be
87a6528cb8624851708b1f4d3fa26beb96f71f1a3cb0c4d48fe0aaf9255fb244, but
the sig is locked to
bc04f79c9988122be8297c3ea2e7aa13fbe18444b1151a547332112616e11480 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_install sig is computed to be
6e8a988562949ae845beb0150acf7702a360094db56096b6e2bbb65820bbb3f0, but
the sig is locked to
38427ff1c0bfa569a27a6c5acf51bb3483d882b18a1fa0bfbfaa371822df7837 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi-native:do_populate_sysroot sig is computed to be
3ba3744800732b69e71d33ea0db797a78bb2340727fc54f211bd0f7c1325374c, but
the sig is locked to
fcd9daa126de91d4d1de701ed1ff1c2774c3e42207e1fff85b86109eb54b290c in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_clean_grub sig is computed to be
928fbd9c1d534333f18a6f751ad705c03f083ff00374a781b02e1aee47b92bee, but
the sig is locked to
67a039367c0593803d8c70207f079fd8be28dbc6c548b13837fa7eb177b156e0 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi-native:do_deploy sig is computed to be
4875f4b51c38f31140775a2a4457839eabef2529791cccbb9ed656eef63892fc, but
the sig is locked to
6576c95aa5c0c7b505ca2cc02fdde3f678f2b039c2f0b57810b17694b6070a46 in
SIGGEN_LOCKEDSIGS_t-x86-64

The grub-efi:do_configure sig is computed to be
84ab069273c4b2703ca4fa200d5fb66adcaffa39b8f36138339d4837b9281a9d, but
the sig is locked to
e8900241347d4616468e7a4a4c37b8496a1167c2b3d58f7bb55332da645bd7e0 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_compile sig is computed to be
619bdca4f1a6df8c8c2c7ad49b7289af3477e3c76c00b84229584793f23fb115, but
the sig is locked to
56ca563b3bcb66b72f53f51562f41dd0cf9af878335836e8fd6b6a07e32fa8bc in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_mkimage sig is computed to be
f212bd74eb95f4d413c9867f853171747fe4fe86912138a0ac79234fe4be73b7, but
the sig is locked to
80e9256f12e3070737c81f76310cc408473b92b877b23494cd1b4c2abdffd56d in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_install sig is computed to be
45753f50a553391bd80cf679039cccf879ef1eaca90e1dcfefb432621dfc0000, but
the sig is locked to
3910d27330229314b793a94c7085c231a56c1073d7e79d4cceade5a373600252 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_populate_sysroot sig is computed to be
3437833e837748a59e002f95773a8f61a715bb56c0f20671fa39a71556ad6d5d, but
the sig is locked to
d0d60bc1d9bf488c7568e592b3b1aeeb2e2796c9994f83fe1b781e0d006e432b in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_package sig is computed to be
81fa6cf23920cea4139ed3cefd6c94a3878580f6a45925279c7d75e3c487f162, but
the sig is locked to
d7ec82448f34ec8c0169f613fdd14237cebb1951efa3d35d53dc71d24f220cb8 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The grub-efi:do_deploy sig is computed to be
f7831a1a7e1d8683e1c0c86fd32486ec8d9e5e713d63e39984aa36f50bff7f91, but
the sig is locked to
1c781659fad7fb174716d05aa5727f68e710ad7c6593dc178f40866d6e868f19 in
SIGGEN_LOCKEDSIGS_t-corei7-64

The tpm2-tools:do_configure sig is computed to be
10fa6cf0c4fa307a427978392ecf60d7a8853e11ca1747ea5ad8743fd42280f3, but
the sig is locked to
5e6a2caa27901f95518467ca35b68043fee7802dfa8be39ae51e61c9eedf9a8d in
SIGGEN_LOCKEDSIGS_t-corei7-64

The wolfssl:do_configure sig is computed to be
5569ddf9b10e2df9f5de456ca35b9baeb34a1f67617357d5e1a9264baf3d1e0e, but
the sig is locked to
eaf1b380210718071d8962eeccbd97efad180fabc750b18f4e98661de06ae11f in
SIGGEN_LOCKEDSIGS_t-corei7-64

The crush:do_configure sig is computed to be
f034116fd9598a09aa975e94dd48964e0d49deecf63d96c436bd4cccc7b68298, but
the sig is locked to
64dfc5ff4a9ee29e9a20f1166ec2ee6fe20ffcd93e7618eabd02435c29f219ed in
SIGGEN_LOCKEDSIGS_t-corei7-64

ERROR: Task quilt-native.do_fetch attempted to execute unexpectedly














Re: Dunfell, nodejs and typescript - short experience report

TRO
 

Hi Simon,
I'm dealing actually with the same problem. Would you like to share your  "configure in my own subclass"?

I'm also thinking there is a need for a bbclass which actually is not using gyp, instead it should be able to "npm run build".

There is alsa a patch for speeding up npm npmsw fetcher https://www.mail-archive.com/openembedded-core@.../msg142406.html
cheers Thomas


Yocto- Apache2 build guide

D, Sharmila <sharmila.d@...>
 

Hi,

I am trying to enable httpd package into my yocto build, steps I followed is as below

1. Added below layer in bblayer.conf file

sources/meta-openembedded/meta-webserver

2. Added below line in local.conf file

IMAGE_INSTALL_append = "apache2"

The yocto build using bitbake core-image-minimal gives below error

WARNING: core-image-minimal-1.0-r0 do_rootfs: busybox.postinst returned 1, marking as unpacked only, configuration required on target.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Postinstall scriptlets of ['busybox'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
Details of the failure are in /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.
ERROR: core-image-minimal-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: /home/h440246/Projects/rfid/BSP/tisdk/build/arago-tmp-glibc/work/omapl138_lcdk-oe-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.2937
ERROR: Task (/home/h440246/Projects/rfid/BSP/tisdk/sources/oe-core/meta/recipes-core/images/core-image-minimal.bb:do_rootfs) failed with exit code '1'

Please provide the solution for the same

With Best Regards,

Sharmila D


Re: Trouble booting basic x86 image

Paul D. DeRocco
 

From: Mittal, Anuj [mailto:anuj.mittal@intel.com]

It looks like you are using the live option in hddimg image? Can you
try adding "rootwait" to kernel parameters and see if that works?

Not sure why it's not dropping to shell, but may be try
adding explicit
call to /bin/sh in meta/recipes-core/initrdscripts/files/init-live.sh
before this point to make sure the media is actually mounted at that
point.

Also, have you tried wic image to see if that works?
Thanks for the advice. I decided to try wic, since that's actually the x86
default if you don't set IMAGE_FSTYPES. It also looks cleaner than hddimg,
since it has a real ext4 partition and no loop mounting.

For the 32-bit build, it produced something my BIOS wouldn't recognize as
bootable, even though it looked fine in gparted. For the 64-bit build, it
booted part way, crashing on an illegal instruction in systemd. For the
64x32-build, it booted but failed trying to run /sbin/init with error -8
(invalid executable). When I look at the drive in Ubuntu, the properties on
that file say it's a link to /lib/systemd/systemd, which makes sense.
Strangely, though, it describes it as a shared library. objdump -f says:

/media/pauld/platform/sbin/init: file format elf32-x86-64
architecture: i386:x64-32, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00024490

So still no joy. I'd rather get this wic version working than go back to the
hddimg version, but I'm not sure what to try next.

Ultimately, I'm just trying to get a vanilla reference build, so that when
the "real" system I'm creating doesn't work (which is often), I can compare
kernel configs, etc., to a known working system.

--

Ciao, Paul D. DeRocco
Paul mailto:pderocco@ix.netcom.com


Re: Huawei e3372h & Quectel EG25-G LTE modems

Zoltan Kerenyi Nagy
 

I'm reading the Quectel dokumentation, and it say that a GobiNet driver should be included as well. But there is no Yocto recipe for that

--
Zolee


Re: Huawei e3372h & Quectel EG25-G LTE modems

Zoltan Kerenyi Nagy
 

Hi Khem,

There is no NetworkManager.conf file on the device. Shoudl I create one?


--
Zolee


Re: Kernel Header UAPI Issue

Karthik Poduval
 

Hi Bruce,

Thanks a lot for your patch (attached in bugzilla
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305). I am
summarizing all steps once again for the benefit of anyone else who
faces the same issue (including myself in the future) and may use this
email list as a reference. The basic need was to export kernel headers
from kernel source for an application recipe (those headers are not a
part of linux-libc-headers recipe).

I applied the patch pointed by Bruce
https://bugzilla.yoctoproject.org/attachment.cgi?id=4647 to my local
BSP layer. The patch has 2 modes of operation (described in the patch
documentation).

mode1: To make this work I added the following lines to my application recipe.

inherit cmake kernel-alt-headers
DEPENDS = "gtest rsync-native"
EXTRA_OECMAKE =
'-DKERNEL_HEADER_DIR:STRING=${WORKDIR}/${KERNEL_ALT_HEADER_DIR}/include'
Then in my CMakeLists.txt.
include_directories(${KERNEL_HEADER_DIR})

The application compiled fine but there was one side effect that
kernel menuconfig (bitbake virtual/kernel -c menuconfig) wasn't able
to run as it complained that the source tree wasn't clean and make
mrproper was needed. This was resolved by a simple fix to the
do_compile_prepend in the patch (added the mrproper command).
do_compile_prepend() {
if [ "${KERNEL_SOURCE_IS_LOCAL}" = "False" ]; then
# install from the staging kernel directory
oe_runmake -C ${STAGING_KERNEL_DIR} headers_install
INSTALL_HDR_PATH=${WORKDIR}/${KERNEL_ALT_HEADER_DIR}
oe_runmake -C ${STAGING_KERNEL_DIR} mrproper
fi
}

mode2: To make this work I added the following line to my kernel recipe.
inherit kernel-alt-headers

to my application recipe following lines were added.
DEPENDS += "virtual/kernel"
EXTRA_OECMAKE =
'-DKERNEL_HEADER_DIR:STRING=${STAGING_DIR_TARGET}/usr/alt-headers/include'
Then in my CMakeLists.txt.
include_directories(${KERNEL_HEADER_DIR})

--
Regards,
Karthik Poduval

On Tue, Feb 23, 2021 at 10:50 AM Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:

On Tue, Feb 23, 2021 at 9:56 AM Karthik Poduval
<karthik.poduval@gmail.com> wrote:

Hi Mikko,

Do you have an example on how you do that ? Do you bbapend the
linux-libc-headers recipe file ?
I have an application that uses dmabuf heap that potentially extends
across multiple BSP's as its BSP agnostic. I don't want to be patching
individual BSP recipes and generating headers. The issue I am facing
is due to backporting the patch from 5.6 to 5.4 so the required header
isn't a part of the linux-libc-headers.bb recipe. Best would have been
a virtual/kernel-keaders target that applications that require BSP
headers would add to their recipe DEPENDS. Why is this not a solved
issue by yocto project ? Why do individual BSP's need to deal with
this differently when the header install mechanism (make
headers_install) is the same irrespective of the type of BSP ?
Because it's not a simple thing to solve (and there's a bugzilla around for it
already, where the thoughts and issues are captured, but that one seems to
have been closed and I can't find it at the moment). I do have a WIP
class that provides some different modes
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=5305),
but with corner cases and concerns, it keeps slipping. Feel free to try it
out and comment in the bug (I'll try myself to be sure it still applied, it has
been a few months).

What works for your case, doesn't mean it is a general/supporable
solution.

But generally speaking, It's an incredibly bad idea to have your libc-headers
tied to the kernel you are building. Every time that kernel changes, you
basically need to rebuild the entire stack .. hence the bad idea. It is such
a common question, that we actually put a warning in the libc-headers
recipe itself.

We do not really want a parallel set of headers in the shared workdir, that are
from the currently built kernel. You'd end up with all sorts of mismatches
and cross includes and potential different behaviour per-application.

We already have the kernel source installed into the shared workdir,
which is what the tips in the libc-headers recipe suggest using. And it
honestly isn't so common the need for sanitized headers that the need for
something like I did in that bug has made it necessary.

Bruce


On Tue, Feb 23, 2021 at 5:18 AM <Mikko.Rapeli@bmw.de> wrote:

Hi,

I know it's not the best or recommended approach, but I find it
hard to avoid merging linux-libc-headers recipe with the actual
kernel recipe that a distro is using. At least a static copy
of some version of uapi headers from that kernel can be used
instead of the poky side linux-libc-headers. This helps to get
the actual BSP SW delivery headers into userspace, SDK etc.

Cheers,

-Mikko


--
Regards,
Karthik Poduval

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


Re: Huawei e3372h & Quectel EG25-G LTE modems

Khem Raj
 


On Tue, Feb 23, 2021 at 10:22 PM Zoltan Kerenyi Nagy <kerenyi.nagy.zoltan@...> wrote:
Hi,

I have a barix ipam400 module, the development is done with Yocto. Recently I managed to modify and include the needed kernel modules into the kernel with Yocto.
However it still doesnt work. Both module work seemleslly and out of the box with a RaspberryPi, but not with this ipam400 modul. The kernel is 4.10.

The latest issue is that when I try to pull up an internet connection the error message is this:
device lo not available because device is strictly unmanage

These are the kernel module which I have included with bitbake -c menuconfig linux, they are all on the target device now:

what does NetworkManager.conf look like on the device ?
especially mark managed=true and see if that helps

 


Do you guys have any idea whats wrong with this setup. I've read the out-of-tree kernel module yocto dokumentation, I did my best and had many suggestions on the forum as well.

--
Zolee



Huawei e3372h & Quectel EG25-G LTE modems

Zoltan Kerenyi Nagy
 

Hi,

I have a barix ipam400 module, the development is done with Yocto. Recently I managed to modify and include the needed kernel modules into the kernel with Yocto.
However it still doesnt work. Both module work seemleslly and out of the box with a RaspberryPi, but not with this ipam400 modul. The kernel is 4.10.

The latest issue is that when I try to pull up an internet connection the error message is this:
device lo not available because device is strictly unmanage

These are the kernel module which I have included with bitbake -c menuconfig linux, they are all on the target device now:


Do you guys have any idea whats wrong with this setup. I've read the out-of-tree kernel module yocto dokumentation, I did my best and had many suggestions on the forum as well.

--
Zolee


Re: [opkg-devel] [opkg-utils PATCH v2] Makefile: separate manpages and utils install

Alex Stewart
 

Merged 1 commit to opkg-utils:master.

74ccbee0f798822041dba5c6564df62a0c60d86b

Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stewart@ni.com

1361 - 1380 of 53814