|
Re: #av1 #armv6 #raspberrypi #neon
#av1
#armv6
#raspberrypi
#neon
Zoran
So, what is your MACHINE variable set to?
Maybe knowing that, somebody can help. Zee
|
|
|
|
Re: Timing a recipe
Ross Burton <ross@...>
As said, buildstats is *exactly* what you want. There's a forked
toggle quoted messageShow quoted text
pybootchart in oe-core that can visualise the data too. Ross
On Mon, 15 Feb 2021 at 20:08, <rustyhowell@...> wrote:
|
|
|
|
#av1 #armv6 #raspberrypi #neon
#av1
#armv6
#raspberrypi
#neon
safouane maaloul
Hello folks,
I have an issue integrating av1 in yocto. I get the compile error "compiling simd-neon.h requires -mfpu=neon or equivalent". The problem is that i use armv6 (raspberrypi zero w) so i can't exactly do that. Anyone have a workaround this problem ?
Best regards, Safouane.Maaloul
|
|
|
|
Re: Regarding Mender integration
Hi,
Please see my comments in-line. On 16/02/2021 19:48, U RAVI KUMAR wrote: I have some issues while integrating the mender on the yocto... This looks like the patch you/mender try/tries to apply does not work with your u-boot version.[0] [0] https://github.com/mendersoftware/meta-mender/tree/master/meta-mender-core/recipes-bsp/u-boot Which Yocto version do you use? Which Mender version do you use? You could look into creating your own Mender integration[1] instead of the mender class. [1] https://docs.mender.io/system-updates-yocto-project/board-integration/bootloader-support/u-boot/manual-u-boot-integration I think the right place to ask Mender specific questions is here[2]. [2] https://hub.mender.io/ Regards, Robert
|
|
|
|
Re: Keep .bbappend for older Yocto version
On Tue, Feb 16, 2021 at 3:54 PM Jonas Vautherin <jonas.vautherin@...> wrote:
Yes in some layers they do work across releases but That does have some restrictions and maintenance costs eg if you are patching a recipe via a bbappend then use more liberal bbappend names using % wild characters and make sure same patch can apply to different versions of the package etc Usually maintaining per Releaee branch turns out to be less costly over time
|
|
|
|
Re: Keep .bbappend for older Yocto version
Jonas Vautherin
Thank you for the answer :-). Yes, that works, and it seems like it is commonly used already. But because there is a way to define which versions are supported in the machine configuration, I thought there may be a way without branches, i.e. having a layer that actually is compatible with multiple versions. Otherwise what's the point of LAYERSERIES_COMPAT, if the way to move to another version is to branch away? Is that a legacy option? Best,
On Wed, 17 Feb 2021, 00:32 Khem Raj, <raj.khem@...> wrote: perhaps you should create a new branch for this layer which will be
|
|
|
|
Re: Keep .bbappend for older Yocto version
perhaps you should create a new branch for this layer which will be
compatible with gatesgarth, you can seed it with dunfell branch and then make needed changes On Tue, Feb 16, 2021 at 3:02 PM Jonas Vautherin <jonas.vautherin@...> wrote:
|
|
|
|
Re: Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021
Trevor Woerner
On Tue 2021-02-16 @ 12:41:37 PM, akuster808 wrote:
On 2/16/21 11:10 AM, Trevor Woerner wrote:You're welcome :-)Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021Thanks for taking and sending the minutes. I take notes every week, but had stopped sending emails to the list at the end of each meeting. A couple people mentioned privately that they appreciate the notes being formatted for email and sent that way, so I picked it back up again.
|
|
|
|
Keep .bbappend for older Yocto version
Jonas Vautherin
Good evening, I am using Yocto Gatesgarth, and I was just updating a layer that was written for Dunfell. In the `conf/layer.conf`, I can simply add "gatesgarth" to `LAYERSERIES_COMPAT_pocketbeagle`, like so: ``` LAYERSERIES_COMPAT_pocketbeagle = "dunfell gatesgarth" ``` However, this does not seem to work for a `.bbappend`. Let me use this particular layer as an example: it is a BSP that defines `linux-yocto_4.19.bbappend` for Dunfell. In my case, I want to define `linux-yocto_5.4.bbappend` for Gatesgarth. When building with Dunfell, I would like it to use the former, and when building with Gatesgarth, I would like it to use the latter. However, if I keep both `linux-yocto_4.19.bbappend` and `linux-yocto_5.4.bbappend` and try to build with Gatesgarth, it fails with: ``` ERROR: No recipes in default available for: /path/to/recipes-kernel/linux/linux-yocto_4.19.bbappend ``` Which makes sense: Gatesgarth does not provide `linux-yocto_4.19`. Is there a way to keep both `*.bbappend` and have Yocto ignore the ones that do not correspond to its version? Or would that be bad practice anyway? Best Regards, Jonas
|
|
|
|
Re: Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021
Trevor,
On 2/16/21 11:10 AM, Trevor Woerner wrote: Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021Thanks for taking and sending the minutes. -armin
|
|
|
|
Re: Timing a recipe
On Tue, Feb 16, 2021 at 11:43 AM <rustyhowell@...> wrote:
you could also look into using buildstats bbclass https://wiki.yoctoproject.org/wiki/TipsAndTricks/InvestigatingBuildTime
|
|
|
|
Re: Timing a recipe
Rusty Howell
"time bitbake recipe" is perfect for manual things. But I wanted to also measure the recipe times when building the entire image. I ended up creating a bbappend with new pre/post tasks for the main tasks (fetch, unpack, configure, compile, install, package). The pre task drops a timestamp file and the post task reads the file, calculates the elapsed time and logs it to a file. It's a bit clunky but it gives the information I want. Thanks for the help.
|
|
|
|
Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for Feb 16 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == disclaimer == Best efforts are made to ensure the below is accurate and valid. However, errors sometimes happen. If any errors or omissions are found, please feel free to reply to this email with any corrections. == attendees == Trevor Woerner, Trevor Woerner, Stephen Jolly, John Kaldas, Peter Kjellerstedt, Jan-Simon Möller, Armin Kuster, Alexandre Belloni, Steve Sakoman, Mark Morton, Randy MacLeod, Michael Halstead, Scott Murray, Joshua Watt, Yi Fan Yu, Richard Purdie, Jon Mason, Bruce Ashfield, Tim Orling, Paul Barker == notes == - 3.2.2 started building - glibc-2.33 caused build issues in containers - YP has a reputation that it isn’t reproducible (?), we’re better than 99% reproducible - fixed a number of reproducibility issues in many recipes, still some remain - automatic update helper ran, please fixup any issues before -m3 (start of March) - added umask (helps with reproducibility) - still have some autobuilder (AB) issues, please take a look == general == RP: lots of churn due to unintative update and extended tarball issue RP: the state of pseudo is worrying RP: lots of low-hanging fruit wrt reproducibility issues https://autobuilder.yocto.io/pub/repro-fail/2021-2-15-rp/rp/ I’ve removed some of the larger ones Peter: what’s the status of RPM? JPEW: there’s a fundamental problem with reproducibility wrt RPM RP: we’re not going to focus on RPM yet JPEW: you could use ptests and see what happens RP: reproducibility was originally a project that was started with debs, so debs supports reproducibility the best (so far). there’s no good reason why RPMs can’t work, but we assume the non-reproducibility issues with RPMs has something to do with RPM, and not the build itself Randy: high priority valgrind bug, traced to glibc upgrade, traced down to a select(2) call, could look at reverting a patch or two and see what happens RP: we might need to take it upstream Randy: we’ll verity whether or not we need to get upstream involved. do you want a patch to skip it, or wait RP: if we had a patch we could move the bug from high priority to med or low RP: the next high pri bug is ARM libevent. seems to happen more frequently on ARM for some reason JonM: i’ll take a look after the call Randy: rust: rebasing my patches, build running now, if it works i’ll send them to the list. Randy: looked briefly at fetcher changes (from Andreas), will get to it later today or tomorrow (it’s not how the Rust community is doing it, so we’ll have to see if that’s okay) RP: 1804 builder 3 has an issue (missing git user email) MichaelH: oops, i missed that on IRC. i’ll take a look RP: there’s a missing git module, wondering why the bring-up didn’t notice/install it Steve: kernel CVEs Steve: on the weekly CVS reports we whitelist linux-yocto (Bruce applies them but they’re not upstream so it gets missed) i disabled that whitelisting and found over 60 CVEs just in Dunfell. do we want to continue whitelisting them? Armin: typically kernel CVEs say “every possible version” they almost never lock the version down, so i doubt it’s actually 60. creates a lot of work because the list isn’t precise and many could be non-issues for a specific kernel version. Bruce does keep up-to-date, so he brings in a lot of the fixes (from upstream) Bruce: i agree with Armin Bruce: if we bring the fixes into our repositories too early, and then they’re applied upstream, it causes even more work, so ideally it would be preferable to wait until they hit upstream and pull them in that way RP: i like the feedback we’re getting from the automated CVE messages going to the mailing list, but we’re not sure, as a public project, whether we should continue whitelisting the kernel-specific ones AlexB: there’s an overflow issue with some of the older kernels (sub-version number going above 255) Scott: so things like uname might report “wrong” info Bruce: i don’t have major concerns, as a project the best we can do is keeping in sync with upstream (and let the vendor trees do their own thing) RP: we have ~50 reported against master. i think it would be great wrt how we’re seen externally to keep up to date with these things SteveS: as a first step we should probably turn on the visibility RP: it might be depressing to see the count suddenly jump so high as we turn this on ScottM: maybe report, but keep separate? RP: maybe SteveS could look at the tooling to see if we could list them separately JonM: maybe report a little this month, some more next, and then more; add them gradually? RP: in any case i think we need to get this list out there; preferably in a way that doesn’t tarnish our reputation SteveS: I can do a one-off to the mailing list and we can talk about it there Stephen: 3.1.6 should be built next week, do you think dunfell will be ready for a build next week? SteveS: I’d prefer to wait a week or so, i think more pseudo stuff will be trickling in RP: 1st of March is feature freeze for m3, so we either try to slot dunfell in now, or after SteveS: thoughts on pseudo? RP: older glibcs are in a reasonable state, the problems we’re seeing are with 2.33 and uninative. so as long as we stay away from glibc-2.33 i think we’ll be fine SteveS: the other issue are the python3 changes that are rippling through meta-oe RP: hopefully we’ll get through their review. my feeling is that we’ll end up merging those, so we should be able to try the build early next week SteveS: if they pass Armin’s testing, they could be merged in RP: let’s aim for next week RP: there are quite a few reproducibility issues on master now, but they seem “safe” SteveS: i’d like to wait on those, and do them after a next build RP: i’ve traced things down and feel better about a number of them, so i think they’re okay SteveS: okay, we’ll aim for next week TimO: a cryptography module for python now needs rust to build TimO: i’ve been playing with qemu images under libvirt, it doesn’t come up, but i think it can be solved with the qemu manager. would it be okay to add the agent into core, or be a bbappend in meta-virt RP: dependencies? TimO: not much RP: sounds good for core Saul: point me at it TimO: it’s in poky-contrib, i’ll point you at it when i'm done Saul: LTS 2022/2024 are we still targeting “every 2 years” as stated on the wiki? RP: it’s a decision to be made by the YP member companies. the TSC will flag this at the next members meeting: 1) when to start next LTS 2) what happens to the current LTS at that point? funding will influence those decisions. no answer yet Saul: it’s a ways off, but some would like to be able to plan TimO: are we still doing a devday? TrevorW: i’d like to plan something RP: thanks. i’d like to see something. i’m worried about the hole we have in advocacy. the advocacy mailing list is a good place to have that talk. make sure to loop in people like Nico, AWaffa, DReyna, RP: i could find the right people at LF if we need to setup a registration (payment) TimO: i really miss those round-table OED{E|A}Ms that we used to have TrevorW: it’d be great to have a round-table on a Sato replacement TimO: also a gui tester (dogtail?) TrevorW: the big thing will be advertising RP: LF and Nico can help with that TimO: when the next OEHH? TrevorW: next wednesday, feb 24th
|
|
|
|
Re: Regarding Mender integration
U RAVI KUMAR <uppadaravi2511@...>
hello everyone, I have an issue while integrating the mender in yocto. getting error while adding INHERIT +=" mender-full" in the local.conf file .Can anyone pls help me out in solving this issue.
On Fri, Feb 12, 2021 at 9:03 PM U RAVI KUMAR via lists.yoctoproject.org <uppadaravi2511=gmail.com@...> wrote:
|
|
|
|
QA notification for completed autobuilder build (yocto-3.2.2.rc1)
Pokybuild User <pokybuild@...>
A build flagged for QA (yocto-3.2.2.rc1) was completed on the autobuilder and is available at:
https://autobuilder.yocto.io/pub/releases/yocto-3.2.2.rc1 Build hash information: bitbake: 0a3bf681530bd63fc0036ca81ef868ab53fde56c meta-arm: aa63e31b6edb5197764c21434219050ab51f0fbd meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43 meta-intel: 1d866c58534eb1d317b7a674c6e6c57ab9594fb0 meta-kernel: f793168bd19af3d8c5a260dd35f387ed9a31794b meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879 oecore: ebaaee50cb3ac75112827f935c48affaf622ce7f poky: d5d6286a66f46f4523e35e0e3f20cd7396195fdc This is an automated message from the Yocto Project Autobuilder Git: git://git.yoctoproject.org/yocto-autobuilder2 Email: richard.purdie@...
|
|
|
|
Yocto Project Status WW07`21
Stephen Jolley
Current Dev Position: YP 3.3 M3 development Next Deadline: 1st March 2021 YP 3.3 M3 build
Next Team Meetings:
Key Status/Updates:
Ways to contribute:
YP 3.3 Milestone Dates:
Planned upcoming dot releases:
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@...
|
|
|
|
[meta-zephyr][PATCH V2 15/15] README.txt: Fix small typo in email subject prefix
Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@...>
Signed-off-by: Andrei Gherzan <andrei.gherzan@...> --- README.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.txt b/README.txt index ce5338b..5a0ccc7 100644 --- a/README.txt +++ b/README.txt @@ -116,4 +116,4 @@ the patches are identifable. Git can be configured to send mails appropriately when using git send-email: $ git config --local sendemail.to yocto@... -$ git config --local format.subjectPrefix meta-zephy][PATCH +$ git config --local format.subjectPrefix meta-zephyr][PATCH -- 2.30.1
|
|
|
|
[meta-zephyr][PATCH V2 14/15] zephyr-kernel-src: Upgrade 2.5.0-rc3 to rc4
Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@...>
Signed-off-by: Andrei Gherzan <andrei.gherzan@...> --- ...rnel-src-2.5.0-rc3.inc => zephyr-kernel-src-2.5.0-rc4.inc} | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src-2.5.0-rc3.inc => zephyr-kernel-src-2.5.0-rc4.inc} (86%) diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc4.inc similarity index 86% rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc4.inc index 4ee9883..b8aa4dc 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc4.inc @@ -1,5 +1,5 @@ SRCREV_FORMAT = "default_cmsis" -SRCREV_default = "v2.5.0-rc3" +SRCREV_default = "v2.5.0-rc4" SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e" SRCREV_nordic = "f3434da6446380fcdd426dbe2866af21d0d549b6" SRCREV_stm32 = "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635" @@ -7,4 +7,4 @@ SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d" SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94" SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0" -PV = "2.5.0-rc3+git${SRCPV}" +PV = "2.5.0-rc4+git${SRCPV}" -- 2.30.1
|
|
|
|
[meta-zephyr][PATCH V2 13/15] zephyr-flash-pyocd.bbclass: Implement configurable probe IDs to program
Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@...>
Implement logic to configure what probes to program based on the PYOCD_FLASH_IDS variable: 1. by default program all attached probes 2. change default behaviour by listing the probe IDs to flash CONNECT_TIMEOUT_SECONDS was also renamed to maintain consistency with the PYOCD_FLASH_IDS variable. One can query the IDs using `pyocd list`. The value of PYOCD_FLASH_IDS can also be injected into the datastore using BB_ENV_EXTRAWHITE. Signed-off-by: Andrei Gherzan <andrei.gherzan@...> --- README.txt | 9 +++++ classes/zephyr-flash-pyocd.bbclass | 61 ++++++++++++++++++++---------- 2 files changed, 50 insertions(+), 20 deletions(-) diff --git a/README.txt b/README.txt index bda872b..ce5338b 100644 --- a/README.txt +++ b/README.txt @@ -67,6 +67,15 @@ dfu-util and/or pyocd need to be installed in your system. If you observe permission errors or the flashing process seem to hang, follow those instructions: https://github.com/pyocd/pyOCD/tree/master/udev +By default, pyocd tries to flash all the attached probes. This behaviour can be +customised by defining the PYOCD_FLASH_IDS variable as a space-separated list +of IDs. Once that is set, the tool will only try to program these IDs. You can +query for the IDs by running `pyocd list` on your host while having the probes +attached. Besides setting this variable through the build's configuration or +metadata, you can also inject its value from command line with something like: + + $ PYOCD_FLASH_IDS='<ID1> <ID2> <ID3>' BB_ENV_EXTRAWHITE="$BB_ENV_EXTRAWHITE PYOCD_FLASH_IDS" bitbake <TARGET> -c flash_usb + Building and Running Zephyr Tests ================================= Presently only toolchains for ARM, x86, IAMCU and Nios2 are supported. diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass index 4d24e6a..a873be4 100644 --- a/classes/zephyr-flash-pyocd.bbclass +++ b/classes/zephyr-flash-pyocd.bbclass @@ -1,4 +1,5 @@ -CONNECT_TIMEOUT_SECONDS ?= "30" +PYOCD_CONNECT_TIMEOUT_SECONDS ?= "30" +PYOCD_FLASH_IDS ?= "all" python do_flash_usb() { try: @@ -7,26 +8,46 @@ python do_flash_usb() { except ImportError: bb.fatal("Flashing with pyocd needs the relevant python package. Make sure your host provides it or consult your distribution packages for how to install this prerequisite.") - timeout = int(d.getVar('CONNECT_TIMEOUT_SECONDS')) + try: + timeout = int(d.getVar('PYOCD_CONNECT_TIMEOUT_SECONDS')) + except ValueError: + bb.fatal(f"PYOCD_CONNECT_TIMEOUT_SECONDS was set to an invalid value: {d.getVar('PYOCD_CONNECT_TIMEOUT_SECONDS')}.") image = f"{d.getVar('DEPLOY_DIR_IMAGE')}/{d.getVar('PN')}.elf" - bb.plain(f"Attempting to flash {image} to board {d.getVar('BOARD')}") - - # Try to connect to a probe with a timeout - now = 0 - step = 3 - while True: - session = ConnectHelper.session_with_chosen_probe(blocking=False, return_first=True) - if session: - break - if now >= timeout: - bb.fatal("Timeout while trying to connect to a probe. Make sure the target device is connected and the udev is configured accordingly. See <https://github.com/mbedmicro/pyOCD/tree/master/udev> for help.") - bb.warn("Can't connect to the probe. Retrying in %d seconds..." % step) - time.sleep(step) - now += step - - with session: - FileProgrammer(session).program(image) - session.board.target.reset() + ids = d.getVar('PYOCD_FLASH_IDS') + + # Compute the list of IDs to program + if ids == 'all': + ids = [] + for probe in ConnectHelper.get_all_connected_probes(blocking=False): + ids.append(probe.unique_id) + if not ids: + bb.fatal("No probe detected. Make sure your target is connected.") + else: + ids = ids.split() + if not ids: + bb.fatal("No probe requested for programming. Make sure PYOCD_FLASH_IDS is set.") + + # Program each ID + for id in ids: + bb.plain(f"Attempting to flash {os.path.basename(image)} to board {d.getVar('BOARD')} [{id}]") + + # Try to connect to a probe with a timeout + now = 0 + step = 3 + while True: + session = ConnectHelper.session_with_chosen_probe(blocking=False, return_first=True, unique_id=id) + if session: + break + if now >= timeout: + bb.fatal(f"Timeout while trying to connect to probe ID: {id}. Make sure the target device is connected and the udev is configured accordingly. See <https://github.com/mbedmicro/pyOCD/tree/master/udev> for help.") + bb.warn(f"Can't connect to the probe ID: {id}. Retrying in {step} seconds...") + time.sleep(step) + now += step + + # Program the selected probe + with session: + FileProgrammer(session).program(image) + session.board.target.reset() } addtask do_flash_usb after do_deploy -- 2.30.1
|
|
|
|
[meta-zephyr][PATCH V2 12/15] zephyr-flash-pyocd.bbclass: Handle import error for pyocd modules
Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@...>
Signed-off-by: Andrei Gherzan <andrei.gherzan@...> --- classes/zephyr-flash-pyocd.bbclass | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass index df3b631..4d24e6a 100644 --- a/classes/zephyr-flash-pyocd.bbclass +++ b/classes/zephyr-flash-pyocd.bbclass @@ -1,8 +1,11 @@ CONNECT_TIMEOUT_SECONDS ?= "30" python do_flash_usb() { - from pyocd.core.helpers import ConnectHelper - from pyocd.flash.file_programmer import FileProgrammer + try: + from pyocd.core.helpers import ConnectHelper + from pyocd.flash.file_programmer import FileProgrammer + except ImportError: + bb.fatal("Flashing with pyocd needs the relevant python package. Make sure your host provides it or consult your distribution packages for how to install this prerequisite.") timeout = int(d.getVar('CONNECT_TIMEOUT_SECONDS')) image = f"{d.getVar('DEPLOY_DIR_IMAGE')}/{d.getVar('PN')}.elf" -- 2.30.1
|
|
|