Forums - Development with the Hexagon SDK on commercial devices

11 posts / 0 new
Last post
Development with the Hexagon SDK on commercial devices
pig20
Join Date: 24 Oct 13
Location: Cambridge
Posts: 1
Posted: Wed, 2013-11-13 11:03

The Hexagon SDK allows custom programmability for the DSP coprocessor on the Snapdragon 800 platform. If I want to develop and test applications that use the DSP coprocessor, can I do so directly on the emerging smartphones featuring the Snapdragon 800 SoC such as Google Nexus 5? Or do I need to specifically use the MDP for development and the smartphones for deployment? If I can use directly the commercial devices for both development and deployment, are there any restrictions compared to the MDP case?

Thanks.

  • Up0
  • Down0
abhikrant sharma
Join Date: 27 Aug 14
Posts: 8
Posted: Tue, 2014-09-30 22:02

HI,

To develop applications and features on deployment devices, you need to enable signing process which is specific to every OEM. Hence MDP is the suggested platform for development. You can check 8074 dragonboard which is fully compliant with Hexagon SDK and provides smooth development experience.

Thanks.

  • Up0
  • Down0
dkartis
Join Date: 18 Nov 13
Posts: 8
Posted: Fri, 2015-04-24 17:50

It seems like running elfsigner.py is not enough. I've tried to do this for a Galaxy S5 and the the DSP application will fail as soon as it gets to the portion of code that's processed on the aDSP. Is the signing process to simply create a new testsig-0x<serial number>.so and put it in the /system/lib/rfsa/adsp folder? I've done this and it works on the dragonBoard but not on the Galaxy

  • Up0
  • Down0
dkartis
Join Date: 18 Nov 13
Posts: 8
Posted: Sun, 2015-04-26 14:24

After development is done on the MDP, can an app be created to be deployed on a production device? How would you sign an app for a specific OEM? 

  • Up0
  • Down0
abhikrant sharma
Join Date: 27 Aug 14
Posts: 8
Posted: Mon, 2015-04-27 11:32

To run a shared library on production device, the library must be signed by respective OEM. As your library is not signed by Samsung, hence it fails to load on Samsung phone whereas it works fine on dragonboard(which is a development device).

  • Up0
  • Down0
abhikrant sharma
Join Date: 27 Aug 14
Posts: 8
Posted: Mon, 2015-04-27 11:52

You need to contact respective OEM to sign the shared library and plug it into their phone.

Thanks,

Abhikrant

  • Up0
  • Down0
dkartis
Join Date: 18 Nov 13
Posts: 8
Posted: Mon, 2015-04-27 12:33

Thanks for the response, you've been a huge help!

  • Up0
  • Down0
Edith
Join Date: 16 Mar 16
Posts: 11
Posted: Wed, 2016-03-16 07:34

Hi,

As it has been some time since last post in this thread I am wondering if things have changed.

Are there any plans to "enable" aDSP support on commercial devices for developing purposes or maybe there were some solutions popped up already?

Br,

Edyta

  • Up0
  • Down0
abhikrant sharma
Join Date: 27 Aug 14
Posts: 8
Posted: Wed, 2016-03-16 22:15

HI,

This limitation is not from Qualcomm but from the phone manufacturer. Any shared object that's loaded on DSP of a commercial phone needs to be signed by respective OEM. So, you need to contact the OEM for getting your shared object signed to run it on DSP.

Thanks

  • Up0
  • Down0
farleylai
Join Date: 4 Dec 14
Posts: 13
Posted: Sat, 2016-11-12 20:12

How about development devcies such as Nexus 6 with custom built AOSP?
Is the signing still necessary or is there a workaround?

I see /dev/adsproc-smd exists but no adsprpcd is running.
Any ideas or clarifications?

  • Up0
  • Down0
Daren Zou
Join Date: 8 Nov 12
Posts: 2
Posted: Fri, 2017-02-10 17:51

Just as farleylai said, will that be possible to run the code on a Nexus/Pixel with custom built AOSP? Can we change the way the DSP code is signed and migrate our own code to run on the DSP? 

I am bring up this topic again course deploying and running my code on actual devices is vital to our development.

Hope somebody can share the experience on this topic.

  • 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.