Re: [yocto][poky][master][PATCH} VirGL: depends on virtual/gbm
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, 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 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 >> --- >> meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb >> b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb >> index 3991895823..65bd1af942 100644 >> --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb >> +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb >> @@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/; >> LICENSE = "MIT" >> LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10" >> >> -DEPENDS = "libdrm virtual/libgl libepoxy" >> +DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy" >> SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b" >> SRC_URI = "git:// >> anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \ >> file://0001-meson.build-use-python3-directly-for-python.patch >> \ >> -- >> 2.30.2 >> >> >> >> >> >> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53697): https://lists.yoctoproject.org/g/yocto/message/53697 Mute This Topic: https://lists.yoctoproject.org/mt/83156599/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto][poky][master][PATCH} VirGL: depends on virtual/gbm
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 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 > --- > meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb > b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb > index 3991895823..65bd1af942 100644 > --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb > +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb > @@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/; > LICENSE = "MIT" > LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10" > > -DEPENDS = "libdrm virtual/libgl libepoxy" > +DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy" > SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b" > SRC_URI = "git:// > anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \ > file://0001-meson.build-use-python3-directly-for-python.patch \ > -- > 2.30.2 > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53696): https://lists.yoctoproject.org/g/yocto/message/53696 Mute This Topic: https://lists.yoctoproject.org/mt/83156599/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto][poky][master][PATCH} VirGL: depends on virtual/gbm
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 --- meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb index 3991895823..65bd1af942 100644 --- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb +++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb @@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/; LICENSE = "MIT" LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10" -DEPENDS = "libdrm virtual/libgl libepoxy" +DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy" SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b" SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \ file://0001-meson.build-use-python3-directly-for-python.patch \ -- 2.30.2 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53695): https://lists.yoctoproject.org/g/yocto/message/53695 Mute This Topic: https://lists.yoctoproject.org/mt/83156599/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [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
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")
> 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 domains power
> domain
> directly enters the power off state when the system suspend is manually
> executed,
> but because the csi1_esc_lpcg clock depends on IMX_SC_R_CSI_1, this panic
> appears.
>
> Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 409 Comm: sh Not tainted 5.10.37-yocto-standard #1
> Hardware name: Freescale i.MX8QM MEK (DT)
> pstate: 0005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
> pc : imx_clk_lpcg_scu_suspend+0x70/0x7c
> lr : imx_clk_lpcg_scu_suspend+0x6c/0x7c
> sp : 800012ebba30
> x29: 800012ebba30 x28: 0002
> x27: 800010892b04 x26: 8000119a0e40
> x25: 8000117c9f54 x24: 800011916020
> x23: 800011a7cf60 x22:
> x21: 000810ba5810 x20: 000810ba5810
> x19: 00081102cd00 x18: 0020
> x17: x16:
> x15: 5904170b x14: 000810dab048
> x13: x12: fffca05f
> x11: 0101010101010101 x10: 800011825ff8
> x9 : 8000100aa0e0 x8 : 8000117ca5a8
> x7 : 8000118225a8 x6 : 3a50
> x5 : x4 :
> x3 : x2 : b9cdc3c7695eb800
> x1 : x0 : 800011b4501c
> Call trace:
> imx_clk_lpcg_scu_suspend+0x70/0x7c
> pm_generic_suspend_noirq+0x38/0x50
> genpd_finish_suspend+0xb8/0x140
> genpd_suspend_noirq+0x20/0x30
> dpm_run_callback+0x50/0x1c0
> __device_suspend_noirq+0xec/0x244
> dpm_noirq_suspend_devices+0x11c/0x320
> dpm_suspend_noirq+0x30/0xa4
> suspend_devices_and_enter+0x3b0/0x8a0
> pm_suspend+0x288/0x330
> state_store+0x98/0x120
> kobj_attr_store+0x1c/0x30
> sysfs_kf_write+0x50/0x60
> kernfs_fop_write_iter+0x124/0x1b4
> new_sync_write+0xf0/0x18c
> vfs_write+0x21c/0x280
> ksys_write+0x78/0x104
> __arm64_sys_write+0x28/0x3c
> el0_svc_common.constprop.0+0x9c/0x1f0
> do_el0_svc+0x78/0xa0
> el0_svc+0x20/0x30
> el0_sync_handler+0x1a4/0x1b0
> el0_sync+0x178/0x180
> Code: aa0003e1 91158040 941e6a79 f9400e60 (b940)
> ---[ end trace 64df5c6b48a8ae0a ]---
>
> Signed-off-by: Xiaolei Wang
> ---
> arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> index c7be9fdc4df0..32f2ea5f60db 100644
> --- a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
> @@ -37,7 +37,7 @@ csi0_core_lpcg: clock-controller@58223018 {
> clocks = < IMX_SC_R_CSI_0 IMX_SC_PM_CLK_PER>;
> bit-offset = <16>;
> clock-output-names = "csi0_lpcg_core_clk";
> - power-domains = < IMX_SC_R_ISI_CH0>;
> + power-domains = < IMX_SC_R_CSI_0>;
> };
>
> csi0_esc_lpcg: clock-controller@5822301c {
> @@ -47,7 +47,7 @@ csi0_esc_lpcg: clock-controller@5822301c {
> clocks = < IMX_SC_R_CSI_0 IMX_SC_PM_CLK_MISC>;
> bit-offset = <16>;
> clock-output-names = "csi0_lpcg_esc_clk";
> - power-domains = < IMX_SC_R_ISI_CH0>;
> + power-domains = < IMX_SC_R_CSI_0>;
> };
>
> csi1_core_lpcg: clock-controller@58243018 {
> @@ -57,7 +57,7 @@ csi1_core_lpcg: clock-controller@58243018 {
> clocks = < IMX_SC_R_CSI_1 IMX_SC_PM_CLK_PER>;
> bit-offset = <16>;
> clock-output-names = "csi1_lpcg_core_clk";
> - power-domains = < IMX_SC_R_ISI_CH0>;
> + power-domains = < IMX_SC_R_CSI_1>;
> };
>
> csi1_esc_lpcg: clock-controller@5824301c {
> @@ -67,7 +67,7 @@ csi1_esc_lpcg: clock-controller@5824301c {
> clocks = < IMX_SC_R_CSI_1 IMX_SC_PM_CLK_MISC>;
> bit-offset = <16>;
> clock-output-names = "csi1_lpcg_esc_clk";
> - power-domains = < IMX_SC_R_ISI_CH0>;
> + power-domains = < IMX_SC_R_CSI_1>;
> };
>
> pi0_pxl_lpcg: clock-controller@58263018 {
> --
> 2.25.1
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9925):
https://lists.yoctoproject.org/g/linux-yocto/message/9925
Mute This Topic: https://lists.yoctoproject.org/mt/83143841/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
Re: [linux-yocto] [yocto-kernel-cache] [yocto-5.10-rt] [PATCH] Fix warning from do_kernel_configcheck in intel-x86 bsp
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]: CONFIG_CFG80211 : m ## .config: 1559 > :configs/v5.10/standard/preempt-rt/ > intel-x86/features/mac80211/mac80211.cfg (m) > configs/v5.10/standard/preempt-rt/intel-x86/features/hostapd/hostapd.cfg > (y) > > [NOTE]: 'CONFIG_MAC80211' last val (y) and .config val (m) do not match > [INFO]: CONFIG_MAC80211 : m ## .config: 1574 > :configs/v5.10/standard/preempt-rt/intel-x86/ > features/mac80211/mac80211.cfg (m) > > configs/v5.10/standard/preempt-rt/intel-x86/features/hostapd/hostapd.cfg (y) > > [NOTE]: 'CONFIG_DPTF_PCH_FIVR' last val (m) and .config val (n) do not match > [INFO]: CONFIG_DPTF_PCH_FIVR : n > > declare these options as "non-hardware". > > Signed-off-by: Zqiang > --- > features/hostapd/hostapd.scc | 2 +- > features/intel-dptf/intel-dptf.scc | 2 +- > features/mac80211/mac80211.scc | 2 +- > 3 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/features/hostapd/hostapd.scc b/features/hostapd/hostapd.scc > index d03b3ce2..aedf9549 100644 > --- a/features/hostapd/hostapd.scc > +++ b/features/hostapd/hostapd.scc > @@ -1,2 +1,2 @@ > # SPDX-License-Identifier: MIT > -kconf hardware hostapd.cfg > +kconf non-hardware hostapd.cfg > diff --git a/features/intel-dptf/intel-dptf.scc > b/features/intel-dptf/intel-dptf.scc > index 0671f673..b488a2c5 100644 > --- a/features/intel-dptf/intel-dptf.scc > +++ b/features/intel-dptf/intel-dptf.scc > @@ -1,4 +1,4 @@ > # SPDX-License-Identifier: MIT > define KFEATURE_DESCRIPTION "Enable Dynamic Platform and Thermal Framework > PCH FIVR Participant device support" > > -kconf hardware intel-dptf.cfg > +kconf non-hardware intel-dptf.cfg > diff --git a/features/mac80211/mac80211.scc b/features/mac80211/mac80211.scc > index 5939f434..01806b6e 100644 > --- a/features/mac80211/mac80211.scc > +++ b/features/mac80211/mac80211.scc > @@ -2,4 +2,4 @@ > define KFEATURE_DESCRIPTION "Enable mac 80211 + WLAN support" > define KFEATURE_COMPATIBILITY board > > -kconf hardware mac80211.cfg > +kconf non-hardware mac80211.cfg > -- > 2.17.1 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9924): https://lists.yoctoproject.org/g/linux-yocto/message/9924 Mute This Topic: https://lists.yoctoproject.org/mt/83046575/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx]: drivers: phy: nxp: free custom data after phy work queue cancelled
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 patch into linux-ycoto kernel, v5.10, > branch is v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx? merged. Bruce > > > Thanks, > Zhantao > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#9923): https://lists.yoctoproject.org/g/linux-yocto/message/9923 Mute This Topic: https://lists.yoctoproject.org/mt/83118970/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
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 > > 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 > wrote: > > > > 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 > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53694): https://lists.yoctoproject.org/g/yocto/message/53694 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
> 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 wrote: > > 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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53693): https://lists.yoctoproject.org/g/yocto/message/53693 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
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 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53692): https://lists.yoctoproject.org/g/yocto/message/53692 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
> 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 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 file pointing to init -> ../lib/systemd/systemd > > Priya. > > On Thu, May 27, 2021 at 7:28 PM Khem Raj wrote: >> >> >> >> On 5/27/21 3:04 PM, sayinswa...@gmail.com wrote: >> > Hello Yocto team: >> > >> > I just started with yocto and would like to know the process for >> > switching the init manager from systemd to sysvinit. >> > >> > I tried this options in config file >> > VIRTUAL-RUNTIME_init_manager = "busybox" >> > PREFERRED_PROVIDER_udev = "sysvinit" >> > PREFERRED_PROVIDER_udev-utils = "sysvinit" >> > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" >> > DEFAULT_DISTRO_FEATURES += " sysvinit" >> > >> > I see a warning when building my machine: >> > >> > No recipe for target: >> > /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend >> >> Please find out which layer is adding this bbappend you could use >> >> bitbake-layers show-appends sysvinit >> >> It seems recipe version is newer perhaps and the bbappend is still made >> for older recipe, these things happen when you mix release branches for >> different layers. >> >> > >> > When I run this build on my target it still shows me systemd init >> > manager... >> > >> > Not sure if I am missing any options. >> > Could you please let me know if there are any pointers I can refer to? >> > >> > Thanks, >> > Priya >> > >> > >> > >> > >> > >> > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53691): https://lists.yoctoproject.org/g/yocto/message/53691 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
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 file pointing to init -> ../lib/systemd/systemd Priya. On Thu, May 27, 2021 at 7:28 PM Khem Raj wrote: > > > On 5/27/21 3:04 PM, sayinswa...@gmail.com wrote: > > Hello Yocto team: > > > > I just started with yocto and would like to know the process for > > switching the init manager from systemd to sysvinit. > > > > I tried this options in config file > > VIRTUAL-RUNTIME_init_manager = "busybox" > > PREFERRED_PROVIDER_udev = "sysvinit" > > PREFERRED_PROVIDER_udev-utils = "sysvinit" > > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" > > DEFAULT_DISTRO_FEATURES += " sysvinit" > > > > I see a warning when building my machine: > > > > No recipe for target: > > /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend > > Please find out which layer is adding this bbappend you could use > > bitbake-layers show-appends sysvinit > > It seems recipe version is newer perhaps and the bbappend is still made > for older recipe, these things happen when you mix release branches for > different layers. > > > > > When I run this build on my target it still shows me systemd init > manager... > > > > Not sure if I am missing any options. > > Could you please let me know if there are any pointers I can refer to? > > > > Thanks, > > Priya > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53690): https://lists.yoctoproject.org/g/yocto/message/53690 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell
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 docs some examples??? Yes, U should! As for an example fix: poky/meta/conf/distro/include/init-manager-*.con, NOT conf/distro/include/init-manager-*.conf (full path is more explicit, isn't it?) And some local.conf examples/snippets (since all descriptions are here and there very dry): ## Add systemd service INIT_MANAGER = "systemd" ## DISTRO_FEATURES_append = " systemd" ## DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" ## VIRTUAL-RUNTIME_init_manager = "systemd" ## VIRTUAL-RUNTIME_dev_manager = "systemd" ## VIRTUAL-RUNTIME_initscripts = "" Where INIT_MANAGER = "systemd" replaces all commented commands below My two cent advice, Zee ___ On Fri, May 28, 2021 at 1:28 AM Khem Raj wrote: > > > > On 5/27/21 3:04 PM, sayinswa...@gmail.com wrote: > > Hello Yocto team: > > > > I just started with yocto and would like to know the process for > > switching the init manager from systemd to sysvinit. > > > > I tried this options in config file > > VIRTUAL-RUNTIME_init_manager = "busybox" > > PREFERRED_PROVIDER_udev = "sysvinit" > > PREFERRED_PROVIDER_udev-utils = "sysvinit" > > DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit" > > DEFAULT_DISTRO_FEATURES += " sysvinit" > > > > I see a warning when building my machine: > > > > No recipe for target: > > /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend > > Please find out which layer is adding this bbappend you could use > > bitbake-layers show-appends sysvinit > > It seems recipe version is newer perhaps and the bbappend is still made > for older recipe, these things happen when you mix release branches for > different layers. > > > > > When I run this build on my target it still shows me systemd init manager... > > > > Not sure if I am missing any options. > > Could you please let me know if there are any pointers I can refer to? > > > > Thanks, > > Priya > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53689): https://lists.yoctoproject.org/g/yocto/message/53689 Mute This Topic: https://lists.yoctoproject.org/mt/83136294/21656 Mute #dunfell:https://lists.yoctoproject.org/g/yocto/mutehashtag/dunfell Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Where to define username/password when fetching sstate via http with basic authentication?
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 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 > > authentication [2]. > > > > How does one set the username & password? By putting it into the URL like > > in the following example, or are other ways available? > > ``` > > SSTATE_MIRRORS ?= "\ > > file://.* http://username:passw...@someserver.tld/share/sstate/PATH; > > ``` > > > > There is an example in the commit you sent, so I would say: > SSTATE_MIRRORS ?= " \ > file://.* > http://someserver.tld/share/sstate/PATH;user=username:password;downloadfilename=PATH > \n" > ? > > Cheers, > Quentin > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53688): https://lists.yoctoproject.org/g/yocto/message/53688 Mute This Topic: https://lists.yoctoproject.org/mt/83145194/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Where to define username/password when fetching sstate via http with basic authentication?
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 only. > > [1] indicates it is possible to serve the sstate-cache over http with basic > authentication [2]. > > How does one set the username & password? By putting it into the URL like in > the following example, or are other ways available? > ``` > SSTATE_MIRRORS ?= "\ > file://.* http://username:passw...@someserver.tld/share/sstate/PATH; > ``` > There is an example in the commit you sent, so I would say: SSTATE_MIRRORS ?= " \ file://.* http://someserver.tld/share/sstate/PATH;user=username:password;downloadfilename=PATH \n" ? Cheers, Quentin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53687): https://lists.yoctoproject.org/g/yocto/message/53687 Mute This Topic: https://lists.yoctoproject.org/mt/83145194/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Where to define username/password when fetching sstate via http with basic authentication?
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 authentication [2]. How does one set the username & password? By putting it into the URL like in the following example, or are other ways available? ``` SSTATE_MIRRORS ?= "\ file://.* http://username:passw...@someserver.tld/share/sstate/PATH; ``` Thank you! [1] https://patchwork.openembedded.org/patch/130333/ [2] https://en.wikipedia.org/wiki/Basic_access_authentication -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53686): https://lists.yoctoproject.org/g/yocto/message/53686 Mute This Topic: https://lists.yoctoproject.org/mt/83145194/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-zephyr][hardknott][PATCH 4/4] acrn.conf: drop acrn machine configuration
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 b/conf/machine/acrn.conf deleted file mode 100644 index c044933..000 --- a/conf/machine/acrn.conf +++ /dev/null @@ -1,9 +0,0 @@ -#@TYPE: Machine -#@NAME: acrn -#@DESCRIPTION: Machine for Zephyr BOARD acrn - -require conf/machine/include/qemu.inc -require conf/machine/include/tune-corei7-common.inc -ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot" - -ARCH_acrn = "x86" -- 2.17.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#53685): https://lists.yoctoproject.org/g/yocto/message/53685 Mute This Topic: https://lists.yoctoproject.org/mt/83145039/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-zephyr][hardknott][PATCH 2/4] intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS
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
Signed-off-by: Naveen Saini
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 14 ++
2 files changed, 17 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf
diff --git a/conf/machine/include/tune-corei7-common.inc
b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 000..2935cff
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,14 @@
+#@TYPE: Machine
+#@NAME: intel-x86-64
+#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set
${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "acrn"
+# ZEPHYR_BOARD ?= "acrn_ehl_crb"
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53682): https://lists.yoctoproject.org/g/yocto/message/53682
Mute This Topic: https://lists.yoctoproject.org/mt/83145036/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-zephyr][hardknott][PATCH 3/4] intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS
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 Saini
---
conf/machine/include/tune-core2-common.inc | 6 ++
conf/machine/intel-x86-32.conf | 12
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf
diff --git a/conf/machine/include/tune-core2-common.inc
b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set
${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53684): https://lists.yoctoproject.org/g/yocto/message/53684
Mute This Topic: https://lists.yoctoproject.org/mt/83145038/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [meta-zephyr][hardknott][PATCH 1/4] zephyr-kernel-src: fix efi generation failure for x86 boards
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 zephyr.efi
Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd
Signed-off-by: Naveen Saini
---
...ry-generation-issue-in-cross-compila.patch | 80 +++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644
recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
diff --git
a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 000..fd6fc6b
--- /dev/null
+++
b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini
+---
+ arch/x86/zefi/zefi.py| 6 +-
+ boards/x86/ehl_crb/CMakeLists.txt| 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+-cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++# Pass --sysroot path for cross compilation
++sysrootarg = "--sysroot=" + args.sysroot
++cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be
used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose
output")
++parser.add_argument("-s", "--sysroot", required=True, help="Cross
compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt
b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt
b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt
b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 6350d86..5d66f0f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -8,3 +8,6 @@ SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
PV = "2.5.0+git${SRCPV}"
+
+SRC_URI_append = "
[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
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 domains power domain
directly enters the power off state when the system suspend is manually
executed,
but because the csi1_esc_lpcg clock depends on IMX_SC_R_CSI_1, this panic
appears.
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 409 Comm: sh Not tainted 5.10.37-yocto-standard #1
Hardware name: Freescale i.MX8QM MEK (DT)
pstate: 0005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
pc : imx_clk_lpcg_scu_suspend+0x70/0x7c
lr : imx_clk_lpcg_scu_suspend+0x6c/0x7c
sp : 800012ebba30
x29: 800012ebba30 x28: 0002
x27: 800010892b04 x26: 8000119a0e40
x25: 8000117c9f54 x24: 800011916020
x23: 800011a7cf60 x22:
x21: 000810ba5810 x20: 000810ba5810
x19: 00081102cd00 x18: 0020
x17: x16:
x15: 5904170b x14: 000810dab048
x13: x12: fffca05f
x11: 0101010101010101 x10: 800011825ff8
x9 : 8000100aa0e0 x8 : 8000117ca5a8
x7 : 8000118225a8 x6 : 3a50
x5 : x4 :
x3 : x2 : b9cdc3c7695eb800
x1 : x0 : 800011b4501c
Call trace:
imx_clk_lpcg_scu_suspend+0x70/0x7c
pm_generic_suspend_noirq+0x38/0x50
genpd_finish_suspend+0xb8/0x140
genpd_suspend_noirq+0x20/0x30
dpm_run_callback+0x50/0x1c0
__device_suspend_noirq+0xec/0x244
dpm_noirq_suspend_devices+0x11c/0x320
dpm_suspend_noirq+0x30/0xa4
suspend_devices_and_enter+0x3b0/0x8a0
pm_suspend+0x288/0x330
state_store+0x98/0x120
kobj_attr_store+0x1c/0x30
sysfs_kf_write+0x50/0x60
kernfs_fop_write_iter+0x124/0x1b4
new_sync_write+0xf0/0x18c
vfs_write+0x21c/0x280
ksys_write+0x78/0x104
__arm64_sys_write+0x28/0x3c
el0_svc_common.constprop.0+0x9c/0x1f0
do_el0_svc+0x78/0xa0
el0_svc+0x20/0x30
el0_sync_handler+0x1a4/0x1b0
el0_sync+0x178/0x180
Code: aa0003e1 91158040 941e6a79 f9400e60 (b940)
---[ end trace 64df5c6b48a8ae0a ]---
Signed-off-by: Xiaolei Wang
---
arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
index c7be9fdc4df0..32f2ea5f60db 100644
--- a/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8-ss-img.dtsi
@@ -37,7 +37,7 @@ csi0_core_lpcg: clock-controller@58223018 {
clocks = < IMX_SC_R_CSI_0 IMX_SC_PM_CLK_PER>;
bit-offset = <16>;
clock-output-names = "csi0_lpcg_core_clk";
- power-domains = < IMX_SC_R_ISI_CH0>;
+ power-domains = < IMX_SC_R_CSI_0>;
};
csi0_esc_lpcg: clock-controller@5822301c {
@@ -47,7 +47,7 @@ csi0_esc_lpcg: clock-controller@5822301c {
clocks = < IMX_SC_R_CSI_0 IMX_SC_PM_CLK_MISC>;
bit-offset = <16>;
clock-output-names = "csi0_lpcg_esc_clk";
- power-domains = < IMX_SC_R_ISI_CH0>;
+ power-domains = < IMX_SC_R_CSI_0>;
};
csi1_core_lpcg: clock-controller@58243018 {
@@ -57,7 +57,7 @@ csi1_core_lpcg: clock-controller@58243018 {
clocks = < IMX_SC_R_CSI_1 IMX_SC_PM_CLK_PER>;
bit-offset = <16>;
clock-output-names = "csi1_lpcg_core_clk";
- power-domains = < IMX_SC_R_ISI_CH0>;
+ power-domains = < IMX_SC_R_CSI_1>;
};
csi1_esc_lpcg: clock-controller@5824301c {
@@ -67,7 +67,7 @@ csi1_esc_lpcg: clock-controller@5824301c {
clocks = < IMX_SC_R_CSI_1 IMX_SC_PM_CLK_MISC>;
bit-offset = <16>;
clock-output-names = "csi1_lpcg_esc_clk";
- power-domains = < IMX_SC_R_ISI_CH0>;
+ power-domains = < IMX_SC_R_CSI_1>;
};
pi0_pxl_lpcg: clock-controller@58263018 {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9922):
https://lists.yoctoproject.org/g/linux-yocto/message/9922
Mute This Topic: https://lists.yoctoproject.org/mt/83143841/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
