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 <[email protected]>
*Gesendet:* Freitag, Januar 10, 2025 6:54:04 PM
*An:* Hecht, Martin (Avnet Silica) <[email protected]>;
[email protected] <[email protected]>;
[email protected] <[email protected]>
*Cc:* [email protected] <[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>; Rocca, Maxime
<[email protected]>
*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$ 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 <[email protected]>
*Gesendet:* Freitag, 10. Januar 2025 17:16
*An:* Hecht, Martin (Avnet Silica) <[email protected]>;
[email protected] <[email protected]>;
[email protected] <[email protected]>
*Cc:* [email protected] <[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>; Rocca, Maxime
<[email protected]>
*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 <[email protected]>
*Gesendet:* Donnerstag, 9. Januar 2025 22:07
*An:* Hecht, Martin (Avnet Silica) <[email protected]>;
[email protected] <[email protected]>;
[email protected] <[email protected]>
*Cc:* [email protected] <[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>; Rocca, Maxime
<[email protected]>
*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.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5533):
https://lists.yoctoproject.org/g/meta-xilinx/message/5533
Mute This Topic: https://lists.yoctoproject.org/mt/110518823/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
