Date   

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:
hey,

On Fri, Oct 8, 2021 at 1:53 PM Alexander Kanavin <alex.kanavin@...> wrote:
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:

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 ;) 

Still, that list has items that should be fulfilled even without seeking YP compatibility, for instance:

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
 

hey,

On Fri, Oct 8, 2021 at 1:53 PM Alexander Kanavin <alex.kanavin@...> wrote:
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:

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 ;) 


Alex

On Fri, 8 Oct 2021 at 11:58, <tienhock.loh@...> wrote:
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
 

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,

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/

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,

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: 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 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




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@windriver.com>
---
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

Khem Raj
 



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.

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?

x86 is for 32 bit intel arch you won’t see
It in pure 64bit machines 


Thanks in advance for any help.



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)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (No change)

AB Bugs: 64 (Last week 62)


Yocto Autobuilder: Latency Monitor and AB-INT - Meeting notes: Oct 7, 2021

Randy MacLeod
 

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

Khem Raj
 

On 10/6/21 11:52 AM, Trevor Woerner wrote:
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@gmail.com>
---
....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@gmail.com>
+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@gmail.com>
+---
+ 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"
use 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@gmail.com>
---
....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@gmail.com>
+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@gmail.com>
+---
+ 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
 

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:

Hi Khem,

I added the VC4GRAPHICS line and here is the complete error that I get:


ERROR: Nothing PROVIDES 'virtual/egl' (but /home/gwilson/Qt-5.15.6/Yocto-build-RPi4/sources/meta-qt5/recipes-qt/qt5/qtbase_git.bb DEPENDS on or otherwise requires it)
vc-graphics PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics
opengldummy PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not opengldummy
vc-graphics-hardfp PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not vc-graphics-hardfp
qtglesstream-dummy-client PROVIDES virtual/egl but was skipped: PREFERRED_PROVIDER_virtual/libgles2 set to mesa, not qtglesstream-dummy-client
NOTE: Runtime target 'zint' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['zint', 'qtbase', 'virtual/egl']

Regards,

Greg


From: Khem Raj <raj.khem@...>
Sent: Tuesday, October 5, 2021 9:31:49 AM
To: Greg Wilson-Lindberg
Cc: yocto@...
Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
 
that should have worked well for userland recipe to provide it. Maybe
you need to set

VC4GRAPHICS = ""

in local.conf

On Tue, Oct 5, 2021 at 8:53 AM Greg Wilson-Lindberg
<GWilson@...> wrote:
>
> I am compiling in 32 bit mode.
>
>
>
> From: Khem Raj <raj.khem@...>
> Sent: Monday, October 4, 2021 5:15 PM
> To: Greg Wilson-Lindberg <GWilson@...>
> Cc: yocto@...
> Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
>
>
>
> It should have automatically found user land package as one of providers but if it is not doing so that means it’s being ignored because it’s not compatible arch or something
>
> Are you compiling 32bit mode ?
>
>
>
>
>
> On Mon, Oct 4, 2021 at 4:08 PM Greg Wilson-Lindberg <GWilson@...> wrote:
>
> Hi Khem,
> Yes, the Raspberry Pi boards do use closed source drivers. What I need is how do I include the proper package that will bring in the necessary virtual/egl for the Raspberry Pi 4.
>
> Greg
> > -----Original Message-----
> > From: Khem Raj <raj.khem@...>
> > Sent: Monday, October 4, 2021 14:17
> > To: Greg Wilson-Lindberg <GWilson@...>;
> > yocto@...
> > Subject: Re: [yocto] virtual/egl on Raspberry Pi 4
> >
> >
> >
> > On 10/4/21 12:39 PM, Greg Wilson-Lindberg wrote:
> > > Hello list,
> > >
> > > I'm working on a Qt supplied boot2qt Yocto build currently based on
> > > Zeus that is running on a Raspberry Pi 4. I recently updated the qt
> > > version to 5.15.6 and Qt changed something in the Yocto configuration
> > > that they are using and now one of the recipes that we use is failing
> > > saying that in needs 'virtual/egl' but that it is not provided by any recipe.
> > >
> > > In the searching that I have done I have found that the raspberry pi 4
> > > is particular on which package supplies the virtual/egl but I haven't
> > > seen anything that indicates what I should do to re-enable it.
> > >
> > > Can anyone tell me what I need to do to enable the correct driver to
> > > get virtual/egl provided on the Raspberry Pi 4? Or maybe even better,
> > > how I could search through the packages that are enabled on the old
> > > and new Yocto trees so that I can figure out what changed between the
> > > releases and re-enable the virtual/egl.
> > >
> >
> > it should be provided by userland package if you are using closed source
> > graphics driver.
> >
> > > Best Regards,
> > >
> > > Greg Wilson-Lindberg
> > >
> > >
> > >
> > >
> > >




[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@arm.com>
---
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


#bitbake TOPDIR not evaluating on custom distro #bitbake

jussi.vanska@...
 

I have a curious problem with TOPDIR environment variable.

Running standard Poky build with 25.0.3 works as expected but when using a custom distro layer the build fails as the host tools are not visible in path. Environment is identical, not counting the different path names, after sourcing the environment and before running bitbake but when running using a custom setup the PATH contains only relative references:

/home/jive/stage/yocto-25.0.3/bitbake/bin:tmp-glibc/hosttools"; export HOME="/home/jive"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P ../localmirror 'http://sources.openembedded.org/quilt-0.66.tar.gz' --progress=dot -v failed with exit code 127, output:
/usr/bin/env: ‘wget’: No such file or directory

whereas the Poky standard seems to expand the TOPDIR and TMPDIR ok

/home/jive/stage/yocto-25.0.3/bitbake/bin:/home/jive/stage/build/tmp/hosttools"; export HOME="/home/jive"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/jive/stage/build/downloads 'https://download.savannah.gnu.org/releases/quilt/quilt-0.66.tar.gz' --progress=dot -v

I can not find a place where the TOPDIR is set in configuration or what recipe/class overrides it. I'm aware the build directory should be under the OEROOT not beside it but this used to work with 18.x versions of YPCore.

cache.py@303 sets the variable and it looks very dangerous as it is relative to recipe currently parsing. Is this really how it should work? Another thing which is confusing is copy_buildsystem.py@46 still uses COREBASE even though the release documentation says the environment variable is deprecated and should not be used anymore. What makes this curious is that the OEROOT related paths work ok so I guess problem is somehow related to OEROOT vs. COREBASE handling.

There is another problem related to this as the inline python in my custom distro configuration distro/layer.conf
COREBASE = '${@os.path.normpath("${OEROOT}")}' does not work but complains

File "/home/jive/stage/yocto-25.0.3/meta/classes/metadata_scm.bbclass", line 27, in base_get_metadata_git_branch(path='${@os.path.normpath("${OEROOT}")}/meta', d=<bb.data_smart.DataSmart object at 0x7fc9ba2e6390>):

Any advice would be welcome before digging deeper into the internals of bitbake.

941 - 960 of 55902