|
[meta-selinux][dunfell][PATCH] libselinux: Backport NULL pointer fix from 3.1
Jonas Brich
Attached the diff.
Thanks
BMW Car IT GmbH Jonas Brich Spezialist Entwicklung Lise-Meitner-Str. 14 89081 Ulm Tel.: +49 731 3780 4292 Mail: jonas.brich@... Web: http://www.bmw-carit.de ---------------------------------------------------------------------- BMW Car IT GmbH Geschaeftsfuehrer: Kai-Uwe Balszuweit und Michael Böttrich Sitz und Registergericht: Muenchen HRB 134810
---------------------------------------------------------------------- |
|
|
|
Re: How to submit/create a new repository in http://git.yoctoproject.org/
Alexander Kanavin
On Fri, 8 Oct 2021 at 14:05, Nicolas Dechesne <nicolas.dechesne@...> wrote:
9. All layers contain a README
file which details the origin of the layer, its maintainer, where to
submit changes, and any dependencies or version requirements. The layer linked above does not have that in its README. Passing the YP compatibility script is also a useful badge of quality. Alex |
|
|
|
Re: How to submit/create a new repository in http://git.yoctoproject.org/
Nicolas Dechesne <nicolas.dechesne@...>
hey, On Fri, Oct 8, 2021 at 1:53 PM Alexander Kanavin <alex.kanavin@...> wrote:
Not really. We definitely believe that the Yocto Project Compatible program is a valuable tool for our ecosystem. However, layers on git.yp.org are not required to be compatible. But that's a good suggestion for the future, perhaps ;)
|
|
|
|
Re: How to submit/create a new repository in http://git.yoctoproject.org/
Alexander Kanavin
There's also a more specific thing you'd need to resolve: I believe you'd need to pass all of the requirements listed here: Alex On Fri, 8 Oct 2021 at 11:58, <tienhock.loh@...> wrote: Hi Alex, |
|
|
|
Re: How to submit/create a new repository in http://git.yoctoproject.org/
tienhock.loh@...
Hi Alex,
Actually we'd like to have it up and get everything (including meta-riscv by Khem) into git.yoctoproject.org so that everything in consolidated into a central location. Does that make sense? Or it is expected that vendors do host their own repository? I see meta-intel, meta-xillinx, so I suspect platform vendor should also get the layers into git.yoctoproject.org I just read that we'll need to join membership to get repos into the git. I will discuss this with the management. Thanks for the quick response Alex. |
|
|
|
Re: How to submit/create a new repository in http://git.yoctoproject.org/
Alexander Kanavin
Hello Tien, I have to ask first: is there a reason you'd like to have it there? Alex On Fri, 8 Oct 2021 at 06:02, <thloh85@...> wrote: Hi all, |
|
|
|
Re: How to enable graphics acceleration on qemux86-64?
Alexander Kanavin
Something in your custom setup disables opengl in qemu-system-native. Can you try core-image-weston with plain poky only? This is the test we use to ensure it does work, it lists all the settings that have to be in place (but in poky they are enabled by default, except the gtk frontend): Alex On Fri, 8 Oct 2021 at 10:26, Manuel Wagesreither <ManWag@...> wrote: Hello all, |
|
|
|
How to enable graphics acceleration on qemux86-64?
Manuel Wagesreither
Hello all,
How can I enable graphics acceleration on qemux86-64? My image is using wayland with weston and the GUI is not exactly fast. * When I do `runqemu slirp kvm gtk`, it throws the following error: `runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: Display 'gtk' is not available.` * `runqemu slirp kvm sdl` works, but the weston GUI does not seem to be accelerated. * `runqemu slirp kvm sdl gl` emits the following: `runqemu - ERROR - Failed to run qemu: qemu-system-x86_64: OpenGL support is disabled` Below I'm posting a snippet of `poky/scripts/runqemu` to have at hand the qemu options enabled by the runqemu options mentioned above: ``` elif arg == 'sdl': if 'gl' in sys.argv[1:]: self.qemu_opt_script += ' -vga virtio -display sdl,gl=on' elif 'gl-es' in sys.argv[1:]: self.qemu_opt_script += ' -vga virtio -display sdl,gl=es' else: self.qemu_opt_script += ' -display sdl' elif arg == 'gtk': if 'gl' in sys.argv[1:]: self.qemu_opt_script += ' -vga virtio -display gtk,gl=on' elif 'gl-es' in sys.argv[1:]: self.qemu_opt_script += ' -vga virtio -display gtk,gl=es' else: self.qemu_opt_script += ' -display gtk' ``` Kind regards, Manuel |
|
|
|
[meta-security][PATCH] recipes-security/chipsec: platform security assessment framework
LiweiSong
Add chipsec, tools to dump and analyzing hardware, system firmware
components, like PCH register, ioport or iomem configuration space. Signed-off-by: Liwei Song <liwei.song@...> --- recipes-security/chipsec/chipsec_git.bb | 35 +++++++++++++++++++++++++ 1 file changed, 35 insertions(+) create mode 100644 recipes-security/chipsec/chipsec_git.bb diff --git a/recipes-security/chipsec/chipsec_git.bb b/recipes-security/chipsec/chipsec_git.bb new file mode 100644 index 000000000000..3339dc142107 --- /dev/null +++ b/recipes-security/chipsec/chipsec_git.bb @@ -0,0 +1,35 @@ +SUMMARY = "CHIPSEC: Platform Security Assessment Framework" + +DESCRIPTION = "CHIPSEC is a framework for analyzing the security \ + of PC platforms including hardware, system firmware \ + (BIOS/UEFI), and platform components." + +LICENSE = "GPLv2" +LIC_FILES_CHKSUM = "file://COPYING;md5=bc2d1f9b427be5fb63f6af9da56f7c5d" + +SRC_URI = "git://github.com/chipsec/chipsec.git;branch=master \ + " + +SRCREV = "b2a61684826dc8b9f622a844a40efea579cd7e7d" + +COMPATIBLE_HOST = "(i.86|x86_64).*-linux" + +S = "${WORKDIR}/git" +EXTRA_OEMAKE = "CC='${CC}' LDFLAGS='${LDFLAGS}' CFLAGS='${CFLAGS}'" + +DEPENDS = "virtual/kernel nasm-native python3-setuptools-native" +RDEPENDS:${PN} += "python3 python3-modules" + +inherit module distutils3 + +do_compile:append() { + cd ${S}/drivers/linux + oe_runmake KSRC=${STAGING_KERNEL_BUILDDIR} +} + +do_install:append() { + install -m 0644 ${S}/drivers/linux/chipsec.ko ${D}${PYTHON_SITEPACKAGES_DIR}/chipsec/helper/linux +} + +FILES:${PN} += "${exec_prefix} \ +" -- 2.17.1 |
|
|
|
How to submit/create a new repository in http://git.yoctoproject.org/
thloh85@...
Hi all,
I'm from StarFive and am working on distro for our risc-v based processor. We currently have a repository (https://github.com/starfive-tech/meta-starfive) and wish to get the repository to be part of git.yoctoproject.org. I couldn't find any information on the process to get the repository into git.yoctoproject.org. Can someone help show me the process? Thanks Tien Hock |
|
|
|
Re: Machine overrides for x86 and x86-64
On Thu, Oct 7, 2021 at 11:29 AM Luiz Balloti <luiz.balloti@...> wrote: Hi everyone. I'm not a Yocto/bitbake expert, so please forgive me for the possibily confusing message. x86 is for 32 bit intel arch you won’t see It in pure 64bit machines
|
|
|
|
booting from nvme SSD
simon
Hi everyone,
I'm currently trying to move from an m.2 SATA SSD to an m.2 nvme SSD for our project, without success. I'm using an Intel NUC7 board that has an m.2 slot which should support (from the datasheet) both SATA and nvme SSD. I'm able to see the grub menu from the nvme drive but when I try to boot to a partition I get stuck on a black screen. Which makes me believe that the bios is able to access and read the nvme SSD (or at least the boot partition) I can't figure out if I'm missing a driver or if I need something specific in our wks file to support nvme SSD I have tested the nvme SSD with an external m.2 to USB adaptor to verify that it's working properly I would like to know if there's anything I should look into. I'm currently on warrior but I believe i had a similar issue with dunfell as well... Smon |
|
|
|
Machine overrides for x86 and x86-64
Luiz Balloti
Hi everyone. I'm not a Yocto/bitbake expert, so please forgive me for the possibily confusing message.
Our current Yocto setup uses sumo (we're stuck with that right now, don't know if it matters). It has one shared layer, an ARM layer with one machine and a "x86" layer with two 32-bit machines. A few recipes in shared our layer use a "x86" override to restrict functionality to these machines (bbappends were causing trouble, so I went the override route). We now have a requirement to migrate one of the x86-32 machines to a 64-bit system. My first step was to use "genericx86-64" as a test machine and inspect a few variables. I was surprised to find out that MACHINEOVERRIDES does not list "x86" anymore, just the machine's name. I'd expect that a common override for x86 machines would be defined, regardless of the bitness, but repeating this with "genericx86" tells me this is not the case. We have meta-intel, but it seems our x86 machine variables come from meta-yocto-bsp (I wonder now if this is a layer priority issue). Is this not a common use case or is our setup fundamentally wrong? Thanks in advance for any help. |
|
|
|
#zeus meta-intel
#zeus
Monsees, Steven C (US)
I am looking at “meta-intel/dynamic-layers/clang-layer/recipes-opencl/compute-runtime” I have been “told” that this compute-runtime recipe should basically build opencl (Neo) with all the required dependencies… I did not think Yocto had support for OpenCL, and was looking to build Neo under the SDK.
(1) Is this true, does meta-intell under zeus now support building OpenCL and the OpenCL Graphics compiler under Yocto ? (2) Of so, what would be the proper way to pull this into my yocto build ?
Thanks, Steve |
|
|
|
Minutes: Yocto Project Weekly Triage Meeting 10/7/2021
Trevor Gamblin
Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage Attendees: Diane, Joshua, Kiran, Michael, Randy,
Richard, Ross, Saul, Stephen, Steve, Tim, Trevor ARs: - David Reyna to update Future/3.99 Toaster bugs Notes:
- Stephen and Trevor
will both be unavailable for the October 14th meeting
Medium+ 3.4 Unassigned Enhancements/Bugs: 68 (Last week 69) Medium+ 3.5 Unassigned Enhancements/Bugs: 12 (Last week
10) AB Bugs: 64
(Last week 62)
|
|
|
|
Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: Oct 7, 2021
YP AB Intermittent failures meeting
=================================== https://windriver.zoom.us/j/3696693975 Attendees: Richard, Trevor, Randy, Saul Summary: ======== Ptest results continue to improve yet again but there's still room for even more improvement. Alex made a graph of the number of AB INT issues per week: https://bootlin.com/~alexandre/SWAT_stats.png We assume that week 15, 16 was when the RCU bug in he kernel started being a problem and week 29 was when it go fixed but more careful analysis is required. The make/ninja load average limit is in but it's not clear if it's effective yet and it breaks dunfell. Trevor has a build of dunfell that with some patches appears to work. If anyone wants to help, we could use more eyes on the logs, particularly the summary logs and understanding iostat # when the dd test times out. Plans for the week: =================== Richard: QA results for M4, etc. Alex: ? Sakib: hook more responsive load average in to latency test. (v3) Trevor: patch to set PARALLEL_MAKE : -l 50 -> dunfell, gatesgarth, hardknott (Aug 5, Oct 7) Confirm that dunfell works now, test other branches. Saul: SBOM Randy: # processes graph of full builds, patch ninja, graph it. Kiran: SBOM Nothing much new below here. Keeping the list since it's still to-do. ../Randy Meeting Notes: ============== 1. job server - ninja could be patched with make's more responsive algorithm next or is this good enough? Aug 26: Randy made some graphs that show that the -l NUM results in the number of compile jobs oscillates *wildly* between 0 and 200 on a 192 core builder compiling chromium. What I did was: $ bitbake -c cleansstate chromium-x11 $ bitbake -c configure chromium-x11 $ bitbake -c compile chromium-x11 and while that compile was running: $ while [ ! -f /tmp/compiling-chromium-is-done ]; do \ cat /proc/loadavg >> procs-load.log ; sleep 0.5 ; done Results so far: https://postimg.cc/gallery/3hjfYfG/f8f46c97 Next step is either: a. collect data as above for an image build and see if the sub-optimal ninja behaviour makes a difference and/or b. patch ninja with make's more responsive load avg algorithm: https://git.savannah.gnu.org/cgit/make.git/commit/?id=d8728efc8 - Richard suggested that we extract make's code for measuring the load average to a separate binary and run it in the periodic io latency test. Also can we translate it to python? - Trevor is working on this and had some problems so next week. (Aug 19 - Trevor is back from vaction so maybe next week.) - Trevor to see if the load average change really did reduce load on WR build systems. (Aug 19) 2. AB status Trevor is learning about buildbot and working on a scheduling bug (CentOS worker?) bitbake layer setup tool should allow multiple backends: eg: kas, a y-a-helper. ptest cases are improving, we may be close to done! Let's wait a week to see how things go. (July29, Aug 5, Aug 19, we're not done...) - lttng-tools ptest is failing. RP is working on it with upstream. The timeout (done on Aug 5) increase hasn't helped. 3. Sakib's improvements to the logging are merged. Sakib generated a summary of all high latency 'top' logs from ~July 23->July 29 by just running his summary script on the merged raw top logs. More analysis required.... Still relevant parts of Previous Meeting Notes: ======================= 4. bitbake server timeout ( no change july 29, Aug 19, Oct 7) "Timeout while waiting for a reply from the bitbake server (60s)" 5. io stalls (no update: July 29, Oct 7) Richard said that it would make sense to write an ftrace utility / script to monitor io latency and we could install it with sudo Ch^W mentioned ftrace on IRC. Sakib and Randy will work on that but not for a week or two or longer! (Aug 19). Randy collected iostat data on 3 build server: https://postimg.cc/gallery/8cN6LYB We agreed that having -ty-2 be ~ 100 utilization for many hours in a row is not acceptable and that a threshold of ~ 10 minutes at 100% utilization may be a reasonable limt. I need to figure out if I can get data on the fraction of IO done per IO clas since we do use ionice to do clean-up and other activities. ../Randy |
|
|
|
Re: [meta-rockchip][PATCH] nanopi-m4: enable booting from uSD
On 10/6/21 11:52 AM, Trevor Woerner wrote:
Enable the vcc3v0_sd regulator on boot so that the device can boot from theuse of override here seems unnecessary |
|
|
|
[meta-rockchip][PATCH] nanopi-m4: enable booting from uSD
Trevor Woerner
Enable the vcc3v0_sd regulator on boot so that the device can boot from the
uSD card (when using certain uSD cards). Upstream-Status: Submitted [http://lists.infradead.org/pipermail/linux-arm-kernel/2021-October/688254.html] Signed-off-by: Trevor Woerner <twoerner@...> --- ....dtsi-enable-sdmmc-regulator-on-boot.patch | 47 +++++++++++++++++++ recipes-kernel/linux/linux-yocto%.bbappend | 1 + 2 files changed, 48 insertions(+) create mode 100644 recipes-kernel/linux/files/0001-rk3399-nanopi4.dtsi-enable-sdmmc-regulator-on-boot.patch diff --git a/recipes-kernel/linux/files/0001-rk3399-nanopi4.dtsi-enable-sdmmc-regulator-on-boot.patch b/recipes-kernel/linux/files/0001-rk3399-nanopi4.dtsi-enable-sdmmc-regulator-on-boot.patch new file mode 100644 index 0000000..c871c5a --- /dev/null +++ b/recipes-kernel/linux/files/0001-rk3399-nanopi4.dtsi-enable-sdmmc-regulator-on-boot.patch @@ -0,0 +1,47 @@ +From 33e3f2f8b22c226977b6461581ae113c3f77f5fd Mon Sep 17 00:00:00 2001 +From: Trevor Woerner <twoerner@...> +Date: Wed, 6 Oct 2021 11:41:23 -0400 +Subject: [PATCH] rk3399-nanopi4.dtsi: enable sdmmc regulator on boot + +When trying to boot a nanopi-m4 board with an SDHC-class uSD card, the boot +comes to a full stop shortly after initializing the mmc subsystem. The boot +can be cajoled into continuing if, after waiting a minute or so, the uSD +card is ejected and re-inserted. Waiting a minute or so before ejecting and +re-inserting the uSD card is crucial since the boot will not continue if +the card is ejected/re-inserted too soon after the boot has stopped. + +The nanopi-m4 has a uSD card and an optional eMMC module, either of which +can be used for booting. In my case I don't have the optional eMMC module, +therefore I'm booting from the uSD card. When booting from the uSD card, +its regulator needs to be enabled at boot. + +Curiously, this should have been an issue from day one, but it only started +to become a problem after commit 98e48cd9283d ("regulator: core: resolve +supply for boot-on/always-on regulators") was merged. Additionally, by +coincidence, I happened to be using an SDHC-class card in my device, and +saw the failure. However, if I use an SDXC-class uSD card the problem does +not occur. + +Much thanks to Mark Brown and Javier Martinez Canillas for their assistance +on irc! + +Signed-off-by: Trevor Woerner <twoerner@...> +--- + arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +index 8c0ff6c96e03..5cf02e2ef9b3 100644 +--- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi ++++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi4.dtsi +@@ -71,6 +71,7 @@ vcc3v0_sd: vcc3v0-sd { + pinctrl-names = "default"; + pinctrl-0 = <&sdmmc0_pwr_h>; + regulator-always-on; ++ regulator-boot-on; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + regulator-name = "vcc3v0_sd"; +-- +2.30.0.rc0 + diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/linux/linux-yocto%.bbappend index 470dc09..61d5116 100644 --- a/recipes-kernel/linux/linux-yocto%.bbappend +++ b/recipes-kernel/linux/linux-yocto%.bbappend @@ -12,3 +12,4 @@ COMPATIBLE_MACHINE:rock64 = "rock64" COMPATIBLE_MACHINE:rock-pi-e = "rock-pi-e" FILESEXTRAPATHS:prepend := "${THISDIR}/files:" +SRC_URI:append:nanopi-m4 = " file://0001-rk3399-nanopi4.dtsi-enable-sdmmc-regulator-on-boot.patch" -- 2.30.0.rc0 |
|
|
|
Re: virtual/egl on Raspberry Pi 4
Greg Wilson-Lindberg <gwilson@...>
Hello Joel, That is what was missing. Qt had reduced the size of their build to what was minimally needed to build their boot2qt demo, and I am using something that they don't.
Thanks for telling me what was missing, Greg From: Joel Winarske <joel.winarske@...>
Sent: Wednesday, October 6, 2021 4:26:01 AM To: Greg Wilson-Lindberg Cc: Khem Raj; Yocto-mailing-list Subject: Re: [yocto] virtual/egl on Raspberry Pi 4 Hi Greg,
Do you have this in your local.conf?
DISTRO_FEATURES_append = " opengl"
On Tue, Oct 5, 2021, 11:22 AM Greg Wilson-Lindberg <gwilson@...> wrote:
|
|
|
|
[meta-zephyr][PATCH] zephyr-kernel-test: disable broken tests
Jon Mason
Add tests that don't currently compile successfully to the remove
list for each specific machine. Signed-off-by: Jon Mason <jon.mason@...> --- recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc index f970225c884d..c7ccf9e05742 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc @@ -5,6 +5,14 @@ ZEPHYRTESTS:remove = "fifo fpu_sharing lifo mbox mem_heap mem_pool \ # Exclude tests which does not build for various reasons ZEPHYRTESTS:remove = "gen_isr_table spinlock smp mp" +# Exclude tests that are not currently compiling +ZEPHYRTESTS:remove:96b-avenger96 = "common device poll queue sleep" +ZEPHYRTESTS:remove:96b-nitrogen = "common device poll queue sleep" +ZEPHYRTESTS:remove:arduino-nano-33-ble = "common device poll queue sleep" +ZEPHYRTESTS:remove:nrf52840dk-nrf52840 = "common device poll queue sleep" +ZEPHYRTESTS:remove:qemu-x86 = "common device interrupt poll queue sleep" +ZEPHYRTESTS:remove:stm32mp157c-dk2 = "common device poll queue sleep" + # test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register #ZEPHYRTESTS:remove:arm += "" -- 2.20.1 |
|
|