Yocto Technical Team Minutes, Engineering Sync, for March 30, 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, Armin Kuster, Richard Purdie, Randy
MacLeod, Jan-Simon Möller, Trevor Gamblin, Tim Orling, Michael Halstead,
Paul Barker, Jon Mason, Joshua Watt, Steven Sakoman, Saul Wold, Scott
Murray, Khem Raj, Peter Kjellerstedt (saur), Ross Burton, Michael
Opdenacker

== notes ==
- 3.2-m3 released
- -m4 being built this week, no more update patches

== general ==
Randy: got info collection thingy working on AB thanks to help from SS and
integrated into results
RP: have you had a chance to look at my theory
Randy: not yet
RP: io-nice doesn’t change async write (I think AlexK pointed this out). we
do nice levels for all processes and io-nice for things that write, it’s
possible that this is where we’re hitting the io block. we might want to
try doing some builds under qemu (then we can enforce more nice levels) as
a means of investigating this issue


RP: the valgrind stuff seems to be testing well in master-next, but i will
defer those to -m4
RP: the -m4 build date is, technically, monday, anything else to include?
Randy: lttng modules?


Khem: i have gcc-11 patches, probably not for -m4, but if the AB has cycles
can i send them up?
RP: on the one hand i’d prefer to not do multiple things at the same time,
on the other hand i can’t stop people from sending new features
Khem: i can hold off a bit. i could send an RFC. yocto project has already
submitted gcc-11 patches and i’m looking to expand the testing on it
RP: any issues for -native recipes?
Khem: i’ve found a bunch already and upstreamed them, any that weren’t
accepted in the upstream project have been put into oe-core


Peter: what about the covered/not-covered (on runqueue) issue
RP: i have drafted a patch and is in master-next. it doesn’t appear to break
anything, but proving it fixes things is hard. have you seen the problem
after adding that patch?
Peter: no
SS: i had seen it on 3 builds, and haven’t seen them again either
RP: trying to reproduce an exact same build (wrt sstate, runqueues, etc) is
hard, so it’s hard to know if we’ve solved it


Khem: in the past we’ve seen issues with bitbake running forever due to
“make -l” issue. so we removed it. but we still see long builds with
qemarm
Randy: how much longer?
Khem: (guessing) 30%
Randy: qemuarm64 too?
Khem: no, just qemuarm. same number of CPUs, same underlying machine
Jon: qemuarmv5 as well?
Khem: no
Jon: maybe it’s a qemuarm hardfloat issue. i’ll try to reproduce it
Khem: i’m building lots of stuff, not just the basics. mostly doing world
builds, so maybe it’s a particular package
<various>: we can give it a try
RP: maybe by dropping the -l you’ve introduced something else (e.g. swapping)
Khem: but no other qemu’s are affected. most builds finish in 10 hours,
but qemuarm gets killed after 13 hours (due to a timeout) which is why i
notice it (because it gets killed)
RP: it would be interesting to look at the build stats data then compare build
times recipe-to-recipe
Randy: is there a bug filed?
Khem: not yet, i can file a tracking bug


TimO: Ross asked me about splitting meta-python out to standalone layer (from
meta-openembedded). would allow us to use dynamic layers. might help with
ptest coverage. it might might other workflows possible (i.e. move it
to gitlab and use their things). some have offered strong opinions that
it’s just splitting for splitting sake
RP: i think splitting out would be good. there’s lots of burnout and it
would be great to spread the load a bit more (instead of making one person
responsible for all meta-oe)
TrevorG: having to share the support with the rest of meta-oe is hard
TimO: Khem had asked us to move to a PR mechanism
JPEW: this subset feels like the best one to be pulled out (as a test)
TimO: true, meta-perl might be a good candidate too. in any case i would start
with dunfell, but nothing before that
Khem: have you considered this from the users point of view. obviously we’re
thinking more of the maintenance point of view but let’s not forget to
seek user input
TimO: obviously it’s going to impact users, they’ll need to change URIs
and bblayers
PaulB: just make sure the layer index gets updated and we could leave a stub
behind that points the user to the change
RP: (same)
Khem: i also think it would help if these layers have separate mailing list.
it’s hard for users to know where to send patches (especially poky). so
instead of using mete-oe as a kitchen sink
TimO: i’ve always wished for a separate mailing list. i’ve had to do lots
of filtering but it doesn’t catch everything
Khem: good to bring to TSC and community to get input
TimO: it’s fairly quick to split this out. mechanics aren’t a problem
Armin: looking at layers that depend on meta-python, do you think they would
change to dynamic layers? meta-networking and meta-multimedia depend on
meta-python, so splitting it out would require pulling it in for many
use-cases
RP: i wouldn't get too worried about the details, everything could be
solved, let’s not worry about all possibilities, when only some might
come to pass. i think more layers is good, maybe it opens up the ability
to use the AB for some of this stuff (as stuff gets smaller)
Randy: so the reasons for are:
1. burden on maintainers
2. quality and test coverage
?
TimO: also simplification (if you want some python you don’t need all of
meta-oe)
RP: i see dependency creep in external layers (since you have to pull in
meta-oe for meta-python then we might as well pull in all these other
things too that we’re already getting in meta-oe)
Randy: do we want to see everything in meta-oe split up, or other splits in
oe-core?
RP: case by case, there’s pros and cons
Randy: what about incremental transition vs a full change-over
TimO: i want to make sure all the ptests are in place first, and there’s the
question of review
Khem: why can’t we add ptests now? (i.e. in meta-oe)
TimO: i’d *like* to add more ptests, but doesn’t mean we will/should
Khem: propose it and see what the feedback is. people are making products with
this and we should make sure to move forward in a way the impacts them in
a way they’re happy with
TimO: 10 people will provide 20 opinions
RP: we can do a POC and move forward
TimO: we’ve talked about it so much over the years and we never agree on
trying a change, maybe people can’t see the benefit until they actually
try it
Randy: could this live on git.yoctoproject.org
TimO: maybe git.openembedded.org instead
Randy: would you track bugs on YP bugzilla
RP: where to host is irrelevant, but there are larger issues (such as better
AB usage, maintainer question, burnout, mailing lists)
Khem: lots of people listed as maintainers of individual packages, but little
actual maintainer help. how many maintainers actually review and help?
RP: the same problem exists in oe-core. there are some that are active, but in
the end it’s usually AlexK that does the upgrades
TimO: it could be an issue of timing, sometime you don’t get to it in a
day and someone else does it. with unlimited resources we would use yp
bugzilla, but there are consequences to the members
Randy: do you want more layers removed too?
Khem: yes, that would be great. i’m not maintainer by choice, then i could
sign up to maintain what matters to me
TrevorG: if we do it now with meta-python, then it lets us know if we should
go ahead and do it with others too
RP: yes, good experiment and we can roll it back. meta-python looks like it
would be a good test
TimO: i have tools that make it easy to do, and then easy to roll back. and
the tools are not just meta-python-specific, they could be used for any
sub-layer


TrevorW: there is a Yocto Project related virtual conference being planned:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
TrevorW: the CfP is now open:
https://pretalx.com/yocto-project-summit-2021/cfp

Thanks @Khem Raj for your valuable response.

As Zeus is not supported with meta-printing Layer . is it feasible to use Zeus in this Scenario?

And For Opencv Package version to use from Krogoth is with zeus is compilable?

need native pip3, was using host's

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb b/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
index b7ff2ad..c0bd35e 100644
--- a/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
+++ b/meta-tpm/recipes-tpm/swtpm/swtpm_0.5.2.bb
@@ -7,7 +7,7 @@ DEPENDS = "libtasn1 coreutils-native expect socat glib-2.0 net-tools-native libt

# configure checks for the tools already during compilation and
# then swtpm_setup needs them at runtime
-DEPENDS += "tpm-tools-native expect-native socat-native"
+DEPENDS += "tpm-tools-native expect-native socat-native python3-pip-native"

SRCREV = "e59c0c1a7b4c8d652dbb280fd6126895a7057464"
SRC_URI = "git://github.com/stefanberger/swtpm.git;branch=stable-0.5 \
@@ -18,7 +18,6 @@ PE = "1"
S = "${WORKDIR}/git"

inherit autotools pkgconfig python3-dir
-PARALLEL_MAKE = ""

TSS_USER="tss"
TSS_GROUP="tss"
--
2.17.1

Signed-off-by: Armin Kuster <akuster808@...>
---
meta-tpm/conf/layer.conf | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index 65788eb..1b766cb 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -13,6 +13,7 @@ LAYERSERIES_COMPAT_tpm-layer = "hardknott"
LAYERDEPENDS_tpm-layer = " \
core \
openembedded-layer \
+ meta-python \
"
BBLAYERS_LAYERINDEX_NAME_tpm-layer = "meta-tpm"

--
2.17.1

ERROR: clamav-0.104.0-r0 do_package: QA Issue: clamav: Files/directories were installed but not shipped in any package:
/lib/systemd/system/clamav-daemon.service
/lib/systemd/system/clamav-clamonacc.service

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-scanners/clamav/clamav_0.104.0.bb | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/recipes-scanners/clamav/clamav_0.104.0.bb b/recipes-scanners/clamav/clamav_0.104.0.bb
index 9e50466..ba036b0 100644
--- a/recipes-scanners/clamav/clamav_0.104.0.bb
+++ b/recipes-scanners/clamav/clamav_0.104.0.bb
@@ -105,7 +105,10 @@ FILES_${PN}-daemon = "${bindir}/clamconf ${bindir}/clamdtop ${sbindir}/clamd \
/usr/etc/clamd.conf* \
${systemd_unitdir}/system/clamav-daemon/* \
${docdir}/clamav-daemon/* ${sysconfdir}/clamav-daemon \
- ${sysconfdir}/logcheck/ignore.d.server/clamav-daemon "
+ ${sysconfdir}/logcheck/ignore.d.server/clamav-daemon \
+ ${systemd_unitdir}/system/clamav-daemon.service \
+ ${systemd_unitdir}/system/clamav-clamonacc.service \
+ "

FILES_${PN}-freshclam = "${bindir}/freshclam \
${sysconfdir}/freshclam.conf* \
--
2.17.1

Signed-off-by: Armin Kuster <akuster808@...>
---
...ython3-privacyidea_3.5.1.bb => python3-privacyidea_3.5.2.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename recipes-security/mfa/{python3-privacyidea_3.5.1.bb => python3-privacyidea_3.5.2.bb} (96%)

diff --git a/recipes-security/mfa/python3-privacyidea_3.5.1.bb b/recipes-security/mfa/python3-privacyidea_3.5.2.bb
similarity index 96%
rename from recipes-security/mfa/python3-privacyidea_3.5.1.bb
rename to recipes-security/mfa/python3-privacyidea_3.5.2.bb
index fb84411..cd0acf8 100644
--- a/recipes-security/mfa/python3-privacyidea_3.5.1.bb
+++ b/recipes-security/mfa/python3-privacyidea_3.5.2.bb
@@ -6,7 +6,7 @@ LICENSE = "AGPL-3.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=c0acfa7a8a03b718abee9135bc1a1c55"

PYPI_PACKAGE = "privacyIDEA"
-SRC_URI[sha256sum] = "c10f8e9ec681af4cb42fde70864c2b9a4b47e2bcccfc1290f83c1283748772c6"
+SRC_URI[sha256sum] = "26aeb0d353af1f212c4df476202516953c20f7f31566cfe0b67cbb553de04763"

inherit pypi setuptools3

--
2.17.1

On 3/30/21 12:42 AM, rohitbjadhav1@... wrote:

Hi
   I was using very old version of Yocto i.e. Krogoth. In that version I am able to use following packages with respective version:
    Package name   Version
   Cups                     2.2.4
   Cups-filter            1.14.0
   qpdf                      6.0.0
   Opencv                 2.4
It was working fine. But When I switch to any other version of Yocto like  Zeus [which I have tried on ].
Specifically for cups-filter pakage observed following errors while compilation and generation of rootfs
ERROR: cups-filters-1.14.0-r0 do_compile: oe_runmake failed
ERROR: cups-filters-1.14.0-r0 do_compile: Execution of '/home/tel/imx_yocto_bsp_Zeus/Yocto_setup/build_imx6ull/tmp/work/cortexa7t2hf-neon-poky-linux-gnueabi/cups-filters/1.14.0-r0/temp/run.do_compile.17590' failed with exit code 1:
It is observed due to wrong c standard while compilation as some log says as follow:
warning: ISO C99 doesn't support unnamed structs/unions [-Wpedantic]
warning: ' LPT #' directive output may be truncated writing 6 bytes into a region of size between 1 and 1024 [-Wformat-truncation=]
warning: 'strncpy' specified bound 1024 equals destination size [-Wstringop-truncation]
filter/pdftoopvp/oprs/OPVPSplash.h:53:3: error: 'GBool' does not name a type

it seems you are locking above said packages to revisions you want, but they also have additional dependencies, eg. the one which is causing issue here is poppler, since poppler version in zeus is 0.80.0 and krogoth has 0.41, however poppler switched to using standard types for bool starting 0.71,

my suggestion is to use the versions that come with zeus release and forward port your app to consume them or second option is to fork versions then you must look at what would be the right set of packages you need to lock to older versions in-order for you to keep things going forward.

Just Need some guideline to resolve this issue.
Please also suggest is there any way to use old pakage of Yocto version to latest Yocto version.
Thanks and Regards
Rohit

--

On 3/30/21 1:48 PM, Ross Burton wrote:

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

Thanks for this infor Randy, really appreciated, I think I will also
look at the h/w angle.

Khem: if you can reproduce this on demand with a clean build (ie
oe-init-build-env with a clean build directory, just set DL_DIR) then
enabling buildstats would give some interesting metrics.
buildstats-diff can compare two build runs and tell you what the
differences are.

yeah this is doing world build of not only core but several other layers included a usual build takes around 10 hrs for this machine config, I am planning to

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

it could very well be rotting hardware underneath the VM.

Ross

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

Thanks for this infor Randy, really appreciated, I think I will also
look at the h/w angle.

Khem: if you can reproduce this on demand with a clean build (ie
oe-init-build-env with a clean build directory, just set DL_DIR) then
enabling buildstats would give some interesting metrics.
buildstats-diff can compare two build runs and tell you what the
differences are.

Ross

No one having problems with sysroot for nativesdk-binutils / nativesdk-gcc?

On 3/30/21 10:45 AM, Randy MacLeod wrote:

Khem  was asking if anyone had seen a >30% difference in build time for
qemuarm compared to other machines. I don't when building on my system:
rmacleod@yow-rmacleod-lx3 b/c-i-m-x86 $ cat x86
real    43m29.142s
user    0m19.887s
sys     0m4.110s
rmacleod@yow-rmacleod-lx3 b/c-i-m-x86 $ cat arm
real    42m58.185s
user    0m19.546s
sys     0m3.867s
This machine is relatively isolated in that there are no other users.
The arm build was done second and I didn't pre-populate the downloads
but so that may account for the 30 second difference.
I wasn't using sstate for either build.

Thanks for this infor Randy, really appreciated, I think I will also look at the h/w angle.

Khem was asking if anyone had seen a >30% difference in build time for
qemuarm compared to other machines. I don't when building on my system:

rmacleod@yow-rmacleod-lx3 b/c-i-m-x86 $ cat x86
real 43m29.142s
user 0m19.887s
sys 0m4.110s

rmacleod@yow-rmacleod-lx3 b/c-i-m-x86 $ cat arm
real 42m58.185s
user 0m19.546s
sys 0m3.867s

This machine is relatively isolated in that there are no other users.
The arm build was done second and I didn't pre-populate the downloads
but so that may account for the 30 second difference.
I wasn't using sstate for either build.
--
# Randy MacLeod
# Wind River Linux

From: Yann Dirson <yann@...>

This patch provides "standard" and "tiny" BSP.

There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.

It's sad that when a different kernel type is selected, and no BSP is
available, this gets silently DWIM-handled - much time gets lost hunting
for the reason.

Tiny is not really testable by itself, I played with it using:

PREFERRED_PROVIDER_virtual/kernel =3D "linux-yocto-tiny"
KERNEL_FEATURES_append =3D "\
ktypes/base/base.scc \
features/debug/printk.scc \
cfg/fs/ext4.scc \
"

Regardless from those additions, quite a number of useless hardware featu=
res
still manage to creep aboard. Despite this, the fitImage weight drops fr=
om
11MB with "standard" to 5MB with "tiny" and boots to serial shell.
---
recipes-kernel/linux/linux-yocto%.bbappend | 6 +++
.../linux-yocto/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4-tiny.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4.cfg | 40 +++++++++++++++
.../linux/linux-yocto/bsp/nanopi-m4.scc | 5 ++
.../linux/linux-yocto/bsp/rk3399.cfg | 48 ++++++++++++++++++
.../linux/linux-yocto/bsp/rk3399.scc | 5 ++
.../linux/linux-yocto/bsp/rockchip.cfg | 50 +++++++++++++++++++
.../linux/linux-yocto/bsp/rockchip.scc | 6 +++
9 files changed, 174 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standa=
rd.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.s=
cc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.scc

diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..5193373 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -1,3 +1,9 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/linux-yocto:"
+
+SRC_URI_append =3D "\
+ file://bsp;type=3Dkmeta;subdir=3Dkernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
COMPATIBLE_MACHINE_radxarock =3D "radxarock"
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc =
b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc
new file mode 100644
index 0000000..5c74d6b
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standard.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE standard
+define KARCH arm
+
+include ktypes/standard/standard.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc b/re=
cipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc
new file mode 100644
index 0000000..6e94d6a
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE tiny
+define KARCH arm
+
+include ktypes/tiny/tiny.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg b/recipes=
-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
new file mode 100644
index 0000000..5864008
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
@@ -0,0 +1,40 @@
+CONFIG_MFD_RK808=3Dy
+CONFIG_COMMON_CLK_RK808=3Dy
+
+# regulators
+CONFIG_REGULATOR_RK808=3Dy
+CONFIG_REGULATOR_FAN53555=3Dy
+
+CONFIG_MMC_BLOCK=3Dy
+
+# audio jack
+CONFIG_SND_SOC_ROCKCHIP_RT5651=3Dm
+
+# BT, maybe some - RFCOMM for headset voice, MSFTEXT ?
+CONFIG_BT=3Dm
+#CONFIG_BT_BCM=3Dm
+#CONFIG_BT_HCIUART_BCM=3Dm
+CONFIG_BT_RFCOMM=3Dm
+CONFIG_BT_RFCOMM_TTY=3Dy
+CONFIG_BT_BNEP=3Dm
+CONFIG_BT_HS=3Dy
+CONFIG_BT_LE=3Dy
+CONFIG_BT_MSFTEXT=3Dy
+CONFIG_BT_DEBUGFS=3Dy
+CONFIG_WIRELESS=3Dy
+CONFIG_RFKILL=3Dm
+
+CONFIG_PHY_ROCKCHIP_DP=3Dy
+
+CONFIG_VIDEO_DEV=3Dm
+CONFIG_V4L_MEM2MEM_DRIVERS=3Dy
+CONFIG_VIDEO_ROCKCHIP_RGA=3Dm
+
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=3Dm
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=3Dm
+
+CONFIG_V4L2_H264=3Dm
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=3Dy
+CONFIG_VIDEO_HANTRO=3Dm
+CONFIG_VIDEO_HANTRO_ROCKCHIP=3Dy
+CONFIG_VIDEO_ROCKCHIP_VDEC=3Dm
diff --git a/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc b/recipes=
-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
new file mode 100644
index 0000000..f4267aa
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware nanopi-m4.cfg
+
+include rk3399.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg b/recipes-ke=
rnel/linux/linux-yocto/bsp/rk3399.cfg
new file mode 100644
index 0000000..232d2cf
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
@@ -0,0 +1,48 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=3Dy
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=3Dy
+CONFIG_ARM64_ERRATUM_827319=3Dy
+CONFIG_ARM64_ERRATUM_824069=3Dy
+CONFIG_ARM64_ERRATUM_819472=3Dy
+
+# cru
+CONFIG_CLK_RK3399=3Dy
+
+CONFIG_PL330_DMA=3Dy
+CONFIG_I2C_RK3X=3Dy
+CONFIG_SERIAL_8250_DW=3Dy
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=3Dy
+CONFIG_PHY_ROCKCHIP_TYPEC=3Dy
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=3Dy
+CONFIG_STMMAC_ETH=3Dm
+CONFIG_STMMAC_PLATFORM=3Dm
+CONFIG_DWMAC_ROCKCHIP=3Dm
+CONFIG_ROCKCHIP_PHY=3Dm
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=3Dy
+CONFIG_ROCKCHIP_DW_MIPI_DSI=3Dy
+CONFIG_ROCKCHIP_ANALOGIX_DP=3Dy
+CONFIG_ROCKCHIP_CDN_DP=3Dy
+CONFIG_DRM_DW_HDMI=3Dm
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=3Dm
+CONFIG_DRM_DW_HDMI_CEC=3Dm
+CONFIG_DRM_DW_MIPI_DSI=3Dm
+CONFIG_DRM_PANFROST=3Dm
+
+# usb
+CONFIG_USB_DWC2=3Dy
+CONFIG_USB_DWC3=3Dy
+CONFIG_USB_DWC3_DUAL_ROLE=3Dy
+
+# sd/mmc
+CONFIG_MMC_SDHCI=3Dy
+CONFIG_MMC_SDHCI_PLTFM=3Dy
+CONFIG_MMC_DW=3Dy
+CONFIG_MMC_DW_ROCKCHIP=3Dy
+CONFIG_MMC_SDHCI_OF_ARASAN=3Dy
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rk3399.scc b/recipes-ke=
rnel/linux/linux-yocto/bsp/rk3399.scc
new file mode 100644
index 0000000..9b1a88e
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rk3399.cfg
+
+include rockchip.scc
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg b/recipes-=
kernel/linux/linux-yocto/bsp/rockchip.cfg
new file mode 100644
index 0000000..eac2a31
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
@@ -0,0 +1,50 @@
+CONFIG_ARCH_ROCKCHIP=3Dy
+CONFIG_COMMON_CLK_ROCKCHIP=3Dy
+CONFIG_REGULATOR=3Dy
+CONFIG_REGULATOR_FIXED_VOLTAGE=3Dy
+CONFIG_REGULATOR_PWM=3Dy
+CONFIG_I2C=3Dy
+CONFIG_FW_LOADER=3Dy
+CONFIG_PHY_ROCKCHIP_EMMC=3Dy
+CONFIG_PINCTRL=3Dy
+CONFIG_PINCTRL_ROCKCHIP=3Dy
+CONFIG_ROCKCHIP_IODOMAIN=3Dy
+CONFIG_ROCKCHIP_PM_DOMAINS=3Dy
+
+CONFIG_PWM=3Dy
+CONFIG_PWM_ROCKCHIP=3Dy
+
+CONFIG_DRM_KMS_HELPER=3Dm
+CONFIG_DRM_FBDEV_EMULATION=3Dy
+CONFIG_ROCKCHIP_IOMMU=3Dy
+CONFIG_DRM_ROCKCHIP=3Dm
+CONFIG_DRM_BRIDGE=3Dy
+
+CONFIG_SND=3Dy
+CONFIG_SND_SOC=3Dy
+CONFIG_SND_HDA_CODEC_HDMI=3Dm
+CONFIG_SND_SOC_ROCKCHIP=3Dm
+CONFIG_SND_SOC_ROCKCHIP_I2S=3Dm
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=3Dm
+
+CONFIG_NVMEM=3Dy
+CONFIG_ROCKCHIP_EFUSE=3Dm
+
+CONFIG_CPU_FREQ=3Dy
+
+# maybe?
+CONFIG_MFD_SYSCON=3Dy
+CONFIG_FB_MODE_HELPERS=3Dy
+
+# possibly for somewhere else
+CONFIG_DRM=3Dm
+CONFIG_DRM_MIPI_DSI=3Dy
+CONFIG_SOUND=3Dy
+CONFIG_USB=3Dy
+CONFIG_SERIAL_8250=3Dy
+CONFIG_SERIAL_8250_CONSOLE=3Dy
+
+# obviously for somewhere else
+CONFIG_MULTIUSER=3Dy
+CONFIG_TTY=3Dy
+CONFIG_SERIAL_EARLYCON=3Dy
diff --git a/recipes-kernel/linux/linux-yocto/bsp/rockchip.scc b/recipes-=
kernel/linux/linux-yocto/bsp/rockchip.scc
new file mode 100644
index 0000000..800f105
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/bsp/rockchip.scc
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rockchip.cfg
+
+include cfg/dmaengine.scc
+include features/mmc/mmc-block.cfg
--=20
2.30.2

From: Yann Dirson <yann@...>

This is a first draft of a kmeta BSP for nanopi-m4, with rough
granularity for now. For testing and comments. See patch 3 to
play with "linux-yocto-tiny" config.

Yann Dirson (3):
linux-yocto: reduce bbappend duplication
NanoPi-M4: let all variants use the same KMACHINE type
WIP linux-yocto: add a NanoPi-M4 BSP

conf/machine/include/nanopi-m4.inc | 1 +
...yocto_%.bbappend =3D> linux-yocto%.bbappend} | 6 +++
recipes-kernel/linux/linux-yocto-dev.bbappend | 10 ----
.../linux/linux-yocto-rt_%.bbappend | 10 ----
.../linux/linux-yocto-tiny_%.bbappend | 10 ----
.../linux-yocto/bsp/nanopi-m4-standard.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4-tiny.scc | 7 +++
.../linux/linux-yocto/bsp/nanopi-m4.cfg | 40 +++++++++++++++
.../linux/linux-yocto/bsp/nanopi-m4.scc | 5 ++
.../linux/linux-yocto/bsp/rk3399.cfg | 48 ++++++++++++++++++
.../linux/linux-yocto/bsp/rk3399.scc | 5 ++
.../linux/linux-yocto/bsp/rockchip.cfg | 50 +++++++++++++++++++
.../linux/linux-yocto/bsp/rockchip.scc | 6 +++
13 files changed, 175 insertions(+), 30 deletions(-)
rename recipes-kernel/linux/{linux-yocto_%.bbappend =3D> linux-yocto%.bb=
append} (80%)
delete mode 100644 recipes-kernel/linux/linux-yocto-dev.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-rt_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-tiny_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-standa=
rd.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4-tiny.s=
cc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rk3399.scc
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.cfg
create mode 100644 recipes-kernel/linux/linux-yocto/bsp/rockchip.scc

--=20
2.30.2

From: Yann Dirson <yann@...>

---
conf/machine/include/nanopi-m4.inc | 1 +
1 file changed, 1 insertion(+)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/na=
nopi-m4.inc
index 74cdae8..603160f 100644
--- a/conf/machine/include/nanopi-m4.inc
+++ b/conf/machine/include/nanopi-m4.inc
@@ -3,6 +3,7 @@
=20
require rk3399.inc
=20
+KMACHINE =3D "nanopi-m4"
KERNEL_DEVICETREE =3D "rockchip/rk3399-nanopi-m4.dtb"
=20
RK_BOOT_DEVICE =3D "mmcblk1"
--=20
2.30.2

From: Yann Dirson <yann@...>

---
...{linux-yocto-dev.bbappend =3D> linux-yocto%.bbappend} | 0
recipes-kernel/linux/linux-yocto-rt_%.bbappend | 10 ----------
recipes-kernel/linux/linux-yocto-tiny_%.bbappend | 10 ----------
recipes-kernel/linux/linux-yocto_%.bbappend | 10 ----------
4 files changed, 30 deletions(-)
rename recipes-kernel/linux/{linux-yocto-dev.bbappend =3D> linux-yocto%.=
bbappend} (100%)
delete mode 100644 recipes-kernel/linux/linux-yocto-rt_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto-tiny_%.bbappend
delete mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend

diff --git a/recipes-kernel/linux/linux-yocto-dev.bbappend b/recipes-kern=
el/linux/linux-yocto%.bbappend
similarity index 100%
rename from recipes-kernel/linux/linux-yocto-dev.bbappend
rename to recipes-kernel/linux/linux-yocto%.bbappend
diff --git a/recipes-kernel/linux/linux-yocto-rt_%.bbappend b/recipes-ker=
nel/linux/linux-yocto-rt_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto-rt_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
-COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
-COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
-COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend b/recipes-k=
ernel/linux/linux-yocto-tiny_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto-tiny_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
-COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
-COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
-COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel=
/linux/linux-yocto_%.bbappend
deleted file mode 100644
index 7702e3f..0000000
--- a/recipes-kernel/linux/linux-yocto_%.bbappend
+++ /dev/null
@@ -1,10 +0,0 @@
-COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
-COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
-COMPATIBLE_MACHINE_radxarock =3D "radxarock"
-COMPATIBLE_MACHINE_firefly-rk3288 =3D "firefly-rk3288"
-COMPATIBLE_MACHINE_vyasa-rk3288 =3D "vyasa-rk3288"
-COMPATIBLE_MACHINE_tinker-board =3D "tinker-board"
-COMPATIBLE_MACHINE_tinker-board-s =3D "tinker-board-s"
-COMPATIBLE_MACHINE_rock-pi-4 =3D "rock-pi-4"
-COMPATIBLE_MACHINE_nanopi-m4 =3D "nanopi-m4"
-COMPATIBLE_MACHINE_nanopi-m4-2gb =3D "nanopi-m4-2gb"
--=20
2.30.2

The Yocto Project Summit Planning Committee is happy to announce the
upcoming 3rd Yocto Project Summit to take place Tuesday and Wednesday
May 25-26 2021, virtually.

The 2-day event will run in 2 tracks including a virtual developers meeting,
beginner tutorial sessions, hands-on intermediate instruction, lightning
talks, regular talks, and social events.

The cost for all attendees will be $40USD. The event will run both days from
noon until 8pm GMT. Registration is not yet open but will be shortly, please
watch for further announcements.

The call for papers is now open and will close at 11:59 PM PST on Sunday,
April 25, 2021. To submit a proposal please visit:
https://pretalx.com/yocto-project-summit-2021/cfp

For more information please visit:
https://www.yoctoproject.org/yocto-project-virtual-summit-2021/

We look forward to seeing you at the conference!

--