Date   

Re: any interest in an official "meta-rubygems" layer?

Jack Mitchell
 

On 27/01/2021 09:09, Robert P. J. Day wrote:
On Wed, 27 Jan 2021, Jack Mitchell wrote:
... snip ...

Hi Robert,

This is something I would be interested in. I have a developed a
much more basic rubygems class privately which I had intended to
opensource and create a similar later, so it would be nice to have a
central place to contribute Ruby/RubyGems improvements. As you have
found there are many layers with spotty Ruby support and a
particular copy of an old class that is being banded about which is
often insufficient.
cool ... care to share your rubygems.bbclass file? be great to
combine the best of both worlds.

rday
Please find attached, it's basically the old ruby class with only
support for pure RubyGems (i.e. no cross-compiling) with some influence
from the pypi class for grabbing and compiling a SRC_URI.

Cheers,
Jack.

--
Jack Mitchell, Consultant
https://www.tuxable.co.uk


Re: Points to consider while moving to new yocto versions

amaya jindal
 

Thankyou for your comments and guidance. 

Currently i am trying to first move from krogoth version of yocto to rocko version first that will suffice our requirements but i need to understand whether any major difference is there in gcc 4.9.3 vs gcc 6.4. As krogoth is usin gcc 4.9.3 /5.3 recipe but rocko is using 6.4/7.x as recipe for gcc source compilation. Please guide.

Regards,
Rohit Jindal

On Mon, Jan 25, 2021 at 6:16 PM Robert Berger@... <robert.berger.yocto.user@...> wrote:
Hi,

My comments are in-line

On 25/01/2021 10:07, amaya jindal wrote:
> Hi All,
>
> We are planning to move to New yocto from current one that is krogoth
> yocto to some updated one.

I would consider it "best practice" to somewhat try to stay up to date
with recent yocto versions and plan for this from the beginning of your
project.

What I mean is to have a "stable release" and a "next release" which is
being used in your nightly builds and tests.

This will make it significantly easier to make version upgrades.

> We are not thinking to move to gates-garth or
> some other major release but the releases than can have easily support
> for arm.

I am not sure what you mean by that?

Which versions make it easier/more difficult to support arm?

It's more a question of which chip/kernel/boot loader,...

>
> Please support and help.
>
> Points need to take care to port to new yocto version.

Ssince you use a completely outdated and end of life version[1] it might
require quite some effort to update, but through pain we learn ;)

[1] https://wiki.yoctoproject.org/wiki/Releases

Which chip do you use?

Is it supported by an upstream kernel/boot loader?

Which (additional) layers do you use?

Are these layers supported by the same version as the Yocto version you
want to move to?

How about your own recipes?

Are they compatible with upstream yocto?

>
> Regards,
> Rohit

Regards,

Robert

>
>
>
>


Re: any interest in an official "meta-rubygems" layer?

Robert P. J. Day
 

On Wed, 27 Jan 2021, Jack Mitchell wrote:
... snip ...

Hi Robert,

This is something I would be interested in. I have a developed a
much more basic rubygems class privately which I had intended to
opensource and create a similar later, so it would be nice to have a
central place to contribute Ruby/RubyGems improvements. As you have
found there are many layers with spotty Ruby support and a
particular copy of an old class that is being banded about which is
often insufficient.
cool ... care to share your rubygems.bbclass file? be great to
combine the best of both worlds.

rday


CMake cannot find installed package #yocto

Vijay Rakesh Munganda
 

Hi,

I had installed a library into the build by writing my own recipe, but cmake couldn't find my installed package. Please anyone suggest what I have to add in my recipe?

CMake Error at recipe-sysroot-native/usr/share/cmake-3.16/Modules/FindPkgConfig.cmake:711 (message):
|   None of the required 'libopentok' found
|   Call Stack (most recent call first):
|   CMakeLists.txt:14 (PKG_SEARCH_MODULE)

Thanks & Regards,
Vijay


[meta-zephyr] bitbake zephyr-helloworld configure failure

Peter Smith <salerio@...>
 

Using master branch

MACHINE=96b_nitrogen bitbake zephyr-helloworld creates a configure error due to a failure for native python to import ruamel.

I fixed this temporarily by creating a python3-ruamel-yaml_%.bbappend that includes the required BBEXTEND and adding python3-ruamel-yaml-native to zephyr-kernel-common.inc.

I don't know (not enough experience) if this is actually a problem in the meta-openembedded recipe or meta-zephyr?

Best Regards
Peter


Re: any interest in an official "meta-rubygems" layer?

Jack Mitchell
 

On 27/01/2021 06:33, Robert P. J. Day wrote:

since it appears that i will be diving head-first into messing with
ruby in some current YP builds, is there any interest in creating a
meta-rubygems layer to start collecting recipes based on what konrad
weihmann has done in his meta-sca layer here?

https://github.com/priv-kweihmann/meta-sca

i've been swapping emails with konrad over the last few days and,
first, it seems clear that it's not appropriate to start dumping
general ruby recipes into meta-sca as that layer is clearly defined as
being for "static code analysis and security hardening", so a new,
more general layer is obviously more appropriate.

also, konrad focuses on using his own "rubygems.bbclass" class file:

https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass

to define recipes that pull from rubygems.org exclusively, and he
agrees that it would keep things simpler to stick with that model;
hence, the proposal of the layer name "meta-rubygems" and not just
"meta-ruby".

konrad already offered to do the maintenance of such a new layer, as
long as there is standard infrastructure support for testing, that
sort of thing. and i'm sure that would make his meta-sca layer simpler
as all the more generic rubygems-based recipes could be moved into the
meta-rubygems layer, leaving his meta-sca layer to focus exclusively
on the code analysis and security recipes, however he wants to do
that.

thoughts? it seems that a new layer could be populated almost
instantly with a large chunk of meta-sca, and we could take it from
there.

rday
Hi Robert,

This is something I would be interested in. I have a developed a much
more basic rubygems class privately which I had intended to opensource
and create a similar later, so it would be nice to have a central place
to contribute Ruby/RubyGems improvements. As you have found there are
many layers with spotty Ruby support and a particular copy of an old
class that is being banded about which is often insufficient.

Regards,
Jack.

--
Jack Mitchell, Consultant
https://www.tuxable.co.uk


any interest in an official "meta-rubygems" layer?

Robert P. J. Day
 

since it appears that i will be diving head-first into messing with
ruby in some current YP builds, is there any interest in creating a
meta-rubygems layer to start collecting recipes based on what konrad
weihmann has done in his meta-sca layer here?

https://github.com/priv-kweihmann/meta-sca

i've been swapping emails with konrad over the last few days and,
first, it seems clear that it's not appropriate to start dumping
general ruby recipes into meta-sca as that layer is clearly defined as
being for "static code analysis and security hardening", so a new,
more general layer is obviously more appropriate.

also, konrad focuses on using his own "rubygems.bbclass" class file:

https://github.com/priv-kweihmann/meta-sca/blob/master/classes/rubygems.bbclass

to define recipes that pull from rubygems.org exclusively, and he
agrees that it would keep things simpler to stick with that model;
hence, the proposal of the layer name "meta-rubygems" and not just
"meta-ruby".

konrad already offered to do the maintenance of such a new layer, as
long as there is standard infrastructure support for testing, that
sort of thing. and i'm sure that would make his meta-sca layer simpler
as all the more generic rubygems-based recipes could be moved into the
meta-rubygems layer, leaving his meta-sca layer to focus exclusively
on the code analysis and security recipes, however he wants to do
that.

thoughts? it seems that a new layer could be populated almost
instantly with a large chunk of meta-sca, and we could take it from
there.

rday


Re: QA notification for completed autobuilder build (yocto-3.3_M2.rc1)

Sangeeta Jain
 

Hi All,

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

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

new issue found

BUG id:14203 - [QA 3.3 M2 RC1] failure in ptest : gstreamer1.0.gstreamer-1.0/pipelines_seek.test


======= Bugs ========
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14203

Thanks,
Sangeeta

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf
Of Pokybuild User
Sent: Thursday, 21 January, 2021 1:05 PM
To: yocto@lists.yoctoproject.org
Cc: qa-build-notification@lists.yoctoproject.org
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.3_M2.rc1)


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


https://autobuilder.yocto.io/pub/releases/yocto-3.3_M2.rc1


Build hash information:

bitbake: 01e901c44ab0f496606b1d45c8953dc54970204c
meta-arm: a8f32f990a0d9dc1db310892c70d5a994c698b32
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: b4e5d33affeaa223459c0935a853485137b4591d
meta-kernel: 8349870943ba44bbd688656897372e881f32c741
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: 79821d5a185e25384f5b6b5158b238bbee17c79e
poky: b5e634644b69a968a93aad0dd0502cf479d3973a



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



Re: openjdk-8 multilib

Rudolf J Streif
 

On 1/26/21 11:35 AM, Richard Purdie wrote:
On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:
I have been scratching my head over building openjdk-8 with multilib for
an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host
arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively
including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc
I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.

Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.

Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.

Cheers,

Richard
Thanks, Richard. That's what I thought it is. Essentially, the includes are, as expected, resolved at parse time of the recipes, which makes entirely sense. The include files themselves conditionally set SRC_URI for patchsets which are evaluated when the recipes eventually is executed. While the conditional include is neat for keeping things separate, a solution might be to combine the two include files into one.

Cheers,
Rudi

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700


Re: openjdk-8 multilib

Richard Purdie
 

On Tue, 2021-01-26 at 09:00 -0800, Rudolf J Streif wrote:
I have been scratching my head over building openjdk-8 with multilib for
an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the
64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host
arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively
including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc
I suspect that at this point in the parse, the mulitlib code hasn't
swizzled the bits around so it still looks like the main lib rather
than the mutlilib.

Including a variable in a require like that is an immediate expansion
operation so it can't be "undone" when things get properly setup later.

Offhand I'm not sure what you'd do to avoid this. The multilibs are all
a bit ugly in some ways. It suggests they need to be setting up the
overrides earlier. The assumption in the code is that people don't use
immediate expansion for this reason.

Cheers,

Richard


openjdk-8 multilib

Rudolf J Streif
 

I have been scratching my head over building openjdk-8 with multilib for an aarch64 system. Essentially, I want to use 32-bit OpenJDK on the 64-bit system.

Theoretically adding to local.conf

require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"

and then building lib32-openjdk-8 should do the trick. However, it does not:

$ bitbake lib32-openjdk-8
<omitted>
ERROR: Nothing PROVIDES 'lib32-openjdk-8'
lib32-openjdk-8 was skipped: incompatible with host arm-fslcmllib32-linux-gnueabi (not in COMPATIBLE_HOST)

The openjdk-8 recipe sets architecture dependency by selectively including an include file:

INC_FILE_SUFFIX = ""
INC_FILE_SUFFIX_aarch64 = "-aarch64"
INC_FILE_SUFFIX_armv7a = "-aarch32"
INC_FILE_SUFFIX_armv7ve = "-aarch32"
require openjdk-8-release${INC_FILE_SUFFIX}.inc
require openjdk-8-cross.inc

The include file for openjdk-8-release-aarch32.inc sets:

COMPATIBLE_HOST = "^$"
COMPATIBLE_HOST_armv7ve = "arm"
COMPATIBLE_HOST_armv7a = "arm"

So this should theoretically work as it does when the recipe is built for native aarch32. Except that it does not in the multilib case. Although building for multilib the recipe includes openjdk-8-release-aarch64.inc instead of openjdk-8-release-aarch32.inc. If I force the recipe to include openjdk-8-release-aarch32.inc everything works fine, except, of course, that OpenJDK cannot be built for aarch64 anymore.

I am not too familiar with the inner workings of bitbake's multilib code. That's why I am looking here for assistance first before spending a lot of time digging through the code.

Thanks,
Rudi


M+ & H bugs with Milestone Movements WW04

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

13888

Toaster is not starting for Django-3

randy.macleod@...

david.reyna@...

3.1.5

3.1.6

 

14031

Exception: KeyError: 'getpwuid(): uid not found: 1000' after 3.1.1 to 3.1.2 update

randy.macleod@...

steve@...

3.1.5

3.1.6

 

14114

Implement proper sphinx docs publishing

randy.macleod@...

nicolas.dechesne@...

3.3 M2

3.3 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW04!

Stephen Jolley
 

All,

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

Who

Count

anuj.mittal@...

2

akuster808@...

1

richard.purdie@...

1

david.reyna@...

1

Grand Total

5

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.3

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

35

ross@...

26

david.reyna@...

21

bluelightning@...

18

bruce.ashfield@...

15

akuster808@...

12

timothy.t.orling@...

12

mark.morton@...

11

JPEWhacker@...

11

kai.kang@...

10

sakib.sajal@...

10

trevor.gamblin@...

9

Qi.Chen@...

6

randy.macleod@...

5

raj.khem@...

5

mingli.yu@...

5

hongxu.jia@...

5

yi.zhao@...

4

idadelm@...

4

chee.yang.lee@...

4

stacygaikovaia@...

4

alejandro@...

3

mostthingsweb@...

3

ydirson@...

2

matthewzmd@...

2

jeanmarie.lemetayer@...

2

pokylinux@...

2

saul.wold@...

2

nicolas.dechesne@...

2

jaewon@...

2

anuj.mittal@...

2

yifan.yu@...

2

sangeeta.jain@...

2

dorindabassey@...

1

aehs29@...

1

mister_rs@...

1

kamensky@...

1

kergoth@...

1

jon.mason@...

1

shachar@...

1

pbarker@...

1

liezhi.yang@...

1

dl9pf@...

1

Martin.Jansa@...

1

twoerner@...

1

kexin.hao@...

1

joe.slater@...

1

mhalstead@...

1

matt.hoosier@...

1

mark.hatle@...

1

mshah@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Status WW04`21

Stephen Jolley
 

Current Dev Position: YP 3.3 M3 development

Next Deadline: 1st March 2021 YP 3.3 M3 build 

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3 M2 is currently in QA and we are now in the final development milestone M3 for 3.3
  • YP 3.1.5 was released.
  • We have a new simple system to help with the SWAT process, “SwatBot”, https://swatbot.yoctoproject.org/ . This aims to simplify the SWAT process by listing the exact list of issues which need to be triaged and tracks the resolutions. It will mainly be of use to anyone participating in the SWAT process but mentioned here as people may see mention of it.
  • Intermittent autobuilder issues continue to occur and with more invasive changes and higher rebuild rates, the numbers are increasing again. 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
  • An interesting idea came up in discussion with Kernel CI about potentially sharing YP autobuilder results into their system. There is an open bug for anyone interested in helping with or tracking this: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14196. It could also be an interesting use case for generating an SBOM with our output artefacts.

 

Ways to contribute:

 

YP 3.3 Milestone Dates:

  • YP 3.3 M2 built and in QA
  • YP 3.3 M2 Release date 2021/01/29
  • YP 3.3 M3 build date 2021/03/01
  • YP 3.3 M3 Release date 2021/03/12
  • YP 3.3 M4 build date 2021/04/05
  • YP 3.3 M4 Release date 2021/04/30

 

Planned upcoming dot releases:

  • YP 3.1.5 was released.
  • YP 3.2.2 build date 2021/02/08
  • YP 3.2.2 release date 2021/02/19
  • YP 3.1.6 build date 2021/02/22
  • YP 3.1.6 release date 2021/03/05
  • YP 3.1.7 build date 2021/03/22
  • YP 3.1.7 release date 2021/04/02

 

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@...

 


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 337 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-rockchip][PATCH v2] rock-pi-4: Split our variant machines

Joshua Watt
 

Splits out the three variants of the rock-pi-4 (A, B & C) into their own
machines. Unfortunately, it is not possible to have a single machine
that works for all three, as there isn't any known ways for the
bootloader to distinguish them. The old rock-pi-4 machine is kept around
for use with older kernels

Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
---
conf/machine/include/rk3399.inc | 2 +-
conf/machine/include/rock-pi-4.inc | 22 ++++++++++++++++++++++
conf/machine/rock-pi-4.conf | 22 ++++------------------
conf/machine/rock-pi-4a.conf | 11 +++++++++++
conf/machine/rock-pi-4b.conf | 11 +++++++++++
conf/machine/rock-pi-4c.conf | 11 +++++++++++
6 files changed, 60 insertions(+), 19 deletions(-)
create mode 100644 conf/machine/include/rock-pi-4.inc
create mode 100644 conf/machine/rock-pi-4a.conf
create mode 100644 conf/machine/rock-pi-4b.conf
create mode 100644 conf/machine/rock-pi-4c.conf

diff --git a/conf/machine/include/rk3399.inc b/conf/machine/include/rk3399.inc
index 4019988..f6b7826 100644
--- a/conf/machine/include/rk3399.inc
+++ b/conf/machine/include/rk3399.inc
@@ -5,8 +5,8 @@ SOC_FAMILY = "rk3399"

DEFAULTTUNE ?= "cortexa72-cortexa53-crypto"

-require conf/machine/include/tune-cortexa72-cortexa53.inc
require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa72-cortexa53.inc
require conf/machine/include/rockchip-defaults.inc

KBUILD_DEFCONFIG ?= "defconfig"
diff --git a/conf/machine/include/rock-pi-4.inc b/conf/machine/include/rock-pi-4.inc
new file mode 100644
index 0000000..9c21084
--- /dev/null
+++ b/conf/machine/include/rock-pi-4.inc
@@ -0,0 +1,22 @@
+# Add a common override for all Rock Pi 4 machines
+MACHINEOVERRIDES =. "rock-pi-4:"
+
+require conf/machine/include/rk3399.inc
+
+RK_BOOT_DEVICE = "mmcblk1"
+WKS_FILE ?= "rock-pi-4.wks"
+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/rock-pi-4.conf b/conf/machine/rock-pi-4.conf
index 5231abf..23bbfc3 100644
--- a/conf/machine/rock-pi-4.conf
+++ b/conf/machine/rock-pi-4.conf
@@ -4,26 +4,12 @@
#@TYPE: Machine
#@NAME: Rock Pi 4 RK3399
#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+#
+# NOTE: This machine is for Kernels before 5.10. If you are using an newer kernel
+# see rock-pi-4{a,b,c}.conf

-require conf/machine/include/rk3399.inc
+require conf/machine/include/rock-pi-4.inc

KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4.dtb"
UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"

-RK_BOOT_DEVICE = "mmcblk1"
-WKS_FILE ?= "rock-pi-4.wks"
-IMAGE_FSTYPES += "wic wic.bmap"
-
-WKS_FILE_DEPENDS ?= " \
- mtools-native \
- dosfstools-native \
- virtual/bootloader \
- virtual/kernel \
- "
-IMAGE_BOOT_FILES ?= "\
- ${KERNEL_IMAGETYPE} \
- "
-
-SERIAL_CONSOLES = "1500000;ttyS2"
-
-MACHINE_EXTRA_RRECOMMENDS += "kernel-modules"
diff --git a/conf/machine/rock-pi-4a.conf b/conf/machine/rock-pi-4a.conf
new file mode 100644
index 0000000..abe2336
--- /dev/null
+++ b/conf/machine/rock-pi-4a.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4A RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+#
+# NOTE: This machine is for Kernel 5.10 and later. If you are using an older
+# kernel, see rock-pi-4.conf
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4a.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4b.conf b/conf/machine/rock-pi-4b.conf
new file mode 100644
index 0000000..587fb32
--- /dev/null
+++ b/conf/machine/rock-pi-4b.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4B RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+#
+# NOTE: This machine is for Kernel 5.10 and later. If you are using an older
+# kernel, see rock-pi-4.conf
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4b.dtb"
+UBOOT_MACHINE = "rock-pi-4-rk3399_defconfig"
diff --git a/conf/machine/rock-pi-4c.conf b/conf/machine/rock-pi-4c.conf
new file mode 100644
index 0000000..3af26ff
--- /dev/null
+++ b/conf/machine/rock-pi-4c.conf
@@ -0,0 +1,11 @@
+#@TYPE: Machine
+#@NAME: Rock Pi 4C RK3399
+#@DESCRIPTION: Rock Pi 4 is a Raspberry Pi 4 Alternative based on Rockchip RK3399 Processor.
+#
+# NOTE: This machine is for Kernel 5.10 and later. If you are using an older
+# kernel, see rock-pi-4.conf
+
+require conf/machine/include/rock-pi-4.inc
+
+KERNEL_DEVICETREE = "rockchip/rk3399-rock-pi-4c.dtb"
+UBOOT_MACHINE = "rock-pi-4c-rk3399_defconfig"
--
2.30.0


Re: [meta-rockchip][PATCH] rock-pi-4: Split our variant machinesy

Joshua Watt
 

On Mon, Jan 25, 2021 at 5:15 PM Trevor Woerner <twoerner@gmail.com> wrote:

Is there any way to make this work with both new (4.10, -dev, -tiny, -rt) and
old (5.4) kernels? What if we left the old rock-pi-4 MACHINE for the 5.4
kernel and required one of the new ones for 5.10?
Ya, we can keep the old machine around for the old kernels


OpenEmbedded Happy Hour January 27 5pm/1700 UTC

Denys Dmytriyenko
 

Hi,

Just a reminder about our upcoming OpenEmbedded Happy Hour on January 27 for
Europe/US timezones @ 1700/5pm UTC (12pm ET):

https://www.openembedded.org/wiki/Calendar
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OpenEmbedded+Happy+Hour+January+27&iso=20210127T17

--
Regards,
Denys Dmytriyenko <denis@denix.org>
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964


Re: [meta-rockchip][PATCH] rock-pi-4: Split our variant machinesy

Trevor Woerner
 

Is there any way to make this work with both new (4.10, -dev, -tiny, -rt) and
old (5.4) kernels? What if we left the old rock-pi-4 MACHINE for the 5.4
kernel and required one of the new ones for 5.10?

1401 - 1420 of 53484