|
Re: FYI: Why people are using #hashtags in yocto email subjects.
#hashtags
Nicolas Dechesne
On Thu, Apr 16, 2020 at 9:36 PM Denys Dmytriyenko < denis@...> wrote: I doubt people that actually send emails to the list use #hashtags.
But the new list server provides this posting feature for anyone to address
the list and requests poster to add #hashtags - very annoying, indeed:
https://lists.yoctoproject.org/g/yocto/post
there is that. And looking at the history on the server, most of the existing tags came from the web. But a hashtag is created automatically when using '#' in the email subject. that's how #define was created:
and this email created #hashtags ;-)
I haven't found a way to disable it.. from what I can see we can 1. force every message to have at least one hashtag...
2. bounce message with a new hashtag in $subject
3. remove new hashtag when used in $subject
I think we will need to do some tests to see what #3 does.. But in any case, I don't think we can prevent users from creating hashtags from the web..
Is that causing any issues with patches workflow?
--
Denys
On Thu, Apr 16, 2020 at 03:18:34PM -0400, Randy MacLeod wrote:
> FYI:
>
> I don't know if I missed the memo/tweet about the email archive feature
> but I just noticed that the new archive site will index emails
> by hashtag:
>
> https://lists.yoctoproject.org/g/yocto
>
> https://lists.yoctoproject.org/g/yocto/hashtags
>
> I thought it was an annoying new behaviour coming from Twitter users
> but now I understand why there are hashtags on my lawn^Hsubject lines.
>
> ;-)
>
> --
> # Randy MacLeod
> # Wind River Linux
>
|
|
|
Re: Guidance Downgrading Python2 in Zeus
#python
MikeB
Thank you all. The new layer did the trick for me also.
Regards, Mike
FYI, we’re doing the same internally (vendor supplied FIPS supported openssl 1.0.2), and the layer Armin suggests worked for us on zeus with minimal additional tweaking.
Good luck!
-Sean
On 4/15/20 9:16 AM, MikeB wrote:
I'm working on a set of platforms that have a FIPs certified OpenSSL. We are at version 1.0.2l.
I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).
We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).
I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).
I know how to downgrade simple recipes, but python is far from simple.
Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?
Have had a chance to look at this layer?
http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/
- armin
Thanks, Mike
|
|
|
[meta-cgl][PATCH] initramfs-cgl-boot: Use common MIT license
Jeremy Puhlman
From: Jeremy Puhlman <jpuhlman@...>
Signed-off-by: Jeremy A. Puhlman <jpuhlman@...>
---
.../recipes-core/initrdscripts/initramfs-cgl-boot_1.0.bb | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boo=
t_1.0.bb b/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boot_=
1.0.bb
index 1a2dd1d..8b1768a 100644
--- a/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boot_1.0.b=
b
+++ b/meta-cgl-common/recipes-core/initrdscripts/initramfs-cgl-boot_1.0.b=
b
@@ -1,8 +1,7 @@
SUMMARY =3D "Support for having multipath iSCSI devices as root file sys=
tem"
LICENSE =3D "MIT"
-LIC_FILES_CHKSUM =3D "file://../COPYING.MIT;md5=3D838c366f69b72c5df05c96=
dff79b35f2"
+LIC_FILES_CHKSUM =3D "file://${COREBASE}/meta/COPYING.MIT;md5=3D3da9cfbc=
b788c80a0384361b4de20420"
SRC_URI =3D "file://init-boot.sh \
- file://COPYING.MIT \
"
=20
do_install() {
--=20
2.20.1
|
|
|
Re: FYI: Why people are using #hashtags in yocto email subjects.
#hashtags
I doubt people that actually send emails to the list use #hashtags. But the new list server provides this posting feature for anyone to address the list and requests poster to add #hashtags - very annoying, indeed: https://lists.yoctoproject.org/g/yocto/post-- Denys
On Thu, Apr 16, 2020 at 03:18:34PM -0400, Randy MacLeod wrote: FYI:
I don't know if I missed the memo/tweet about the email archive feature
but I just noticed that the new archive site will index emails
by hashtag:
https://lists.yoctoproject.org/g/yocto
https://lists.yoctoproject.org/g/yocto/hashtags
I thought it was an annoying new behaviour coming from Twitter users
but now I understand why there are hashtags on my lawn^Hsubject lines.
;-)
--
# Randy MacLeod
# Wind River Linux
|
|
|
FYI: Why people are using #hashtags in yocto email subjects.
#hashtags
Randy MacLeod
|
|
|
Re: Building gutenprint recipe
Randy MacLeod
On 2018-07-07 6:02 a.m., Timm wrote: There was a gutenprint recipe back in OE-Classic:
https://layers.openembedded.org/layerindex/oe-classic/recipe/12076/
But currently there is no gutenprint available for Yocto. Timm, Did you ever get the gutenprint recipe to work? Are you able to add it to meta-oe or share what you have done so far here? ../Randy I tried to build my own recipe. But I got stuck at the stage where the
build process wants to call some generated binaries:
| ./extract-strings `cat xml-stamp | sed -e
's;^;../../../gutenprint-5.2.11/src/xml/;'` > xmli18n-tmp.h.tmp
| /lib/ld-linux-armhf.so.3: No such file or directory
So, I introduced a "native" recipe, which just compiles the
"extract-strings" for me:
----------------------------------------------------------------------------------------------------------
SECTION = "libs"
require gutenprint_${PV}.bb
DEPENDS = "gettext-native"
inherit native autotools
EXTRA_OECONG = "\
--disable-libgutenprintui2 \
--disable-samples \
--without-gimp2 \
--without-doc \
--disable-nls \
--disable-nls-macos \
--without-foomatic \
--without-foomatic3 \
--disable-escputil \
--disable-test \
--disable-testpattern \
--without-cups \
"
do_compile() {
oe_runmake -C src/xml/ extract-strings
}
-----------------------------------------------------------------------------------------------------------------
The next step is quite unclear for me? How can I tell the build system
not to generate the extract-strings again and use the native instead?
As reference I used the build scripts from openwrt and buildroot. But
I'm not able to translate this build steps to Yocto.
https://github.com/FranciscoBorges/openwrt-printing-packages/blob/master/net/gutenprint/Makefile
https://github.com/buildroot/buildroot/blob/master/package/gutenprint/gutenprint.mk
-- # Randy MacLeod # Wind River Linux
|
|
|
[patchtest-oe][PATCH] test_mbox_mailinglist: Correct suggested mailing lists for docs and poky
A new mailing list was recently introduced for documentation related discussions including patches. And the domain for Yocto mailing lists was changed with the migration to groups.io. Change-Id: If687dcbaef4adf128196d8c80f3ea8b1b31b7738 Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@...> --- tests/test_mbox_mailinglist.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/test_mbox_mailinglist.py b/tests/test_mbox_mailinglist.py index e5700b4..d2781af 100644 --- a/tests/test_mbox_mailinglist.py +++ b/tests/test_mbox_mailinglist.py @@ -38,8 +38,8 @@ class MailingList(base.Base): Project = collections.namedtuple('Project', ['name', 'listemail', 'gitrepo', 'paths']) bitbake = Project(name='Bitbake', listemail='bitbake-devel@...', gitrepo=' http://git.openembedded.org/bitbake/', paths=paths['bitbake']) - doc = Project(name='Documentantion', listemail='yocto@...', gitrepo=' http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/', paths=paths['documentation']) - poky = Project(name='Poky', listemail='poky@...', gitrepo=' http://git.yoctoproject.org/cgit/cgit.cgi/poky/', paths=paths['poky']) + doc = Project(name='Documentantion', listemail='docs@...', gitrepo=' http://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/', paths=paths['documentation']) + poky = Project(name='Poky', listemail='poky@...', gitrepo=' http://git.yoctoproject.org/cgit/cgit.cgi/poky/', paths=paths['poky']) oe = Project(name='oe', listemail='openembedded-devel@...', gitrepo=' http://git.openembedded.org/meta-openembedded/', paths=paths['oe']) -- 2.21.1
|
|
|
Re: QA notification for completed autobuilder build (yocto-3.1.rc2)
On Wed, 2020-04-15 at 16:05 -0700, akuster wrote:
On 4/15/20 3:25 PM, Paul Eggleton wrote:
Release notes draft attached, including a dedication to Scott
(wasn't sure where to put that so I've just left it at the top) and
contributors list. Let me know if you notice anything
missing/incorrect. Thanks for pulling this together.
I've also sent out the 3.1 migration guide for the reference
manual, Richard has just merged the changes: I see the review window is down to an hour before merging. Is code
review by twitter the next new thing ; )
It was merged on the basis it was a good starter and followup patches are easy and very welcome. Cheers, Richard
|
|
|
Re: QA notification for completed autobuilder build (yocto-3.1.rc2)
Armin Kuster
On 4/15/20 3:25 PM, Paul Eggleton
wrote:
Release notes draft attached, including a dedication to Scott (wasn't sure where to put that so I've just left it at the top) and contributors list. Let me know if you notice anything missing/incorrect.
Thanks for pulling this together.
I've also sent out the 3.1 migration guide for the reference manual, Richard has just merged the changes:
I see the review window is down to an hour before merging. Is code
review by twitter the next new thing ; )
I responded the patches on the docs list.
- armin
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=c31ddaba1f3181c577fdaa3ce519a42b6f8f2d9a
Publishing to the website is still TBD, but some review there would be great as well.
Cheers,
Paul
|
|
|
Re: QA notification for completed autobuilder build (yocto-3.1.rc2)
|
|
|
Re: Guidance Downgrading Python2 in Zeus
#python
FYI, we’re doing the same internally (vendor supplied FIPS supported openssl 1.0.2), and the layer Armin suggests worked for us on zeus with minimal additional tweaking.
Good luck!
-Sean
toggle quoted messageShow quoted text
From: yocto@... <yocto@...>
On Behalf Of akuster
Sent: Wednesday, April 15, 2020 9:23 AM
To: MikeB <mabnhdev@...>; yocto@...
Subject: Re: [yocto] Guidance Downgrading Python2 in Zeus #python
On 4/15/20 9:16 AM, MikeB wrote:
I'm working on a set of platforms that have a FIPs certified OpenSSL. We are at version 1.0.2l.
I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).
We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).
I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).
I know how to downgrade simple recipes, but python is far from simple.
Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?
Have had a chance to look at this layer?
http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/
- armin
Thanks, Mike
|
|
|
Re: Guidance Downgrading Python2 in Zeus
#python
Armin Kuster
On 4/15/20 9:16 AM, MikeB wrote:
I'm working on a set of platforms that have a FIPs certified
OpenSSL. We are at version 1.0.2l.
I've found that the new version of python in Zeus (2.7.17)
requires a newer version of OpenSSL (1.1).
We really don't want to go through a new round of certification,
so we want to keep our current OpenSSL (1.0.2l).
I think the easiest solution is to downgrade python 2 back to the
version used by Sumo (2.7.15).
I know how to downgrade simple recipes, but python is far from
simple.
Can someone give me some guidance on how to approach the downgrade
of python2 in Zeus?
Have had a chance to look at this layer?
http://git.yoctoproject.org/cgit/cgit.cgi/meta-openssl102-fips/
- armin
Thanks, Mike
|
|
|
Re: Guidance Downgrading Python2 in Zeus
#python
I think python2 *recipe* requires openssl 1.1, but python2 itself will work just fine with openssl 1.0. So you only need to adjust the dependency, there are several ways to do that.
Alex
I'm working on a set of platforms that have a FIPs certified OpenSSL. We are at version 1.0.2l.
I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).
We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).
I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).
I know how to downgrade simple recipes, but python is far from simple.
Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?
Thanks, Mike
|
|
|
Guidance Downgrading Python2 in Zeus
#python
MikeB
I'm working on a set of platforms that have a FIPs certified OpenSSL. We are at version 1.0.2l.
I've found that the new version of python in Zeus (2.7.17) requires a newer version of OpenSSL (1.1).
We really don't want to go through a new round of certification, so we want to keep our current OpenSSL (1.0.2l).
I think the easiest solution is to downgrade python 2 back to the version used by Sumo (2.7.15).
I know how to downgrade simple recipes, but python is far from simple.
Can someone give me some guidance on how to approach the downgrade of python2 in Zeus?
Thanks, Mike
|
|
|
Randy MacLeod
On 2020-04-14 11:51 a.m., Ajam Ali wrote: Hi Randy,
In my image most of the size is consumed by heavy size packages.
So i have given this task of image size reduction to application team.
If i will remove the dependencies then may be some feature get disabled which could be needed.
Till now i am able to remove only python3 from dependencies.
Thanks for the summary Ajam. ../Randy Thanks,
Ajam Ali
------------------------------------------------------------------------
*From:* Randy MacLeod <randy.macleod@...>
*Sent:* Monday, April 13, 2020 11:18 PM
*To:* Ajam Ali <AjamA@...>; yocto@... <yocto@...>; gley-yocto@m.gmane-mx.org <gley-yocto@m.gmane-mx.org>
*Subject:* Re: [yocto] Image size reduction
**[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]
On 2020-04-04 12:27 p.m., Ajam Ali wrote:
Hi All,
Thanks for your suggestions. I am working on your suggestions.
I will let you know if it did not work for me. Ajam,
It would be useful if you could reply either way.
If there's still a problem then perhaps someone can help.
If you are able to resolve the issue, then a brief summary
of what you did could help the next person who has a similar
issue.
Thanks,
../Randy
Regards,
Ajam Ali
------------------------------------------------------------------------
*From:* yocto@... <mailto:yocto@...> <yocto@...> <mailto:yocto@...> on behalf of Gmane Admin via lists.yoctoproject.org <gley-yocto=m.gmane-mx.org@...> <mailto:gley-yocto=m.gmane-mx.org@...>
*Sent:* Saturday, April 4, 2020 9:36 PM
*To:* yocto@... <mailto:yocto@...> <yocto@...> <mailto:yocto@...>
*Subject:* Re: [yocto] Image size reduction
[CAUTION: This Email is from outside the Organization. Do not click links or open attachments unless you trust the sender.]
Op 29-03-2020 om 18:28 schreef Ajam Ali:
Hi All,
Actually my current image size is 3.9GB because of heavy size packages
required by my project and without project required packages my image
size in Yocto is 800MB. So your project adds 3.1GB right
I want to reduce the image size as maximum as possible. 3.1GB is huge. Compare to f.i. Libreoffice (installed 0.5GB or so).
Either your own code has a lot of fat, or you are pulling in lots of
packages you don't really need. But is there no way to advise you
without knowing more.
Please suggest the best possible way so that I could reduce the maximum
possible size(desirable below 1.5 GB).
Thanks in advance,
Ajam Ali
Sent from Outlook Mobile <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fblhgte&;data=02%7C01%7Cajama%40hcl.com%7Cf719cb14fe674f86f02408d7d8b236b0%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637216132261322392&sdata=8in2t%2B6mXtrsRwa7GmgGQDl69uRzL7g4smj%2Ba3QG9gU%3D&reserved=0 <https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms%2Fblhgte&data=02%7C01%7Cajama%40hcl.com%7C128e3933213f473fc34a08d7dfd2da33%7C189de737c93a4f5a8b686f4ca9941912%7C0%7C0%7C637223969041569087&sdata=gY%2FoAEw1u9iOH8l9146xlNknKSslGAhehsRsWa83%2F10%3D&reserved=0>>
::DISCLAIMER::
------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and
intended for the named recipient(s) only. E-mail transmission is not
guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
may contain viruses in transmission. The e mail and its contents (with
or without referred errors) shall therefore not attach any liability on
the originator or HCL or its affiliates. Views or opinions, if any,
presented in this email are solely those of the author and may not
necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior
written consent of authorized representative of HCL is strictly
prohibited. If you have received this email in error please delete it
and notify the sender immediately. Before opening any email and/or
attachments, please check them for viruses and other defects.
------------------------------------------------------------------------
--
# Randy MacLeod
# Wind River Linux
-- # Randy MacLeod # Wind River Linux
|
|
|
Re: QA notification for completed autobuilder build (yocto-3.1.rc2)
Hello Richard,
toggle quoted messageShow quoted text
-----Original Message----- From: yocto@... <yocto@...> On Behalf Of Richard Purdie Sent: Tuesday, April 14, 2020 2:12 PM To: Jain, Sangeeta <sangeeta.jain@...>; yocto@...; Tummalapalli, Vineela <vineela.tummalapalli@...>; Paul Eggleton <bluelightning@...> Cc: otavio@...; yi.zhao@...; Sangal, Apoorv <apoorv.sangal@...>; Yeoh, Ee Peng <ee.peng.yeoh@...>; Chan, Aaron Chun Yew <aaron.chun.yew.chan@...>; akuster808@...; sjolley.yp.pm@... Subject: Re: [yocto] QA notification for completed autobuilder build (yocto-3.1.rc2) Hi Sangeeta/Vineela, On Sat, 2020-04-11 at 07:26 +0000, Jain, Sangeeta wrote: This is the full report for yocto-3.1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/t
ree/?h=intel-yocto-testresults
======= Summary ========
No high milestone defects.
No new defects are found in this cycle.
Note: Few failures are observed. These are setup issue since running
tests remotely, not real yocto issue. Thanks for the QA run! The TSC met today and this was one of the topics discussed. We would have time for another build and QA run but none of the queued changes or open bugs appear to be significant enough to warrant that. We'd therefore like to proceed to release rc2 which will be slightly ahead of schedule and aim to have a prompt point release thereafter with the inevitable fixes as people start using it. Paul (cc'd) is working on the release notes which is a ton of work and much appreciated, thanks Paul. Vineela: Could you prepare the release so we're ready when we have the release notes please? [Vineela]: Thank you for the update. Yes I'm preparing the release. After we get release notes, I have to get the testreport and release notes reviewed and approved by TSC. Once reviewed and approved, will get the tagging done and will be ready for the release announcement. --- We're also pleased to say we do have an LTS maintainer lined up and that should be announced soon. Cheers, Richard
|
|
|
Re: QA notification for completed autobuilder build (yocto-3.1.rc2)
Hi Sangeeta/Vineela, On Sat, 2020-04-11 at 07:26 +0000, Jain, Sangeeta wrote: This is the full report for yocto-3.1.rc2:
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
======= Summary ========
No high milestone defects.
No new defects are found in this cycle.
Note: Few failures are observed. These are setup issue since running
tests remotely, not real yocto issue. Thanks for the QA run! The TSC met today and this was one of the topics discussed. We would have time for another build and QA run but none of the queued changes or open bugs appear to be significant enough to warrant that. We'd therefore like to proceed to release rc2 which will be slightly ahead of schedule and aim to have a prompt point release thereafter with the inevitable fixes as people start using it. Paul (cc'd) is working on the release notes which is a ton of work and much appreciated, thanks Paul. Vineela: Could you prepare the release so we're ready when we have the release notes please? We're also pleased to say we do have an LTS maintainer lined up and that should be announced soon. Cheers, Richard
|
|
|
Re: [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core
On Tue, Apr 14, 2020 at 12:02 PM Joshua Watt <JPEWhacker@...> wrote:
On 4/14/20 10:48 AM, Khem Raj wrote:
On Tue, Apr 14, 2020 at 6:32 AM Joshua Watt <JPEWhacker@...> wrote:
Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.
Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rockchip-defaults.inc | 3 +-
...-cfg-Allow-specification-of-ncurses-.patch | 51 -------------------
recipes-kernel/linux/linux-longterm_4.19.bb | 9 ----
recipes-kernel/linux/linux-longterm_5.4.bb | 7 ---
recipes-kernel/linux/linux-mainline_5.6.bb | 9 ----
recipes-kernel/linux/linux-mutual.inc | 18 -------
recipes-kernel/linux/linux-stable_5.5.bb | 7 ---
...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++++++++++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 +
recipes-kernel/linux/linux-yocto_5.4.bbappend | 5 ++
11 files changed, 41 insertions(+), 103 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
delete mode 100644 recipes-kernel/linux/linux-mutual.inc
delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
create mode 100644 recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend
I think another solution could be to use yocto kernel tooling but
point to mainline kernels much like what meta-meson [1] is doing
this will let you keep bumping to latest releases from mainline, this
approach is used by many other BSPs
[1] https://github.com/superna9999/meta-meson/blob/master/recipes-kernel/linux/linux-yocto-meson64_5.4.bb My goal here was to minimize the maintenance required for this BSP layer
to get newer kernels. Using the linux-yocto kernel in OE-core is quite
simple (as this patch shows) and allows us to piggyback off of Bruce's
work to keep everything up to date. While it is possible that OE-core
accidentally breaks something in this layer with a kernel update, it
seems likely this would be pretty rare and would probably require less
overall work than maintaining our own kernel recipes, particularly for
the set of boards in this BSP which have really good and stable support
in the kernel.
You replied faster than I could, so I turfed my answer! See below.
I think it should be possible to easily track the upstream vanilla
kernel branches in the linux-yocto recipe, and Bruce has done some work
to make this easier, but I think there might need to be little more work
in that area before it's completely ready to go.
Everything is good go to go, and I can point out what has been in place for a while: linux-yocto master is tracking mainline maser. No changes and linux-yocto v<x.y>/base tracks -stable, no changes. If you want to pick up the bare minimum of boot fixes, or some of the filesystem features v<x.y>/standard/base. Any significant bsp or board changes are always isolated in their own branch. As Joshua said, chasing a bunch of different versions (even if they are all pointing to the same upstream, (linux-yocto included)) does mean that there is variance, duplicated sanity and the need to chuck patches around. i.e. you'll get all the CVEs (that could be outside of -stable), -stable, etc, at the same pace as other boards. I don't see that as a bad thing, but of course, opinions vary :D If it makes things even easier, I could create a linux-yocto-mainline (recipe name off the top of my head) and it would just be the linux-yocto recipe pointing KBRANCH to master, or v<x.y>/base, no other changes. I'm sensitive to creating too many kernel recipes since it then becomes more confusing to pick the right thing .. but doing it the way I mention means that the breakage/QA/update follows the linux-yocto jumps and is very little extra effort. Cheers, Bruce
diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc
-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"
SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
# meta-rockchip default settings
# kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
LINUX_VERSION_EXTENSION ?= "-rockchip"
# xserver
diff --git a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..0000000
--- a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@...>
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-In some cross build environments such as the Yocto Project build
-environment it provides an ncurses library that is compiled
-differently than the host's version. This causes display corruption
-problems when the host's curses includes are used instead of the
-includes from the provided compiler are overridden. There is a second
-case where there is no curses libraries at all on the host system and
-menuconfig will just fail entirely.
-
-The solution is simply to allow an override variable in
-check-lxdialog.sh for environments such as the Yocto Project. Adding
-a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
-compiling and linking against the right headers and libraries.
-
-Signed-off-by: Jason Wessel <jason.wessel@...>
-cc: Michal Marek <mmarek@...>
-cc: linux-kbuild@...
-Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
----
- scripts/kconfig/mconf-cfg.sh | 8 ++++++++
- 1 file changed, 8 insertions(+)
- mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh
-
-diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
-old mode 100755
-new mode 100644
-index c812872d7f9d..65a9b9e5b8a6
---- a/scripts/kconfig/mconf-cfg.sh
-+++ b/scripts/kconfig/mconf-cfg.sh
-@@ -4,6 +4,14 @@
- PKG="ncursesw"
- PKG2="ncurses"
-
-+if [ "$CROSS_CURSES_LIB" != "" ]; then
-+ echo libs=\'$CROSS_CURSES_LIB\'
-+ if [ x"$CROSS_CURSES_INC" != x ]; then
-+ echo cflags=\'$CROSS_CURSES_INC\'
-+ fi
-+ exit 0
-+fi
-+
- if [ -n "$(command -v pkg-config)" ]; then
- if pkg-config --exists $PKG; then
- echo cflags=\"$(pkg-config --cflags $PKG)\"
---
-2.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0000000
--- a/recipes-kernel/linux/linux-longterm_4.19.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "4.19.113"
-KBRANCH ?= "linux-4.19.y"
-SRCREV ?= "54b4fa6d39551639cb10664f6ac78b01993a1d7e"
-
-require linux-mutual.inc
-
-COMPATIBLE_MACHINE = "(firefly-rk3288|marsboard-rk3066|radxarock|rock2-square|^tinker-board$|vyasa-rk3288)"
diff --git a/recipes-kernel/linux/linux-longterm_5.4.bb b/recipes-kernel/linux/linux-longterm_5.4.bb
deleted file mode 100644
index 60be6fe..0000000
--- a/recipes-kernel/linux/linux-longterm_5.4.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.4.28"
-KBRANCH ?= "linux-5.4.y"
-SRCREV ?= "462afcd6e7ea94a7027a96a3bb12d0140b0b4216"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-mainline_5.6.bb b/recipes-kernel/linux/linux-mainline_5.6.bb
deleted file mode 100644
index 8d33590..0000000
--- a/recipes-kernel/linux/linux-mainline_5.6.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.6-rc7"
-KBRANCH ?= "master"
-SRCREV ?= "16fbf79b0f83bc752cee8589279f1ebfe57b3b6e"
-
-require linux-mutual.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
diff --git a/recipes-kernel/linux/linux-mutual.inc b/recipes-kernel/linux/linux-mutual.inc
deleted file mode 100644
index ba3ab6e..0000000
--- a/recipes-kernel/linux/linux-mutual.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-DESCRIPTION = "Linux Kernel"
-SECTION = "kernel"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = " \
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${KBRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch \
- "
-
-inherit kernel
-require recipes-kernel/linux/linux-yocto.inc
-
-PV = "${LINUX_VERSION}+git${SRCPV}"
-
-KCONF_BSP_AUDIT_LEVEL = "0"
-deltask kernel_configme
diff --git a/recipes-kernel/linux/linux-stable_5.5.bb b/recipes-kernel/linux/linux-stable_5.5.bb
deleted file mode 100644
index b5c7cdc..0000000
--- a/recipes-kernel/linux/linux-stable_5.5.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.5.13"
-KBRANCH ?= "linux-5.5.y"
-SRCREV ?= "fe5ae687d01e74854ed33666c932a9c11e22139c"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
new file mode 100644
index 0000000..751f1ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
@@ -0,0 +1,31 @@
+From 04ab2a1f052f363985b373f07ea71840918378d2 Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@...>
+Date: Wed, 19 Feb 2020 13:10:32 -0600
+Subject: [PATCH] ARM: dts: rockchip: Keep rk3288-tinker SD card IO powered
+ during reboot
+
+IO voltage regulator for the SD card must be kept on all the time,
+otherwise when the board reboots the SD card can't be read by the
+bootloader.
+
+Signed-off-by: Joshua Watt <JPEWhacker@...>
+Upstream-Status: Accepted in 5.7
+---
+ arch/arm/boot/dts/rk3288-tinker.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
+index 312582c1bd37..acfaa12ec239 100644
+--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
++++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
+@@ -276,6 +276,7 @@
+ };
+
+ vccio_sd: LDO_REG5 {
++ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+--
+2.17.1
+
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
new file mode 100644
index 0000000..97b8cda
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -0,0 +1,2 @@
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+
diff --git a/recipes-kernel/linux/linux-yocto_5.4.bbappend b/recipes-kernel/linux/linux-yocto_5.4.bbappend
new file mode 100644
index 0000000..e832529
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# tinker-board and tinker-board-s. rk3288 covers both
+SRC_URI_append_rk3288 = " file://0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch"
+
--
2.17.1
-- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
|
|
|
Re: [meta-rockchip][PATCH] Use linux-yocto kernel from OE-core
On 4/14/20 10:48 AM, Khem Raj wrote: On Tue, Apr 14, 2020 at 6:32 AM Joshua Watt <JPEWhacker@...> wrote:
Updates all machines to use the linux-yocto kernel from OE-core instead
of maintaining distinct kernels in this repository.
Signed-off-by: Joshua Watt <JPEWhacker@...>
---
conf/machine/include/rk3288.inc | 2 +-
conf/machine/include/rockchip-defaults.inc | 3 +-
...-cfg-Allow-specification-of-ncurses-.patch | 51 -------------------
recipes-kernel/linux/linux-longterm_4.19.bb | 9 ----
recipes-kernel/linux/linux-longterm_5.4.bb | 7 ---
recipes-kernel/linux/linux-mainline_5.6.bb | 9 ----
recipes-kernel/linux/linux-mutual.inc | 18 -------
recipes-kernel/linux/linux-stable_5.5.bb | 7 ---
...-Keep-rk3288-tinker-SD-card-IO-power.patch | 31 +++++++++++
recipes-kernel/linux/linux-yocto_%.bbappend | 2 +
recipes-kernel/linux/linux-yocto_5.4.bbappend | 5 ++
11 files changed, 41 insertions(+), 103 deletions(-)
delete mode 100644 recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
delete mode 100644 recipes-kernel/linux/linux-longterm_4.19.bb
delete mode 100644 recipes-kernel/linux/linux-longterm_5.4.bb
delete mode 100644 recipes-kernel/linux/linux-mainline_5.6.bb
delete mode 100644 recipes-kernel/linux/linux-mutual.inc
delete mode 100644 recipes-kernel/linux/linux-stable_5.5.bb
create mode 100644 recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
create mode 100644 recipes-kernel/linux/linux-yocto_%.bbappend
create mode 100644 recipes-kernel/linux/linux-yocto_5.4.bbappend
I think another solution could be to use yocto kernel tooling but
point to mainline kernels much like what meta-meson [1] is doing
this will let you keep bumping to latest releases from mainline, this
approach is used by many other BSPs
[1] https://github.com/superna9999/meta-meson/blob/master/recipes-kernel/linux/linux-yocto-meson64_5.4.bb My goal here was to minimize the maintenance required for this BSP layer to get newer kernels. Using the linux-yocto kernel in OE-core is quite simple (as this patch shows) and allows us to piggyback off of Bruce's work to keep everything up to date. While it is possible that OE-core accidentally breaks something in this layer with a kernel update, it seems likely this would be pretty rare and would probably require less overall work than maintaining our own kernel recipes, particularly for the set of boards in this BSP which have really good and stable support in the kernel. I think it should be possible to easily track the upstream vanilla kernel branches in the linux-yocto recipe, and Bruce has done some work to make this easier, but I think there might need to be little more work in that area before it's completely ready to go. diff --git a/conf/machine/include/rk3288.inc b/conf/machine/include/rk3288.inc
index a7edac5..480e250 100644
--- a/conf/machine/include/rk3288.inc
+++ b/conf/machine/include/rk3288.inc
@@ -7,7 +7,7 @@ require conf/machine/include/tune-cortexa17.inc
require conf/machine/include/soc-family.inc
require conf/machine/include/rockchip-defaults.inc
-KBUILD_DEFCONFIG = "multi_v7_defconfig"
+KBUILD_DEFCONFIG ?= "multi_v7_defconfig"
KERNEL_IMAGETYPE = "zImage"
SERIAL_CONSOLES = "115200;ttyS2"
diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index 82fd590..a4e2a2c 100644
--- a/conf/machine/include/rockchip-defaults.inc
+++ b/conf/machine/include/rockchip-defaults.inc
@@ -1,7 +1,8 @@
# meta-rockchip default settings
# kernel
-PREFERRED_PROVIDER_virtual/kernel ?= "linux-stable"
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
+KCONFIG_MODE ?= "alldefconfig"
LINUX_VERSION_EXTENSION ?= "-rockchip"
# xserver
diff --git a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch b/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
deleted file mode 100644
index 0b2d077..0000000
--- a/recipes-kernel/linux/files/0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 846b11d8c834af4fa62393dadb490ea8246b332c Mon Sep 17 00:00:00 2001
-From: Bruce Ashfield <bruce.ashfield@...>
-Date: Mon, 2 Jul 2018 23:10:28 -0400
-Subject: [PATCH] menuconfig,mconf-cfg: Allow specification of ncurses location
-
-In some cross build environments such as the Yocto Project build
-environment it provides an ncurses library that is compiled
-differently than the host's version. This causes display corruption
-problems when the host's curses includes are used instead of the
-includes from the provided compiler are overridden. There is a second
-case where there is no curses libraries at all on the host system and
-menuconfig will just fail entirely.
-
-The solution is simply to allow an override variable in
-check-lxdialog.sh for environments such as the Yocto Project. Adding
-a CROSS_CURSES_LIB and CROSS_CURSES_INC solves the issue and allowing
-compiling and linking against the right headers and libraries.
-
-Signed-off-by: Jason Wessel <jason.wessel@...>
-cc: Michal Marek <mmarek@...>
-cc: linux-kbuild@...
-Signed-off-by: Bruce Ashfield <bruce.ashfield@...>
----
- scripts/kconfig/mconf-cfg.sh | 8 ++++++++
- 1 file changed, 8 insertions(+)
- mode change 100755 => 100644 scripts/kconfig/mconf-cfg.sh
-
-diff --git a/scripts/kconfig/mconf-cfg.sh b/scripts/kconfig/mconf-cfg.sh
-old mode 100755
-new mode 100644
-index c812872d7f9d..65a9b9e5b8a6
---- a/scripts/kconfig/mconf-cfg.sh
-+++ b/scripts/kconfig/mconf-cfg.sh
-@@ -4,6 +4,14 @@
- PKG="ncursesw"
- PKG2="ncurses"
-
-+if [ "$CROSS_CURSES_LIB" != "" ]; then
-+ echo libs=\'$CROSS_CURSES_LIB\'
-+ if [ x"$CROSS_CURSES_INC" != x ]; then
-+ echo cflags=\'$CROSS_CURSES_INC\'
-+ fi
-+ exit 0
-+fi
-+
- if [ -n "$(command -v pkg-config)" ]; then
- if pkg-config --exists $PKG; then
- echo cflags=\"$(pkg-config --cflags $PKG)\"
---
-2.20.1
-
diff --git a/recipes-kernel/linux/linux-longterm_4.19.bb b/recipes-kernel/linux/linux-longterm_4.19.bb
deleted file mode 100644
index 11c18e3..0000000
--- a/recipes-kernel/linux/linux-longterm_4.19.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "4.19.113"
-KBRANCH ?= "linux-4.19.y"
-SRCREV ?= "54b4fa6d39551639cb10664f6ac78b01993a1d7e"
-
-require linux-mutual.inc
-
-COMPATIBLE_MACHINE = "(firefly-rk3288|marsboard-rk3066|radxarock|rock2-square|^tinker-board$|vyasa-rk3288)"
diff --git a/recipes-kernel/linux/linux-longterm_5.4.bb b/recipes-kernel/linux/linux-longterm_5.4.bb
deleted file mode 100644
index 60be6fe..0000000
--- a/recipes-kernel/linux/linux-longterm_5.4.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.4.28"
-KBRANCH ?= "linux-5.4.y"
-SRCREV ?= "462afcd6e7ea94a7027a96a3bb12d0140b0b4216"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-mainline_5.6.bb b/recipes-kernel/linux/linux-mainline_5.6.bb
deleted file mode 100644
index 8d33590..0000000
--- a/recipes-kernel/linux/linux-mainline_5.6.bb
+++ /dev/null
@@ -1,9 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.6-rc7"
-KBRANCH ?= "master"
-SRCREV ?= "16fbf79b0f83bc752cee8589279f1ebfe57b3b6e"
-
-require linux-mutual.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
diff --git a/recipes-kernel/linux/linux-mutual.inc b/recipes-kernel/linux/linux-mutual.inc
deleted file mode 100644
index ba3ab6e..0000000
--- a/recipes-kernel/linux/linux-mutual.inc
+++ /dev/null
@@ -1,18 +0,0 @@
-DESCRIPTION = "Linux Kernel"
-SECTION = "kernel"
-LICENSE = "GPLv2"
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=bbea815ee2795b2f4230826c0c6b8814"
-
-SRC_URI = " \
- git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=${KBRANCH} \
- file://0001-menuconfig-mconf-cfg-Allow-specification-of-ncurses-.patch \
- "
-
-inherit kernel
-require recipes-kernel/linux/linux-yocto.inc
-
-PV = "${LINUX_VERSION}+git${SRCPV}"
-
-KCONF_BSP_AUDIT_LEVEL = "0"
-deltask kernel_configme
diff --git a/recipes-kernel/linux/linux-stable_5.5.bb b/recipes-kernel/linux/linux-stable_5.5.bb
deleted file mode 100644
index b5c7cdc..0000000
--- a/recipes-kernel/linux/linux-stable_5.5.bb
+++ /dev/null
@@ -1,7 +0,0 @@
-FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
-
-LINUX_VERSION ?= "5.5.13"
-KBRANCH ?= "linux-5.5.y"
-SRCREV ?= "fe5ae687d01e74854ed33666c932a9c11e22139c"
-
-require linux-mutual.inc
diff --git a/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
new file mode 100644
index 0000000..751f1ad
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch
@@ -0,0 +1,31 @@
+From 04ab2a1f052f363985b373f07ea71840918378d2 Mon Sep 17 00:00:00 2001
+From: Joshua Watt <JPEWhacker@...>
+Date: Wed, 19 Feb 2020 13:10:32 -0600
+Subject: [PATCH] ARM: dts: rockchip: Keep rk3288-tinker SD card IO powered
+ during reboot
+
+IO voltage regulator for the SD card must be kept on all the time,
+otherwise when the board reboots the SD card can't be read by the
+bootloader.
+
+Signed-off-by: Joshua Watt <JPEWhacker@...>
+Upstream-Status: Accepted in 5.7
+---
+ arch/arm/boot/dts/rk3288-tinker.dtsi | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/arm/boot/dts/rk3288-tinker.dtsi b/arch/arm/boot/dts/rk3288-tinker.dtsi
+index 312582c1bd37..acfaa12ec239 100644
+--- a/arch/arm/boot/dts/rk3288-tinker.dtsi
++++ b/arch/arm/boot/dts/rk3288-tinker.dtsi
+@@ -276,6 +276,7 @@
+ };
+
+ vccio_sd: LDO_REG5 {
++ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+--
+2.17.1
+
diff --git a/recipes-kernel/linux/linux-yocto_%.bbappend b/recipes-kernel/linux/linux-yocto_%.bbappend
new file mode 100644
index 0000000..97b8cda
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_%.bbappend
@@ -0,0 +1,2 @@
+COMPATIBLE_MACHINE .= "|firefly-rk3288|marsboard-rk3066|radxarock|rock-pi-4|rock2-square|tinker-board-s|tinker-board|vyasa-rk3288"
+
diff --git a/recipes-kernel/linux/linux-yocto_5.4.bbappend b/recipes-kernel/linux/linux-yocto_5.4.bbappend
new file mode 100644
index 0000000..e832529
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.4.bbappend
@@ -0,0 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
+
+# tinker-board and tinker-board-s. rk3288 covers both
+SRC_URI_append_rk3288 = " file://0001-ARM-dts-rockchip-Keep-rk3288-tinker-SD-card-IO-power.patch"
+
--
2.17.1
|
|
|
Re: Files get sporadically lost for native packages
During a recent data center move mail permissions were not carried over correctly. I've sorted this now and bugzilla e-mail should start arriving shortly. If you don't receive e-mail as expected please make another attempt. If problems persist reach out to me directly for support.
Thank you, Michael Halstead SysAdmin / Yocto Project
Adding Michael (lack of confirmtation email from bugzilla).
Alex
On Mon, 13 Apr 2020 at 19:59, Konrad Weihmann < kweihmann@...> wrote: Hi Randy,
I'm trying all day to create an account at bugzilla to file the issue,
but somehow I don't get any confirmation mail (although I tried several
mail accounts today, and no it didn't got stuck in spam;-)) - guess
that's not how it is supposed to be, right :-)? - I don't know where to
address such a problem, so take this reply as FYI.
Best
Konrad
On 03.04.20 21:28, Randy MacLeod wrote:
> On 2020-04-02 4:44 a.m., Konrad Weihmann wrote:
>>
>> To answer your others questions... see below
>>
>> On 02.04.20 05:42, Randy MacLeod wrote:
>>> On 2020-03-28 8:26 a.m., Konrad Weihmann wrote:
>>>> Hi,
>>>>
>>>> I'm facing the following error message sporadically on all branches
>>>> I tried so far (master, zeus, warrior and thud)
>>>>
>>>> The stack trace of python calls that resulted in this
>>>> exception/failure was:
>>>> File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
>>>> 0001:
>>>> *** 0002:extend_recipe_sysroot(d)
>>>> 0003:
>>>> File: '/build/poky/meta/classes/staging.bbclass', lineno: 551,
>>>> function: extend_recipe_sysroot
>>>> 0547: dest = newmanifest[l]
>>>> 0548: if l.endswith("/"):
>>>> 0549: staging_copydir(l, targetdir,
>>>> dest, seendirs)
>>>> 0550: continue
>>>> *** 0551: staging_copyfile(l, targetdir, dest,
>>>> postinsts, seendirs)
>>>> 0552:
>>>> 0553: bb.note("Installed into sysroot: %s" % str(msg_adding))
>>>> 0554: bb.note("Skipping as already exists in sysroot: %s" %
>>>> str(msg_exists))
>>>> 0555:
>>>> File: '/build/poky/meta/classes/staging.bbclass', lineno: 152,
>>>> function: staging_copyfile
>>>> 0148: os.symlink(linkto, dest)
>>>> 0149: #bb.warn(c)
>>>> 0150: else:
>>>> 0151: try:
>>>> *** 0152: os.link(c, dest)
>>>> 0153: except OSError as err:
>>>> 0154: if err.errno == errno.EXDEV:
>>>> 0155: bb.utils.copyfile(c, dest)
>>>> 0156: else:
>>>> Exception: FileNotFoundError: [Errno 2] No such file or directory:
>>>> '/build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'
>>>> ->
>>>> '/build/poky/build/tmp/work/qemux86_64-mine-linux/core-image-minimal-mine/1.0-r0/recipe-sysroot-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc'
>>>>
>>>> I already had a look at the manifest
>>>>
>>>> cat manifest-x86_64-python3-msgcheck-native.populate_sysroot
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/__init__.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/python3-msgcheck-native
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/sysroot-providers/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
>>>>
>>>>
>>>> which states the file should be there, but when doing
>>>>
>>>> find
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__init__.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/po.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/__pycache__/msgcheck.cpython-37.pyc
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/po.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck/msgcheck.py
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/dependency_links.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/requires.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/top_level.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/SOURCES.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/PKG-INFO
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/lib/python3.7/site-packages/msgcheck-2.8-py3.7.egg-info/entry_points.txt
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/bin/msgcheck
>>>>
>>>> /build/poky/build/tmp/sysroots-components/x86_64/python3-msgcheck-native/usr/share
>>>>
>>>>
>>>> the file isn't there.
>>>>
>>>> This happens to random python packages compiled as native (sometimes
>>>> even for python-native itself), but (afaik) not for cross or target
>>>> packages (I'm pretty sure because of the different packaging applied).
>>>> So I digged a little into the code
>>>> classes/sstate.bbclass:sstate_install, which seems to create the
>>>> sysroot-component dir and the manifest.
>>>> There is a gap between the manifest creation (line 285) and the
>>>> hardlinking (line till 311).
>>>>
>>>> Now my question is there any place where a file potentially could
>>>> get lost? - at first glance there shouldn't be one - I have to admit
>>>> that I don't fully understand all this subprocess magic in
>>>> lib/oe/path.py:copyhardlinktree.
>>>> What I do to fix the issue is reopening the manifest and double
>>>> check for missing files and remove them from the manifest, but this
>>>> feels wrong - so any advise is welcome...
>>>>
>>>> Hope that someone more familiar with the topic could have a look.
>>>
>>> Hi Konrad,
>>>
>>> I'm not really familiar with that code but it's being run buy 1000s of
>>> builder around the world so let's try to eliminate a few possibilities.
>>>
>>> When did you start having this problem?
>> Since the start of the test distribution I'm working on. But also for
>> plain poky builds if I forcefully inject all of the python-native
>> site-packages via local.conf (DEPENDS_class-native += "..."), without
>> actually using them in the recipe scope
>>> How often do you think it's happening: 1 in 3 builds, 1 in 10?
>> See the other mail - looks like it heavily depends on the host
>>> Tell us about your machine: OS,version, disk, CPUs, ram
>> See the other mail
>>> Do you do anything special in your conf dir? Send local.conf perhaps.
>> No custom modification (just for testing the DEPENDS-injection)
>>> Do you have any local bbappends or commits on top of poky or
>>> in other layers?
>> No
>>> Have you tried to simplify the build to eliminate problems
>>> potentially caused by other layers?
>> I did - see above
>>> Are you able to reproduce the problem on more than one build machine?
>> See the other mail
>>> Are you able to reproduce the problem on a different Linux distro?
>> Not really - Debian 9 was fine all other Hosts are Ubuntu based
>>> Are there other builds or users on the machine that may be causing
>>> extra load?
>> No the hosts are just being poorly equipped - at least the ones that
>> produce this issue
>
>
> Hi Konrad,
>
> Thanks for the detailed and complete replies.
>
> I don't think I've seen this error and we do 100s of builds
> per day using local many-core systems running Ubuntu-18.04
> but with the builds in docker containers using a variety of
> OS distributions.
>
> My first *wild* guess is that the problem might go away on the Azure
> systems if you allocate more memory. That might be an easy
> test to do so that we can confirm that it happens more frequently
> when there is a memory constraint. Can you do that test?
>
> I've also BCCed someone who might know someone who
> would be interested in fixing Azure + Yocto bugs. Let's see
> if they can help. :)
>
> It would also be helpful if you created a defect in:
>
> https://bugzilla.yoctoproject.org/
>
> and hopefully add a patch in that defect including the -native recipes that
> are required to make the problem happen.
>
> Thanks,
>
> ../Randy
>
>
>>>
>>>
>>> ../Randy
>>>
>>>>
>>>> Thanks
>>>>
>>>> Konrad
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
|
|
|
