It looks like a Mesa dependency is looming for NVIDIA:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902
Thanks
On Fri, May 28, 2021 at 1:30 PM Alexander Kanavin
wrote:
> Thanks, it took me a moment to understand that this still does not mean
> that nvidia supports gbm somehow,
Thanks, it took me a moment to understand that this still does not mean
that nvidia supports gbm somehow, somewhere, but rather that virgl needs to
be explicit about needing gbm.
The patch should be going to the oe-core list.
Alex
On Fri, 28 May 2021 at 21:16, Joel Winarske wrote:
>
> This
This addresses cases where the platform doesn't depend on Mesa. Tegra is
one example.
>From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h
Signed-off-by: Joel Winarske
---
merged.
Bruce
In message: [linux-yocto] [kernel v5.10/standard/nxp-sdk-5.4/nxp-imx8][PATCH]
arm64: dts: imx8: Modify csi0 and csi1esc_lpcg and core_lpcg clock power domain
on 28/05/2021 Xiaolei Wang wrote:
> Because commit f2bddbbe40c9 ("irqchip: imx-irqsteer: Block the runtime PM")
>
merged.
Bruce
In message: [linux-yocto] [yocto-kernel-cache] [yocto-5.10-rt] [PATCH] Fix
warning from do_kernel_configcheck in intel-x86 bsp
on 26/05/2021 qiang.zh...@windriver.com wrote:
> From: Zqiang
>
> [NOTE]: 'CONFIG_CFG80211' last val (y) and .config val (m) do not match
> [INFO]:
In message: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]:
drivers: phy: nxp: free custom data after phy work queue cancelled
on 27/05/2021 Zhantao Tang wrote:
>
> Hi Bruce,
>
>
> There is an patch to fix a kernel panic issue.
>
> Would you please help to merge this
Typo. No leading space INIT_MANAGER = "sysvinit".
Thanks,
Priya.
On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
> > you don't want the leading space.
>
> I got the idea from reading
>
>
> you don't want the leading space.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection
But this is exactly why we need some explicit examples. :-)
Zee
___
On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day
On Fri, 28 May 2021, Zoran wrote:
> > Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
>
> Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
> blank at the beginning)?
>
> Thank you,
> Zee
you don't want the leading space.
rday
-=-=-=-=-=-=-=-=-=-=-=-
> Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?
Thank you,
Zee
___
On Fri, May 28, 2021 at 1:47 PM Swapna Nannapaneni
wrote:
>
> Thanks Robert and Raj!!
>
> I am using Yocto
Thanks Robert and Raj!!
I am using Yocto 3.1 Dunfell release.
You are right about the .bbappend file. Changed the name in the overlay to
new-ver.bbappend and no longer see the warning.
Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf but
looks like generated rootfs has init
Why do I (always) point out the obvious?
And I do need... Geniuses are not meant to fix The World to understand them!?
Geniuses should understand The World (and act properly)!
Extras to geniality, do you, YOCTO primes, think?
___
Robert... If I am correct, i'm I?
Should you include in
Hi Quentin,
obviously I didn't read that page carefully enough. Sorry for the noise and
thanks for the hint.
Cheers, Manuel
Am Fr, 28. Mai 2021, um 11:35, schrieb Quentin Schulz:
> Hi Manuel,
>
> On Fri, May 28, 2021 at 11:26:26AM +0200, Manuel Wagesreither wrote:
> > Hello all,
> >
> > to
Hi Manuel,
On Fri, May 28, 2021 at 11:26:26AM +0200, Manuel Wagesreither wrote:
> Hello all,
>
> to speed up builds, we would like to make the CI generated sstate-cache
> available via internet. Due to IP concerns, we don't want to make it
> publically available but for authenticated hosts
Hello all,
to speed up builds, we would like to make the CI generated sstate-cache
available via internet. Due to IP concerns, we don't want to make it publically
available but for authenticated hosts only.
[1] indicates it is possible to serve the sstate-cache over http with basic
zephyr can be build for 'acrn' with following configuration:
MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"
Signed-off-by: Naveen Saini
---
conf/machine/acrn.conf | 9 -
1 file changed, 9 deletions(-)
delete mode 100644 conf/machine/acrn.conf
diff --git a/conf/machine/acrn.conf
User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"
By default it set to Elkhart Lake CRB 'ehl_crb'
Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb
* acrn
* acrn_ehl_crb
Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html
User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"
By default it set to MinnowBoard Max 'minnowboard'
Currently 32-bit supported boards:
* up_squared_32
* minnowboard
Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html
Signed-off-by: Naveen
With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit
mode).
To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build
Because commit f2bddbbe40c9 ("irqchip: imx-irqsteer: Block the runtime PM")
prohibits the interrupt the interrupt device from entering the runtime PM mode,
so the two power domains it attaches cannot enter the runtime PM, which causes
the two domains to not enter the low power mode. These two
20 matches
Mail list logo
