Mity CPU Platforms » MitySOM-QC6490

Hi David,

Regarding Item 1:

We are currently working on support for for QLI 2.0 as our next release. Below is a table my buddy Opus created based our current release and some internal WIP updates we have:

Regarding updating the GPU userspace independently, we have found that all the parts of a release are typically tied together pretty closely. I would say there is decent risk of complications with trying to do something like attempting to update just the Adreno driver for QLI 1.5 to get cl_qcom_ml_ops support. Can you detail what interfaces you need to be functional for your application and as soon as we have a prelim build that supports QLI 2.0 and your required interfaces we could share that to get you running on 2.0 ASAP.

Regarding Item 2:

Thank you for sharing. I will check if this is still an issue with QLI 2.0.

Regarding Item 3:

Thank you for sharing as well. I will look into addressing this.

Thanks,
Greg

Hi Greg,

Fantastic — thank you. A preliminary QLI 2.0 build would be very welcome. The interfaces we need functional, in priority order:

1. OpenCL 3.0 on the Adreno 643 — headless, from a container: /dev/kgsl-3d0 + /dev/dma_heap/system passthrough, libOpenCL.so.1 > libOpenCL_adreno.so.1 and its dlopen closure (libgsl/libCB/libq3dtools_adreno/libadreno_utils/libllvm*). We validate with clinfo/clpeak + our own FP32 conv-net benchmarks.
2. Vulkan compute on the Adreno 643 — headless instance creation + compute queue (no WSI/display). Today this needs an ICD manifest for libvulkan_adreno.so.1 and /dev/dri/renderD128; either keeping that recipe working or wiring a manifest into the image is fine. We validate with vulkaninfo + ncnn compute.
3. Docker/containers (we bind-mount the host GPU userspace read-only into ubuntu:24.04-based containers — glibc compatibility of the Adreno userspace matters; 1.5''s build needed glibc >= 2.39).

1. cl_qcom_ml_ops / CLML with entry points resolving via clGetExtensionFunctionAddressForPlatform — FP16/FP32 ML ops on the GPU. We plan to drive it via TVM's CLML backend and/or direct CLML calls.

1. cl_qcom_recordable_queues, cl_khr_fp16, cl_qcom_ext_host_ptr(_iocoherent), cl_khr_image2d_from_buffer (zero-copy paths)
2. USB host on the USB-A port + RTL8153 USB-Ethernet (our only network path — a USB-C VBUS issue we saw kept us from using that for a network adapter: Unable to get vbus regulator err: -19, supply pm_ivbus_bd)
3. OSTree layout compatibility (we install only to /usr/local, /opt, /home, /etc) and working opkg/BusyBox userland assumptions, or release notes on what changed with the 6.18 kernel jump

We can turn around validation results on a prelim build quickly. Also, for the dev kit with the newer production-speed RAM, will it ship with QLI 1.5?

Thanks!
David

Hi David,

Thank you for the details. I will post a prelim build that meets your requirements here ASAP.

Regarding your question on the dev kit with the newer production-speed RAM, it will ship with what we refer to as BSP Release 1.2, which is QLI 1.5 based.

Thanks,
Greg

Thank you!

Some ancillary feedback for a QLI 2.0+ image based on working the current dev kit - lmk if you need these broken out separately.

1. The stock image ships pulseaudio.service enabled with a config that segfaults on the headless dev kit (pal-config-parser: can''t open /proc/asound/cards, invalid port handset-mic) → crash-loop every ~3 s forever (restart counter 271 in 14 min). The audit/journal storm eventually wedges journald and then all of userspace (sshd accepts TCP but never sends a banner; getty dead) — a power-cycle-only hang that hit us twice in two days. Workaround: mask pulseaudio. Suggest the BSP either fix the PAL config, gate the unit on sound hardware, or set StartLimitBurst so a crash-looping unit gives up.
2. No hardware watchdog is exposed (/sys/class/watchdog/ empty on QLI 1.5) — combined with (1), a wedged device cannot self-recover, which matters for unattended/embedded deployments. Request: enable the Qualcomm APSS watchdog node so RuntimeWatchdogSec= works.
3. Minor: SysRq-over-serial-break appears inert (kernel likely built without CONFIG_MAGIC_SYSRQ_SERIAL) — useful escape hatch on a headless board if cheap to enable.

Masking pulseaudio was fine for me - we don't have audio needs currently - so, I'm not blocked by this at the moment

Hi David,

Here is a link to a prelim build which should allow you to continue your validation.

• The specified Must-haves should be in there, but let me know if I misunderstood anything.
• cl_qcom_ml_ops is present along with the functions you specified as nice-to-have
• FW was modified to lower RAM speed so this build works on rev1 and rev4 SOMs. If you think it would be helpful to have a build without this limitation for running on rev4 boards only please let me know and I can provide one.
• MACHINE = rb3gen2-core-kit as opposed to MACHINE = qcs6490-mitysom-devkit for the time being, as I used rb3gen2-core-kit as a starting point for the port to QLI 2.0
• adb is not currently working on this build, though I have verified the usb-c port still works with usb flash drives
• Support for RTL8153 USB-Ethernet is present and I have verified it working via the USB A ports
• I'll have to look closer into the OSTree layout compatibility
• I have not seen issues with pulseaudio.service on this build, but there are other random crashes/issues that we are still working on digging into.
• /sys/class/watchdog is no longer empty
• CONFIG_MAGIC_SYSRQ_SERIAL=y

My next focus will be on making this prelim setup available to rebuild similar to scarthgap-next. If you have any issues impacting your validation efforts please let me know so I can see what I can do.

Thanks,
Greg

Greg,

Sorry for the delayed reply. Thanks for this! Looks like it addresses all of our immediate needs. I'll flash the device tomorrow and let you know how it goes. One quick question from my agent ...

Looks like rawprogram3.xml overwrites the cdt partition (board identity/DDR config) with an RB3Gen2 cdt.bin.Which CDT should a MitySOM use with this package — or should we skip the cdt entry? Either way, we'll back up ours first.

David

Hi David,

Sounds good! Keep me posted if you run into any major issues or inconveniencies (e.g. one thing I forgot to mention is that the prelim build was built with a lot of debug options enabled, so boot times etc are much more verbose and will take longer. I can easily post an image with these debug options removed if they are impeding your validation efforts).

I'll post an update here when I've made the current WIP branch public in case you want to rebuild locally.

Regarding the CDT, Qualcomm started including this as part of the image flash in QLI 2.0. Previously this was treated as a separate configuration programming process. Please keep the RB3Gen2 cdt.bin as part of the programming process for the prelim QLI 2.0 image. If you revert back to the QLI 1.5 images, BSP Release 1.1 and BSP Release 1.2 in Repositories and Pre-built Images have the CDT binaries and instructions for flashing them, so just make sure you do that before programming the QLI 1.5 qcom-multimedia-image files.

Thanks,
Greg

Hi Greg,

Flashed the prelim build today — mostly excellent news, one blocker on the headline feature:

Working out of the box: headless Vulkan compute (native  vulkaninfo : API 1.3.295, driver 0.855.5 — the QLI 1.5 loader-symbol issue is fully resolved), OpenCL 3.0 (35 extensions), docker in-image, RTL8153 via USB-A,  /sys/class/watchdog  populated, clpeak matches our QLI 1.5 numbers (~11.6 GB/s / ~770 GFLOPS SP, as expected with the rev1 RAM limit).

Blocker —  *cl_qcom_ml_ops*  is not exposed at runtime on our kit: the extension is absent from the device extension string, and all  *clCreateMLOp*QCOM*  entry points return NULL from  *clGetExtensionFunctionAddressForPlatform*  (control check:  *clSetPerfHintQCOM*  resolves fine, and the CLML implementation is visibly present in  *libOpenCL_adreno.so.1* ). We believe the driver gates ml_ops by GPU identity: with this image's DTB our GPU identifies as  *qcom,adreno-635.0*  (kgsl  *Adreno635v1* , CL device name "Adreno (TM) 635") rather than Adreno 643. Your comparison table showed  *CL_DEVICE_NAME = "QUALCOMM"*  (truncated) on your 2.0 setup — did your test unit identify as a 643? If so, a DTB carrying the 643 chip-id (e.g., as part of the mitysom machine port) may be all that's needed. Happy to test any iteration same-day.

Minor notes:  *Adreno 635*  also appears in Vulkan's deviceName; a second OpenCL platform (Mesa rusticl, 0 devices) is present as your table noted; verbose boot is no problem for us.

Thanks,
David