Date   

M+ & H bugs with Milestone Movements WW24

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

3362

Improve dependency analysis tools

richard.purdie@...

newcomer@...

Future

3.99

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW23!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

2

ross@...

1

JPEWhacker@...

1

liezhi.yang@...

1

richard.purdie@...

1

Grand Total

6

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 WW24 of who have open medium or higher bugs and enhancements against YP 3.4.   There are 96 possible work days left until the final release candidates for YP 3.4 needs to be released.

Who

Count

richard.purdie@...

32

ross@...

31

michael.opdenacker@...

22

david.reyna@...

22

bruce.ashfield@...

21

bluelightning@...

12

akuster808@...

12

timothy.t.orling@...

11

trevor.gamblin@...

11

JPEWhacker@...

11

sakib.sajal@...

10

kai.kang@...

9

randy.macleod@...

9

hongxu.jia@...

6

Qi.Chen@...

6

mingli.yu@...

6

chee.yang.lee@...

5

raj.khem@...

5

tony.tascioglu@...

5

yi.zhao@...

4

alexandre.belloni@...

3

mostthingsweb@...

3

yf3yu@...

2

mshah@...

2

pokylinux@...

2

ydirson@...

2

jaewon@...

2

alejandro@...

2

yoctoproject@...

1

naveen.kumar.saini@...

1

kergoth@...

1

Martin.Jansa@...

1

stacygaikovaia@...

1

dl9pf@...

1

liezhi.yang@...

1

open.source@...

1

weaverjs@...

1

nicolas.dechesne@...

1

kexin.hao@...

1

mark.hatle@...

1

mister_rs@...

1

jon.mason@...

1

john.kaldas.enpj@...

1

jeanmarie.lemetayer@...

1

devendra.tewari@...

1

aehs29@...

1

diego.sueiro@...

1

matthewzmd@...

1

thomas.perrot@...

1

saul.wold@...

1

douglas.royds@...

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

 


Re: [meta-java] icedtea7 fetching error

Richard Purdie
 

On Mon, 2021-06-14 at 21:31 +0000, Richard Leitner - SKIDATA wrote:
On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:
On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.
Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!
In theory if these are the names the metadata was using and you have the standard
OE/Yocto source mirrors, this should "just work"...

Cheers,

Richard


Re: [meta-java] icedtea7 fetching error

Richard Leitner
 

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:
On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.
Thank you very much Richard!
The openjdk8 tarballs are now hosted at https://downloads.yoctoproject.org/mirror/sources/
with their local download names.

Unfortunately I currently don't have the time and resources to provide a
patch for fixing the URLs and adding the mirror.
So help is greatly appreciated!

regards;rl


Cheers,

Richard


Re: [meta-java] icedtea7 fetching error

Richard Leitner
 

On Mon, Jun 14, 2021 at 09:29:05PM +0100, Richard Purdie wrote:
On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.
Thanks for that!

I'm currently uploading the tarballs and provide you the link as soon as
it's finished (sorry, really crappy uplink here 😕)

It's about 1GiB with following files affected:

openjdk8-242-corba-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-corba-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-corba-jdk8u242-ga.tar.bz2
openjdk8-242-hotspot-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-hotspot-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-hotspot-jdk8u242-ga.tar.bz2
openjdk8-242-jaxp-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jaxp-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jaxp-jdk8u242-ga.tar.bz2
openjdk8-242-jaxws-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jaxws-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jaxws-jdk8u242-ga.tar.bz2
openjdk8-242-jdk8u-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jdk8u-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jdk8u-jdk8u242-ga.tar.bz2
openjdk8-242-jdk-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-jdk-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-jdk-jdk8u242-ga.tar.bz2
openjdk8-242-langtools-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-langtools-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-langtools-jdk8u242-ga.tar.bz2
openjdk8-242-nashorn-aarch64-shenandoah-jdk8u242-b07.tar.bz2
openjdk8-242-nashorn-jdk8u242-ga-aarch32-200120.tar.bz2
openjdk8-242-nashorn-jdk8u242-ga.tar.bz2
openjdk8-252-corba-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-corba-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-corba-jdk8u252-ga.tar.bz2
openjdk8-252-hotspot-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-hotspot-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-hotspot-jdk8u252-ga.tar.bz2
openjdk8-252-jaxp-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jaxp-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jaxp-jdk8u252-ga.tar.bz2
openjdk8-252-jaxws-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jaxws-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jaxws-jdk8u252-ga.tar.bz2
openjdk8-252-jdk8u-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jdk8u-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jdk8u-jdk8u252-ga.tar.bz2
openjdk8-252-jdk-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-jdk-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-jdk-jdk8u252-ga.tar.bz2
openjdk8-252-langtools-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-langtools-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-langtools-jdk8u252-ga.tar.bz2
openjdk8-252-nashorn-aarch64-shenandoah-jdk8u252-b09.tar.bz2
openjdk8-252-nashorn-jdk8u252-ga-aarch32-20200415.tar.bz2
openjdk8-252-nashorn-jdk8u252-ga.tar.bz2
openjdk8-265-corba-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-corba-jdk8u265-ga.tar.bz2
openjdk8-265-hotspot-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-hotspot-jdk8u265-ga.tar.bz2
openjdk8-265-jaxp-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jaxp-jdk8u265-ga.tar.bz2
openjdk8-265-jaxws-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jaxws-jdk8u265-ga.tar.bz2
openjdk8-265-jdk8u-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jdk8u-jdk8u265-ga.tar.bz2
openjdk8-265-jdk-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-jdk-jdk8u265-ga.tar.bz2
openjdk8-265-langtools-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-langtools-jdk8u265-ga.tar.bz2
openjdk8-265-nashorn-jdk8u265-ga-aarch32-20200729.tar.bz2
openjdk8-265-nashorn-jdk8u265-ga.tar.bz2
openjdk8-272-corba-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-corba-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-corba-jdk8u272-ga.tar.bz2
openjdk8-272-hotspot-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-hotspot-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-hotspot-jdk8u272-ga.tar.bz2
openjdk8-272-jaxp-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jaxp-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jaxp-jdk8u272-ga.tar.bz2
openjdk8-272-jaxws-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jaxws-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jaxws-jdk8u272-ga.tar.bz2
openjdk8-272-jdk8u-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jdk8u-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jdk8u-jdk8u272-ga.tar.bz2
openjdk8-272-jdk-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-jdk-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-jdk-jdk8u272-ga.tar.bz2
openjdk8-272-langtools-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-langtools-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-langtools-jdk8u272-ga.tar.bz2
openjdk8-272-nashorn-aarch64-shenandoah-jdk8u272-b10.tar.bz2
openjdk8-272-nashorn-jdk8u272-b09-aarch32-20200929.tar.bz2
openjdk8-272-nashorn-jdk8u272-ga.tar.bz2
openjdk8-292-corba-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-corba-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-corba-jdk8u292-ga.tar.bz2
openjdk8-292-hotspot-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-hotspot-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-hotspot-jdk8u292-ga.tar.bz2
openjdk8-292-jaxp-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jaxp-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jaxp-jdk8u292-ga.tar.bz2
openjdk8-292-jaxws-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jaxws-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jaxws-jdk8u292-ga.tar.bz2
openjdk8-292-jdk8u-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jdk8u-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jdk8u-jdk8u292-ga.tar.bz2
openjdk8-292-jdk-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-jdk-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-jdk-jdk8u292-ga.tar.bz2
openjdk8-292-langtools-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-langtools-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-langtools-jdk8u292-ga.tar.bz2
openjdk8-292-nashorn-aarch64-shenandoah-jdk8u292-b10.tar.bz2
openjdk8-292-nashorn-jdk8u292-ga-aarch32-20210423.tar.bz2
openjdk8-292-nashorn-jdk8u292-ga.tar.bz2
icedtea-2.1.3.tar.gz



Cheers,

Richard
regards;rl


Re: [meta-java] icedtea7 fetching error

Richard Purdie
 

On Mon, 2021-06-14 at 20:20 +0000, Richard Leitner - SKIDATA wrote:
On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?
If someone points me at the tarballs I can probably sort something out with
our source mirrors.

Cheers,

Richard


Re: [meta-java] icedtea7 fetching error

Richard Leitner
 

On Thu, Jun 10, 2021 at 10:57:46AM +0200, Alexander Kanavin wrote:
I have the tarball. I think we should toss it somewhere safe and update the
recipe, as it is unlikely the old mercurial repo is coming back.

Suggestions?
Sorry for the late reply, I was on vacation 😉.

Nothing that comes to my mind directly. Do you know of any hosting
possibilites from YP or OE-Core?

@Richard: Sorry for putting you in that conversation without warning...
But maybe you may guide us in a direction where to host/mirror some "legacy"
meta-java source tarballs?

regards;rl


Alex

On Tue, 8 Jun 2021 at 08:10, <George.Mocanu@...> wrote:

Hello,


I am trying to build something that relies on meta-java, but it fails on
do_fetch for the icedtea7 recipe:

--2021-06-07 17:24:33-- http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2
Resolving icedtea.classpath.org (icedtea.classpath.org)... 172.104.137.120
Connecting to icedtea.classpath.org (icedtea.classpath.org)|172.104.137.120|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2021-06-07 16:21:05 ERROR 404: Not Found.

ERROR: icedtea7-native-2.1.3-r1.0 do_fetch: Fetcher failure for URL: 'http://icedtea.classpath.org/hg/release/icedtea7-forest-2.1/archive/f89009ada191.tar.bz2;name=openjdk;unpack=false;downloadfilename=openjdk-f89009ada191.tar.bz2'. Unable to fetch URL from any source.


Following this link, seems like the webserver is down. Do you know any
mirror that I can use in the meantime?

Thanks,
George




Re: [meta-rockchip][PATCH v2] Rock64: add machine

Trevor Woerner
 

Hi Yann,

Thanks for the contribution!

On Mon 2021-05-31 @ 04:00:58 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>

This is a RK3328 board from Pine64.
Board details at https://wiki.pine64.org/wiki/ROCK64.

Default image is built to boot from SD-card. Building an image for
eMMC requires to set RK_BOOT_DEVICE="mmcblk0".

Signed-off-by: Yann Dirson <yann@...>
---

This is just basic initial support without a kernel BSP. As is the
board boots with a serial console.

Note I had to create the SoC definition for rk3328, and rather than
setting serial at 115200 there just to have the board definition
override it with rockchip-standard 1500000 I've set the latter right
in rk3328.inc.
Sounds good. I prefer the rockchip default of 1,500,000 anyway.


Changes in v2:
- include Ayufan's patch for mmc aliases so presence of eMMC won't
prevent booting from SD

conf/machine/include/rk3328.inc | 25 ++++++++++++++++
conf/machine/rock64.conf | 30 +++++++++++++++++++
...an-dtsi-rk3328-add-mmc0-mmc1-aliases.patch | 27 +++++++++++++++++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++++
4 files changed, 88 insertions(+)
create mode 100644 conf/machine/include/rk3328.inc
create mode 100644 conf/machine/rock64.conf
create mode 100644 recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch

diff --git a/conf/machine/include/rk3328.inc b/conf/machine/include/rk3328.inc
new file mode 100644
index 0000000..7d67627
--- /dev/null
+++ b/conf/machine/include/rk3328.inc
@@ -0,0 +1,25 @@
+# Copyright (C) 2020 Garmin Ltd. or its subsidaries
Odd that you'd be assigning the copyright to Garmin ;-)

+# Released under the MIT license (see COPYING.MIT for the terms)
+
+SOC_FAMILY = "rk3328"
+
+DEFAULTTUNE ?= "cortexa53-crypto"
+
+require conf/machine/include/soc-family.inc
+require conf/machine/include/tune-cortexa53.inc
+require conf/machine/include/rockchip-defaults.inc
+
+KBUILD_DEFCONFIG ?= "defconfig"
+KERNEL_CLASSES = "kernel-fitimage"
+KERNEL_IMAGETYPE = "fitImage"
+
+TFA_PLATFORM = "rk3328"
+TFA_BUILD_TARGET = "bl31"
+
+UBOOT_SUFFIX ?= "itb"
+UBOOT_ENTRYPOINT ?= "0x06000000"
+
+SERIAL_CONSOLES = "1500000;ttyS2"
+
+PREFERRED_PROVIDER_virtual/bootloader ?= "u-boot"
+SPL_BINARY ?= "idbloader.img"
diff --git a/conf/machine/rock64.conf b/conf/machine/rock64.conf
new file mode 100644
index 0000000..38bc9fa
--- /dev/null
+++ b/conf/machine/rock64.conf
@@ -0,0 +1,30 @@
+# Copyright (C) 2021 Blade SAS
Can you also specify an OSS-friendly licence too?

+
+#@TYPE: Machine
+#@NAME: Rock64
+#@DESCRIPTION: Rock64 RK3328 board from Pine64
+
+require include/rk3328.inc
+
+MACHINE_FEATURES += "usbhost serial"
+
+UBOOT_MACHINE = "rock64-rk3328_defconfig"
+KERNEL_DEVICETREE = "rockchip/rk3328-rock64.dtb"
+
+# set to mmcblk0 for booting from optional eMMC
+RK_BOOT_DEVICE ?= "mmcblk1"
+
+WKS_FILE ?= "rock-pi-4.wks"
Personally I'd prefer to see a rock64 wic file which includes an rk3328
default, even if it is a copy of the rock-pi-4 layout.

+IMAGE_FSTYPES += "wic wic.bmap"
+
+WKS_FILE_DEPENDS ?= " \
+ mtools-native \
+ dosfstools-native \
+ virtual/bootloader \
+ virtual/kernel \
+ "
+IMAGE_BOOT_FILES ?= "\
+ ${KERNEL_IMAGETYPE} \
+ "
+
+KBUILD_DEFCONFIG = "defconfig"
diff --git a/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
new file mode 100644
index 0000000..1ad3b9e
--- /dev/null
+++ b/recipes-kernel/linux/files/0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch
@@ -0,0 +1,27 @@
+From f10cfe01f753348d346374008b8e8f5f26ed94ab Mon Sep 17 00:00:00 2001
+From: Kamil Trzcinski <ayufan@...>
+Date: Mon, 28 Aug 2017 11:24:37 +0200
+Subject: [PATCH] ayufan: dtsi: rk3328: add mmc0/mmc1 aliases
+Upstream-Status: Pending [https://github.com/ayufan-rock64/linux-mainline-kernel/commit/f10cfe01f753348d346374008b8e8f5f26ed94ab]
+
+Change-Id: I82a5394df8a505f7d1496393621c1198895c88b0
+---
+ arch/arm64/boot/dts/rockchip/rk3328.dtsi | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+index 0afed15bc7ff..800f1c796882 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+@@ -27,6 +27,8 @@
+ i2c1 = &i2c1;
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
++ mmc0 = &emmc;
++ mmc1 = &sdmmc;
+ ethernet0 = &gmac2io;
+ ethernet1 = &gmac2phy;
+ };
+--
+2.30.2
+
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend
index 7702e3f..3789c72 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -8,3 +8,9 @@ COMPATIBLE_MACHINE_tinker-board-s = "tinker-board-s"
COMPATIBLE_MACHINE_rock-pi-4 = "rock-pi-4"
COMPATIBLE_MACHINE_nanopi-m4 = "nanopi-m4"
COMPATIBLE_MACHINE_nanopi-m4-2gb = "nanopi-m4-2gb"
+COMPATIBLE_MACHINE_rock64 = "rock64"
+
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
+# indeed applicable to all rk3328 boards
I have a roc-rk3328-cc ("renegade") board I should investigate adding. Then I
can see if this applies there as well.

+SRC_URI_append_rock64 = " file://0001-ayufan-dtsi-rk3328-add-mmc0-mmc1-aliases.patch"
--
2.30.2


Re: thoughts on YP-friendly developer laptop?

Adrian Bunk
 

On Mon, Jun 14, 2021 at 07:58:19AM -0400, Robert P. J. Day wrote:

starting to think about a new laptop that will, among other things,
do lots of OE/YP builds, and i'll start with this as the basis for a
few questions about hard drives:

https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e

while an SSD would be delightful, i'm concerned about how doing
frequent 40-50G builds would wear out an SSD. so i was considering
looking for something with a fast regular HD for the actual build
directories, but room to put in an M.2 NVMe that would hold fairly
static content, like the OS itself, all the layers, a local source
mirror and so on.

am i overthinking this? anyone have a laptop setup that is smokin'
fast (yeah, 8 core AMD ryzen :-),
When using a laptop with only 16 GB RAM to build with 8 or 16 threads,
on what drive will the heavily used large swap partition be?

gcc loves to use > 2 GB RAM for non-trivial C++ code,
with 16 threads I'd recommend 64 GB RAM.

and a dual drive layout that seems
to work well with lots and lots of OE builds?
Ask for the specs of the SSD and do the math.

E.g. 150 TBW / 50 GB/build = 3000 builds

If you are building from scratch so often that the resulting number
is a worry, I'd rather buy 128 GB RAM and use a tmpfs instead of
creating a spinning rust bottleneck.

rday
cu
Adrian


Re: thoughts on YP-friendly developer laptop?

Jack Mitchell
 

- Ryzen based for core count
- No dedicated GPU as more wattage available for CPU + less heat for cpu
boosting
- Dual NVMe slots, or at least on-board emmc + NVMe slot, hold tmp in
NVMe, replace if it dies. Probably not going to be an issue, I have a
1TB NVMe drive which I've been doing multiple daily builds on for 2
years which is still at 99% health.

For a decent manufacturer? Dell aren't recommended at the moment as the
QA due to pandemic conditions is lacking and machines are arriving
broken. HP do some decent Ryzen based laptops, as do Lenovo. For a wild
card you can also check out System76 but they're just OEM rebrands.

Good luck, it's a minefield out there.

Regards,
Jack

On 14/06/2021 12:58, Robert P. J. Day wrote:

starting to think about a new laptop that will, among other things,
do lots of OE/YP builds, and i'll start with this as the basis for a
few questions about hard drives:

https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e

while an SSD would be delightful, i'm concerned about how doing
frequent 40-50G builds would wear out an SSD. so i was considering
looking for something with a fast regular HD for the actual build
directories, but room to put in an M.2 NVMe that would hold fairly
static content, like the OS itself, all the layers, a local source
mirror and so on.

am i overthinking this? anyone have a laptop setup that is smokin'
fast (yeah, 8 core AMD ryzen :-), and a dual drive layout that seems
to work well with lots and lots of OE builds?

rday




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


thoughts on YP-friendly developer laptop?

Robert P. J. Day
 

starting to think about a new laptop that will, among other things,
do lots of OE/YP builds, and i'll start with this as the basis for a
few questions about hard drives:

https://www.dell.com/en-ca/shop/gaming-laptops/g15-ryzen-edition-gaming-laptop/spd/g-series-15-5515-laptop/ng155515_sb_ps25e

while an SSD would be delightful, i'm concerned about how doing
frequent 40-50G builds would wear out an SSD. so i was considering
looking for something with a fast regular HD for the actual build
directories, but room to put in an M.2 NVMe that would hold fairly
static content, like the OS itself, all the layers, a local source
mirror and so on.

am i overthinking this? anyone have a laptop setup that is smokin'
fast (yeah, 8 core AMD ryzen :-), and a dual drive layout that seems
to work well with lots and lots of OE builds?

rday


Re: QEMU Size Increase from Yocto Thud to Zeus

Zoran
 

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.
Does it mean that with the local.conf line:

# enable,disable,depends,rdepends
#
PACKAGECONFIG[qemu] = "--with-qemu,--without-qemu,qemu,"

The QEMU is completely removed (this is all that needs to be done, or...)?

Thank you,
Zee
_______

On Mon, Jun 14, 2021 at 12:14 PM Ross Burton <ross@...> wrote:

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Ross

On Mon, 14 Jun 2021 at 09:04, Aashik Aswin <thisisaash9698@...> wrote:

Thanks for the clarification, yes I am installing QEMU in my image. Is there some way that we can disable the additional architectures and streamline the size ?

Thanks

On Fri, Jun 11, 2021 at 8:48 PM Ross Burton <ross@...> wrote:

Are you installing qemu into your image though?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

On Fri, 11 Jun 2021 at 11:40, Aashik Aswin <thisisaash9698@...> wrote:

Hi Experts,

I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.

Thud (4.19) - 223084 KiB qemu
Zeus (5.4) - 474757 KiB qemu

Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?

Appreciate your help.

TIA,
Aashik




Re: QEMU Size Increase from Yocto Thud to Zeus

Ross Burton <ross@...>
 

Yes, look at the PACKAGECONFIGs and setting QEMU_TARGETS.

Ross

On Mon, 14 Jun 2021 at 09:04, Aashik Aswin <thisisaash9698@...> wrote:

Thanks for the clarification, yes I am installing QEMU in my image. Is there some way that we can disable the additional architectures and streamline the size ?

Thanks

On Fri, Jun 11, 2021 at 8:48 PM Ross Burton <ross@...> wrote:

Are you installing qemu into your image though?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

On Fri, 11 Jun 2021 at 11:40, Aashik Aswin <thisisaash9698@...> wrote:

Hi Experts,

I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.

Thud (4.19) - 223084 KiB qemu
Zeus (5.4) - 474757 KiB qemu

Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?

Appreciate your help.

TIA,
Aashik



Re: [meta-java] icedtea7 fetching error

marvin.franke@...
 

Hello,

you can use wildebeest's mirror:

ICEDTEA_HG_URL = "http://icedtea.wildebeest.org/hg/release/${ICEDTEA_PREFIX}"

Marvin


Re: [meta-zephyr][PATCH v2 1/2] zephyr-kernel: Add OpenThread add module to build

Stefan Schmidt
 

Hello.

On 11.06.21 03:26, Saini, Naveen Kumar wrote:

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Stefan Schmidt
Sent: Thursday, June 10, 2021 4:28 PM
To: yocto@...
Cc: Stefan Schmidt <stefan@...>; Stefan Schmidt
<stefan.schmidt@...>
Subject: [yocto] [meta-zephyr][PATCH v2 1/2] zephyr-kernel: Add
OpenThread add module to build

From: Stefan Schmidt <stefan.schmidt@...>

OpenThread support in Zephyr is realised as an external module. Make sure
we pull it in and have it available for applications to use it.

Signed-off-by: Stefan Schmidt <stefan.schmidt@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 1 +
3 files changed, 3 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 330fe59..35c4106 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -29,6 +29,7 @@ ZEPHYR_MODULES_append_arm =
"\;${S}/modules/cmsis"
ZEPHYR_MODULES_append_nordic = "\;${S}/modules/hal/nordic"
ZEPHYR_MODULES_append_stm32 = "\;${S}/modules/hal/stm32"
ZEPHYR_MODULES_append_openamp = "\;${S}/modules/lib/open-
amp\;${S}/modules/hal/libmetal"
+ZEPHYR_MODULES_append_openthread =
"\;${S}/modules/lib/openthread"
This is not required. It already listed in required sample recipe. Please remove it.
Fixed.


EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
index 8475b5b..4910db2 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
@@ -4,6 +4,7 @@ SRCREV_cmsis =
"c3bd2094f92d574377f7af2aec147ae181aa5f8e"
SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-
kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5e43583..4937a77 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -15,6 +15,7 @@ SRC_URI = "\
git://github.com/zephyrproject-
rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=
stm32 \
git://github.com/zephyrproject-
rtos/mbedtls.git;protocol=https;destsuffix=git/modules/lib/mbedtls;name=
mbedtls \
git://github.com/zephyrproject-rtos/open-
amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-
amp \
+
+ git://github.com/zephyrproject-rtos/openthread.git;protocol=https;bran
+ ch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
git://github.com/zephyrproject-
It would cause build failure with v2.5.0. So add SRCREV_openthread in zephyr-kernel-src-2.5.0.inc too.
Indeed, I did not test with 2.5. Thanks for spotting. Fixed.

I send a v3 now.

regards
Stefan Schmidt


[meta-zephyr][PATCH v3 2/2] zephyr-openthread-echo-client: Add new echo-client variant for OpenThread

Stefan Schmidt
 

From: Stefan Schmidt <stefan.schmidt@...>

Similar to the normal echo-client example it demonstrates socket usage,
but in this variant we enable the OpenThread config overlay and add the
needed module to the build.

Signed-off-by: Stefan Schmidt <stefan.schmidt@...>
---
.../zephyr-kernel/zephyr-openthread-echo-client.bb | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-openthread-echo-c=
lient.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-openthread-echo-client.b=
b b/recipes-kernel/zephyr-kernel/zephyr-openthread-echo-client.bb
new file mode 100644
index 0000000..c985df2
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-openthread-echo-client.bb
@@ -0,0 +1,8 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR =3D "${S}/samples/net/sockets/echo_client"
+
+ZEPHYR_MODULES_append =3D "\;${S}/modules/lib/mbedtls"
+ZEPHYR_MODULES_append =3D "\;${S}/modules/lib/openthread"
+
+EXTRA_OECMAKE +=3D "-DOVERLAY_CONFIG=3Doverlay-ot.conf"
--=20
2.31.1


[meta-zephyr][PATCH v3 1/2] zephyr-kernel: Add OpenThread add module to build

Stefan Schmidt
 

From: Stefan Schmidt <stefan.schmidt@...>

OpenThread support in Zephyr is realised as an external module. Make
sure we pull it in and have it available for applications to use it.

Signed-off-by: Stefan Schmidt <stefan.schmidt@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 1 +
3 files changed, 3 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/r=
ecipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 545197f..9cdc721 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -4,6 +4,7 @@ SRCREV_cmsis =3D "c3bd2094f92d574377f7af2aec147ae181aa5f8=
e"
SRCREV_nordic =3D "f3434da6446380fcdd426dbe2866af21d0d549b6"
SRCREV_stm32 =3D "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635"
SRCREV_open-amp =3D "de1b85a13032a2de1d8b6695ae5f800b613e739d"
+SRCREV_openthread =3D "385e19da1ae15f27872c2543b97276a42f102ead"
SRCREV_libmetal =3D "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt =3D "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
SRCREV_mbedtls =3D "24d84ecff195fb15c889d9046e44e4804d626c67"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc b/r=
ecipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
index 8475b5b..4910db2 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
@@ -4,6 +4,7 @@ SRCREV_cmsis =3D "c3bd2094f92d574377f7af2aec147ae181aa5f8=
e"
SRCREV_nordic =3D "574493fe29c79140df4827ab5d4a23df79d03681"
SRCREV_stm32 =3D "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
SRCREV_open-amp =3D "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread =3D "385e19da1ae15f27872c2543b97276a42f102ead"
SRCREV_libmetal =3D "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_tinycrypt =3D "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
SRCREV_mbedtls =3D "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes=
-kernel/zephyr-kernel/zephyr-kernel-src.inc
index d65cc06..fb62cae 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -15,6 +15,7 @@ SRC_URI =3D "\
git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=3Dhttps;d=
estsuffix=3Dgit/modules/hal/stm32;name=3Dstm32 \
git://github.com/zephyrproject-rtos/mbedtls.git;protocol=3Dhttps;des=
tsuffix=3Dgit/modules/lib/mbedtls;name=3Dmbedtls \
git://github.com/zephyrproject-rtos/open-amp.git;protocol=3Dhttps;de=
stsuffix=3Dgit/modules/lib/open-amp;name=3Dopen-amp \
+ git://github.com/zephyrproject-rtos/openthread.git;protocol=3Dhttps;=
branch=3Dzephyr;destsuffix=3Dgit/modules/lib/openthread;name=3Dopenthread=
\
git://github.com/zephyrproject-rtos/libmetal.git;protocol=3Dhttps;de=
stsuffix=3Dgit/modules/hal/libmetal;name=3Dlibmetal \
git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=3Dhttps;d=
estsuffix=3Dgit/modules/crypto/tinycrypt;name=3Dtinycrypt \
file://0001-cmake-add-yocto-toolchain.patch \
--=20
2.31.1


Re: QEMU Size Increase from Yocto Thud to Zeus

Aashik Aswin
 

Thanks for the clarification, yes I am installing QEMU in my image. Is there some way that we can disable the additional architectures and streamline the size ?

Thanks

On Fri, Jun 11, 2021 at 8:48 PM Ross Burton <ross@...> wrote:
Are you installing qemu into your image though?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

On Fri, 11 Jun 2021 at 11:40, Aashik Aswin <thisisaash9698@...> wrote:
>
> Hi Experts,
>
> I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
> On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.
>
> Thud (4.19) - 223084  KiB     qemu
> Zeus (5.4) - 474757  KiB     qemu
>
> Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?
>
> Appreciate your help.
>
> TIA,
> Aashik
>
>
>

3581 - 3600 of 57416