Greetings,
I’m working on a way to access and code the Hexagon DSP on the Dragonboard 410c. If anyone knows the procedure, please share.
Thank you
Having the same doubt
Hi @kcvastare and @caseycube,
We also do not have access to the technical information of Hexagon DSP on Dragonboard 410c and not able to do anything about it at the moment.
Your messages of requests on this forum will help us.
Lets wait for the situation changes.
Adding support for the Hexagon SDK in the Linux release is indeed “on the roadmap”. There are a few pieces missing:
- Hexagon SDK runtime libs/apps/samples
- kernel driver to expose the IPC APIs used by the Hexagon SDK runtime
The DSP firmware that we use has support for the SDK already, but without the 2 pieces above, it can’t be used.
Note that this would only enable access to HExagon through the QCOM SDK, like it is possible on Android builds. You do not get full control of the DSP. But I am assuming you were aware of that.
Thank you @ndec and @ldts-atsuka for your quick response.
@ndec, I have a few more doubts
Which Hexagon SDK supports dragonboard 410c?
could you please share the links to download the SDK runtime and the kernel drivers?
Thanks again
I am not sure… I was under the impression that it had been released for Android on 410c, but I couldn’t find any link/info… Hopefully someone else can comment on that.
Hi Linaro Experts,
Is there any update for support Hexagon SDK on Debian?
I’m not sure whether I miss any release note because I cannot find the related information about it.
Only found this topic to discuss about it.
Thanks.
Best regards,
Johnny
Hi @dodoamuro,
Following github repo seems to have some information about running apps on Hexagon DSP present in 410c/820c.
PS: I haven’t tested this personally. For any issues, please raise it in the repo for better support.
Thanks,
Mani
Hi
I have similar problem. I try to run DSP application on Debain.
As Android does, libadsprpc.so and adsprpc.ko are required. But they are missing on Debian.
Is there any alternative way to run program on DSP on Debain?
Thank you.
If you read mcharleb’s github information carefully, he refers to the “Upstream” and “Downstream” kernels. The Upstream kernel is the Debian kernel from Linaro where almost all of the customizations for Qualcomm processors have been formally merged into the latest kernel. The Downstream kernel is the Qualcomm kernel (based on Linux 3.18) with millions of lines of changes. The FastRPC and Diag features are required, and I don’t think they have made it into the Linaro/Debian builds.
I also played with OpenCL on the 820c Dragonboard. My attempted approach was to take the Android binaries and run them under Debian. The process starts with your OpenCL source code which then gets compiled into a shader, this step almost works, but the Android OpenCL compiler gets caught up looking for a basic Android library .so file which is not available under Debian. I suspect that there is a package that could be installed for Android emulation, but I didn’t find it. This approach might be closer to working under AOSP.
Even if I had managed to get the shader compiled nativly, it would have run into the missing FastRPC library issue.
@anon91830841 When will FastRPC and OpenCL be available?
-Lawrence-
hi @ljking,
There is on going work on fastRPC at the moment and we expect a working solution within the next 2 to 3 months, for 410c and 820c. With all the pieces in place, the expectation is that what mentioned in the Github link above will ‘just work’ with the Debian and OpenEmbedded based releases for the Dragonboard, and with upstream kernel in general.
For OpenCL, there is a bit of community work done by the Freedreno people regarding GPU compute support, but there is no short term expectation/plan for OpenCL.
Hi @anon91830841,
If we want to try it by ourselves before fastRPC ready, could we get the Downstream kernel to test it first?
If yes, where can we download the Downstream kernel?
Thanks.
Best regards,
Johnny
hi @dodoamuro,
we are not doing any work with the downstream CAF/MSM kernel, so I cannot really answer your question. The github link in one of the previous post seems to indicate it’s possible… but that’s the only thing I can tell…
the main developer working on fastRPC for upstream / Linaro releases is out currently. I am hoping we can get some basic instructions to try fastRPC on top of our releases (for DB410c) within the next 2 weeks. It will be raw instructions, and you will need to rebuild a custom kernel branch and a few user space tools, though. Would that help?
Hi @anon91830841,
Your information is really helpful!! Hope we can see the release soon.
Thanks.
Best regards,
Johnny
Hi ndec :
Appreciate with your great help.
May I contact with you by your mail or my mail (kentc.chiang@msa.hinet.net) for fastRPC.
Appreciate again
hi @albertchiang,
we provide free support on this forum for the 96boards community, please avoid private messages as much as possible, as this won’t benefit the entire community.
thanks
Hi ndec :
Sorry and understood.
-
We just wish can get Fast RPC Binary code (even beta version) to test for customer project ASAP.
Even help to test or debug is ok for us. -
We are afraid of the actually release schedule delay.
We are feel apologize again
Also appreciate with your help for so many information
Albert
Also we had wrote request to Linaro Developer service on 8/20 but no feedback until now. So we didn’t know how to speed it up. Thanks.
Hi Linaro Experts,
For Qualcomm 410 Linux 3D Test , Does it had 3D test report ? Also using which benchmark test it ? Does it with Qualcomm proprietary files ?
Also in below 96board and Qualcomm BSP:
https://releases.linaro.org/96boards/dragonboard410c/linaro/openembedded/18.01/rpb/
Does they had above 3D test report ? Benchmark test ? with ualcomm proprietary files or not ?
Your help is highly appreciate
Albert
hi @albertchiang,
If I understand your question correctly, you are asking about OpenGL/GLes support, right? If so, then we are using an open source graphics driver, from the Mesa project, called freedreno. Mesa/Freedreno project is the user space side of the OpenGL/GLes implementation. It runs on top of the kernel DRM/KMS driver.
There is no Qualcomm proprietary software involved in the kernel and user space.
On the GPU, there is a firmware required, and this firmware is proprietary and distributed by Qualcomm (it is included in the linux-firmware project).
Any standard Linux graphics test suite or benchmark is expected to work.
