Dragon Q6A vpu firmware loading

Dragon Series
1

I am working on adding support for the Dragon Q6A on Alpine Linux. So far, I think things are going pretty well. The qcs6490 is quite fast and the board’s performance for software building seems to be to quite capable. I’m keeping temps down when compiling with the armored heatsink case and a couple usb powered fans above and below. I’m not surprised that so much power in such a small package generates heat so fast. While building, the only temp that goes above 60c is the ufs module, but that always seems to run hotter in general (I suppose due its close proximity to the soc).

Some context:

  • Hypervisor Override option in bios set to enabled (to boot in EL2 by default)
  • Kernel build based on Radxa’s kernel sources (github/radxa/kernel linux-7.0.11 branch)
  • aic8800 drivers and firmware (github/radxa-pkg/aic8800)
  • UEFI boot via grub, modified using customized version of Fedora’s grub-mkconfig patch
  • Current image build is based on packages in a merge request I have in at Alpine’s gitlab instance, with the exception of the kernel config (which I’m working to make as stable as possible) and patch(es) mentioned below for debug purposes
  • The image is burnt to a usb thumb drive. It consists of 2 gpt partitions (efi and root), though the root is currently unused (bios seems to refuse to boot media with less than two partitions). This is used to do a mostly standard alpine install to a blank sd card.
  • I’m planning to on setting repositories for my builds and images on my vps server, but have not gotten it finished yet

While there are only a few issues in the dmesg log, right now I am trying to resolve an error for the qcom-iris module failing to load the vpu firmware. I have added a patch to the kernel build that adds some debug (mostly printk’s sprinkled in) to try to narrow down the issue and also to get to the bottom is error messages. If I understand correctly, the res.a0 value after the arm_smccc_smc_quirk() function call in drivers/firmware/qcom_scm-smc.c:102 is -2 which I believe equates to SMCCC_RET_NOT_REQUIRED defined in include/linux/arm-smccc.h. I am not sure, but this seems to imply that perhaps the firmware load is not actually failing but that EL3 is saying it already has it? I haven’t given up on my debugging attempts, but I thought maybe someone here might have some ideas or maybe some guidance.

I intended to link to more of my sources, but the UX here is restricting me to two links since this is my first post.

Cheers,
John

1 Like
2

I’ve looked closer at the return codes for __arrm_smccc_smc_quirk() and now I think I was looking up the value in the wrong place. I think the -2 value more likely equates to QCOM_SCM_EINVAL_ARG as defined in drivers/firmware/qcom/qcom_scm.h. That makes it an actual error. I don’t think the firmware blob is corrupt, I’ve checked it against a few sources and they were all the same. I wondered if the kodiak.dtsi file might have the wrong blob in it, but that seems unlikely to me; otherwise this would be happening to others.

3

I’ve done a fresh install and this is no longer an issue. The vpu firmware load issues do not show up in dmesg. The qcom_iris driver shows up with lsmod and several of related v4l modules also. I’ve yet to actually test the functionality, but at least the firmware should be gettting loaded now. Not sure what caused the issue before; perhaps the firmware file was actually corrupted somehow.