I'm looping in @Allagadapa, Varunkumar<mailto:varunkumar.allagad...@amd.com>, @Kharche, Yogesh<mailto:yogesh.khar...@amd.com>, @Udatha, Raghu<mailto:raghu.uda...@amd.com> from our multimedia eng and verif teams - please add anyone I missed. I assume the below was tested as part of multimedia regressions for our 24.2 release. Can you please help?
Cheers, Chris From: meta-xilinx@lists.yoctoproject.org <meta-xilinx@lists.yoctoproject.org> On Behalf Of Hecht, Martin (Avnet Silica) via lists.yoctoproject.org Sent: Monday, January 13, 2025 8:41 AM To: Mark Hatle <mark.ha...@kernel.crashing.org>; meta-xilinx@lists.yoctoproject.org; McDowell, Tony <tony.mcdow...@amd.com> Cc: Hatle, Mark <mark.ha...@amd.com>; Gundlupet Raju, Sandeep <sandeep.gundlupet-r...@amd.com>; Toomey, John <john.too...@amd.com>; Woerner, Trevor <trevor.woer...@amd.com>; Rocca, Maxime <maxime.ro...@amd.com> Subject: Re: [meta-xilinx] status of mali support of the BSP 2024.2 / weston, glmark2, kmscube Hi Mark, with adding INHERIT:remove = "create-spdx" in local.conf the images with the proprietary driver will be build (core-image-full-cmdline as well as core-full-image-weston, distro=petalinux). Just tried an old sdcard on zcu106 with an image based on core-image-weston build with 2023.1 and distro poky. weston comes up immediately and glmark2-es2-weston runs on weston but glmark2-es2-drm doesn't (after stoppong weston). Also weston came up on 2024.1 with distro=poky and weston9 fallback because libmali. But my video pipes with up to 4 cameras worked well so far (on 2023.1). I'm afraid there is something broken in version 2024.2 in current gpu and drm configuration as well with weston since the bsp uses systemd. I would really appreciate if you or someone else could check weston and glmark2 (on weston and on drm) on a zcu106 or zcu104 with empty PL if you could build core-image-weston and weston comes up. Version 2024.2 seams to be so differently .... I as wrote, I'm used tha both worked so far until 2023.1 or 2023.2 I rely on getting that running for our customer demo for Serma and other customers showing up t o4 cameras working in parallel and doing some other stuff in PL. Thanks a lot BR Martin ________________________________ Von: Mark Hatle <mark.ha...@kernel.crashing.org<mailto:mark.ha...@kernel.crashing.org>> Gesendet: Freitag, 10. Januar 2025 19:44 An: Hecht, Martin (Avnet Silica) <martin.he...@avnet.eu<mailto:martin.he...@avnet.eu>>; meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org> <meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org>>; tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com> <tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com>> Cc: mark.ha...@amd.com<mailto:mark.ha...@amd.com> <mark.ha...@amd.com<mailto:mark.ha...@amd.com>>; sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com> <sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com>>; john.too...@amd.com<mailto:john.too...@amd.com> <john.too...@amd.com<mailto:john.too...@amd.com>>; trevor.woer...@amd.com<mailto:trevor.woer...@amd.com> <trevor.woer...@amd.com<mailto:trevor.woer...@amd.com>>; Rocca, Maxime <maxime.ro...@amd.com<mailto:maxime.ro...@amd.com>> Betreff: [External]Re: [meta-xilinx] status of mali support of the BSP 2024.2 / weston, glmark2, kmscube Figured out why we didn't see it. If you explicitly install 'kernel-module-mali', you get the failure. However, if you indirectly install it, then everything works fine. So in your image, just install the libmali-xlnx (or something that depends on that) and leave the 'kernel-module-mali' out of it. --Mark On 1/10/25 11:56 AM, Hecht, Martin (Avnet Silica) wrote: > Hi Mark, > > Thanks a lot. > > Is there a chance to collaborate in that? > > Also I will go ahead on that next week. > > BR Martin > > > -------------------------------------------------------------------------------- > *Von:* Mark Hatle > <mark.ha...@kernel.crashing.org<mailto:mark.ha...@kernel.crashing.org>> > *Gesendet:* Freitag, Januar 10, 2025 6:54:04 PM > *An:* Hecht, Martin (Avnet Silica) > <martin.he...@avnet.eu<mailto:martin.he...@avnet.eu>>; > meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org> > <meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org>>; > tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com> > <tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com>> > *Cc:* mark.ha...@amd.com<mailto:mark.ha...@amd.com> > <mark.ha...@amd.com<mailto:mark.ha...@amd.com>>; > sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com> > <sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com>>; > john.too...@amd.com<mailto:john.too...@amd.com> > <john.too...@amd.com<mailto:john.too...@amd.com>>; > trevor.woer...@amd.com<mailto:trevor.woer...@amd.com> > <trevor.woer...@amd.com<mailto:trevor.woer...@amd.com>>; Rocca, Maxime > <maxime.ro...@amd.com<mailto:maxime.ro...@amd.com>> > *Betreff:* [External]Re: [meta-xilinx] status of mali support of the BSP > 2024.2 > / weston, glmark2, kmscube > > I've replicated the problem, I don't know the cause. It's odd that we aren't > seeing this on internal builds, but I can reproduce it here. > > --Mark > > On 1/10/25 10:39 AM, Hecht, Martin (Avnet Silica) via lists.yoctoproject.org > wrote: >> Hi Mark, >> >> that versions as cloned with repo using the manifest for 2024.2. >> >> Build Configuration: >> BB_VERSION = "2.8.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "universal" >> TARGET_SYS = "aarch64-xilinx-linux" >> MACHINE = "zcu106-zynqmp" >> DISTRO = "petalinux" >> DISTRO_VERSION = >> "2024.2+snapshot-effc3f999b891773d51b021b77f1775d7569fa33" >> TUNE_FEATURES = "aarch64 crc cortexa72-cortexa53" >> TARGET_FPU = "" >> XILINX_RELEASE_VERSION = "v2024.2" >> DISTRO_NAME = "PetaLinux" >> ROS_DISTRO = "jazzy" >> ROS_VERSION = "2" >> ROS_PYTHON_VERSION = "3" >> XILINX_XSCT_VERSION = "2024.2" >> meta >> meta-poky = "HEAD:e86fd88e8efbbc2aa4730776ab284e072d57da04" >> >> >> >> martin@avt74j0:/opt/yocto/AMD/xlnx-rel-v2024.2/sources$<mailto:martin@avt74j0:/opt/yocto/AMD/xlnx-rel-v2024.2/sources$> >> repo info >> Manifest branch: >> Manifest merge branch: refs/heads/rel-v2024.2 >> Manifest groups: default,platform-linux >> ---------------------------- >> Project: yocto-manifests >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/manifest >> Current revision: 9bd495acf4ac6c9ef98bcae2903815d2aef397a6 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-amd-adaptive-socs >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-amd-adaptive-socs >> Current revision: de538f8f12d6753769d5a7258b06a710425a3fb3 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-arm >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-arm >> Current revision: 1947c000299c0330e8a866996505221a14c0e1ea >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-aws >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-aws >> Current revision: 4ab666977b3a91ada750d6a0b70af8a7945dfea4 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-embedded-plus >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-embedded-plus >> Current revision: a92de9de148bafcea91e294255a22c695dc72383 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-jupyter >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-jupyter >> Current revision: 6b9b2542f3e52d30f5100747ce312dc46791c5cc >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-kria >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-kria >> Current revision: b42f08af84520fbcfffb0b6da7bcc902d1c30bc1 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-mingw >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-mingw >> Current revision: acbba477893ef87388effc4679b7f40ee49fc852 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> ---------------------------- >> Project: meta-openamp >> Mount path: /opt/yocto/AMD/xlnx-rel-v2024.2/sources/meta-openamp >> Current revision: 68049285b561f071bd7cc093f9ecbe4f5518ddf9 >> Manifest revision: rel-v2024.2 >> Local Branches: 0 >> : >> >> BR Martin >> -------------------------------------------------------------------------------- >> *Von:* Mark Hatle >> <mark.ha...@kernel.crashing.org<mailto:mark.ha...@kernel.crashing.org>> >> *Gesendet:* Freitag, 10. Januar 2025 17:16 >> *An:* Hecht, Martin (Avnet Silica) >> <martin.he...@avnet.eu<mailto:martin.he...@avnet.eu>>; >> meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org> >> >> <meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org>>; >> tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com> >> <tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com>> >> *Cc:* mark.ha...@amd.com<mailto:mark.ha...@amd.com> >> <mark.ha...@amd.com<mailto:mark.ha...@amd.com>>; >> sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com> >> <sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com>>; >> john.too...@amd.com<mailto:john.too...@amd.com> >> <john.too...@amd.com<mailto:john.too...@amd.com>>; >> trevor.woer...@amd.com<mailto:trevor.woer...@amd.com> >> <trevor.woer...@amd.com<mailto:trevor.woer...@amd.com>>; Rocca, Maxime >> <maxime.ro...@amd.com<mailto:maxime.ro...@amd.com>> >> *Betreff:* [External]Re: [meta-xilinx] status of mali support of the BSP >> 2024.2 >> / weston, glmark2, kmscube >> >> >> On 1/10/25 10:12 AM, Mark Hatle wrote: >>> >>> >>> On 1/10/25 9:14 AM, Hecht, Martin (Avnet Silica) wrote: >>>> Hi Mark and Tony, >>>> >>>> please apologize that I need to come back because unresolved challenges >>>> with >>>> both ways to get the ARM Mali up and running. >>>> >>>> At first thanks for the hints sent yesterday. >>>> >>>> Creating the board specific configs works good so far, especially when >>>> using >>>> parameter -r to include the original board config additionally. >>>> >>>> Nevertheless I'm struggling with the mali support at all. As you Mark are >>>> the >>>> official maintainer I would really appreciate if you could point me to >>>> someone >>>> who has tested both mali configurations. It seems something is missing for >>>> lima >>>> and SDPX info is missing/configured wrong for mali. >>>> >>>> I reduced my test case on zcu106-zynqmp without any additional custom >>>> layers and >>>> xsct flow. According the README.md of meta-xilinx-mali400 I can't get >>>> neither >>>> lima nor (old propriatary) mali400. >>>> >>>> Building with >>>> xsct flow and mali400, distro=petalinux according >>>> meta-xilinx-mali400/README.md >>>> bitbake stops building core-image-full-cmdline stops with the following >>>> error >>>> message: >>>> >>>> ERROR: core-image-full-cmdline-1.0-r0 do_rootfs: Unable to find package >>>> with >>>> name 'kernel-module-mali' in SPDX file >>>> /mnt/data2/projects2/v2024.2/alvium_linux_xlnx/build_zcu106_20250110/tmp/deploy/spdx/by-hash/zcu106_zynqmp/sstate:kernel-module-mali:zcu106_zynqmp-xilinx-linux:r9p0-01rel0:r0:zcu106_zynqmp:12:/kernel-module-mali-6.6.40-xilinx-g2b7f6f70a62a.spdx.json >>>> ERROR: Logfile of failure stored in: >>>> /mnt/data2/projects2/v2024.2/alvium_linux_xlnx/build_zcu106_20250110/tmp/work/zcu106_zynqmp-xilinx-linux/core-image-full-cmdline/1.0/temp/log.do_rootfs.3318289 >>>> ERROR: Task >>>> (/opt/yocto/AMD/xlnx-rel-v2024.2/sources/poky/meta/recipes-extended/images/core-image-full-cmdline.bb:do_rootfs) >>>> failed with exit code '1' >>> >>> >>> What version of 'poky' are you using? There was a bug in the original >>> scarthgap >>> release that failed like this. Current Scarthgap (5.0.4-5.0.6) should be >>> working. (It may have been fixed prior to 5.0.4, but I'm not sure which >>> release >>> it was fixed in.) >>> >>> The underlying issue is a regex was incompatible w/ a scarthgap change. If >>> you >>> are using latest meta-xilinx and poky (scarthgap) and experiencing this >>> issue, >>> let me know. I need a copy of your configuration to try to replicate it. >> >> I forgot, there is a workaround for this issue -- if required. In your >> local.conf, the following SHOULD disable spdx. >> >> INHERIT:remove = "create-spdx" >> >>> --Mark >>> >>>> I hadn't have the time to try to fix that by myself right now. But I I >>>> think >>>> it's a known bug or untested. >>>> >>>> If I change the config to lima than bitbake builds and I see lime module is >>>> loaded as well as mesa has been installed. Nevertheless glmark2-es2-drm >>>> starts. >>>> I have seen similar issue in 2024.1 on fullscreen but on the other hande I >>>> could >>>> get weston up and runnint and glmark2 could be run on weston. Nevertheless >>>> Neither on 2024.1 nor 2024.2 I could get kmscube running as I used for >>>> testing >>>> since 2018.x... >>>> >>>> I assume someone has tested the current BSP configurations incl. weston and >>>> glmark2. >>>> >>>> Please check / let check the mali configuration or if possible please send >>>> over >>>> a tested yocto config (in best case for an (almost) empty PL) for one of >>>> the >>>> boards zcu106, zcu104 or (zcu102 not tested right now). I need to overcome >>>> that >>>> issue to focuss on our 4 channel CSI camera deisgn again for the customer >>>> presentation at Serma Engineering very soon. (and other customers) >>>> >>>> BR Martin >>>> >>>> -------------------------------------------------------------------------------- >>>> *Von:* Mark Hatle >>>> <mark.ha...@kernel.crashing.org<mailto:mark.ha...@kernel.crashing.org>> >>>> *Gesendet:* Donnerstag, 9. Januar 2025 22:07 >>>> *An:* Hecht, Martin (Avnet Silica) >>>> <martin.he...@avnet.eu<mailto:martin.he...@avnet.eu>>; >>>> meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org> >>>> >>>> <meta-xilinx@lists.yoctoproject.org<mailto:meta-xilinx@lists.yoctoproject.org>>; >>>> tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com> >>>> <tony.mcdow...@amd.com<mailto:tony.mcdow...@amd.com>> >>>> *Cc:* mark.ha...@amd.com<mailto:mark.ha...@amd.com> >>>> <mark.ha...@amd.com<mailto:mark.ha...@amd.com>>; >>>> sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com> >>>> <sandeep.gundlupet-r...@amd.com<mailto:sandeep.gundlupet-r...@amd.com>>; >>>> john.too...@amd.com<mailto:john.too...@amd.com> >>>> <john.too...@amd.com<mailto:john.too...@amd.com>>; >>>> trevor.woer...@amd.com<mailto:trevor.woer...@amd.com> >>>> <trevor.woer...@amd.com<mailto:trevor.woer...@amd.com>>; Rocca, Maxime >>>> <maxime.ro...@amd.com<mailto:maxime.ro...@amd.com>> >>>> *Betreff:* [External]Re: [meta-xilinx] status of mali support of the BSP >>>> 2024.2 >>>> / weston, glmark2, kmscube >>>> >>>> >>>> On 1/9/25 10:25 AM, Hecht, Martin (Avnet Silica) via >>>> lists.yoctoproject.org wrote: >>>> > Hi Mark and Tony, >>>> > >>>> > just a question regarding current status of mali support of the BSP >>>> 2024.2. >>>> >>>> You need to be sure your project includes the meta-xilinx-mali400 layer. >>>> This >>>> includes all of the support for the mali400 that is in the ZynqMP EG and >>>> EV line. >>>> >>>> See the README.md file in that layer for more information. >>>> >>>> > I'm used to have the proprietary mali userspace lib since we enable >>>> Weston and >>>> > libgbm many years ago together with your colleagues (Alok Gupta and >>>> Kwon Hyun) . >>>> >>>> Both the proprietary and open source (mesa-lima) support is available. >>>> When >>>> using PetaLinux, the proprietary mali driver is defaulted. If you are >>>> using a >>>> different distribution you will need to enable it as the open source >>>> library is >>>> the default. >>>> >>>> In short, open source driver (and proprietary) is enabled when the machine >>>> includes the MACHINE_FEATURES of 'mali400'. Then the proprietary driver >>>> is >>>> further enabled with a DISTRO_FEATURES that includes "libmali". >>>> >>>> There are both advantages and disadvantages of both the proprietary and >>>> open >>>> source drivers, thus we enable the use of both of them, but they are >>>> mutually >>>> exclusive in your filesystem -- so you will need to decide which to use. >>>> >>>> > So far I remember I could get it running with 2023.1 too (with weston >>>> 9). >>>> >>>> Weston newer then 9 requires OpenGL/mesa interfaces that are not provided >>>> by the >>>> proprietary libmali driver. The layer provides a port of Weston 9 for use >>>> with >>>> the proprietary driver, but also allows Weston 13 (in scarthgap/2024.2) to >>>> be >>>> used if you are using the open source mesa-lima. >>>> >>>> > I never tested lima before. But since 2024.1 and 2024.1 I can't get >>>> weston >>>> > running when buidling core-image-weston even also with distro >>>> petalinux. >>>> >>>> Your machine and distro both need to be enabled with the FEATURES I >>>> mentioned >>>> above. In 2024.2, we explicitly moved this out to make it clear what is >>>> being >>>> done for mali support, as many users will not need it. >>>> >>>> > Also I can't get glmark2-es2-drm running on kms as I used to run. Same >>>> for >>>> kmscube. >>>> >>>> I'd suggest reporting this through the normal AMD support methods. I have >>>> limited experience executing the glmark2 demos, so I'm not sure what is and >>>> isn't supported and the ramifications of this. >>>> >>>> > I'm working on a customer demo were I need to use the gpu for online >>>> and offline >>>> > rendering for video streams in realtime. I did this in past with a >>>> similar >>>> > approach as kmscube over several releases since probably 2018.x. So it >>>> was >>>> > possible to use the Mali GPU for video transformation (2D, 3D) and >>>> mixing >>>> > multiple layers in gstreamer .... >>>> > >>>> > In weston I was also able with the older BSP's to adjust the bpp of >>>> the video >>>> > memory in dts as well in weston to use 32bpp. >>>> > >>>> > Currently I'm struggeling because I can't use drm correctly. >>>> > >>>> > Can someone confirm that weston and glmark2 works in 2024.2? I tried >>>> both mali >>>> > configurations on zcu106 as described in >>>> > sources/meta-xilinx/meta-xilinx-mali400/README.md . >>>> > >>>> >>>> I'm not familiar with all of the ways that the mali400 is being used. I >>>> would >>>> expect if it worked in the past it should still work, at least in the >>>> context of >>>> the proprietary driver. >>>> >>>> If you are using the ZynqMP EV, then you also need to ensure that you have >>>> enabled the 'vcu' support and are using it with gstreamer for the highest >>>> performance. But beyond that I don't have much experience with it to add >>>> more >>>> details. I think the AMD forums may be better equipped to answer specific >>>> questions about using the components for the best experience. >>>> >>>> --Mark >>>> >>>> > >>>> > Thank you very much in advance. >>>> > >>>> > BR Martin >>>> > >>>> > We continuously commit to comply with the applicable data protection >>>> laws and >>>> > ensure fair and transparent processing of your personal data. >>>> > Please read our privacy statement including an information notice and >>>> data >>>> > protection policy for detailed information on our website. >>>> > >>>> > >>>> > >>>> > >>>> > >>>> >>>> We continuously commit to comply with the applicable data protection laws >>>> and >>>> ensure fair and transparent processing of your personal data. >>>> Please read our privacy statement including an information notice and data >>>> protection policy for detailed information on our website. >>>> >>>> >>>> >>>> >>>> >> >> We continuously commit to comply with the applicable data protection laws and >> ensure fair and transparent processing of your personal data. >> Please read our privacy statement including an information notice and data >> protection policy for detailed information on our website. >> >> >> >> >> > > We continuously commit to comply with the applicable data protection laws and > ensure fair and transparent processing of your personal data. > Please read our privacy statement including an information notice and data > protection policy for detailed information on our website. > We continuously commit to comply with the applicable data protection laws and ensure fair and transparent processing of your personal data. Please read our privacy statement including an information notice and data protection policy for detailed information on our website.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#5536): https://lists.yoctoproject.org/g/meta-xilinx/message/5536 Mute This Topic: https://lists.yoctoproject.org/mt/110518823/21656 Group Owner: meta-xilinx+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
