Date   

Can layer maintainers add yocto-X.Y tags for yocto-3.3 and later?

Randy MacLeod
 

Hi,


I've CCed some of the maintainers of more widely used Yocto layers
to get comments on about tagging. Please add in people who I may
have missed.


For a while now, oe-core has had a yocto-X.Y tag in addition to the
release branch name. This helps users easily find the exact commit
that corresponds to the say 3.3 GA release. There have been some
omissions in tagging but Michael and Richard are adjusting the
release process so that tagging will happen more consistently.

Most yocto layers have not adopted the tagging perhaps because they
weren't aware of it so that's why I'm writing this email. Tagging
will make it easy to find the first commit for a specific release
independent of what the branching policy of a layer is. Layer maintainers sometimes create the release branch in advance of
when oe-core is released and by adding the tag, it would make it
clear when the layer considers content to be officially released.
Of course it's up to users to decide if they are going to follow
the HEAD of a branch or, for some reason, stick with a tagged commit
or private branch off that commit.


Are there any concerns about attempting to do this for yocto-3.3
and later?

Should we make it a requirement for yocto compliance?
Should it be a feature tested by the yocto compliance script?



Here's what's in oe-core and bitbake now:
$ cd .../oe-core.git
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.1.7
yocto-3.2
yocto-3.2.1
yocto-3.3

$ cd bitbake/
$ git tag -l | grep yocto-3
yocto-3.0
yocto-3.1
yocto-3.2

--
# Randy MacLeod
# Wind River Linux


Re: [OE-core] [PATCH 6/7] default-distrovars.inc: add wayland/opengl to default distro features

Randy MacLeod
 

Cross-posting to yocto since this is of general interest.

On 2021-04-23 2:02 p.m., Alexander Kanavin wrote:
This puts them on equal terms with x11 distro feature
(which I think is due).
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
meta/conf/distro/include/default-distrovars.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc
index 9fcc10f83a..384ee7fc98 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -10,7 +10,7 @@ LOCALE_UTF8_ONLY ?= "0"
LOCALE_UTF8_IS_DEFAULT ?= "1"
LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0"
-DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat"
+DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat wayland opengl"
DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}"
IMAGE_FEATURES ?= ""
We (Wind River) already drop the x11 DF from some of our distros and
we'd likely do the same for wayland and opengl so while this seems
like the wrong change for headless systems it is one we could deal with.

There was some discussion about this topic on the tech call today and
people were concerned about BSP support for opengl since the software
rendering in mesa is horridly slow.

Kevin, Bryan,
Can you comment if you think we'd have any show-stopper problems
with opengl support for BSPs?

Joshua said that weston has a usable RDP (remote desktop backend) but
I'm not sure how usable it is especially for single application sharing.
This contrasts with x11 where you can use X11 forwarding over
ssh trivially for whole desktops or an application.

In conclusion, I see the value in pushing yocto forward but we may need
to wait for agreement from BSP folks so let's see what they say.

../Randy



--
# Randy MacLeod
# Wind River Linux


Yocto Project Status WW17`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.1.7 was released.
  • Patches are now flowing into master for 3.4 for M1 which is now undergoing active development.
  • We added automated yocto-check-layer testing to the YP autobuilder for key project layers which include meta-openembedded and meta-virtualization as well as member layers. The aim is to ensure key project layers interoperate well with each other and we’d like to thank the layer maintainers who’ve helped ensure these layers started passing tests.
  • Libseccomp has moved to OE-Core due to its widespread use and becoming a hard requirement for some software. As such its now in the default DISTRO_FEATURES.
  • There is a potentially controversial proposal to add opengl to the default DISTRO_FEATURES as part of the move to wayland rather than X11 Xserver based systems which people may wish to review carefully.
  • Elections for the two OE positions on the YP TSC are ongoing on the openembedded-members list. Please contact the OE board if you are not a member but would like to be.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You  can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 build date 2021/06/07
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.7 has been released.
  • YP 3.2.4 build date 2021/05/3
  • YP 3.2.4 release date 2021/05/14
  • YP 3.3.1 build date 2021/05/17
  • YP 3.3.1 release date 2021/05/28
  • YP 3.1.8 build date 2021/05/24
  • YP 3.1.8 release date 2021/06/04
  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


looking for a bit more info on licensing certain recipe files

Robert P. J. Day
 

for the first time, i'm digging around in the docs for how to
properly license various types of recipes, so a couple simple
questions to start with, at least so i can make a first pass of
cleaning up some content in front of me.

as we established recently, packagegroup files need no licensing,
the obvious observation being that they represent the collection of
licenses that comprise them. however, i notice that the
packagegroup.bbclass file does indeed define a default license:

LICENSE ?= "MIT"

so not only does a packagegroup have a default (MIT) license, but it's
conditional suggesting one could give it a different license. what
other licenses would make sense for a packagegroup? I'm sticking with
the default that packagegroup recipe files need no LICENSE assignment,
but now i'm curious as to what other options there are (or perhaps
that that default assignment in packagegroup.bbclass is obsolete).

the same sort of question can be asked about image files, including
the generic OE core-image*.bb recipe files. of all those current
core-image files:

core-image-base.bb
core-image-minimal.bb
core-image-minimal-dev.bb
core-image-minimal-initramfs.bb
core-image-minimal-mtdutils.bb
core-image-tiny-initramfs.bb

fail into two camps.

the first sets a license, then inherits core-image:

LICENSE = "MIT"
inherit core-image

the second type simply "require"s one of the other recipe files so it
has no need to set its own license, as in core-image-minimal-dev.bb:

require core-image-minimal.bb

similar to packagegroups, does a core-image recipe really need a
separate LICENSE setting, or could that be added to core-image.bbclass
to centralize it (if it's even needed at all)?

finally, WRT .bbappend files, the original recipes will have their
own licenses and if the .bbappend file is doing nothing but adding
some configuration (you know, PACKAGECONFIG, EXTRA_OEMAKE, that sort
of thing), then there should be no need for licensing in the bbappend
file. does all this sound reasonable so far?

rday


Re: ERROR: Fetcher failure: Fetch command export...

Quentin Schulz
 

On Tue, Apr 27, 2021 at 02:01:24AM -0400, jchludzinski via lists.yoctoproject.org wrote:
When I trying using bitbake to build openembedded Linux kernel, it dies with
these download failures:

NOTE: Fetching uninative binary shim http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b
(will check PREMIRRORS first)
WARNING: Failed to fetch URL http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b,
attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export
SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/jski/poky/scripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/bin:/home/jski/poky/bitbake/bin:/home/jski/poky/build/tmp/hosttools";
export HOME="/home/jski"; /usr/bin/env wget -t 2 -T 30 --passive-ftp
--no-check-certificate -P /home/jski/poky/build/downloads/uninative/5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz'
--progress=dot -v failed with exit code 4, output:
--2021-04-27 01:49:09-- http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz
Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... failed:
Connection timed out.
wget: unable to resolve host address 'downloads.yoctoproject.org'
It looks like an issue with your DNS which does not return anything for
downloads.yoctoproject.org?

Cheers,
Quentin


Re: running application in user mode instead of root #yocto

Alessandro Tagliapietra
 

I'm new to yocto as well but what we do is in our own custom image:

inherit extrausers
EXTRA_USERS_PARAMS = " useradd nodered"

and then since we use systemd we've created our own service file that includes:

User=nodered

in the [service] block definition, so the executable is run using that user instead of root.

Extrausers docs are https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-extrausers

An alternative you might look at is the useradd class https://git.yoctoproject.org/cgit.cgi/poky/tree/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb which probably lets you set the users in your own recipe instead at image level


Re: running application in user mode instead of root #yocto

Yann Dirson
 

Hello,

I am trying to run my application in less privilege mode instead of root user.
As i am new to Yocto build could you please some one suggest on how to configure my build environment to get user and run
my application with the user privileges at startup.
You may be interested in ROOTLESS_X="1", to open a non-priviledged X11 session.


Regards,
Vijay


--
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech


running application in user mode instead of root #yocto

mail2uvijay@...
 

Hi All,

I am trying to run my application in less privilege mode instead of root user.
As i am new to Yocto build could you please some one suggest on how to configure my build environment to get user and run
my application with the user privileges at startup.

Regards,
Vijay


ERROR: Fetcher failure: Fetch command export...

jchludzinski
 

When I trying using bitbake to build openembedded Linux kernel, it dies with these download failures:

NOTE: Fetching uninative binary shim http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b (will check PREMIRRORS first)
WARNING: Failed to fetch URL http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b, attempting MIRRORS if available
ERROR: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/jski/poky/scripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin/x86_64-poky-linux:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/usr/bin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/sbin:/home/jski/poky/build/tmp/work/core2-64-poky-linux/defaultpkgname/1.0-r0/recipe-sysroot-native/bin:/home/jski/poky/bitbake/bin:/home/jski/poky/build/tmp/hosttools"; export HOME="/home/jski"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/jski/poky/build/downloads/uninative/5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz' --progress=dot -v failed with exit code 4, output:
--2021-04-27 01:49:09--  http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz
Resolving downloads.yoctoproject.org (downloads.yoctoproject.org)... failed: Connection timed out.
wget: unable to resolve host address ‘downloads.yoctoproject.org’

WARNING: Disabling uninative as unable to fetch uninative tarball: Fetcher failure for URL: 'http://downloads.yoctoproject.org/releases/uninative/3.0/x86_64-nativesdk-libc.tar.xz;sha256sum=5ec5a9276046e7eceeac749a18b175667384e1f445cd4526300a41404d985a5b'. Unable to fetch URL from any source.
WARNING: To build your own uninative loader, please bitbake uninative-tarball and set UNINATIVE_TARBALL appropriately.

Why?


M+ & H bugs with Milestone Movements WW17

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW17 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

11766

nobody group added by systemd sysusers.d

randy.macleod@...

yi.zhao@...

3.3 M1

3.4 M2

 

13425

Add bblock and bbunlock helper tools

richard.purdie@...

newcomer@...

3.3 M4

3.4 M1

 

14099

PACKAGE_EXCLUDE not removing packages when PACKAGE_CLASSES = "package_deb"

randy.macleod@...

randy.macleod@...

3.3 M4

3.4 M1

 

14126

resolvconf incompatible with busybox flock

richard.purdie@...

newcomer@...

3.3 M4

3.4 M1

 

14295

ptest test image core-image-sato-sdk-ptest failure

randy.macleod@...

randy.macleod@...

3.3 M4

3.4 M2

 

14283

gitsm fetcher failure when LFS content is present in the main repo

richard.purdie@...

richard.purdie@...

3.3 M4

3.4 M1

 

14338

Tmux -c (CWD) requires Tmux 1.9

randy.macleod@...

pbbudny@...

0.0.0

3.4 M1

 

14352

ssh connection failure during xorg testing on qemuarm

randy.macleod@...

alexandre.belloni@...

3.4

3.4 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Enhancements/Bugs closed WW17!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

richard.purdie@...

16

yf3yu@...

8

michael.opdenacker@...

3

mhalstead@...

2

randy.macleod@...

2

prabin.ca@...

1

Grand Total

32

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.4

Stephen Jolley
 

All,

Below is the list as of top 50 bug owners as of the end of WW17 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 130 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

richard.purdie@...

30

ross@...

28

david.reyna@...

23

bruce.ashfield@...

20

michael.opdenacker@...

17

bluelightning@...

14

timothy.t.orling@...

12

akuster808@...

11

randy.macleod@...

11

trevor.gamblin@...

11

JPEWhacker@...

10

sakib.sajal@...

10

kai.kang@...

8

hongxu.jia@...

7

raj.khem@...

6

Qi.Chen@...

6

chee.yang.lee@...

6

mingli.yu@...

5

yi.zhao@...

4

mostthingsweb@...

3

idadelm@...

3

saul.wold@...

3

jaewon@...

2

alexandre.belloni@...

2

jeanmarie.lemetayer@...

2

ydirson@...

2

pokylinux@...

2

stacygaikovaia@...

2

nicolas.dechesne@...

2

jon.mason@...

2

alejandro@...

2

naveen.kumar.saini@...

1

Martin.Jansa@...

1

john.kaldas.enpj@...

1

open.source@...

1

mhalstead@...

1

twoerner@...

1

yoctoproject@...

1

changqing.li@...

1

dl9pf@...

1

devendra.tewari@...

1

kexin.hao@...

1

mshah@...

1

shachar@...

1

steve@...

1

mister_rs@...

1

liezhi.yang@...

1

victor.kamensky7@...

1

matt.ranostay@...

1

kergoth@...

1

aehs29@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 356 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now, “3.2”, “3.3, "3.99" and "Future", the more pressing/urgent issues being in "3.2" and then “3.3”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


[meta-zephyr][PATCH 1/1] CI: add Gitlab CI support

Jon Mason
 

Signed-off-by: Jon Mason <jon.mason@arm.com>
---
.gitlab-ci.yml | 172 ++++++++++++++++++++++++++++++++++++++
ci/96b-avenger96.yml | 9 ++
ci/96b-nitrogen.yml | 6 ++
ci/acrn.yml | 6 ++
ci/base.yml | 35 ++++++++
ci/check-machine-coverage | 26 ++++++
ci/check-warnings | 18 ++++
ci/jobs-to-kas | 19 +++++
ci/logging.yml | 13 +++
ci/meta-oe.yml | 8 ++
ci/meta-python.yml | 10 +++
ci/qemu-cortex-m3.yml | 6 ++
ci/qemu-nios2.yml | 6 ++
ci/qemu-x86.yml | 6 ++
ci/testimage.yml | 5 ++
ci/update-repos | 40 +++++++++
16 files changed, 385 insertions(+)
create mode 100644 .gitlab-ci.yml
create mode 100644 ci/96b-avenger96.yml
create mode 100644 ci/96b-nitrogen.yml
create mode 100644 ci/acrn.yml
create mode 100644 ci/base.yml
create mode 100755 ci/check-machine-coverage
create mode 100755 ci/check-warnings
create mode 100755 ci/jobs-to-kas
create mode 100644 ci/logging.yml
create mode 100644 ci/meta-oe.yml
create mode 100644 ci/meta-python.yml
create mode 100644 ci/qemu-cortex-m3.yml
create mode 100644 ci/qemu-nios2.yml
create mode 100644 ci/qemu-x86.yml
create mode 100644 ci/testimage.yml
create mode 100755 ci/update-repos

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 000000000000..06cdf535e53b
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,172 @@
+image: ghcr.io/siemens/kas/kas
+
+ # First do a common bootstrap, and then build all the targets
+stages:
+ - prep
+ - bootstrap
+ - build
+ - test
+
+# Common job fragment to get a worker ready
+.setup:
+ stage: build
+ variables:
+ KAS_WORK_DIR: $CI_PROJECT_DIR/work
+ KAS_REPO_REF_DIR: $CI_BUILDS_DIR/persist/repos
+ SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
+ DL_DIR: $CI_BUILDS_DIR/persist/downloads
+ BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
+ before_script:
+ - echo KAS_WORK_DIR = $KAS_WORK_DIR
+ - echo SSTATE_DIR = $SSTATE_DIR
+ - echo DL_DIR = $DL_DIR
+ - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR
+
+# Generalised fragment to do a Kas build
+.build:
+ extends: .setup
+ script:
+ - KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME)
+ - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
+ - kas build $KASFILES
+ - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
+
+# KAS testing
+.test:
+ extends: .setup
+ stage: test
+ script:
+ - KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME)
+ - kas build $KASFILES -c testimage
+
+
+#
+# Prep stage, update repositories once
+#
+update-repos:
+ extends: .setup
+ stage: prep
+ script:
+ - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
+
+
+#
+# Bootstrap stage, machine coverage
+#
+
+# What percentage of machines in the layer do we build
+machine-coverage:
+ stage: bootstrap
+ script:
+ - ./ci/check-machine-coverage
+ coverage: '/Coverage: \d+/'
+
+
+#
+# Build stage, the actual build jobs
+#
+
+96b-avenger96:
+ extends: .build
+
+96b-nitrogen:
+ extends: .build
+
+acrn:
+ extends: .build
+
+qemu-cortex-m3:
+ extends: .build
+ artifacts:
+ paths:
+ - work/build/tmp-newlib/deploy/images/qemu-cortex-m3/*
+ expire_in: 1 day
+
+qemu-nios2:
+ extends: .build
+ artifacts:
+ paths:
+ - work/build/tmp-newlib/deploy/images/qemu-nios2/*
+ expire_in: 1 day
+ allow_failure: true
+
+qemu-x86:
+ extends: .build
+ artifacts:
+ paths:
+ - work/build/tmp-newlib/deploy/images/qemu-x86/*
+ expire_in: 1 day
+
+
+#
+# Third phase, the test jobs
+#
+
+# QEMU based machines can use testimage, others will need something else (i.e., LAVA)
+
+qemu-cortex-m3/testimage:
+ extends: .test
+ needs:
+ - job: qemu-cortex-m3
+
+qemu-nios2/testimage:
+ extends: .test
+ needs:
+ - job: qemu-nios2
+ allow_failure: true
+
+qemu-x86/testimage:
+ extends: .test
+ needs:
+ - job: qemu-x86
+
+
+#
+# Utility tasks, not executed automatically
+#
+
+# Make the persistant files modifiable by all runners
+chmod-presistent:
+ extends: .setup
+ stage: prep
+ when: manual
+ script:
+ - chmod -R 755 $CI_BUILDS_DIR/persist/*
+
+delete-dl-dir:
+ extends: .setup
+ stage: prep
+ when: manual
+ script:
+ - rm -rf $DL_DIR/*
+
+delete-repo-dir:
+ extends: .setup
+ stage: prep
+ when: manual
+ script:
+ - rm -rf $KAS_REPO_REF_DIR/*
+
+# Delete all sstate
+delete-sstate:
+ extends: .setup
+ stage: prep
+ when: manual
+ script:
+ - rm -rf $SSTATE_DIR/*
+
+# Wipe out old sstate
+prune-sstate:
+ extends: .setup
+ stage: prep
+ when: manual
+ script:
+ - find $SSTATE_DIR -type f -atime +30 -delete
+
+# Report on disk usage
+usage:
+ extends: .setup
+ stage: prep
+ when: manual
+ script:
+ - du -h -s $DL_DIR $SSTATE_DIR $KAS_REPO_REF_DIR
diff --git a/ci/96b-avenger96.yml b/ci/96b-avenger96.yml
new file mode 100644
index 000000000000..9ab58aa83ffa
--- /dev/null
+++ b/ci/96b-avenger96.yml
@@ -0,0 +1,9 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: 96b-avenger96
+
+target:
+ - zephyr-philosophers
diff --git a/ci/96b-nitrogen.yml b/ci/96b-nitrogen.yml
new file mode 100644
index 000000000000..ecd96fb67136
--- /dev/null
+++ b/ci/96b-nitrogen.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: 96b-nitrogen
diff --git a/ci/acrn.yml b/ci/acrn.yml
new file mode 100644
index 000000000000..53748defebec
--- /dev/null
+++ b/ci/acrn.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: acrn
diff --git a/ci/base.yml b/ci/base.yml
new file mode 100644
index 000000000000..8e6cf0caf525
--- /dev/null
+++ b/ci/base.yml
@@ -0,0 +1,35 @@
+header:
+ version: 9
+ includes:
+ - meta-python.yml
+
+distro: zephyr
+
+defaults:
+ repos:
+ refspec: hardknott
+
+repos:
+ meta-zephyr:
+
+ poky:
+ url: https://git.yoctoproject.org/git/poky
+ layers:
+ meta:
+ meta-poky:
+
+env:
+ BB_LOGCONFIG: ""
+
+local_conf_header:
+ base: |
+ CONF_VERSION = "1"
+ INHERIT += "rm_work"
+ ERROR_QA = "${WARN_QA}"
+ testimage: |
+ IMAGE_CLASSES += "testimage"
+
+machine: unset
+
+target:
+ - zephyr-kernel-test-device
diff --git a/ci/check-machine-coverage b/ci/check-machine-coverage
new file mode 100755
index 000000000000..726714d8b0fe
--- /dev/null
+++ b/ci/check-machine-coverage
@@ -0,0 +1,26 @@
+#! /usr/bin/env python3
+
+from pathlib import Path
+import sys
+
+metazephyr = Path.cwd()
+
+if metazephyr.name != "meta-zephyr":
+ print("Not running inside meta-zephyr")
+ sys.exit(1)
+
+# All machine configurations
+machines = metazephyr.glob("conf/machine/*.conf")
+machines = set(p.stem for p in machines)
+
+# All kas files
+kas = metazephyr.glob("ci/*.yml")
+kas = set(p.stem for p in kas)
+
+missing = machines - kas
+print(f"The following machines are missing: {', '.join(sorted(missing))}.")
+
+covered = len(machines) - len(missing)
+total = len(machines)
+percent = int(covered / total * 100)
+print(f"Coverage: {percent}%")
diff --git a/ci/check-warnings b/ci/check-warnings
new file mode 100755
index 000000000000..cc396423d8bf
--- /dev/null
+++ b/ci/check-warnings
@@ -0,0 +1,18 @@
+#! /bin/bash
+
+# Expects the path to a log file as $1, and if this file has any content
+# then display the contents and exit with an error code.
+
+set -e -u
+
+LOGFILE=$1
+
+if test -s $LOGFILE; then
+ echo ==============================
+ echo The build had warnings/errors:
+ echo ==============================
+ cat $LOGFILE
+ exit 1
+fi
+
+exit 0
diff --git a/ci/jobs-to-kas b/ci/jobs-to-kas
new file mode 100755
index 000000000000..70579703bc07
--- /dev/null
+++ b/ci/jobs-to-kas
@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Read a GitLab CI job name on $1 and transform it to a
+# list of Kas yaml files
+
+set -e -u
+
+# Read Job namne from $1 and split on /
+IFS=/ read -r -a PARTS<<<$1
+
+# Prefix each part with ci/
+PARTS=("${PARTS[@]/#/ci/}")
+
+# Suffix each part with .yml
+PARTS=("${PARTS[@]/%/.yml}")
+
+# Print colon-separated
+IFS=":"
+echo "${PARTS[*]}"
diff --git a/ci/logging.yml b/ci/logging.yml
new file mode 100644
index 000000000000..3af10295f8f3
--- /dev/null
+++ b/ci/logging.yml
@@ -0,0 +1,13 @@
+# Python logging configuration to write all warnings to a separate file
+version: 1
+
+handlers:
+ warnings:
+ class: logging.FileHandler
+ level: WARNING
+ filename: warnings.log
+ formatter: BitBake.logfileFormatter
+
+loggers:
+ BitBake:
+ handlers: [warnings]
diff --git a/ci/meta-oe.yml b/ci/meta-oe.yml
new file mode 100644
index 000000000000..ccd34f3a3ffa
--- /dev/null
+++ b/ci/meta-oe.yml
@@ -0,0 +1,8 @@
+header:
+ version: 9
+
+repos:
+ meta-openembedded:
+ url: https://git.openembedded.org/meta-openembedded
+ layers:
+ meta-oe:
diff --git a/ci/meta-python.yml b/ci/meta-python.yml
new file mode 100644
index 000000000000..3f76118ccd09
--- /dev/null
+++ b/ci/meta-python.yml
@@ -0,0 +1,10 @@
+header:
+ version: 9
+ includes:
+ - meta-oe.yml
+
+repos:
+ meta-openembedded:
+ url: https://git.openembedded.org/meta-openembedded
+ layers:
+ meta-python:
diff --git a/ci/qemu-cortex-m3.yml b/ci/qemu-cortex-m3.yml
new file mode 100644
index 000000000000..73b46039abed
--- /dev/null
+++ b/ci/qemu-cortex-m3.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: qemu-cortex-m3
diff --git a/ci/qemu-nios2.yml b/ci/qemu-nios2.yml
new file mode 100644
index 000000000000..75166054c265
--- /dev/null
+++ b/ci/qemu-nios2.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: qemu-nios2
diff --git a/ci/qemu-x86.yml b/ci/qemu-x86.yml
new file mode 100644
index 000000000000..c5d23f471bf8
--- /dev/null
+++ b/ci/qemu-x86.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: qemu-x86
diff --git a/ci/testimage.yml b/ci/testimage.yml
new file mode 100644
index 000000000000..19ea66773b94
--- /dev/null
+++ b/ci/testimage.yml
@@ -0,0 +1,5 @@
+header:
+ version: 9
+
+target:
+ - zephyr-kernel-test-device
diff --git a/ci/update-repos b/ci/update-repos
new file mode 100755
index 000000000000..fa638aad2efb
--- /dev/null
+++ b/ci/update-repos
@@ -0,0 +1,40 @@
+#! /usr/bin/env python3
+
+# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
+
+import sys
+import os
+import subprocess
+import pathlib
+
+def repo_shortname(url):
+ # Taken from Kas (Repo.__getattr__) to ensure the logic is right
+ from urllib.parse import urlparse
+ url = urlparse(url)
+ return ('{url.netloc}{url.path}'
+ .format(url=url)
+ .replace('@', '.')
+ .replace(':', '.')
+ .replace('/', '.')
+ .replace('*', '.'))
+
+repositories = (
+ "https://git.yoctoproject.org/git/poky",
+ "https://git.openembedded.org/meta-openembedded",
+)
+
+if __name__ == "__main__":
+ if "KAS_REPO_REF_DIR" not in os.environ:
+ print("KAS_REPO_REF_DIR needs to be set")
+ sys.exit(1)
+
+ base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
+
+ for repo in repositories:
+ repodir = base_repodir / repo_shortname(repo)
+ if repodir.exists():
+ print("Updating %s..." % repo)
+ subprocess.run(["git", "-C", repodir, "fetch"], check=True)
+ else:
+ print("Cloning %s..." % repo)
+ subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
--
2.20.1


[meta-zephyr][PATCH 0/1] Gitlab CI for meta-zephyr

Jon Mason
 

No one asked for it, but here it is, Gitlab CI for meta-zephyr. Stolen and repurposed from meta-arm. This building and testing should help discover regressions more quickly. And if you include this patch, I'll do nightly builds via my gitlab account (https://gitlab.com/jonmason00/meta-zephyr/-/pipelines) for all to observe.

NOTE: I've been unable to get qemu-nios2 to build. So, I've set the gitlab ci flag of "allow_failures". If someone can tell me the magical incantations to get it working, I'll happily modify the gitlab ci to get it working.

Thanks,
Jon

---

Jon Mason (1):
CI: add Gitlab CI support

.gitlab-ci.yml | 172 ++++++++++++++++++++++++++++++++++++++
ci/96b-avenger96.yml | 9 ++
ci/96b-nitrogen.yml | 6 ++
ci/acrn.yml | 6 ++
ci/base.yml | 35 ++++++++
ci/check-machine-coverage | 26 ++++++
ci/check-warnings | 18 ++++
ci/jobs-to-kas | 19 +++++
ci/logging.yml | 13 +++
ci/meta-oe.yml | 8 ++
ci/meta-python.yml | 10 +++
ci/qemu-cortex-m3.yml | 6 ++
ci/qemu-nios2.yml | 6 ++
ci/qemu-x86.yml | 6 ++
ci/testimage.yml | 5 ++
ci/update-repos | 40 +++++++++
16 files changed, 385 insertions(+)
create mode 100644 .gitlab-ci.yml
create mode 100644 ci/96b-avenger96.yml
create mode 100644 ci/96b-nitrogen.yml
create mode 100644 ci/acrn.yml
create mode 100644 ci/base.yml
create mode 100755 ci/check-machine-coverage
create mode 100755 ci/check-warnings
create mode 100755 ci/jobs-to-kas
create mode 100644 ci/logging.yml
create mode 100644 ci/meta-oe.yml
create mode 100644 ci/meta-python.yml
create mode 100644 ci/qemu-cortex-m3.yml
create mode 100644 ci/qemu-nios2.yml
create mode 100644 ci/qemu-x86.yml
create mode 100644 ci/testimage.yml
create mode 100755 ci/update-repos

--
2.20.1


Improving NPM recipe build speed

Alessandro Tagliapietra
 

Hi everyone,

I'm making an image that includes the node-red recipe from meta-iot-cloud.
The whole process takes about 30+ minutes for that recipe alone (most of the time spent in do_configure).
Now I want to override the recipe systemd service file and create a nodered user. Every time I change my bbappend file I have to wait 30+ minutes to have the result even for a small systemd file change.

Is it possible to speed up the process somehow?

Thanks in advance


Hardknott: grub immediately reboots

Tony Battersby
 

After upgrading from Dunfell (YP 3.1) to Hardknott (YP 3.3), our
firmware was unable to boot.  Our target hardware is x86-64 booting in
legacy BIOS mode using grub on a variety of motherboards and CPUs.  The
grub menu would never show up; instead it would reboot immediately,
leading to an endless reboot loop.

I have two different workarounds.  Create a bbappend file for grub, and
do one of the following two things:

1) Add the following line:

CFLAGS_remove = "-O2"

2) Or make a patch to revert the following commit, and add it to SRC_URI:

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=4ea7bae51f97e49c84dc67ea30b466ca8633b9f6


NOTE: this commit fixes a CVE, so do not revert it without due
consideration.


Here is my upstream bug report:

https://savannah.gnu.org/bugs/index.php?60458


Is anyone else experiencing this problem?  I am wondering how it got
past Yocto QA.

Tony Battersby
Cybernetics


Re: [meta-security] [dunfell] [PATCH 0/3] Backport several IMA fixes to LTS dunfell

Armin Kuster
 

On 4/18/21 11:41 PM, liu.ming50@gmail.com wrote:
From: Ming Liu <ming.liu@toradex.com>
I have not forgotten about these. My build system is backlogged.

I hope to process these by this weekend.

-armin

Ming Liu (3):
ima-evm-keys: add file-checksums to IMA_EVM_X509
meta: drop IMA_POLICY from policy recipes
initramfs-framework-ima: introduce IMA_FORCE

.../initrdscripts/initramfs-framework-ima.bb | 5 +++++
.../initrdscripts/initramfs-framework-ima/ima | 9 +++++++--
.../recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb | 1 +
.../ima-policy-appraise-all_1.0.bb | 9 ++-------
.../ima_policy_hashed/ima-policy-hashed_1.0.bb | 9 ++-------
.../ima_policy_simple/ima-policy-simple_1.0.bb | 9 ++-------
6 files changed, 19 insertions(+), 23 deletions(-)


Criteria for bitbake to skip recipes #bitbake

keydi
 

I wonder what are all possible criteria for Bitbake to decide to skip recipe (please compare to reports delivered by bitbake-layers). Recipe overlay, recipe version, others? Which knowledge source to find more details in?


[meta-rockchip][PATCH v4 3/3] linux-yocto: add an initial NanoPi-M4 BSP

Yann Dirson
 

From: Yann Dirson <yann@blade-group.com>

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.
Not all SoC/board features are covered yet either (esp. Wifi/Bluetooth an=
d
audio jack), and properly-woking HDMI still needs patches.

Tiny is not fully testable by itself, it can be minimally booted with
serial console (though still missing CONFIG_MULTIUSER for serial getty,
and CONFIG_INOTIFY_USER for proper udev operation) 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 \
cfg/8250.scc \
"

Such a tiny build is still using mainline defconfig with lots of hardware
features, and the kernel can be slimmed down even more by using:

KBUILD_DEFCONFIG =3D ""

Kernel weight using default configurations:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Signed-off-by: Yann Dirson <yann@blade-group.com>
---
.../files/bsp/rockchip/nanopi-m4-standard.scc | 7 ++
.../files/bsp/rockchip/nanopi-m4-tiny.scc | 7 ++
.../linux/files/bsp/rockchip/nanopi-m4.cfg | 15 ++++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 71 +++++++++++++++++++
.../linux/files/bsp/rockchip/rk3399.scc | 5 ++
.../linux/files/bsp/rockchip/rockchip.cfg | 50 +++++++++++++
.../linux/files/bsp/rockchip/rockchip.scc | 6 ++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++
9 files changed, 172 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-sta=
ndard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tin=
y.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.scc

diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.s=
cc b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
new file mode 100644
index 0000000..5c74d6b
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/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/files/bsp/rockchip/nanopi-m4-tiny.scc b=
/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc
new file mode 100644
index 0000000..6e94d6a
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/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/files/bsp/rockchip/nanopi-m4.cfg b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
new file mode 100644
index 0000000..7802ab3
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -0,0 +1,15 @@
+CONFIG_MFD_RK808=3Dy
+CONFIG_COMMON_CLK_RK808=3Dy
+
+CONFIG_REGULATOR_RK808=3Dy
+CONFIG_REGULATOR_FAN53555=3Dy
+
+CONFIG_MMC_BLOCK=3Dy
+CONFIG_PWRSEQ_SIMPLE=3Dy
+
+# RTL8211E
+CONFIG_REALTEK_PHY=3Dm
+
+# AP6356S
+CONFIG_BT_BCM=3Dm
+CONFIG_BT_HCIUART_BCM=3Dy
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
new file mode 100644
index 0000000..f4267aa
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/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/files/bsp/rockchip/rk3399.cfg b/recipes=
-kernel/linux/files/bsp/rockchip/rk3399.cfg
new file mode 100644
index 0000000..f5f2909
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
@@ -0,0 +1,71 @@
+# 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_PHYLIB=3Dm
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=3Dy
+CONFIG_ROCKCHIP_DW_MIPI_DSI=3Dy
+CONFIG_ROCKCHIP_ANALOGIX_DP=3Dy
+CONFIG_ROCKCHIP_CDN_DP=3Dy
+CONFIG_PHY_ROCKCHIP_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
+
+# HDMI audio
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=3Dm
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=3Dm
+
+CONFIG_VIDEO_DEV=3Dm
+CONFIG_V4L_MEM2MEM_DRIVERS=3Dy
+CONFIG_VIDEO_ROCKCHIP_RGA=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
+
+# usb
+CONFIG_USB_DWC2=3Dy
+CONFIG_USB_DWC3=3Dy
+CONFIG_USB_DWC3_DUAL_ROLE=3Dy
+
+# sd/mmc
+CONFIG_MMC=3Dy
+CONFIG_MMC_SDHCI=3Dy
+CONFIG_MMC_SDHCI_PLTFM=3Dy
+CONFIG_MMC_DW=3Dy
+CONFIG_MMC_DW_ROCKCHIP=3Dy
+CONFIG_MMC_SDHCI_OF_ARASAN=3Dy
+
+# temperature sensors
+CONFIG_THERMAL=3Dy
+CONFIG_THERMAL_OF=3Dy
+CONFIG_ROCKCHIP_THERMAL=3Dm
+CONFIG_IIO=3Dy
+CONFIG_ROCKCHIP_SARADC=3Dm
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rk3399.scc b/recipes=
-kernel/linux/files/bsp/rockchip/rk3399.scc
new file mode 100644
index 0000000..9b1a88e
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rk3399.cfg
+
+include rockchip.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.cfg
new file mode 100644
index 0000000..05a397d
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
@@ -0,0 +1,50 @@
+CONFIG_CPU_ISOLATION=3Dy
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=3Dy
+CONFIG_HZ_250=3Dy
+CONFIG_CPU_IDLE=3Dy
+CONFIG_ARM_CPUIDLE=3Dy
+
+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_SPI=3Dy
+CONFIG_SPI_ROCKCHIP=3Dm
+
+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
+CONFIG_CPU_FREQ_THERMAL=3Dy
+CONFIG_HWMON=3Dy
+CONFIG_THERMAL_HWMON=3Dy
+
+CONFIG_CRYPTO_HW=3Dy
+CONFIG_CRYPTO_DEV_ROCKCHIP=3Dm
+
+CONFIG_MMC_BLOCK_MINORS=3D32
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.scc
new file mode 100644
index 0000000..800f105
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rockchip.cfg
+
+include cfg/dmaengine.scc
+include features/mmc/mmc-block.cfg
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..9658681 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -1,3 +1,9 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+
+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"
--=20
2.30.2

2181 - 2200 of 55440