|
Re: [meta-zephyr][PATCH 2/2] nrf52840dk_nrf52840.conf: Add nRF52840 DK support
Naveen Saini
So far, MACHINE configurations are named using '-' instead of '_' . Could you use change it ?
toggle quoted messageShow quoted text
Regards, Naveen
-----Original Message-----
|
|
|
|
Yocto Technical Team Minutes, Engineering Sync, for May 18, 2021
Trevor Woerner
Yocto Technical Team Minutes, Engineering Sync, for May 18, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit == announcements == The upcoming Yocto Project Summit is taking place May 25-26 2021 details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/ registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501 == 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, Stephen Jolley, Peter Kjellerstedt, Steve Sakoman, Joshua Watt, Scott Murray, Michael Halstead, Ross Burton, Randy MacLeod, Tim Orling, Jon Mason, Jan-Simon Möller, Alexandre Belloni, Bruce Ashfield, Richard Purdie, Trevor Gamblin, Tony Tascioglu, Alejandro H == notes == - 3.2.4 was released (gatesgarth), this is the last 3.2.x release before community support - 3.3.1 is in QA (hardknott) - round of AUH updates being added now - Anuj not available, RP acting as maintainer for hardknott - huge drop in CVEs against master - multiconfig issues in bitbake - smp enabled on qemu arm/x86 and switched to newer MACHINE for x86 - OOM issue tracked to glibc - bitbake heartbeat events causing bitbake to hang, patch pending - sstate bug tracked down (thanks JaMa), fix merged - enabled more resource control == general == RP: the bitbake heartbeat issues seems to be cause by additional logging that was added RP: mips/ppc/arm glibc usermode testing seems to cause an OOM issues (it was found to be using 83GB and up) Ross: that’s a lot of memory for a glibc test RP: appears to loop infinitely, even if glibc exits, it leaves things behind that eat up memory. there are some tests that segfault in malloc(), seeing 12GB of memory being used, we might have to get rid of them until we can figure it out. this seems unloved, if nobody fixes this we'll pull it out Ross: glibc tests running inside qemu-user? Ross: what about downgrading qemu RP: the tests are things we supply (system mode and user mode) x86 is fast enough (thanks to kvm) that they can run okay, but off architectures struggle Ross: hopefully we’ll just find some tests to disable (if they’re not important enough) RP: i’ve identified 4 tests specifically (e.g. pthread timed locked loop) Ross: be interesting to run on real hardware to see if there’s an actual leak in qemu or an issue with the test RP: maybe we can add a resource constraint so qemu dies and doesn’t take the whole system down with it instead Ross: we can look at it from an arm point of view RP: this is an oe-selftest, so not run on arm RP: rpm and deb compression not covered, and we know rpm (for example) is using all available threads (because it uses liblzma directly instead of xz) so our constraints aren’t trickling down to tools like this. we need to look to see if there are other places and examples of this happening RP: open letter about challenges (maintainers, resources, contributions to day-to-day running of an open source project). was written because people have asked me to. let me know if you know of anyone wanting to follow up. for example, it would be nice to know who is using the project (and list it publicly). spread the word. see: https://lists.openembedded.org/g/openembedded-architecture/topic/open_source_maintainers_an/82722442 ScottM: multiconfig issues on hardknott? any details? about to start some dunfell stuff RP: i don’t think some things have been backported to dunfell, a fix was added to master but it didn’t fix the problem. looked at it last week but got dragged away by other things. JPEW: we use multiconfig a lot, i’ll take a look at it RP: instead of a deferred list that is continuously updated, i want it to calculate things once (the rehash list), so take a look at what’s in master-next. it shouldn’t be too hard to pull back into dunfell JPEW: we use dunfell at work, so it shouldn't be too hard to test. i can test master-next at home RP: the master-next patch should apply to dunfell quite easily RP: i’m worried about multiconfig RP: we’ve improved the sstate cleanups quite a bit, tmp cleanliness is quite good (hardknott) but people are writing recipes that don’t care if data is machine-specific, this causes multiconfig to blow up. people are writing bad recipes and then complaining when their bad recipes blow things up JPEW: how to tell if recipe is bad? can we automate something? RP: no, not easily JPEW: the problem happens when all multiconfigs share the same tmp directory? RP: yes. writing a test would be hard, it would have to go into oe not bitbake JPEW: curious to know how many people are using multiconfig and using multiconfig with tmp directories RP: according to irc, many Ross: i think there are lots of people using multiconfig too soon, multiconfig is overkill for them, and then they end up abusing the tmp dirctory JPEW: because multiconfig uses a common tmp directory by default? Ross: yes AlejandroH: i submitted doc fix to recommend people use separate tmp dirs when using multiconfig JPEW: i will be talking about it next week in my hands-on class at the YP Summit RP: to Ross’s point, too many people are now turning to multiconfig to build completely separate builds for multiple separate machines. this ignores how the build works, historically ScottM: sstate stamps are not machine-specific RP: exactly. i think we have to figure out how to detect it, but not sure TrevorW: do we want to steer people away from using multiconfig to build unrelated images for unrelated machines? RP: i don’t think we can, i think this is what people have been wanting, so we need to make sure people are doing it right. JPEW: on the stamp files, would it be possible (expedient) to run bitbake in a way that all it does is generate the stamp files for all tasks? then maybe we could run bitbake to generate all these stamps and then look for overlaps? RP: that’s what deferred tasks are. where it sees sstate stamp files that overlap it will do one first, then look at the other overlapping ones. ideally doing one first will put stuff into sstate that the others can then use. so it does do these checks. the problem is that when there are mistakes in the recipes these tasks don’t actually have anything to do with each other: 1. hashes are identical or not (deferred tasks) 2. checks for stamp overlaps (don’t run 2 tasks with the same hash) TimO: that explains why i’m not seeing issues because i always build with separate tmp dirs. we can use shared download dir and shared sstate dirs, but it’s only with shared tmp dirs? RP: yes. but you will be seeing deferred tasks, they just won’t interfere with each other if you’re using separate tmp dirs AlejandroH: i test dunfell multiconfig but haven’t seen it (because i too use separate tmp dirs for each build) JPEW: in theory we should be able to use the same tmp dir, we just have to do it right RP: actually, in my testing i have been using separate tmp dirs, but i’m still seeing issues. so i don’t think separate tmp dirs is completely related. qemu cross wrapper script was building it twice and the license was the same but causes a rehash event for one of the builds, this is what starts the problems. so the cause is: deferred builds, multiconfig, reusing hashes TrevorW: cancel next week’s call due to YP Summit? RP: (gathers consensus) agreed RP: software bill of materials, SBOM (in the US) we don’t have one currently, but we could do something similar following the model of the license SPDX. this could really put our project in the limelight Randy: i think Saul has looked into this TrevorW: i’ll add it to the OEDVM list JPEW: we have a tool internally that does something like this, if Saul is working on it then i’d like to be looped in RP: meta-doubleopen seems to be doing something like this: https://github.com/doubleopen-project/meta-doubleopen https://lists.yoctoproject.org/g/yocto/topic/vs_vs_yocto_make/82910309 we don’t need multiple solutions, we need something simple and be able to say we have it, then build on it JPEW: do you do that at WR? RP: the tool i linked does SPDX PeterK: easy as long as it’s open source, the closed code we bring in gets harder TrevorW: isn’t this what we get with buildhistory? RP: yes, apart from the spdx format JPEW: since we’re building everything, we have all the data RP: i’m sure there will be lots of corner cases, but we need to say “we do this” JPEW: json format in version 2 RP: and we can translate accordingly (xls, rdf, yaml, json, xml) RP: let’s use the licensing email list to discuss this
|
|
|
|
Makefile environment variables do not work on some host
Aymeric Dumaz <aymericdumaz@...>
Hello,
I have created a recipe to call multiple makefile and set a variable if it's not defined inside them, meaning I set it before "oe_runmake". It works as expected on a Debian testing, but with a Ubuntu base chroot it does not. I have written a simple recipe and the steps I used to configure the Ubuntu chroot; on Debian I can see "var -bar-" inside log.do_compile, but on Ubuntu it will only be "var --". I'm not sure where the bug is located; I'm using Dunfell but I always thought the host running Yocto was not relevant during the compilation. Thanks. ### Ubuntu chroot: download the image [0], extract it and start the chroot, update it [1], add the en_US.UTF-8 locale [2], install Yocto dependencies [3], then add an user. ### testvar.bb SRC_URI = "file://Makefile" LICENSE = "CLOSED" S = "${WORKDIR}" do_compile() { FOO=bar oe_runmake } ### Makefile all: @echo "var -$(FOO)-" clean: [0] http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04.2-base-amd64.tar.gz [1] apt update && apt upgrade [2] apt install locales && dpkg-reconfigure locales - select "159" then "3" [3] apt install python3 python3-distutils binutils chrpath cpio cpp diffstat g++ gawk gcc git make patch wget xxd
|
|
|
|
Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1
Jon Mason
On Tue, May 18, 2021 at 11:24 AM Zbigniew Bodek
<zbigniew.bodek@...> wrote: My recommendation would be to pull that patch out and apply it directly on top of v2.5.0 (assuming that is feasible). Maybe even asking the upstream zephyr project to port this to v2.5.0 and make it v2.5.1 would be the optimal solution. As far as a master-next branch, that would be up to Naveen.
|
|
|
|
Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1
Jon Mason
On Tue, May 18, 2021 at 8:30 AM Wojciech Zmuda <zmuda.w@...> wrote:
Do we really want to have Zephyr on a release candidate? IMHO, we should never be doing this, as we should want the kernel in meta-zephyr to be as stable as possible. If this is really desired, perhaps a master-next branch for things like this. Thanks, Jon ---
|
|
|
|
[meta-zephyr][PATCH] qemuzephyrrunner.py: use existing qemu conf file
Jon Mason
Read the generated QEMU conf file, instead of using hard coded values.
This allows for machines not conforming to the hard coded values to work with testimage. Signed-off-by: Jon Mason <jon.mason@...> --- conf/machine/qemu-x86.conf | 1 + lib/oeqa/utils/qemuzephyrrunner.py | 89 +++++++++++++++++++++++++----- 2 files changed, 77 insertions(+), 13 deletions(-) diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf index d85c22215520..ce79b5b1f510 100644 --- a/conf/machine/qemu-x86.conf +++ b/conf/machine/qemu-x86.conf @@ -9,6 +9,7 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot" # For runqemu QB_SYSTEM_NAME = "qemu-system-i386" +QB_MACHINE = "-machine type=pc-1.3" QB_OPT_APPEND = "-nographic -no-acpi" QB_CPU_x86 = "-cpu qemu32,+nx,+pae" QB_CPU_KVM_x86 = "-cpu kvm32" diff --git a/lib/oeqa/utils/qemuzephyrrunner.py b/lib/oeqa/utils/qemuzephyrrunner.py index e8a1bd4544cf..a1ed30be1ca8 100644 --- a/lib/oeqa/utils/qemuzephyrrunner.py +++ b/lib/oeqa/utils/qemuzephyrrunner.py @@ -14,6 +14,7 @@ import select import bb import tempfile import sys +import configparser from oeqa.utils.qemurunner import QemuRunner class QemuZephyrRunner(QemuRunner): @@ -42,6 +43,72 @@ class QemuZephyrRunner(QemuRunner): # 5 minutes timeout... self.endtime = time.time() + 60*5 + self.qemuboot = False + self.d = {'QB_KERNEL_ROOT': '/dev/vda'} + + def get(self, key): + if key in self.d: + return self.d.get(key) + elif os.getenv(key): + return os.getenv(key) + else: + return '' + + def set(self, key, value): + self.d[key] = value + + def read_qemuboot(self): + if not self.qemuboot: + if self.get('DEPLOY_DIR_IMAGE'): + deploy_dir_image = self.get('DEPLOY_DIR_IMAGE') + else: + bb.warning("Can't find qemuboot conf file, DEPLOY_DIR_IMAGE is NULL!") + return + + if self.rootfs and not os.path.exists(self.rootfs): + # Lazy rootfs + machine = self.get('MACHINE') + if not machine: + machine = os.path.basename(deploy_dir_image) + self.qemuboot = "%s/%s-%s.qemuboot.conf" % (deploy_dir_image, + self.rootfs, machine) + else: + cmd = 'ls -t %s/*.qemuboot.conf' % deploy_dir_image + try: + qbs = subprocess.check_output(cmd, shell=True).decode('utf-8') + except subprocess.CalledProcessError as err: + raise RunQemuError(err) + if qbs: + for qb in qbs.split(): + # Don't use initramfs when other choices unless fstype is ramfs + if '-initramfs-' in os.path.basename(qb) and self.fstype != 'cpio.gz': + continue + self.qemuboot = qb + break + if not self.qemuboot: + # Use the first one when no choice + self.qemuboot = qbs.split()[0] + self.qbconfload = True + + if not self.qemuboot: + # If we haven't found a .qemuboot.conf at this point it probably + # doesn't exist, continue without + return + + if not os.path.exists(self.qemuboot): + raise RunQemuError("Failed to find %s (wrong image name or BSP does not support running under qemu?)." % self.qemuboot) + + cf = configparser.ConfigParser() + cf.read(self.qemuboot) + for k, v in cf.items('config_bsp'): + k_upper = k.upper() + if v.startswith("../"): + v = os.path.abspath(os.path.dirname(self.qemuboot) + "/" + v) + elif v == ".": + v = os.path.dirname(self.qemuboot) + self.set(k_upper, v) + + def create_socket(self): bb.note("waiting at most %s seconds for qemu pid" % self.runqemutime) tries = self.runqemutime @@ -66,7 +133,6 @@ class QemuZephyrRunner(QemuRunner): if not os.path.exists(self.tmpdir): bb.error("Invalid TMPDIR path %s" % self.tmpdir) - #logger.error("Invalid TMPDIR path %s" % self.tmpdir) return False else: os.environ["OE_TMPDIR"] = self.tmpdir @@ -82,21 +148,18 @@ class QemuZephyrRunner(QemuRunner): bb.error("Invalid kernel path: %s" % self.kernel) return False - self.qemuparams = '-nographic -serial unix:%s,server' % (self.socketname) - qemu_binary = "" - if 'arm' in self.machine or 'cortex' in self.machine: - qemu_binary = 'qemu-system-arm' - qemu_machine_args = '-machine lm3s6965evb' - elif 'x86' in self.machine: - qemu_binary = 'qemu-system-i386' - qemu_machine_args = '-machine type=pc-1.3 -no-acpi -nographic -cpu qemu32,+nx,+pae' - elif 'nios2' in self.machine: - qemu_binary = 'qemu-system-nios2' - qemu_machine_args = '-machine altera_10m50_zephyr' - else: + self.qemuparams = '-serial unix:%s,server' % (self.socketname) + + self.read_qemuboot() + qemu_binary = self.get('QB_SYSTEM_NAME') + qemu_machine_args = self.get('QB_MACHINE') + if qemu_binary == "" or qemu_machine_args == "": bb.error("Unsupported QEMU: %s" % self.machine) return False + self.qemuparams += " %s " %self.get('QB_OPT_APPEND') + self.qemuparams += " %s " %self.get('QB_CPU') + self.origchldhandler = signal.getsignal(signal.SIGCHLD) signal.signal(signal.SIGCHLD, self.handleSIGCHLD) -- 2.20.1
|
|
|
|
Yocto Project Status WW20`21
Stephen Jolley
Current Dev Position: YP 3.4 M1 Next Deadline: 7th June 2021 YP 3.4 M1 build
Next Team Meetings:
Key Status/Updates:
https://lists.openembedded.org/g/openembedded-architecture/topic/open_source_maintainers_an/82722442
We are working to identify the load pattern on the infrastructure that seems to trigger these.
Ways to contribute:
YP 3.4 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@...
|
|
|
|
VS: VS: [yocto] Make do_image_complete wait for an earlier task
Mikko Murto
-----Alkuperäinen viesti-----Thanks, I'll give that a go! I did have a quick look and you're going further than I'd been thinking of, at leastI'll give do_populate_lic task a look. I'm actually hoping we could simply what we're doing today however the more IWe're working on this as a part of a workflow that utilizes the SPDX files. Our tool uploads the source code archived by the layer to a Fossology instance, after which it queries Fossology's API for the file level license and copyright data. We then utilize OSS Review Toolkit by converting the SPDX file to ORT's data format and use ORT's Evaluator and Reporter to evaluate license compliance and create notice files and other reports. This is done to evaluate the image not based on the declared licenses of packages, which may omit some licenses of individual files, but those individual files. For the SBOM information, we do need to somehow make something as usefulThe huge SPDX files created might indeed not be super useful for all use cases. Long term, some kind of configurability regarding e.g. the level of granularity (packages vs. files) could enable the layer to be used for more use cases than the one we're currently working on. Mikko
|
|
|
|
[meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1
Wojciech Zmuda
From: Zbigniew Bodek <zbigniew.bodek@...>
Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...> --- 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 5ee40d4..9fc08ba 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc @@ -2,7 +2,7 @@ LICENSE = "Apache-2.0" LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc" # Default to a stable version -PREFERRED_VERSION_zephyr-kernel ??= "2.5.0" +PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1" include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc inherit cmake -- 2.25.1
|
|
|
|
[meta-zephyr][PATCH 1/2] zephyr-kernel-src-2.6.0-rc1.inc: Add support for zephyr kernel version 2.6.0-rc1
Wojciech Zmuda
From: Zbigniew Bodek <zbigniew.bodek@...>
This version can be selected defining PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1" Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...> --- .../zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 10 ++++++++++ 1 file changed, 10 insertions(+) create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc new file mode 100644 index 0000000..6ea1593 --- /dev/null +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc @@ -0,0 +1,10 @@ +SRCREV_FORMAT = "default_cmsis" +SRCREV_default = "v2.6.0-rc1" +SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e" +SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681" +SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df" +SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef" +SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb" +SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0" + +PV = "2.6.0-rc1+git${SRCPV}" -- 2.25.1
|
|
|
|
[meta-zephyr][PATCH 0/2] Update Zephyr version to 2.6.0-rc1
Wojciech Zmuda
From: Wojciech Zmuda <wojciech.zmuda@...>
2.6.0-rc1 has been released 9 days ago and contains a vast number of improvements. Release notes available here: https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.6.0-rc1 I'm sending this patch set on behalf of the original author Zbigniew Bodek <zbigniew.bodek@...> Zbigniew Bodek (2): zephyr-kernel-src-2.6.0-rc1.inc: Add support for zephyr kernel version 2.6.0-rc1 zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1 .../zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 10 ++++++++++ recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc -- 2.25.1
|
|
|
|
[meta-zephyr][PATCH 2/2] nrf52840dk_nrf52840.conf: Add nRF52840 DK support
Wojciech Zmuda
From: Wojciech Zmuda <wojciech.zmuda@...>
Add support for Nordic Semiconductor nRF52840 Development Kit board. This is a generic MACHINE over nRF52 SoC family config plus PyOCD flashing ability. Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...> --- conf/machine/nrf52840dk_nrf52840.conf | 8 ++++++++ 1 file changed, 8 insertions(+) create mode 100644 conf/machine/nrf52840dk_nrf52840.conf diff --git a/conf/machine/nrf52840dk_nrf52840.conf b/conf/machine/nrf52840dk_nrf52840.conf new file mode 100644 index 0000000..0aa50e0 --- /dev/null +++ b/conf/machine/nrf52840dk_nrf52840.conf @@ -0,0 +1,8 @@ +#@TYPE: Machine +#@NAME: nrf52840dk_nrf52840 + +#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52840 Development Kit. + +require conf/machine/include/nrf52.inc +ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd" +ARCH_nrf52840dk_nrf52840 = "arm" -- 2.25.1
|
|
|
|
[meta-zephyr][PATCH 1/2] nrf52832.inc: Rename to nrf52.inc
Wojciech Zmuda
From: Wojciech Zmuda <wojciech.zmuda@...>
The file is so generic anyway it can be targeted for the nRF52 family without any harm. Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...> --- conf/machine/96b-nitrogen.conf | 2 +- conf/machine/include/{nrf52832.inc => nrf52.inc} | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) rename conf/machine/include/{nrf52832.inc => nrf52.inc} (86%) diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf index 998db4c..48f2041 100644 --- a/conf/machine/96b-nitrogen.conf +++ b/conf/machine/96b-nitrogen.conf @@ -3,6 +3,6 @@ #@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board. -require conf/machine/include/nrf52832.inc +require conf/machine/include/nrf52.inc ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd" ARCH_96b-nitrogen = "arm" diff --git a/conf/machine/include/nrf52832.inc b/conf/machine/include/nrf52.inc similarity index 86% rename from conf/machine/include/nrf52832.inc rename to conf/machine/include/nrf52.inc index e938aa6..d22f8bc 100644 --- a/conf/machine/include/nrf52832.inc +++ b/conf/machine/include/nrf52.inc @@ -1,7 +1,7 @@ #@TYPE: Machine -#@NAME: nrf52832 +#@NAME: nrf52xxx -#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52832 (Cortex-M4) SoC. +#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52xxx (Cortex-M4) SoC. require conf/machine/include/tune-cortexm4.inc -- 2.25.1
|
|
|
|
[meta-zephyr][PATCH 0/2] Add nRF52840 DK support
Wojciech Zmuda
From: Wojciech Zmuda <wojciech.zmuda@...>
This patch set adds support for Nordic Semiconductor nRF5284 Development Kit board. Since there already is nRF52xx family chip support added (specifically nRF52832 used in 96Boards Nitrogen), make this support a bit more generic to cover the whole family, then add a platform-specific configs for both nRF-based boards on top of it. The change has been tested with the actual nRF52840 DK board by building and flashing with `-c flash_usb` some sample applications. Wojciech Zmuda (2): nrf52832.inc: Rename to nrf52.inc nrf52840dk_nrf52840.conf: Add nRF52840 DK support conf/machine/96b-nitrogen.conf | 2 +- conf/machine/include/{nrf52832.inc => nrf52.inc} | 4 ++-- conf/machine/nrf52840dk_nrf52840.conf | 8 ++++++++ 3 files changed, 11 insertions(+), 3 deletions(-) rename conf/machine/include/{nrf52832.inc => nrf52.inc} (86%) create mode 100644 conf/machine/nrf52840dk_nrf52840.conf -- 2.25.1
|
|
|
|
Re: VS: [yocto] Make do_image_complete wait for an earlier task
Richard Purdie
On Tue, 2021-05-18 at 07:09 +0000, Mikko Murto wrote:
I don't have much to go on but guessing, if you run some test and then rerun thatLähettäjä: Richard Purdie <richard.purdie@...>That is odd indeed. I need to give it another go. As for accounting for sstate, test, the second build would come from sstate. If a build comes from sstate, it will skip tasks that precede the sstate artefact. More specifically, if sstate exists for do_packagedata, it would skip any tasks preceeding that task including your do_create_spdx task. There is no direct dependency from do_image_complete on the do_create_spdx tasks. You can add: do_rootfs[recrdeptask] += "do_create_spdx" but this will have the side effect that the build will never use sstate and always rebuild since that task isn't an sstate task. I did have a quick look and you're going further than I'd been thinking of, atI've been giving some thought to SDPX and SBOM during our build process so IPublic at https://github.com/doubleopen-project/meta-doubleopen. The usual least initially. What I'm thinking of in core YP initially is to have do_packagedata generate SPDX data for the output packaged files in do_package/do_packagedata. I noticed you go further and process all the input sources and I'm not sure we're ready to do that yet. Doing it at do_package/do_packagedata time would still access any of the sources included from a debug perspective, hence it should correctly find the shipped manifest/license info without the complexity of having to scan all the sources For your level of source scanning, I'd look at the existing do_populate_lic task which is sstate and generates license info. I think I'd be in favour of totally replacing that with something generating spdx output... I'm actually hoping we could simply what we're doing today however the more I look at all the information you can put into SPDX, the more I worry that whilst we can generate tons of data and huge SPDX files, I'm not sure they're actually useful to anyone to actually use :/. For the SBOM information, we do need to somehow make something as useful as our normal manifest to people for this to be useful and adopted, at least from my perspective. Cheers, Richard
|
|
|
|
Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.3.1.rc1)
Sangeeta Jain
Hi all,
toggle quoted messageShow quoted text
Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.1.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 is next Thursday, May 20. Thanks, Sangeeta
-----Original Message-----
|
|
|
|
VS: [yocto] Make do_image_complete wait for an earlier task
Mikko Murto
Lähettäjä: Richard Purdie <richard.purdie@...>That is odd indeed. I need to give it another go. As for accounting for sstate, no, at least not intentionally. I've been giving some thought to SDPX and SBOM during our build process so IPublic at https://github.com/doubleopen-project/meta-doubleopen. The usual disclaimers about PoC-level spaghetti apply; all questions and comments very much appreciated! 😊 Mikko
|
|
|
|
Re: Make do_image_complete wait for an earlier task
Richard Purdie
On Tue, 2021-05-18 at 06:15 +0000, Mikko Murto wrote:
Hi,This seems a little odd since image.bbclass has: do_rootfs[recrdeptask] += "do_packagedata" which means do_rootfs should only happen after all do_packagedata have run. Your task is added before do_packagedata. do_image and do_image_complete should run after do_rootfs. I'm wondering if the issue is more to do with reuse of previous build artefacts where sstate is involved. Does your added task account for sstate? I've been giving some thought to SDPX and SBOM during our build process so I am curious what you're doing, is the work public anywhere? Cheers, Richard
|
|
|
|
Make do_image_complete wait for an earlier task
Mikko Murto
Hi,
I've created a task do_create_spdx that gets some data from packages after do_package. The task is currently added with `addtask do_create_spdx after do_package before do_packagedata` The data is then enriched and combined in do_image_complete by adding the combining function to IMAGE_POSTPROCESS_COMMAND. For the most part everything works as expected, but for some packages do_create_spdx does not complete in time for the combination step in do_image_complete. Is there a way for me force do_image_complete to wait for do_create_spdx to have been completed for all packages? Best regards, Mikko Murto
|
|
|
|
Re: vlc 3.0.11 package issue
On Mon, May 17, 2021 at 10:57 PM sateesh m <sateesh0457@...> wrote:
usually it means lua version mismatch. You might be hitting same issue as reported here https://trac.videolan.org/vlc/ticket/25036 there is a patch attached to that ticket. Please try to apply that and see if it helps. https://trac.videolan.org/vlc/attachment/ticket/25036/0001-lua-Make-scripts-compatible-to-lua-5.4.patch How can I fix this issue. Is I need to apply patch for this?if patch is present please give me guidance. Can anybody knows this problem help me.
|
|
|