1. Messages
  2. what's the situation with yocto support for qualcomm qcs{410,610} eval boards?

Re: what's the situation with yocto support for qualcomm qcs{410,610} eval boards?

Nicolas Dechesne <nicolas.dechesne@...>
 

hey,

On Thu, May 19, 2022 at 9:31 PM Robert P. J. Day <rpjday@...> wrote:

   colleague just asked if i had any useful advice (spoiler: no) on how
easy it would be to build a yocto-based image for *some* qcs410-based
eval board. i'm familiar with meta-qcom, and machine definitions for
dragonboards, but this is clearly(?) different, and i see nothing in
the meta-qcom layer for this.

the underlying chipset , e.g. the Qualcomm QCS410 (or 610) is not supported upstream. So a 'regular' OE + meta-qcom is not going to be straightforward. meta-qcom typically supports 'machines' and soc which have enough upstream support (mostly the one we, at Linaro, work with). 
 

   what i see is that qualcomm supplies a linux sdk, and i quote from
https://linuxgizmos.com/module-and-dev-kit-run-linux-on-qcs610-camera-soc/:

"A Linux SDK is built on Yocto Thud with Linux kernel 4.1.4. The SDK
integrates Qualcomm optimizations, GStreamer wth RTSP streaming support,
and AI support for TensorFlow Lite and Qualcomm SNPE. Android 10 support
is coming later."

   the more i read in the last half hour, the more it seems that one
needs to bury oneself in qualcomm SDK, and repo-based checkouts from
codeaurora and so on. is this the way to go? or have i missed something?

Yes, you are correct. that is a description of the QCOM/vendor 'SDK'. It's typically built from one version of Yocto + the vendor kernel (they recycled the Android kernel used in similar devices) + some open source user space (sometimes inherited from Android) + some non open source user space, distributed as binary blobs. 


   colleague has some freedom in choice of qcs410-based eval board, if
that makes things easier.

I would be happy to merge new machines in meta-qcom, assuming their BSP is a 'vanilla' BSP which does not require any of the user space components from the vendor SDK.. Depending on the use cases needed it might be very feasible to have enough upstream support for this board.. we (at linaro) provide such services too.. 
 


rday
Join {yocto@lists.yoctoproject.org to automatically receive all group messages.