Re: [yocto] Dependency for binary package
On Fri, Aug 26, 2022 at 10:38 AM Rudolf J Streif wrote: > > On 8/25/22 5:44 PM, Khem Raj wrote: > > On Thu, Aug 25, 2022 at 4:56 PM Rudolf J Streif > > wrote: > >> > >> On 8/25/22 4:49 PM, Khem Raj wrote: > >>> On Thu, Aug 25, 2022 at 4:44 PM Rudolf J Streif > >>> wrote: > Thanks, Khem. > > On 8/25/22 4:27 PM, Khem Raj wrote: > > On Thu, Aug 25, 2022 at 7:30 AM Rudolf J Streif > > wrote: > >> I am packaging a binary package that has been built with the SDK > created > >> with the exact same configuration. > >> > >> During do_package I am getting an error that a dependency on > >> libGLESv2.so()(64bit) cannot be met. Adding mesa to RDEPENDS does > not > >> resolve the issue. I can bypass it in the recipe by adding > file-rdeps to > >> INSANE_SKIP. However, then when the rootfs is created libdnf > complains > >> that the dependency on libGLES is not met and aborts. > >> > >> The application works just fine on the target if I copy it manually > to > >> the rootfs but that's not the best thing to do. It should be > packaged > >> and installed. > >> > >> Unfortunately I don't understand well enough how these checks work > and > >> why they are complaining about it. Maybe somebody can shed some > light on it. > > some libraries do not set SONAME in them, which can trip the shlibs > > code. Can you > > check if libgles in question has SONAME encoded in its ELF header > > > > readelf -d | grep SONAME > > > > might be what you can use to deduce it. > libGLESv2 in question on the target was built with YP: > > 0x000e (SONAME) Library soname: > [libGLESv2.so.2] > > The SDK that builds the application was built with the same YP setup. > That's why I am scratching my head. > >>> interesting, are you adding RDEPENDS on libgles2-mesa ? > >> Yes, but that does not satisfy the dependency: > >> > >> ERROR: virtuoso-0.1-r0 do_package_qa: QA Issue: /opt/virtuoso/virtuoso > >> contained in package virtuoso requires libGLESv2.so()(64bit), but no > >> providers found in RDEPENDS:virtuoso? [file-rdeps] > > I see a potential problem here, the soname is libGLESv2.so.2 but the > > dependency its > > complaining about is libGLESv2.so()(64bit), ( you see the missing > > version number ?) > > > > Can you run > > > > readelf -d | grep NEEDED > > > > and see what libs are encoded in the ELF > > Yes, I have. These are the libs: > > 0x0001 (NEEDED) Shared library: [libQt5Quick.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Gui.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Qml.so.5] > 0x0001 (NEEDED) Shared library: > [libQt5Network.so.5] > 0x0001 (NEEDED) Shared library: > [libQt5SerialPort.so.5] > 0x0001 (NEEDED) Shared library: [libQt5Core.so.5] > 0x0001 (NEEDED) Shared library: [librt.so.1] > 0x0001 (NEEDED) Shared library: [libdl.so.2] > 0x0001 (NEEDED) Shared library: [libatomic.so.1] > 0x0001 (NEEDED) Shared library: [libGLESv2.so] This is the problem link. So either the sdk has provided them faulty install or they have replaced some stuff knowiingly or unknowingly or they have environment issues where their make system is finding this library elsewhere during their app build You can ask them for content of Usr/lib of their sdk instAll If you do then it would be interesting to see if the library and its corresponding links are intact > 0x0001 (NEEDED) Shared library: [libpthread.so.0] > 0x0001 (NEEDED) Shared library: [libstdc++.so.6] > 0x0001 (NEEDED) Shared library: [libm.so.6] > 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] > 0x0001 (NEEDED) Shared library: [libc.so.6] > > It's asking for libGLESv2.so. It's no problem on the target since it's > correctly resolved by ldd: > > root@tgt-lcd7:/usr/lib# ldconfig -p |grep libGLES > libGLESv2.so.2 (libc6,x86-64) => /lib64/libGLESv2.so.2 > libGLESv2.so.2 (libc6) => /lib/libGLESv2.so.2 > libGLESv2.so (libc6,x86-64) => /lib64/libGLESv2.so > libGLESv1_CM.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM.so.1 > libGLESv1_CM.so.1 (libc6) => /lib/libGLESv1_CM.so.1 > libGLESv1_CM.so (libc6,x86-64) => /lib64/libGLESv1_CM.so > > However, I cannot wrap my head around why this would happen with a > binary that has been compiled and linked with the YP SDK that exactly > matches the rootfs of the target: > > Target: > > root@tgt-lcd7:/usr/lib# ls -l libGLES* > lrwxrwxrwx 1 root root14 Mar 9 2018 libGLESv2.so -> libGLESv2.so.2 > lrwxrwxrwx 1 root root18 Mar 9 2018 libGLESv2.so.2 -> > libGLESv2.so.2.0.0 >
Re: [yocto] Devtool fails if SRCREV is set to ${AUTOREV} #kirkstone #devtool #yocto
I'm having the exact same issue when just modifying a custom linux recipie
which is essntially the same as the one provided but referencing 5.15 after
transposing recipies from dunfell to kirkstone. The builds without any devtool
modify sources work fine but the second I am working with a devtool'd linux it
produces that error. So the current best workflow seems to be to make changes
in a branch on the remote repository which will require forking the kernel
sources and then pointing the branch at the branch created on the fork of the
repository.
In my naieve attempts to troubleshoot this I tried changing SRCREV to the same
branch name I was referencing and changed the error message to the new format
where it changes the raise line to the following it seemed to be using SRCREV
for ud.unresolvedrev[name], that doesn't seem correct to me as if I changed the
SRCREV to "5.15" (different from the git branch) it would output "5.15". Not
sure if this is expected.
raise bb.fetch2.FetchError("Recipe uses a floating tag/branch '%s' for repo
'%s' without a fixed SRCREV yet doesn't call bb.fetch2.get_srcrev() (use SRCPV
in PV for OE)." % (ud.unresolvedrev[name], ud.host+ud.path))
^ https://git.yoctoproject.org/poky/plain/bitbake/lib/bb/fetch2/git.py
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57913): https://lists.yoctoproject.org/g/yocto/message/57913
Mute This Topic: https://lists.yoctoproject.org/mt/93100438/21656
Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone
Mute #devtool:https://lists.yoctoproject.org/g/yocto/mutehashtag/devtool
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Dependency for binary package
On 8/25/22 5:44 PM, Khem Raj wrote: On Thu, Aug 25, 2022 at 4:56 PM Rudolf J Streif wrote: On 8/25/22 4:49 PM, Khem Raj wrote: On Thu, Aug 25, 2022 at 4:44 PM Rudolf J Streif wrote: Thanks, Khem. On 8/25/22 4:27 PM, Khem Raj wrote: On Thu, Aug 25, 2022 at 7:30 AM Rudolf J Streif wrote: I am packaging a binary package that has been built with the SDK created with the exact same configuration. During do_package I am getting an error that a dependency on libGLESv2.so()(64bit) cannot be met. Adding mesa to RDEPENDS does not resolve the issue. I can bypass it in the recipe by adding file-rdeps to INSANE_SKIP. However, then when the rootfs is created libdnf complains that the dependency on libGLES is not met and aborts. The application works just fine on the target if I copy it manually to the rootfs but that's not the best thing to do. It should be packaged and installed. Unfortunately I don't understand well enough how these checks work and why they are complaining about it. Maybe somebody can shed some light on it. some libraries do not set SONAME in them, which can trip the shlibs code. Can you check if libgles in question has SONAME encoded in its ELF header readelf -d | grep SONAME might be what you can use to deduce it. libGLESv2 in question on the target was built with YP: 0x000e (SONAME) Library soname: [libGLESv2.so.2] The SDK that builds the application was built with the same YP setup. That's why I am scratching my head. interesting, are you adding RDEPENDS on libgles2-mesa ? Yes, but that does not satisfy the dependency: ERROR: virtuoso-0.1-r0 do_package_qa: QA Issue: /opt/virtuoso/virtuoso contained in package virtuoso requires libGLESv2.so()(64bit), but no providers found in RDEPENDS:virtuoso? [file-rdeps] I see a potential problem here, the soname is libGLESv2.so.2 but the dependency its complaining about is libGLESv2.so()(64bit), ( you see the missing version number ?) Can you run readelf -d | grep NEEDED and see what libs are encoded in the ELF Yes, I have. These are the libs: 0x0001 (NEEDED) Shared library: [libQt5Quick.so.5] 0x0001 (NEEDED) Shared library: [libQt5Gui.so.5] 0x0001 (NEEDED) Shared library: [libQt5Qml.so.5] 0x0001 (NEEDED) Shared library: [libQt5Network.so.5] 0x0001 (NEEDED) Shared library: [libQt5SerialPort.so.5] 0x0001 (NEEDED) Shared library: [libQt5Core.so.5] 0x0001 (NEEDED) Shared library: [librt.so.1] 0x0001 (NEEDED) Shared library: [libdl.so.2] 0x0001 (NEEDED) Shared library: [libatomic.so.1] 0x0001 (NEEDED) Shared library: [libGLESv2.so] 0x0001 (NEEDED) Shared library: [libpthread.so.0] 0x0001 (NEEDED) Shared library: [libstdc++.so.6] 0x0001 (NEEDED) Shared library: [libm.so.6] 0x0001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0001 (NEEDED) Shared library: [libc.so.6] It's asking for libGLESv2.so. It's no problem on the target since it's correctly resolved by ldd: root@tgt-lcd7:/usr/lib# ldconfig -p |grep libGLES libGLESv2.so.2 (libc6,x86-64) => /lib64/libGLESv2.so.2 libGLESv2.so.2 (libc6) => /lib/libGLESv2.so.2 libGLESv2.so (libc6,x86-64) => /lib64/libGLESv2.so libGLESv1_CM.so.1 (libc6,x86-64) => /lib64/libGLESv1_CM.so.1 libGLESv1_CM.so.1 (libc6) => /lib/libGLESv1_CM.so.1 libGLESv1_CM.so (libc6,x86-64) => /lib64/libGLESv1_CM.so However, I cannot wrap my head around why this would happen with a binary that has been compiled and linked with the YP SDK that exactly matches the rootfs of the target: Target: root@tgt-lcd7:/usr/lib# ls -l libGLES* lrwxrwxrwx 1 root root 14 Mar 9 2018 libGLESv2.so -> libGLESv2.so.2 lrwxrwxrwx 1 root root 18 Mar 9 2018 libGLESv2.so.2 -> libGLESv2.so.2.0.0 -rwxr-xr-x 1 root root 46792 Mar 9 2018 libGLESv2.so.2.0.0 SDK: [rstreif@threaddy lib]$ ls -l libGLES* lrwxrwxrwx. 1 rstreif rstreif 14 Aug 25 11:35 libGLESv2.so -> libGLESv2.so.2 lrwxrwxrwx. 1 rstreif rstreif 18 Aug 25 11:36 libGLESv2.so.2 -> libGLESv2.so.2.0.0 -rwxr-xr-x. 1 rstreif rstreif 46792 Aug 25 11:36 libGLESv2.so.2.0.0 Unfortunately I don't have the sources of the application otherwise I would have YP build it. But the customer claims they are building it with the SDK. I am trying to get to the bottom of their end too. I can SKIP_INSANE file-rdeps but then I am getting the same issue when creating the rootfs with dnf. But in all fairness, I don't have control over the entire process. The customer builds the executable with the SDK I gave them. They give me the executable to put in the rootfs. Thanks, Rudi -- Rudolf J Streif CEO/CTO ibeeto +1.855.442.3386 x700 -- Rudolf J Streif
Re: [yocto] Bitbake + Patches
[ In the future, please make sure to reply to list and not just to me. ]
[ Top posting since Outlook doesn’t support inline responses to HTML mails. ]
No, you are supposed to copy the suggest text for the bbappend verbatim, with
the exception of the SRC_URI[md5sum] which need to be corrected to match the
actual MD5 sum (which bitbake will tell you when you try to build). The
suggested additions/deletions for SRC_URI in the bbappend I suggested should be
correct as specified, based on the differences between the apache2 recipe in
Zeus and master. You will also need to copy the three new patch files from
master of meta-webserver, and any of the other patches that have been updated
between Zeus and master. Changing PV takes care of the actual update of the
code to the new version (since it determines which tar ball is fetched from
upstream).
//Peter
From: forums
Sent: den 26 augusti 2022 14:21
To: Peter Kjellerstedt
Subject: Re: [yocto] Bitbake + Patches
FILESEXTRAPATHS_prepend := "${THISDIR}/${BPN}:"
LIC_FILES_CHKSUM = "file://LICENSE;md5=bddeddfac80b2c9a882241d008bb41c3"
PV = "2.4.54"
SRC_URI += "file://0008-Fix-perl-install-directory-to-usr-bin.patch \
file://0009-support-apxs.in-force-destdir-to-be-empty-string.patch
\
file://0001-make_exports.awk-not-expose-the-path.patch"
SRC_URI_remove = "file://apache-configure_perlbin.patch"
SRC_URI[md5sum] = ""
SRC_URI[sha256sum] =
"eb397feeefccaf254f8d45de3768d9d68e8e73851c49afd5b7176d1ecf80c340"
H Peter. I have t admin, looking at the above bbappend, its really confusing to
me. I’ve looked at some of the documents on bitbake and I just can’t find
anything to teach me how to put a bbappend together to accomplish upgrading an
application.
Like for example:
SRC_URI += "file://0008-Fix-perl-install-directory-to-usr-bin.patch
I believe this one should be:
SRC_URI += file:/usr/bin/patch
The next one:
file://0009-support-apxs.in-force-destdir-to-be-empty-string.patch
I’ve no idea what this one will nee to be.
And this one:
file://0001-make_exports.awk-not-expose-the-path.patch
I don’t know what is supposed to go here either.
Then the SRC_URI_remove will be a pointer to the file containing the patches
containing the diff’e between apache 12.4.1 and apache 2.4.54 ? I don’t think
you can create a single patch file containing diff’s between multiple versions
can you? I think it would have to be diff’s between apache 2.4.41 and 2.4.42.
Right. Totally confused as to what to do here.
Any further help appreciated.
If you know of a resource for me to reference please pass it on. I just don’t
see any clear documentation that explains how to construct a bbappend file.
Thanks, Jim
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57911): https://lists.yoctoproject.org/g/yocto/message/57911
Mute This Topic: https://lists.yoctoproject.org/mt/93191096/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[yocto] [yocto-autobuilder-helper][kirkstone] config.json: Set SDKMACHINE to aarch64 for oe-selftest-armhost
From: Ross Burton
Although bitbake.conf sets the default SDKMACHINE to the build
architecture, config.json resets that to i686.
As oe-selftest assumes that the SDKs it builds are usable on the host
machine, we should set SDKMACHINE=aarch64 in the oe-selftest-armhost
build.
A follow-up more invasive patch to clean up the SDKMACHINE assignments
is in progress, once it has been verified to not cause regressions.
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
(cherry picked from commit 65281a56452cf2bc547c60c0b2131422ab48a3d2)
Signed-off-by: Steve Sakoman
---
config.json | 1 +
1 file changed, 1 insertion(+)
diff --git a/config.json b/config.json
index 101ddff..298caf6 100644
--- a/config.json
+++ b/config.json
@@ -836,6 +836,7 @@
"TEMPLATE" : "selftest"
},
"oe-selftest-armhost" : {
+"SDKMACHINE": "aarch64",
"TEMPLATE" : "selftest"
},
"reproducible" : {
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#57910): https://lists.yoctoproject.org/g/yocto/message/57910
Mute This Topic: https://lists.yoctoproject.org/mt/93270345/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [linux-yocto] [kernel-cache][PATCH] efi.cfg: Drop ACPI dependency
On Fri, Aug 26, 2022 at 8:36 AM Andrei Gherzan wrote: > > On Fri, 26 Aug 2022, at 03:43, Bruce Ashfield wrote: > > On Wed, Aug 24, 2022 at 4:30 AM Andrei Gherzan wrote: > >> > >> On Wed, 24 Aug 2022, at 02:26, Bruce Ashfield wrote: > >> > In message: Re: [linux-yocto] [kernel-cache][PATCH] efi.cfg: Drop ACPI > >> > dependency > >> > on 22/08/2022 Andrei Gherzan wrote: > >> > > >> >> On Mon, 22 Aug 2022, at 18:55, Andrei Gherzan wrote: > >> >> > From: Andrei Gherzan > >> >> > > >> >> > On X86 this will have no impact as CONFIG_ACPI is enabled by default. > >> >> > On > >> >> > the other hand, ARM64 would be affected as they don't have the same > >> >> > default. The defconfig for arm64 recommends CONFIG_ACPI and this patch > >> >> > follows this recommendation in the qemuarm64 bsp configuration to fix > >> >> > ACPI-only EFI boots on this arch. > >> >> > > >> >> > arm (32bit) would also be unaffected as there is no ACPI support there > >> >> > at all. And this unconditional drop (CONFIG_ACPI) will actually fix a > >> >> > configuration warning when enabling EFI on a arm (32bit) machine: > >> >> > > >> >> > [INFO]: config 'CONFIG_ACPI' was set, but it wasn't assignable, check > >> >> > (parent) dependencies > >> >> > > >> >> > Upstream-status: Pending > >> >> > >> >> Please drop this when you apply the patch. It is from a layer local > >> >> integration. > >> > > >> > No problem. Which kernel versions are you targetting for this ? > >> > >> I'm targeting 5.10 at this point but the later ones should be useful too. > > > > When I merge these sorts of things to an older kernel, they need to be > > on master (unless they really are version specific), and preferably on > > the intermediate versions, just so we have consistent behaviour. > > It makes sense and that is why I've initially sent it against master so that > when it gets merged there, I can ping you or propose it for the older > versions. Nevertheless, it looks like it ended up everywhere now so all good. Perfect. >From your other kirkstone patches (to meta-virt), I assumed you also wanted the older version. We are aligned! Bruce > > Thanks, > Andrei -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11599): https://lists.yoctoproject.org/g/linux-yocto/message/11599 Mute This Topic: https://lists.yoctoproject.org/mt/93187197/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] [PATCH v5.10/standard/bcm-2xxx-rpi] drivers: drm: vc4: fix build failure caused by merge conflicts
On Fri, Aug 26, 2022 at 9:20 AM Li, Meng wrote:
>
> My patches series is only for v5.15 kernel, and includes a fix building issue
> patch and upgrading patches from sdk repo
> I will debug and create a patch only to fix the building issue for v5.10
> kernel in later.
I'll wait to hear from you if I should take this patch, or another version.
Cheers,
Bruce
>
> Thanks,
> Limeng
>
> > -Original Message-
> > From: Panait, Ovidiu
> > Sent: Friday, August 26, 2022 4:48 PM
> > To: bruce.ashfi...@gmail.com
> > Cc: linux-yocto@lists.yoctoproject.org; Li, Meng
> > Subject: [PATCH v5.10/standard/bcm-2xxx-rpi] drivers: drm: vc4: fix build
> > failure caused by merge conflicts
> >
> > In 0487f95471af ("Merge branch 'v5.10/standard/base' into
> > v5.10/standard/bcm-2xxx-rpi") there was a conflict between linux-stable
> > backports
> > de63dbc29681 ("drm/vc4: hdmi: Disable audio if dmas property is present but
> > empty")
> > 717325e814d0 ("drm/vc4: hdmi: Limit the BCM2711 to the max without
> > scrambling")
> > 36f797a10f30 ("drm/vc4: hdmi: Fix timings for interlaced modes")
> > ed2f42bd8021 ("drm/vc4: dsi: Correct pixel order for DSI0") and existing rpi
> > SDK commits.
> >
> > This caused the following build failures:
> > 1. drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_config_pv':
> > drivers/gpu/drm/vc4/vc4_crtc.c:377:56:
> > warning: value computed is not used [-Wunused-value]
> > 377 | PV_VERTA_VBP) |
> > drivers/gpu/drm/vc4/vc4_crtc.c:380:57:
> > error: expected ';' before ')' token
> > 380 | PV_VERTA_VSYNC));
> > | ^
> > drivers/gpu/drm/vc4/vc4_crtc.c:380:57:
> > error: expected statement before ')' token
> >
> > 2. drivers/gpu/drm/vc4/vc4_hdmi.c:1540:13:
> > error: redeclaration of 'len' with no linkage
> > | 1540 | int len;
> > | | ^~~
> >
> > Remove unneeded duplicated code to fix this.
> >
> > Signed-off-by: Ovidiu Panait
> > ---
> > drivers/gpu/drm/vc4/vc4_crtc.c | 17 -
> > drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ---
> > 2 files changed, 20 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> > index 26cf9cc105fe..c50a8286f3e6 100644
> > --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> > @@ -338,17 +338,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc,
> > struct drm_encoder *encode
> > VC4_SET_FIELD(mode->hdisplay * pixel_rep / ppc,
> >PV_HORZB_HACTIVE));
> >
> > - CRTC_WRITE(PV_VERTA,
> > -VC4_SET_FIELD(mode->crtc_vtotal - mode-
> > >crtc_vsync_end +
> > - interlace,
> > - PV_VERTA_VBP) |
> > -VC4_SET_FIELD(mode->crtc_vsync_end - mode-
> > >crtc_vsync_start,
> > - PV_VERTA_VSYNC));
> > - CRTC_WRITE(PV_VERTB,
> > -VC4_SET_FIELD(mode->crtc_vsync_start - mode-
> > >crtc_vdisplay,
> > - PV_VERTB_VFP) |
> > -VC4_SET_FIELD(mode->crtc_vdisplay,
> > PV_VERTB_VACTIVE));
> > -
> > if (interlace) {
> > bool odd_field_first = false;
> > u32 field_delay = mode->htotal * pixel_rep / (2 * ppc); @@ -
> > 372,12 +361,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc,
> > struct
> > drm_encoder *encode
> > CRTC_WRITE(PV_VERTA_EVEN,
> > VC4_SET_FIELD(vert_bp_even, PV_VERTA_VBP) |
> > VC4_SET_FIELD(vert_sync, PV_VERTA_VSYNC));
> > -VC4_SET_FIELD(mode->crtc_vtotal -
> > - mode->crtc_vsync_end,
> > - PV_VERTA_VBP) |
> > -VC4_SET_FIELD(mode->crtc_vsync_end -
> > - mode->crtc_vsync_start,
> > - PV_VERTA_VSYNC));
> > CRTC_WRITE(PV_VERTB_EVEN,
> > VC4_SET_FIELD(vert_fp_even, PV_VERTB_VFP) |
> > VC4_SET_FIELD(mode->crtc_vdisplay,
> > PV_VERTB_VACTIVE)); diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > b/drivers/gpu/drm/vc4/vc4_hdmi.c index a147dad0f52c..00e9416edc3d
> > 100644
> > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> > @@ -108,8 +108,6 @@ static bool vc4_hdmi_mode_needs_scrambling(const
> > struct drm_display_mode *mode)
> > return (mode->clock * 1000) > HDMI_14_MAX_TMDS_CLK; }
> >
> > -#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
> > -
> > static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused) {
> > struct drm_info_node *node = (struct drm_info_node *)m->private;
> > @@ -1537,7 +1535,6 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi
> > *vc4_hdmi)
> > const __be32 *addr;
> > int index,
Re: [linux-yocto] [PATCH v5.10/standard/bcm-2xxx-rpi] drivers: drm: vc4: fix build failure caused by merge conflicts
My patches series is only for v5.15 kernel, and includes a fix building issue
patch and upgrading patches from sdk repo
I will debug and create a patch only to fix the building issue for v5.10 kernel
in later.
Thanks,
Limeng
> -Original Message-
> From: Panait, Ovidiu
> Sent: Friday, August 26, 2022 4:48 PM
> To: bruce.ashfi...@gmail.com
> Cc: linux-yocto@lists.yoctoproject.org; Li, Meng
> Subject: [PATCH v5.10/standard/bcm-2xxx-rpi] drivers: drm: vc4: fix build
> failure caused by merge conflicts
>
> In 0487f95471af ("Merge branch 'v5.10/standard/base' into
> v5.10/standard/bcm-2xxx-rpi") there was a conflict between linux-stable
> backports
> de63dbc29681 ("drm/vc4: hdmi: Disable audio if dmas property is present but
> empty")
> 717325e814d0 ("drm/vc4: hdmi: Limit the BCM2711 to the max without
> scrambling")
> 36f797a10f30 ("drm/vc4: hdmi: Fix timings for interlaced modes")
> ed2f42bd8021 ("drm/vc4: dsi: Correct pixel order for DSI0") and existing rpi
> SDK commits.
>
> This caused the following build failures:
> 1. drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_config_pv':
> drivers/gpu/drm/vc4/vc4_crtc.c:377:56:
> warning: value computed is not used [-Wunused-value]
> 377 | PV_VERTA_VBP) |
> drivers/gpu/drm/vc4/vc4_crtc.c:380:57:
> error: expected ';' before ')' token
> 380 | PV_VERTA_VSYNC));
> | ^
> drivers/gpu/drm/vc4/vc4_crtc.c:380:57:
> error: expected statement before ')' token
>
> 2. drivers/gpu/drm/vc4/vc4_hdmi.c:1540:13:
> error: redeclaration of 'len' with no linkage
> | 1540 | int len;
> | | ^~~
>
> Remove unneeded duplicated code to fix this.
>
> Signed-off-by: Ovidiu Panait
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 17 -
> drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ---
> 2 files changed, 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
> index 26cf9cc105fe..c50a8286f3e6 100644
> --- a/drivers/gpu/drm/vc4/vc4_crtc.c
> +++ b/drivers/gpu/drm/vc4/vc4_crtc.c
> @@ -338,17 +338,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc,
> struct drm_encoder *encode
> VC4_SET_FIELD(mode->hdisplay * pixel_rep / ppc,
>PV_HORZB_HACTIVE));
>
> - CRTC_WRITE(PV_VERTA,
> -VC4_SET_FIELD(mode->crtc_vtotal - mode-
> >crtc_vsync_end +
> - interlace,
> - PV_VERTA_VBP) |
> -VC4_SET_FIELD(mode->crtc_vsync_end - mode-
> >crtc_vsync_start,
> - PV_VERTA_VSYNC));
> - CRTC_WRITE(PV_VERTB,
> -VC4_SET_FIELD(mode->crtc_vsync_start - mode-
> >crtc_vdisplay,
> - PV_VERTB_VFP) |
> -VC4_SET_FIELD(mode->crtc_vdisplay,
> PV_VERTB_VACTIVE));
> -
> if (interlace) {
> bool odd_field_first = false;
> u32 field_delay = mode->htotal * pixel_rep / (2 * ppc); @@ -
> 372,12 +361,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc, struct
> drm_encoder *encode
> CRTC_WRITE(PV_VERTA_EVEN,
> VC4_SET_FIELD(vert_bp_even, PV_VERTA_VBP) |
> VC4_SET_FIELD(vert_sync, PV_VERTA_VSYNC));
> -VC4_SET_FIELD(mode->crtc_vtotal -
> - mode->crtc_vsync_end,
> - PV_VERTA_VBP) |
> -VC4_SET_FIELD(mode->crtc_vsync_end -
> - mode->crtc_vsync_start,
> - PV_VERTA_VSYNC));
> CRTC_WRITE(PV_VERTB_EVEN,
> VC4_SET_FIELD(vert_fp_even, PV_VERTB_VFP) |
> VC4_SET_FIELD(mode->crtc_vdisplay,
> PV_VERTB_VACTIVE)); diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c
> b/drivers/gpu/drm/vc4/vc4_hdmi.c index a147dad0f52c..00e9416edc3d
> 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -108,8 +108,6 @@ static bool vc4_hdmi_mode_needs_scrambling(const
> struct drm_display_mode *mode)
> return (mode->clock * 1000) > HDMI_14_MAX_TMDS_CLK; }
>
> -#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
> -
> static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused) {
> struct drm_info_node *node = (struct drm_info_node *)m->private;
> @@ -1537,7 +1535,6 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi
> *vc4_hdmi)
> const __be32 *addr;
> int index, len;
> int ret;
> - int len;
>
> if (!of_find_property(dev->of_node, "dmas", ) ||
> len == 0) {
> --
> 2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11597):
https://lists.yoctoproject.org/g/linux-yocto/message/11597
Mute This Topic:
Re: [linux-yocto] [kernel-cache][PATCH] efi.cfg: Drop ACPI dependency
On Fri, 26 Aug 2022, at 03:43, Bruce Ashfield wrote: > On Wed, Aug 24, 2022 at 4:30 AM Andrei Gherzan wrote: >> >> On Wed, 24 Aug 2022, at 02:26, Bruce Ashfield wrote: >> > In message: Re: [linux-yocto] [kernel-cache][PATCH] efi.cfg: Drop ACPI >> > dependency >> > on 22/08/2022 Andrei Gherzan wrote: >> > >> >> On Mon, 22 Aug 2022, at 18:55, Andrei Gherzan wrote: >> >> > From: Andrei Gherzan >> >> > >> >> > On X86 this will have no impact as CONFIG_ACPI is enabled by default. On >> >> > the other hand, ARM64 would be affected as they don't have the same >> >> > default. The defconfig for arm64 recommends CONFIG_ACPI and this patch >> >> > follows this recommendation in the qemuarm64 bsp configuration to fix >> >> > ACPI-only EFI boots on this arch. >> >> > >> >> > arm (32bit) would also be unaffected as there is no ACPI support there >> >> > at all. And this unconditional drop (CONFIG_ACPI) will actually fix a >> >> > configuration warning when enabling EFI on a arm (32bit) machine: >> >> > >> >> > [INFO]: config 'CONFIG_ACPI' was set, but it wasn't assignable, check >> >> > (parent) dependencies >> >> > >> >> > Upstream-status: Pending >> >> >> >> Please drop this when you apply the patch. It is from a layer local >> >> integration. >> > >> > No problem. Which kernel versions are you targetting for this ? >> >> I'm targeting 5.10 at this point but the later ones should be useful too. > > When I merge these sorts of things to an older kernel, they need to be > on master (unless they really are version specific), and preferably on > the intermediate versions, just so we have consistent behaviour. It makes sense and that is why I've initially sent it against master so that when it gets merged there, I can ping you or propose it for the older versions. Nevertheless, it looks like it ended up everywhere now so all good. Thanks, Andrei -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#11596): https://lists.yoctoproject.org/g/linux-yocto/message/11596 Mute This Topic: https://lists.yoctoproject.org/mt/93187197/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Qt based application fails to start with error "Could not initialize egl display" with Yocto Kirkstone
Hi All, I am trying to run qml-launcher (https://github.com/alamminsalo/qml-launcher) with yocto 4.0 kirkstone. I've implemented a service file to start this qml-launcher (service file attached) but systemd fails to start the service with logs saying "Could not initialize egl display". However, if i run qml-launcher binary without service on wayland terminal, it works just fine. The same service file and same qml-launcher application worked fine as a service with yocto dunfell, but there seems to be some issue with weston in kirkstone release. Hoping for a valuable input here. Regards, Ansar Rasool [Unit] Description= Start qml-launcher After=multi-user.target Requires=graphical.target [Service] Type=simple PermissionsStartOnly=true ExecStart=/usr/bin/qml-launcher Environment="XDG_RUNTIME_DIR=/run/user/0" Restart=always [Install] WantedBy=multi-user.target -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57909): https://lists.yoctoproject.org/g/yocto/message/57909 Mute This Topic: https://lists.yoctoproject.org/mt/93267815/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Multiple Images on the same HW platform with one image recipe
Hello Yocto Experts, I have a minor question regarding how to manage multiple projects within Yocto with MACHINE_FEATURES, DISTRO_FEATURES and IMAGE_FEATURES. If I have one HW platform but two images, where the latter one contains a bit more applications, am I supposed to have one MACHINE, one DISTRO and 2 IMAGES? Or maybe one IMAGE but somehow to define IMAGE_FEATURES / EXTRA_IMAGE_FEATURES differently in those two cases? Due to simplicity, I would rather have one image recipe. Whats the best way to achieve this? Thanks. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#57908): https://lists.yoctoproject.org/g/yocto/message/57908 Mute This Topic: https://lists.yoctoproject.org/mt/93267814/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH v5.10/standard/bcm-2xxx-rpi] drivers: drm: vc4: fix build failure caused by merge conflicts
In 0487f95471af ("Merge branch 'v5.10/standard/base' into
v5.10/standard/bcm-2xxx-rpi") there was a conflict between linux-stable
backports
de63dbc29681 ("drm/vc4: hdmi: Disable audio if dmas property is present but
empty")
717325e814d0 ("drm/vc4: hdmi: Limit the BCM2711 to the max without scrambling")
36f797a10f30 ("drm/vc4: hdmi: Fix timings for interlaced modes")
ed2f42bd8021 ("drm/vc4: dsi: Correct pixel order for DSI0")
and existing rpi SDK commits.
This caused the following build failures:
1. drivers/gpu/drm/vc4/vc4_crtc.c: In function 'vc4_crtc_config_pv':
drivers/gpu/drm/vc4/vc4_crtc.c:377:56:
warning: value computed is not used [-Wunused-value]
377 | PV_VERTA_VBP) |
drivers/gpu/drm/vc4/vc4_crtc.c:380:57:
error: expected ';' before ')' token
380 | PV_VERTA_VSYNC));
| ^
drivers/gpu/drm/vc4/vc4_crtc.c:380:57:
error: expected statement before ')' token
2. drivers/gpu/drm/vc4/vc4_hdmi.c:1540:13:
error: redeclaration of 'len' with no linkage
| 1540 | int len;
| | ^~~
Remove unneeded duplicated code to fix this.
Signed-off-by: Ovidiu Panait
---
drivers/gpu/drm/vc4/vc4_crtc.c | 17 -
drivers/gpu/drm/vc4/vc4_hdmi.c | 3 ---
2 files changed, 20 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c
index 26cf9cc105fe..c50a8286f3e6 100644
--- a/drivers/gpu/drm/vc4/vc4_crtc.c
+++ b/drivers/gpu/drm/vc4/vc4_crtc.c
@@ -338,17 +338,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc,
struct drm_encoder *encode
VC4_SET_FIELD(mode->hdisplay * pixel_rep / ppc,
PV_HORZB_HACTIVE));
- CRTC_WRITE(PV_VERTA,
- VC4_SET_FIELD(mode->crtc_vtotal - mode->crtc_vsync_end +
-interlace,
-PV_VERTA_VBP) |
- VC4_SET_FIELD(mode->crtc_vsync_end - mode->crtc_vsync_start,
-PV_VERTA_VSYNC));
- CRTC_WRITE(PV_VERTB,
- VC4_SET_FIELD(mode->crtc_vsync_start - mode->crtc_vdisplay,
-PV_VERTB_VFP) |
- VC4_SET_FIELD(mode->crtc_vdisplay, PV_VERTB_VACTIVE));
-
if (interlace) {
bool odd_field_first = false;
u32 field_delay = mode->htotal * pixel_rep / (2 * ppc);
@@ -372,12 +361,6 @@ static void vc4_crtc_config_pv(struct drm_crtc *crtc,
struct drm_encoder *encode
CRTC_WRITE(PV_VERTA_EVEN,
VC4_SET_FIELD(vert_bp_even, PV_VERTA_VBP) |
VC4_SET_FIELD(vert_sync, PV_VERTA_VSYNC));
- VC4_SET_FIELD(mode->crtc_vtotal -
-mode->crtc_vsync_end,
-PV_VERTA_VBP) |
- VC4_SET_FIELD(mode->crtc_vsync_end -
-mode->crtc_vsync_start,
-PV_VERTA_VSYNC));
CRTC_WRITE(PV_VERTB_EVEN,
VC4_SET_FIELD(vert_fp_even, PV_VERTB_VFP) |
VC4_SET_FIELD(mode->crtc_vdisplay,
PV_VERTB_VACTIVE));
diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
index a147dad0f52c..00e9416edc3d 100644
--- a/drivers/gpu/drm/vc4/vc4_hdmi.c
+++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
@@ -108,8 +108,6 @@ static bool vc4_hdmi_mode_needs_scrambling(const struct
drm_display_mode *mode)
return (mode->clock * 1000) > HDMI_14_MAX_TMDS_CLK;
}
-#define HDMI_14_MAX_TMDS_CLK (340 * 1000 * 1000)
-
static int vc4_hdmi_debugfs_regs(struct seq_file *m, void *unused)
{
struct drm_info_node *node = (struct drm_info_node *)m->private;
@@ -1537,7 +1535,6 @@ static int vc4_hdmi_audio_init(struct vc4_hdmi *vc4_hdmi)
const __be32 *addr;
int index, len;
int ret;
- int len;
if (!of_find_property(dev->of_node, "dmas", ) ||
len == 0) {
--
2.37.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11595):
https://lists.yoctoproject.org/g/linux-yocto/message/11595
Mute This Topic: https://lists.yoctoproject.org/mt/93266154/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
