1. yocto@lists.yoctoproject.org
  2. Messages
   Date   
Re: preempt-rt

Leon Woestenberg
 

Hello Steve,

On Wed, 3 Nov 2021 at 13:44, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

I have a platform based off a aarm64 Xilinx based kernel, which is not a compliant mainline kernel… so, I will need to go the preemp-rt patch route.


Depends, no mainline kernel? Vendor kernel?

Can you share the machine name? Might be supported already in a layer with -rt.

Regards,

Leon
--
-- 
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com
preempt-rt

Monsees, Steven C (US)
 

 

I have a platform based off a aarm64 Xilinx based kernel, which is not a compliant mainline kernel… so, I will need to go the preemp-rt patch route.

 

Can you supply an example Yocto recipe that applies the patch, doesn’t even have to be arm based… just looking for baseline I might use to carve out support for my platform.

 

Thanks,

Steve
Re: Yocto Unauthenticated git Protocol No Longer Supported

Alexander Kanavin
 


On Tue, 2 Nov 2021 at 21:18, Jay Foster <jay.foster@...> wrote:
Thanks.  Can you provide links to these patches?  I have no choice in using rocko.
Note that the failure was in the do_packagedata task, where it is issuing a 'git -c core.fsyncobjectfiles=0 ls-remote <git-url>' command.  I am using a source premirror so it has not (yet) shown up in do_fetch.

Jay

On 11/2/2021 1:03 PM, Alexander Kanavin wrote:
There are patches in master-next for this. You can backport them, but you really shouldn't be using rocko.

Alex

On Tue, 2 Nov 2021 at 20:50, Jay Foster <jay.foster@...> wrote:
My yocto builds started failing today (November 2, 2021) due to this
(https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git)
issue.  Is there a fix for the yocto fetcher?  I using rocko.

Jay
Re: Yocto Unauthenticated git Protocol No Longer Supported

Jay Foster
 

Thanks.  Can you provide links to these patches?  I have no choice in using rocko.
Note that the failure was in the do_packagedata task, where it is issuing a 'git -c core.fsyncobjectfiles=0 ls-remote <git-url>' command.  I am using a source premirror so it has not (yet) shown up in do_fetch.

Jay

On 11/2/2021 1:03 PM, Alexander Kanavin wrote:
There are patches in master-next for this. You can backport them, but you really shouldn't be using rocko.

Alex

On Tue, 2 Nov 2021 at 20:50, Jay Foster <jay.foster@...> wrote:
My yocto builds started failing today (November 2, 2021) due to this
(https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git)
issue.  Is there a fix for the yocto fetcher?  I using rocko.

Jay
Re: Yocto Unauthenticated git Protocol No Longer Supported

Alexander Kanavin
 

There are patches in master-next for this. You can backport them, but you really shouldn't be using rocko.

Alex


On Tue, 2 Nov 2021 at 20:50, Jay Foster <jay.foster@...> wrote:
My yocto builds started failing today (November 2, 2021) due to this
(https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git)
issue.  Is there a fix for the yocto fetcher?  I using rocko.

Jay
Yocto Unauthenticated git Protocol No Longer Supported

Jay Foster
 

My yocto builds started failing today (November 2, 2021) due to this (https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git) issue.  Is there a fix for the yocto fetcher?  I using rocko.

Jay
Re: yocto preempt-rt

Anuj Mittal
 

On Tue, 2021-11-02 at 17:34 +0100, Leon Woestenberg wrote:
On Tue, Nov 2, 2021 at 5:26 PM Bruce Ashfield
<bruce.ashfield@...> wrote:

Correct.

The rt patches are already integrated on the branches that that
recipe will build out of the linux-yocto repository.
And adding to that, besides the Yocto maintained kernel,  meta-intel
has it's own kernel GIT repo/branch for the kernel and -rt kernel
maintained by Intel.
Right, you can either build linux-yocto-rt or the Intel version with
linux-intel-rt. linux-intel tree might have some platform specific
patches that have either been backported or not upstreamed yet.

The branch & version information is available in the recipe.

Thanks,

Anuj
Re: yocto preempt-rt

Leon Woestenberg
 

On Tue, Nov 2, 2021 at 5:26 PM Bruce Ashfield <bruce.ashfield@...> wrote:

Correct.

The rt patches are already integrated on the branches that that recipe will build out of the linux-yocto repository.
And adding to that, besides the Yocto maintained kernel, meta-intel
has it's own kernel GIT repo/branch for the kernel and -rt kernel
maintained by Intel.

(There might be some overlap in the maintainers, I am not aware of the
differences between those.).

I used the latter with success on Intel Atom 3950 for hard real-time purposes.

Regards,

Leon.
Re: yocto preempt-rt

Bruce Ashfield
 

Correct.

The rt patches are already integrated on the branches that that recipe will build out of the linux-yocto repository.

Bruce

On Tue, Nov 2, 2021 at 12:23 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Is it true that no patch work is required if out under

…/poky/meta/recipes-kernel, there exists  a yocto-linux-rt_##.##.bb recipe that matches your kernel release?, and that it will build the full preemptive RT Kernel ?

 

Thanks,

Steve

 






--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
yocto preempt-rt

Monsees, Steven C (US)
 

 

Is it true that no patch work is required if out under

…/poky/meta/recipes-kernel, there exists  a yocto-linux-rt_##.##.bb recipe that matches your kernel release?, and that it will build the full preemptive RT Kernel ?

 

Thanks,

Steve

 
Yocto Project Status WW43`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.4 has been released. Thanks to everyone who contributed!
  • YP 3.3.4 is due to build this week and will be the last planned release of the hardknott series.
  • YP 3.5 Planning document: https://docs.google.com/document/d/1OXw-NKoL_Vb9RWI6sRPs3zTcAn4hHPtG0Y2BIs7xIzo/edit?usp=sharing
  • Git’s default branch choice could potentially change in the future and we’re seeing service providers like github change policy too. To react to this variability the project really needs to start encoding the branch name used in SRC_URI rather than having a default of master. OE-Core has been converted and there is a script ( scripts/contrib/convert-srcuri.py) to help with conversions. Bitbake will start warning where this is unset soon (patch in master-next).
  • Github has announced that git protocol support will be dropped as of January. We use this in a number of our SRC_URIs. This has been discussed on the architecture list and we have a plan to warn (and later error) on problematic urls and magically map to the correct urls within bitbake. The latter change is easily backported to older bitbake releases and will allow older branches to continue to function without invasive changes. The conversion script mentioned above can also convert github urls.
  • We have seen a drop in the number of patches in “Pending” state, partly thanks to work from Richard to send libtool and gcc patches upstream or otherwise clean them up. Others are also stepping forward to try and reduce the number of patches in Pending state, help would be much appreciated as spread over a number of people this could be quickly handled and reduced.
  • 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 build date 2021/11/01
  • YP 3.3.4 Release date 2021/11/12
  • YP 3.1.12 build date 2021/11/15
  • 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: yocto meta-intel preempt-rt

Monsees, Steven C (US)
 

I will check...

Would you have an example of a recipe that shows how to apply the rt path ?

Thanks,
Steve

-----Original Message-----
From: Leon Woestenberg <leon@...>
Sent: Tuesday, November 2, 2021 8:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] yocto meta-intel preempt-rt

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros. For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.


Hello Steve,

I have been running the PREEMPT_RT for Intel platforms for a few releases, I remember it fetched sources from a GIT branch for -rt (PREEMPT_RT). So it does not need to apply separate patches in that case.

Could you check if this is the case for you as well?

Regards,

Leon.

p.s. Slightly off-topic, I moved away from PREEMPT_RT in favor of task isolation mode, where we use one CPU core in isolated single task mode, for *much* lower latencies than PREEMPT_RT can provide.


--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Nov 2, 2021 at 12:30 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:



I have an Intel based platform, and was looking to implement preempt-rt on it to test.



For Intel, the meta-intel component recipe appears to supports
“linux-intel-rt”, and I can build my intel based platform with this
and it boots… My platform kernel is currently 4.19 based under the
meta-inteI component I do not see the rt patch/patches being applied…



Is meta-intel component recipe building the full preempt-rt support ?, or do I still need to apply the patch ?



Thanks,

Steve
Re: yocto meta-intel preempt-rt

Leon Woestenberg
 

Hello Steve,

I have been running the PREEMPT_RT for Intel platforms for a few
releases, I remember it fetched sources from a GIT branch for -rt
(PREEMPT_RT). So it does not need to apply separate patches in that
case.

Could you check if this is the case for you as well?

Regards,

Leon.

p.s. Slightly off-topic, I moved away from PREEMPT_RT in favor of task
isolation mode, where we use one CPU core in isolated single task
mode, for *much* lower latencies than PREEMPT_RT can provide.


--
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Nov 2, 2021 at 12:30 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@...> wrote:




I have an Intel based platform, and was looking to implement preempt-rt on it to test.



For Intel, the meta-intel component recipe appears to supports “linux-intel-rt”, and I can build my intel based platform with this and it boots… My platform kernel is currently 4.19 based under the meta-inteI component I do not see the rt patch/patches being applied…



Is meta-intel component recipe building the full preempt-rt support ?, or do I still need to apply the patch ?



Thanks,

Steve
yocto meta-intel preempt-rt

Monsees, Steven C (US)
 

 

I have an Intel based platform, and was looking to implement preempt-rt on it to test.

 

For Intel, the meta-intel component recipe appears to supports “linux-intel-rt”, and I can build my intel based platform with this  and it boots…  My platform kernel is currently 4.19 based under the meta-inteI component I do not see the rt patch/patches being applied…

 

Is meta-intel component recipe building the full preempt-rt support ?, or do I still need to apply the patch ?

 

Thanks,

Steve

 
Re: #swupdate integration error. #swupdate

tomzy
 

Hi Vishal,

It looks like there is some problem with `u-boot-fw-utils` compilation. Are you
using U-Boot in your system? Which target do you try to build? As you can see
[here](https://github.com/sbabic/meta-swupdate/blob/f2d65d87485ada5a2d3a744fd7b9e46ec7e6b9f2/recipes-support/swupdate/swupdate.inc#L73)

building update image adds `u-boot-fw-utils` to DEPENDS when U-Boot is used. And
from the logs it looks like the compilation fails because of wrong
`UBOOT_MACHINE` set. See
[here](https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot-fw-utils_2018.01.bb?h=sumo&id=b39f4146de84d7b36861859ec669d9c8e2ca77c6#n13)

 

Cheers,
--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com
[meta-zephyr][PATCH] README.txt: update for honister release

Naveen Saini
 

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
README.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.txt b/README.txt
index 5a0ccc7..9889b01 100644
--- a/README.txt
+++ b/README.txt
@@ -9,9 +9,9 @@ Prerequisites:
==============

This layer depends on:
- Yocto distro (master)
+ Yocto distro (honister)
git://git.yoctoproject.org/poky
- Python layer (meta-openembedded/meta-python)
+ Python layer (meta-openembedded/meta-python) (honister)
git://git.openembedded.org/meta-openembedded

Modify local conf by adding:
--
2.17.1
Re: Specified SDKMACHINE value is not valid

Khem Raj
 

On 11/1/21 3:52 PM, Richard Purdie wrote:
On Mon, 2021-11-01 at 21:50 +0100, Josef Holzmayr wrote:
(re-adding list as I messed up)

Am Mo., 1. Nov. 2021 um 21:45 Uhr schrieb jchludzinski
<jchludzinski@...>:

I want to build this image for a Raspberry Pi, which means ARM.
MACHINE = "raspberrypi3"
(for example, pick your specific one like
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine
)

Is that not possible?

That can't be true!
Building the SDK for an architecture other than x86 is not supported
at the moment.
Not quite true, aarch64 is supported and tested as an SDKMACHINE value.
at one point, I had ppc64le working as SDKMACHINE target as well.


But again, this is about the SDK. And you probably just
want to build the image, where the standard procedures apply. Add the
BSP layer, set MACHINE.
Right, this sounds like MACHINE is wanted for raspberrypi.
Cheers,
Richard
Re: Specified SDKMACHINE value is not valid

Richard Purdie
 

On Mon, 2021-11-01 at 21:50 +0100, Josef Holzmayr wrote:
(re-adding list as I messed up)

Am Mo., 1. Nov. 2021 um 21:45 Uhr schrieb jchludzinski
<jchludzinski@...>:

I want to build this image for a Raspberry Pi, which means ARM.
MACHINE = "raspberrypi3"
(for example, pick your specific one like
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine
)

Is that not possible?

That can't be true!
Building the SDK for an architecture other than x86 is not supported
at the moment.
Not quite true, aarch64 is supported and tested as an SDKMACHINE value.

But again, this is about the SDK. And you probably just
want to build the image, where the standard procedures apply. Add the
BSP layer, set MACHINE.
Right, this sounds like MACHINE is wanted for raspberrypi.

Cheers,

Richard
Re: Specified SDKMACHINE value is not valid

Josef Holzmayr
 

(re-adding list as I messed up)

Am Mo., 1. Nov. 2021 um 21:45 Uhr schrieb jchludzinski
<jchludzinski@...>:

I want to build this image for a Raspberry Pi, which means ARM.
MACHINE = "raspberrypi3"
(for example, pick your specific one like
http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/tree/conf/machine
)

Is that not possible?

That can't be true!
Building the SDK for an architecture other than x86 is not supported
at the moment. But again, this is about the SDK. And you probably just
want to build the image, where the standard procedures apply. Add the
BSP layer, set MACHINE.

---John


On 2021-11-01 05:55, Josef Holzmayr wrote:
jchludzinski via lists.yoctoproject.org [1]
<jchludzinski=vivaldi.net@...> schrieb am Mo., 1.
Nov. 2021, 07:27:

NEWBIE question!

I tried building and I get: "_Specified SDKMACHINE value is not
valid_"

pi@raspberrypi ~/p/build> bitbake core-image-minimal
/usr/lib/python3/dist-packages/html5lib/_trie/_base.py:3:
DeprecationWarning: Using or importing the ABCs from 'collections'
instead of from 'collections.abc' is deprecated, and in 3.8 it will
stop working
from collections import Mapping
WARNING: Host distribution "raspbian-10" has not been validated with
this version of the build system; you may possibly experience
unexpected failures. It is recommended that you use a tested
distribution.
ERROR: OE-core's config sanity checker detected a potential
misconfiguration.
Either fix the cause of this error or at your own risk disable
the checker (see sanity.conf).
Following is the list of potential problems / advisories:

Specified SDKMACHINE value is not valid

Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit
code.
I've tried setting SDKMACHINE to 'arm' and 'qemuarm' but get the
same message?
SDKMACHINE only accepts x86, in either 32 or 64 bit variants, see
https://docs.yoctoproject.org/ref-manual/variables.html#term-SDKMACHINE

Obviously I failed to do something (properly)?

Ideas?

Links:
------
[1] http://lists.yoctoproject.org
M+ & H bugs with Milestone Movements WW44

Stephen Jolley
 

All,

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

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

12917

Warnings from nightly-multilib builds (build-deps)

kai.kang@...

kai.kang@...

3.4 M4

3.5

 

13338

SDK  build fails if image contains bash

randy.macleod@...

unassigned@...

3.4 M4

3.5 M1

 

13766

Using TCLIB=musl results in SDKs producing incompatible binaries

randy.macleod@...

sakib.sajal@...

3.5 M3

3.5 M1

 

14126

resolvconf incompatible with busybox flock

randy.macleod@...

newcomer@...

3.4 M4

3.5 M2

 

14157

git fetcher: consider using different git commands for repo packing, eliminating "git pack-redundant"

randy.macleod@...

newcomer@...

3.4 M4

3.5 M1

 

14185

Git 2.30.0 defaults to main

randy.macleod@...

richard.purdie@...

3.4 M4

3.5 M1

 

14522

qemuppc doesn't shutdown within timeout (serial console issues)

randy.macleod@...

randy.macleod@...

3.6

3.5

 

14553

insane.bbclass: host-user-contaminated QA doesn't skip the home directory

randy.macleod@...

kiran.surendran@...

3.4 M4

3.5 M1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 
2201 - 2220 of 57387