Date   

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

Teoh, Jay Shen
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.12.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion next Tuesday, Nov 23.

Thanks,
Jay

-----Original Message-----
From: yocto@... <yocto@...> On Behalf
Of Richard Purdie
Sent: Wednesday, 17 November, 2021 6:25 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification <qa-build-notification@...>
Subject: [yocto] QA notification for completed autobuilder build (yocto-
3.1.12.rc1)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.12.rc1


Build hash information:

bitbake: c0348de8121c3a842bf44906f7e2f79e93f7275b
meta-agl: 0406cbb235fb08ce9e6f9d07e64e0932b20050a9
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 2f72301f5a73279c4d2f12fc6218876629666e06
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 625da85e7b01b71cc310267b0ba7119eb139e9f7
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 7889158dcd187546fc5e99fd81d0779cad3e8d17
oecore: 44b1970c40e9d73f6e63fb10cdc55837a26f5921
poky: 0839888394a6e42e96f9f0d201376eb38bc79b24



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


psplash logo not comming #yocto #ubuntu #uboot #gatesgarth #bitbake

abhi <abhishek.kumar@...>
 

hi sir,

i am working on yocto ,i created one core-image-base inside that image i want to set logo on u-boot and kernel side ,i added psplash also in local.conf (IMAGE_FEATURES = "psplash")  .
but default logo even not coming please tell how set splash screen logo in yocto side, bellow error i got it will be helpfull for u.

thanks in advance


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

Hi Khem,

On Tue, Nov 16, 2021 at 10:50:13AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.
meta-rockchip does not have a honister branch for now because it is
still working with master branch from OE-Core. This patch does not break
this behaviour.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
Do I add a "known issues" to the README then? Or where am I supposed to
add this piece of information were this patch not merged?

if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.
I think we both understand each other's stance and I've no additional
arguments to give, so it'll be up to the maintainer(s) which is
officially Trevor, but maybe I am not aware of other unofficial
maintainers :)

In any case, I can have this patch in my own vendor BSP but since it
applies to all RK3399-based devices, I thought it'd be nicer to have it
in upstream meta-rockchip than in a vendor BSP unrelated to the boards
one's using.

@Trevor/maintainers, let us know what's your opinion on this so I know
if I should send a v2 using inline python function for SRC_URI instead
of using the anonymous python function.

Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?

Cheers,
Quentin


NFS under yocto

Monsees, Steven C (US)
 

 

Current yocto build is based on zeus…

We have one board running Yocto Embedded linux that is sharing a drive partition via NFS.

Another board is mounting the NFS share and has a few processes that can write data to the drive.

We are seeing conditions were concurrent writes (two client processes) appear to result in “Stale File Handles”.

The drive partition is using the NTFS file system.

 

We are wondering if there are any issues in the NFS Server or Client that could be causing these “Stale File Handles”.

We have tried to change some of the options used to mount the NFS share.

Are there any options in how the location is shared that we should try?

 

Anyone hear about or experienced similar issues ?

 

Thanks,

Steve


QA notification for completed autobuilder build (yocto-3.1.12.rc1)

Richard Purdie
 

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.12.rc1


Build hash information:

bitbake: c0348de8121c3a842bf44906f7e2f79e93f7275b
meta-agl: 0406cbb235fb08ce9e6f9d07e64e0932b20050a9
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 2f72301f5a73279c4d2f12fc6218876629666e06
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 625da85e7b01b71cc310267b0ba7119eb139e9f7
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: 7889158dcd187546fc5e99fd81d0779cad3e8d17
oecore: 44b1970c40e9d73f6e63fb10cdc55837a26f5921
poky: 0839888394a6e42e96f9f0d201376eb38bc79b24



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


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Khem Raj
 

On Tue, Nov 16, 2021 at 10:03 AM Quentin Schulz <foss@...> wrote:



On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?
meta-rockchip does not have honister branch for now. So it expects
master to keep working with honister for now. kernel upgrades are
already committed into honister branch on meta-yocto-bsps so fix it
already available in latest honister
branch and will be in imminent point release soon as well.


meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.
I would say yes, document it as that of a known issue and possible fix
if someone is using exact point release. They might have snapshotted
meta-rockpi too and in that case it will be easy for them to carry a
local patch if needed.
vesion specific patching would also be setting a not so desired
patching practice, so I am trying to avoid it if we can.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.
Update to latest honister branch or wait for 3.4.1, would be my suggestion.


Cheers
Quentin


Cheers,
Quentin


Re: Yocto Project Status WW46`21

Michael Opdenacker
 

Hi Stephen

Thanks for the report! Sorry, I couldn't attend the meeting.

On 11/16/21 4:47 PM, Stephen Jolley wrote:

* A request was made to continue hardknott support in the community
and this was agreed until Feb/March next year but will not overlap
the LTS.
Could I update this on https://wiki.yoctoproject.org/wiki/Releases?
Cheers
Michael.
--

Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

On November 16, 2021 6:45:05 PM GMT+01:00, Khem Raj <raj.khem@...> wrote:
On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <
quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet
MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because
Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?
I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch
If you could explain what's *really* bothering you, I could try to find a proper explanation or agree with you but it's a bit too vague to me right now. Anyway, I'll do some guesses in the next paragraphs.

Because Ethernet does not work for all RK3399-based boards in the latest and only release of Honister?

meta-rockchip is the BSP layer for Rockchip based devices, if not there, where should I put this patch?

Or are we just going to say "Ethernet does not work, we know" to people asking instead of having this patch in? Obviously you could tell them to upgrade their oe-core/poky git repo to rolling honister or 3.4.1 once it's out but having this patch in avoid those questions.

I understand we're talking about policy here. I am not fond of this patch either but Ethernet is quite critical on boards which don't have WiFi for example. I don't have anything better to suggest to fix this in the *latest* release.

Cheers
Quentin


Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Khem Raj
 



On Tue, Nov 16, 2021 at 9:12 AM Quentin Schulz <quentin.schulz@...> wrote:
On Tue, Nov 16, 2021 at 09:08:41AM -0800, Khem Raj wrote:
> On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
> <quentin.schulz@...> wrote:
> >
> > On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
> > > On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
> > > <quentin.schulz@...> wrote:
> > > >
> > > > From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
> > > > controller found on RK3399 is not working.
> > > >
> > > > A fix is available in v5.14.12 and later (available also in v5.15)
> > > > which is provided here and applied to linux-yocto source tree if
> > > > linux-yocto version is of the impacted ones.
> > > >
> > > > The conditional patching is unfortunately required because Honister 3.4
> > > > has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
> > > > linux-yocto v5.14.14.
> > >
> > > Patching piece below looks quite a bit.
> > > lets just fix v5.14.14 and dont worry about 3.4
> > >
> >
> > v5.14.14 is already fixed. The only release currently is 3.4 and I hit
> > that issue, hence the patch.
> > I assume not everybody is updating to 3.4.1 when it's out, I've seen
> > people running behind dot releases.
> > What's bothering you?
>
> once dot release is out then thats whats maintained not the original
> release since they are incremental.
> the anon python to apply a patch. Can you explain why we want to patch
> applied this way ?
>

I could define a python function and use it like this:
SRC_URI:append:rk3399 = "${@rk3399_fix_mac(d)}"

Would that work better for you?

I am not yet convinced why should we have such version specific patch 


Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Khem Raj
 

On Tue, Nov 16, 2021 at 9:04 AM Quentin Schulz
<quentin.schulz@...> wrote:

On Tue, Nov 16, 2021 at 09:00:42AM -0800, Khem Raj wrote:
On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4
v5.14.14 is already fixed. The only release currently is 3.4 and I hit
that issue, hence the patch.
I assume not everybody is updating to 3.4.1 when it's out, I've seen
people running behind dot releases.
What's bothering you?
once dot release is out then thats whats maintained not the original
release since they are incremental.
the anon python to apply a patch. Can you explain why we want to patch
applied this way ?


Cheers,
Quentin


Re: [meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Khem Raj
 

On Tue, Nov 16, 2021 at 7:52 AM Quentin Schulz
<quentin.schulz@...> wrote:

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.
Patching piece below looks quite a bit.
lets just fix v5.14.14 and dont worry about 3.4


Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
...-rk-Fix-ethernet-on-rk3399-based-dev.patch | 63 +++++++++++++++++++
.../linux/linux-yocto/5.14-rk3399-mac-fix.scc | 1 +
.../linux/linux-yocto_5.14.bbappend | 11 ++++
3 files changed, 75 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
create mode 100644 recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
create mode 100644 recipes-kernel/linux/linux-yocto_5.14.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
new file mode 100644
index 0000000..b2ce7e8
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
@@ -0,0 +1,63 @@
+From 8efe947ea1eace444d78398a31469b30e47ae585 Mon Sep 17 00:00:00 2001
+From: Punit Agrawal <punitagrawal@...>
+Date: Wed, 29 Sep 2021 22:50:49 +0900
+Subject: [PATCH] net: stmmac: dwmac-rk: Fix ethernet on rk3399 based devices
+
+[ Upstream commit aec3f415f7244b7747a7952596971adb0df2f568 ]
+
+Commit 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+while getting rid of a runtime PM warning ended up breaking ethernet
+on rk3399 based devices. By dropping an extra reference to the device,
+the commit ends up enabling suspend / resume of the ethernet device -
+which appears to be broken.
+
+While the issue with runtime pm is being investigated, partially
+revert commit 2d26f6e39afb to restore the network on rk3399.
+
+Fixes: 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+Suggested-by: Heiko Stuebner <heiko@...>
+Signed-off-by: Punit Agrawal <punitagrawal@...>
+Cc: Michael Riesch <michael.riesch@...>
+Tested-by: Heiko Stuebner <heiko@...>
+Link: https://lore.kernel.org/r/20210929135049.3426058-1-punitagrawal@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@...>
+Signed-off-by: Sasha Levin <sashal@...>
+
+Upstream-Status: Backport [8efe947ea1eace444d78398a31469b30e47ae585]
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+index ed817011a94a..6924a6aacbd5 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+@@ -21,6 +21,7 @@
+ #include <linux/delay.h>
+ #include <linux/mfd/syscon.h>
+ #include <linux/regmap.h>
++#include <linux/pm_runtime.h>
+
+ #include "stmmac_platform.h"
+
+@@ -1528,6 +1529,8 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
+ return ret;
+ }
+
++ pm_runtime_get_sync(dev);
++
+ if (bsp_priv->integrated_phy)
+ rk_gmac_integrated_phy_powerup(bsp_priv);
+
+@@ -1539,6 +1542,8 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac)
+ if (gmac->integrated_phy)
+ rk_gmac_integrated_phy_powerdown(gmac);
+
++ pm_runtime_put_sync(&gmac->pdev->dev);
++
+ phy_power_on(gmac, false);
+ gmac_clk_enable(gmac, false);
+ }
+--
+2.33.1
+
diff --git a/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
new file mode 100644
index 0000000..1ad2bde
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
@@ -0,0 +1 @@
+patch 0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
diff --git a/recipes-kernel/linux/linux-yocto_5.14.bbappend b/recipes-kernel/linux/linux-yocto_5.14.bbappend
new file mode 100644
index 0000000..5eaa604
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.14.bbappend
@@ -0,0 +1,11 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+
+# Fix Ethernet on 5.14 until 5.14.11 (included) for RK3399 MAC controller
+# Conditional patching required because Honister 3.4 has linux-yocto
+# v5.14.9 and Honister 3.4.1 will have at least linux-yocto v5.14.14.
+python __anonymous() {
+ kver = d.getVar('LINUX_VERSION') or ''
+ if bb.utils.is_semver(kver) \
+ and bb.utils.vercmp_string(kver, '5.14.11') <= 0:
+ d.appendVar('SRC_URI', ' file://5.14-rk3399-mac-fix.scc')
+}
--
2.30.2




Re: Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

Darcy Watkins
 

Thanks Martin,

 

I added an extra step to sync up the ca-certificates within my docker container that I use to build dunfell.  This seems to have resolved the issue that I encountered.

 

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com

 

From: Martin Jansa <martin.jansa@...>
Date: Wednesday, November 3, 2021 at 5:26 PM
To: Darcy Watkins <dwatkins@...>
Cc: yocto@... <yocto@...>
Subject: Re: [yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

Most likely expired Let's Encrypt certificate (which salsa.debian.org where ca-certificates are hoster is using) on your builder (host OS), see e.g. for ubuntu:

 

So to fix this update ca-certificates on your host distribution and then it should be fine.

 

On Thu, Nov 4, 2021 at 1:20 AM Darcy Watkins <dwatkins@...> wrote:

Hi,

 

After syncup of Yocto dunfell, I get the following error:

 

dwatkins@carmd-ed-n11377-docker-dwatkins_apollo17:64bit build $ bitbake ca-certificates -c fetch

Loading cache: 100% |#################################################################################################################################################################################################################################################| Time: 0:00:00

Loaded 4042 entries from dependency cache.

Parsing recipes: 100% |###############################################################################################################################################################################################################################################| Time: 0:00:00

Parsing of 2833 .bb files complete (2815 cached, 18 parsed). 4060 targets, 183 skipped, 0 masked, 0 errors.

WARNING: No recipes available for:

  /home/dwatkins/workspace/mgos/apollo17/meta-mg90-bsp/recipes-kernel/firmware/linux-firmware_git.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mg90-bsp/recipes-kernel/linux/linux-qoriq_4.19.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mgos-distro/meta-openssl-fips/recipes-support/openssl/openssl_1.0.2%.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mgos-core/recipes-support/cherrypy/cherrypy-python_%.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mgos-core/recipes-support/hostapd/hostapd_2.6.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mgos-core/recipes-support/hostapd/hostapd_2.8.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mgos-core/recipes-support/wpa-supplicant/wpa-supplicant_2.6.bbappend

  /home/dwatkins/workspace/mgos/apollo17/meta-mgos-core/recipes-support/wpa-supplicant/wpa-supplicant_2.7.bbappend

NOTE: Resolving any missing task queue dependencies

 

Build Configuration:

BB_VERSION           = "1.46.0"

BUILD_SYS            = "x86_64-linux"

NATIVELSBSTRING      = "universal"

TARGET_SYS           = "arm-poky-linux-gnueabi"

MACHINE              = "mg90"

DISTRO               = "mgos"

DISTRO_VERSION       = "3.1.11"

TUNE_FEATURES        = "arm vfp cortexa7 neon callconvention-hard"

TARGET_FPU           = "hard"

meta-mgos-core       = "main:96c5c6d35f19d16f65100ee29cb23e9a1470876c"

meta-mgos-release    = "main:0825ac63c95db495330848f80d6d68b6f47a77d4"

meta-mg90-bsp        = "main:47d0284b7a337df7587055c405213f9428c94884"

meta-mgos-airprime   = "main:5e8ffb01629c60d282b22e3313740e3b2cf325f4"

meta                 

meta-daisy-cf        

meta-openssl-fips    

meta-sigma           = "main:abf8a7a7408b690dfb0dff796ce8e94b6b661b0d"

meta                 

meta-poky            

meta-yocto-bsp       = "HEAD:0810ac6b926cd901f0619e95f367efc79d4c3159"

meta-oe              

meta-networking      

meta-python          

meta-perl            = "HEAD:814eec96c2a29172da57a425a3609f8b6fcc6afe"

meta-security        

meta-integrity       

meta-security-compliance 

meta-security-isafw  = "HEAD:b76698c788cb8ca632077a972031899ef15025d6"

meta-freescale       = "HEAD:727fd8df20c8ee58474ce15cd5e1459f14bee977"

meta-java            = "HEAD:6e84638d77ac921aac46649095bca5ddbde94d2a"

workspace            = "<unknown>:<unknown>"

 

Initialising tasks: 100% |############################################################################################################################################################################################################################################| Time: 0:00:00

Sstate summary: Wanted 0 Found 0 Missed 0 Current 0 (0% match, 0% complete)

NOTE: No setscene tasks

NOTE: Executing Tasks

WARNING: ca-certificates-20211016-r0 do_fetch: Failed to fetch URL git://salsa.debian.org/debian/ca-certificates.git;protocol=https, attempting MIRRORS if available

ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export PATH="/home/dwatkins/workspace/mgos/apollo17/build/tmp/sysroots-uninative/x86_64-linux/usr/bin:/home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/scripts:/home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/recipe-sysroot-native/usr/bin/allarch-poky-linux:/home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/recipe-sysroot/usr/bin/crossscripts:/home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/recipe-sysroot-native/usr/sbin:/home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/recipe-sysroot-native/usr/bin:/home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/recipe-sysroot-native/sbin:/home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/recipe-sysroot-native/bin:/home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/bitbake/bin:/home/dwatkins/workspace/mgos/apollo17/build/tmp/hosttools"; export HOME="/home/dwatkins"; LANG=C git -c core.fsyncobjectfiles=0 fetch -f --progress "https://salsa.debian.org/debian/ca-certificates.git" refs/*:refs/* failed with exit code 128, no output

ERROR: ca-certificates-20211016-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://salsa.debian.org/debian/ca-certificates.git;protocol=https')

ERROR: Logfile of failure stored in: /home/dwatkins/workspace/mgos/apollo17/build/tmp/work/all-poky-linux/ca-certificates/20211016-r0/temp/log.do_fetch.11215

ERROR: Task (/home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/meta/recipes-support/ca-certificates/ca-certificates_20211016.bb:do_fetch) failed with exit code '1'

NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 1 failed.

 

Summary: 1 task failed:

  /home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/meta/recipes-support/ca-certificates/ca-certificates_20211016.bb:do_fetch

Summary: There were 2 WARNING messages shown.

Summary: There were 2 ERROR messages shown, returning a non-zero exit code.

dwatkins@carmd-ed-n11377-docker-dwatkins_apollo17:64bit build $

 

 

Looking in the git history, I find a recent commit…

 

commit 7158bf0775383eefcec148c47310b4681bfbed86

Author: Alexander Kanavin <alex.kanavin@...>

Date:   Tue Oct 19 17:33:29 2021 +0200

 

    ca-certificates: update 20210119 -> 20211016

    

    (From OE-Core rev: 43aa25b523b2c11ce483ea22435196dfca259b30)

    

    Signed-off-by: Alexander Kanavin <alex@...>

    Signed-off-by: Alexandre Belloni <alexandre.belloni@...>

    Signed-off-by: Richard Purdie <richard.purdie@...>

    (cherry picked from commit c479b8a810d966d7267af1b4dac38a46f55fc547)

    Signed-off-by: Steve Sakoman <steve@...>

    Signed-off-by: Richard Purdie <richard.purdie@...>

 

 

I don’t think this is necessarily the culprit as I likely fetched long ago and have been using cached content since.

 

Is this part of that unauthenticated GIT protocol issue?

 

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com



Open source tool for dealing with Yocto license manifest files #aom #yocto

Janne Kiiskila <janne.kiiskila@...>
 

Are you working with Yocto builds? Do you need to understand what licenses you have? Do you need to understand what changed between two builds/releases/versions?

I know the pain. License manifest will contain everything you need, but it is not in a very easily consumable format, especially the changes.

Pelion has today released an open source tool that allows you to quickly convert the Yocto's license manifest file into:
- a CSV file
- an Excel file (with pivot table)

and by giving the tool two different manifest files - a change summary (again in .CSV and .xlsx-format).

https://github.com/PelionIoT/licensetool

Our small thanks to the Yocto project. I hope others will find this tool useful.

Best Regards,


Janne Kiiskilä
Program/project manager,
Pelion


[meta-rockchip][PATCH] kernel: linux-yocto: fix broken Ethernet MAC controller on RK3399 on 5.14 >= version <= 5.14.11

Quentin Schulz
 

From Linux kernel v5.14 to v5.14.11 (both included), the Ethernet MAC
controller found on RK3399 is not working.

A fix is available in v5.14.12 and later (available also in v5.15)
which is provided here and applied to linux-yocto source tree if
linux-yocto version is of the impacted ones.

The conditional patching is unfortunately required because Honister 3.4
has linux-yocto v5.14.9 and Honister 3.4.1 will have at least
linux-yocto v5.14.14.

Cc: Quentin Schulz <foss+yocto@...>
Signed-off-by: Quentin Schulz <quentin.schulz@...>
---
...-rk-Fix-ethernet-on-rk3399-based-dev.patch | 63 +++++++++++++++++++
.../linux/linux-yocto/5.14-rk3399-mac-fix.scc | 1 +
.../linux/linux-yocto_5.14.bbappend | 11 ++++
3 files changed, 75 insertions(+)
create mode 100644 recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
create mode 100644 recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
create mode 100644 recipes-kernel/linux/linux-yocto_5.14.bbappend

diff --git a/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
new file mode 100644
index 0000000..b2ce7e8
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
@@ -0,0 +1,63 @@
+From 8efe947ea1eace444d78398a31469b30e47ae585 Mon Sep 17 00:00:00 2001
+From: Punit Agrawal <punitagrawal@...>
+Date: Wed, 29 Sep 2021 22:50:49 +0900
+Subject: [PATCH] net: stmmac: dwmac-rk: Fix ethernet on rk3399 based devices
+
+[ Upstream commit aec3f415f7244b7747a7952596971adb0df2f568 ]
+
+Commit 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+while getting rid of a runtime PM warning ended up breaking ethernet
+on rk3399 based devices. By dropping an extra reference to the device,
+the commit ends up enabling suspend / resume of the ethernet device -
+which appears to be broken.
+
+While the issue with runtime pm is being investigated, partially
+revert commit 2d26f6e39afb to restore the network on rk3399.
+
+Fixes: 2d26f6e39afb ("net: stmmac: dwmac-rk: fix unbalanced pm_runtime_enable warnings")
+Suggested-by: Heiko Stuebner <heiko@...>
+Signed-off-by: Punit Agrawal <punitagrawal@...>
+Cc: Michael Riesch <michael.riesch@...>
+Tested-by: Heiko Stuebner <heiko@...>
+Link: https://lore.kernel.org/r/20210929135049.3426058-1-punitagrawal@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@...>
+Signed-off-by: Sasha Levin <sashal@...>
+
+Upstream-Status: Backport [8efe947ea1eace444d78398a31469b30e47ae585]
+---
+ drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+index ed817011a94a..6924a6aacbd5 100644
+--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
+@@ -21,6 +21,7 @@
+ #include <linux/delay.h>
+ #include <linux/mfd/syscon.h>
+ #include <linux/regmap.h>
++#include <linux/pm_runtime.h>
+
+ #include "stmmac_platform.h"
+
+@@ -1528,6 +1529,8 @@ static int rk_gmac_powerup(struct rk_priv_data *bsp_priv)
+ return ret;
+ }
+
++ pm_runtime_get_sync(dev);
++
+ if (bsp_priv->integrated_phy)
+ rk_gmac_integrated_phy_powerup(bsp_priv);
+
+@@ -1539,6 +1542,8 @@ static void rk_gmac_powerdown(struct rk_priv_data *gmac)
+ if (gmac->integrated_phy)
+ rk_gmac_integrated_phy_powerdown(gmac);
+
++ pm_runtime_put_sync(&gmac->pdev->dev);
++
+ phy_power_on(gmac, false);
+ gmac_clk_enable(gmac, false);
+ }
+--
+2.33.1
+
diff --git a/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
new file mode 100644
index 0000000..1ad2bde
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto/5.14-rk3399-mac-fix.scc
@@ -0,0 +1 @@
+patch 0001-net-stmmac-dwmac-rk-Fix-ethernet-on-rk3399-based-dev.patch
diff --git a/recipes-kernel/linux/linux-yocto_5.14.bbappend b/recipes-kernel/linux/linux-yocto_5.14.bbappend
new file mode 100644
index 0000000..5eaa604
--- /dev/null
+++ b/recipes-kernel/linux/linux-yocto_5.14.bbappend
@@ -0,0 +1,11 @@
+FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"
+
+# Fix Ethernet on 5.14 until 5.14.11 (included) for RK3399 MAC controller
+# Conditional patching required because Honister 3.4 has linux-yocto
+# v5.14.9 and Honister 3.4.1 will have at least linux-yocto v5.14.14.
+python __anonymous() {
+ kver = d.getVar('LINUX_VERSION') or ''
+ if bb.utils.is_semver(kver) \
+ and bb.utils.vercmp_string(kver, '5.14.11') <= 0:
+ d.appendVar('SRC_URI', ' file://5.14-rk3399-mac-fix.scc')
+}
--
2.30.2


Yocto Project Status WW46`21

Stephen Jolley
 

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.3.4 has been through QA and is waiting on release approval after discussion of bug 14622, likely will be released.
  • YP 3.1.12 was built but had autobuilder failures so is also being discussed.
  • A request was made to continue hardknott support in the community and this was agreed until Feb/March next year but will not overlap the LTS.
  • Patches to guard against poor performance if servers are unresponsive have been merged along with mirror urls for key components. These should make the system more robust and allow builds to work with infrastructure outages. Fixes are in master and dunfell with hardknott and honister due to have the backports as well.
  • Packagegroups which are also allarch will now raise errors if they depend on anything using the PKG: package renaming mechanism (e.g. debian.bbclass renaming).
  • We continue to see a reduction in the number of patches in “Pending” state. Many thanks to everyone who has taken the time to review patch status and handle accordingly, particularly where they were accepted upstream.
  • Intermittent issues continue to rise and help is very much welcome on these issues. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M1 build date 2021/12/06
  • YP 3.5 M1 Release date 2021/12/17
  • YP 3.5 M2 build date 2022/01/10
  • YP 3.5 M2 Release date 2022/1/21
  • YP 3.5 M3 build date 2022/2/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.3.4 is in review for release
  • YP 3.1.12 is being built
  • YP 3.1.12 Release date 2021/11/26
  • YP 3.4.1 build date 2021/11/22
  • YP 3.4.1 Release date 2021/12/03
  • YP 3.1.13 build date 2021/12/13
  • YP 3.1.13 Release date 2021/12/22
  • YP 3.1.14 build date 2022/01/24
  • YP 3.1.14 Release date 2022/02/04
  • YP 3.4.2 build date 2022/02/07
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

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

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Re: Task vardeps on a variable changed externally

Mohannad Oraby
 

Hi,

I am facing the same problem right now. I have created some new variables e.g., INTERNAL_VARIABLE, added them to BB_ENV_EXTRAWHITE, and in some recipes, I expect that some tasks are executed again, when I change these variables
e.g., do_install[vardeps] = "INTERNAL_VARIABLE"

I have two possible values for this variable. When I set the variable for the first time, everything works and there is no problem, the do_install will run when I change from one value to another. However, if I set the variable again to the old value, and I execite "bitbake recipename" again, this does not work, and this leads to some wrong/old data located in work directory, and also produced in the image.

I tried setting BB_DONT_CACHE, but this did not work at all.

I do not want to always run the tasks i.e., do_install[[nostamp] = "1", I just want it to run again every time I change this INTERNAL_VARIABLE.

Is what I am expecting a normal behavior? Or Yocto does not work this way?

Regards,
Mohannad 


[meta-zephyr][PATCH v3 4/4] zephyr-lvgl: new recipe

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bartosz.golaszewski@...>

This adds a recipe for building the lvgl sample from mainline zephyr
source. We need to include one upstream patch that fixes a build problem
with lvgl and pull in two other modules or otherwise the default config
will fail to build. Currently only the nordic reference devkit for
nrf52840 is supported.

Big thanks to Eilís Ní Fhlannagáin <elizabeth.flanagan@...> for
helping me with that.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
...0001-cmake-added-missing-file-ext-to.patch | 42 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.6.1.inc | 1 +
.../zephyr-kernel/zephyr-kernel-src-2.7.0.inc | 1 +
.../zephyr-kernel/zephyr-kernel-src.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-lvgl.bb | 18 ++++++++
5 files changed, 63 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-lvgl.bb

diff --git a/recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch b/recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
new file mode 100644
index 0000000..6aeca14
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-cmake-added-missing-file-ext-to.patch
@@ -0,0 +1,42 @@
+From 783c1f78c8e39751fe89d0883c8bce7336f55e94 Mon Sep 17 00:00:00 2001
+From: Torsten Rasmussen <Torsten.Rasmussen@...>
+Date: Thu, 19 Aug 2021 08:53:00 +0200
+Subject: [PATCH] cmake: added missing file ext to
+ lv_font_dejavu_16_persian_hebrew.c
+
+CMake >= 3.20 requires file extensions explicitly added to source files.
+
+See CMP0115:
+> Starting in CMake 3.20, CMake prefers all source files to have their
+> extensions explicitly listed:
+
+In the CMakeLists.txt, the file lv_font_dejavu_16_persian_hebrew.c
+was added without its .c extension, causing never CMakes ti fail
+discovering the file.
+
+This has been fixed by correctly add the file as:
+lv_font_dejavu_16_persian_hebrew.c
+
+Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@...>
+---
+Upstream-status: Accepted
+
+ CMakeLists.txt | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 57b07c84..0f433edc 100644
+--- a/CMakeLists.txt
++++ b/CMakeLists.txt
+@@ -58,7 +58,7 @@ zephyr_library_sources(
+ src/lv_misc/lv_utils.c
+
+ src/lv_font/lv_font.c
+- src/lv_font/lv_font_dejavu_16_persian_hebrew
++ src/lv_font/lv_font_dejavu_16_persian_hebrew.c
+ src/lv_font/lv_font_fmt_txt.c
+ src/lv_font/lv_font_loader.c
+ src/lv_font/lv_font_montserrat_12.c
+--
+Gitee
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
index 9f28df7..ce5e067 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc
@@ -2,6 +2,7 @@ SRCREV_FORMAT = "default_cmsis"
SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_lvgl = "31acbaa36e9e74ab88ac81e3d21e7f1d00a71136"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
index f425d9f..b6a6fc4 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.7.0.inc
@@ -2,6 +2,7 @@ SRCREV_FORMAT = "default_cmsis"
SRCREV_cmsis = "b0612c97c1401feeb4160add6462c3627fe90fc7"
SRCREV_default = "3f826560aaf81a444018293bd6acce3c339fe150"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_lvgl = "31acbaa36e9e74ab88ac81e3d21e7f1d00a71136"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
SRCREV_nordic = "a6e5299041f152da5ae0ab17b2e44e088bb96d6d"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index d8b086b..c973c2a 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -14,6 +14,7 @@ SRC_URI = "\
git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/nordic;name=nordic \
git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;branch=main;destsuffix=git/modules/hal/stm32;name=stm32 \
git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/libmetal;name=libmetal \
+ git://github.com/zephyrproject-rtos/lvgl.git;branch=zephyr;protocol=https;destsuffix=git/modules/lib/gui/lvgl;name=lvgl \
git://github.com/zephyrproject-rtos/mbedtls.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/mbedtls;name=mbedtls \
git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/open-amp;name=open-amp \
git://github.com/zephyrproject-rtos/openthread.git;protocol=https;nobranch=1;branch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
diff --git a/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb b/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb
new file mode 100644
index 0000000..4f08fc7
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-lvgl.bb
@@ -0,0 +1,18 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/subsys/display/lvgl"
+ZEPHYR_MODULES:append = "\;${S}/modules/lib/gui/lvgl\;${S}/modules/debug/segger"
+
+# TODO Once more machines and displays are supported, add a PACKAGECONFIG.
+EXTRA_OECMAKE:append =" -DSHIELD=adafruit_2_8_tft_touch_v2"
+
+SRC_URI:append = " \
+ file://0001-cmake-added-missing-file-ext-to.patch;patchdir=modules/lib/gui/lvgl \
+ git://github.com/zephyrproject-rtos/segger.git;protocol=https;nobranch=1;destsuffix=git/modules/debug/segger;name=segger \
+ git://github.com/zephyrproject-rtos/TraceRecorderSource.git;branch=zephyr;protocol=https;destsuffix=git/modules/debug/TraceRecorder;name=TraceRecorderSource \
+"
+
+SRCREV_segger = "3a52ab222133193802d3c3b4d21730b9b1f1d2f6"
+SRCREV_TraceRecorderSource = "36c577727642457b0db7274298a4b96558374832"
+
+COMATIBLE_MACHINE = "(nrf52840dk-nrf52840)"
--
2.30.1


[meta-zephyr][PATCH v3 3/4] zephyr-kernel-src: order git repos alphabetically

Bartosz Golaszewski
 

From: Bartosz Golaszewski <bartosz.golaszewski@...>

As the number of repos pulled gets bigger it's easier to parse them
if they are ordered alphabetically.

Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@...>
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index d8dd3ab..d8b086b 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -13,10 +13,10 @@ SRC_URI = "\
git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;nobranch=1;destsuffix=git/modules/cmsis;name=cmsis \
git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/nordic;name=nordic \
git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;branch=main;destsuffix=git/modules/hal/stm32;name=stm32 \
+ git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/libmetal;name=libmetal \
git://github.com/zephyrproject-rtos/mbedtls.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/mbedtls;name=mbedtls \
git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;nobranch=1;destsuffix=git/modules/lib/open-amp;name=open-amp \
git://github.com/zephyrproject-rtos/openthread.git;protocol=https;nobranch=1;branch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
- git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;nobranch=1;destsuffix=git/modules/hal/libmetal;name=libmetal \
git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;nobranch=1;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
"
S = "${WORKDIR}/git"
--
2.30.1

2101 - 2120 of 57419