Forums - Hexagon SDK 1.1.0 support for APQ8064's DSP - A few issues

2 posts / 0 new
Last post
Hexagon SDK 1.1.0 support for APQ8064's DSP - A few issues
sateesh.pedagadi
Join Date: 22 Jul 14
Posts: 1
Posted: Mon, 2014-08-18 03:04

Hi

I have an Inforce IFC6410 board that uses APQ8064. I am not managing to run Hexagion DSP examples provided in Hexagon SDK 1.1.0 on this  board.

A) I was wondering if this is because the SDK 1.1.0 can only support 800 based boards as highlighted here.

The folder Hexagon_SDK\1.1.0\images\ seem to contain only one folder M8974AAAAAAAZL220527A.19 and my wild guess about the substring 8974 in folder name is a reference to 800 based chip. But the README.FIRST.txt in the folder  Hexagon_SDK\1.1.0\images\M8974AAAAAAAZL220527A.19\adsp_proc\avs\aDSPSim has the following (line 83 )

set HEXAGON_IMAGE_ROOT=T:\M8960AAAAANAZL100550\adsp_proc , which may refer that DSP images folder for 8960 (APQ8064) should have existed (may be in the past?). This may explain my doubt in (A) because the SDK doesnot have the correct images for the board I have (again, guess work). 

When I tried to run calculator example, I always got a message "adspmgd not supported". I did not manage to figure out where the issue was as adsprpc.ko seemed to load fine, a test signature was generated and pushed to /system/lib/rfsa/adsp folder. This is all inline with the documenation provided. So I tried a different approach, this time building and running DSP's fastcv cornerApp example. 

After a few trial and errors, all the files were pushed into the right folders on the target as described in the documentation but running the cornerapp example threw an error 'adsp error: dspCV dlopen'.  Looking into the .mak and .min files for the app, I understood that "hexagonv4_" flavour of the files were missing as APQ8064's DSP is qdspv4 (from here). 

Looking into the library depenency chain for cornerApp, I have created "hexagonv4_" flavours for cornerApp\lib\fastcv\dspCV but I have hit a deadend with lib\fastcv and lib\common\app_mem_heap libraries as there is no source to build these libraries. 

A few questions for experts

1. Does Hexagon SDK1.1.0 support APQ8064 based hardware? 

2. Is there a different version of Hexagon SDK that can be acquired and must be used for APQ8064's DSP development? How can developers access it?

3. Does cornerApp example has any dependency on the DSP images? What is the role of a DSP image and when does it come into play?

4. What is the use of 'hexagon_Release_dynamic' flavoured .mak and .min files? Does the code built from using these files capabale of identifying the DSP version during runtime?

5. Supposing cornerApp example can run on its own with a depencency chain involving dspCV, fastcv and app_mem_heap libraries, are there qdspv4 flavoured built libraries for qDSPv4? May be this is where the issue is, wherein the libs were compiled against dspv5 and are incompatible with qdspv4?

6. Is it possible that the above assumptions are all incorrect and all I need is an Android image that has support for qDSPv4, which I may not have on the target?

I would be grateful for any resolutions or directions I can get to get the DSP working on my board.

PS: When I flashed the images provided by the board manufacturer, the 'getserial' app threw adsprpc errors. It was advised in the documentation to contact the manufacturer to get a test signature that has to be pushed to /system/lib/rfsa/adsp folder. One way I figured to get around this is to build the android image myself and flash it on the board. Not sure if this poses a risk (security/hack) but getserial seems to work with the image I have built.

Many thanks in advance

Sateesh

 

 

 

  • Up0
  • Down0
analci
Join Date: 10 Sep 15
Posts: 2
Posted: Wed, 2015-09-16 19:00

I am having the exact issue with SDK releases 1.2 and 2.0 on the IFC6410 board that uses APQ8064. Can somebody give an update?

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.