FAQ

Common FAQ

How to link c++ libraries statically on Android side?

If you are using Android GCC tools, you can link libstdc++ statically by adding the below lines to your android.min file:

<application_name>_LIBS += $(ANDROID_TOOLS_DIR)\platforms\android-<Android-API-LEVEL>\arch-arm\usr\lib\libstdc++.a

e.g: calculator_LIBS += $(ANDROID_TOOLS_DIR)\platforms\android-26\arch-arm\usr\lib\libstdc++.a

If you are using Android CLANG tools, you can link libc++ statically by adding the below lines to your android.min file:

<application_name>_LIBS += $(ANDROID_TOOLS_DIR)/sysroot/usr/lib/aarch64-linux-android/libc+_static.a

<application_name>_LIBS += $(ANDROID_TOOLS_DIR)/sysroot/usr/lib/aarch64-linux-android/libc+abi.a

e.g: calculator_LIBS += $(ANDROID_TOOLS_DIR)/sysroot/usr/lib/aarch64-linux-android/libc+_static.a

calculator_LIBS += $(ANDROID_TOOLS_DIR)/sysroot/usr/lib/aarch64-linux-android/libc+abi.a
How to run examples on target from Command Line Interface (CLI)?

Almost all the SDK examples have a walkthrough script to run the example on the target. This script compiles the example for the HLOS and DSP variants, optionally signs the device, pushes the built libraries to the device and finally, runs the example executable on the device. Refer to this for more information.
How to convert an older project to glue-free?

With versions earlier than 3.5, the examples contain a glue folder which has <variant>.mak and V_<variant>.min files. When a glue-based example is built for a variant, the rules mentioned in the <variant>.mak> file will be invoked to build the example and its dependencies, using libraries and includes mentioned in V_<variant>.min file. To modify the dependencies in a glue-based project, the glue folder contents needs to be updated which is not practical to do.

Glue-free projects were introduced to provide an easy way to change/add dependencies. All the SDK examples are converted to use the glue-free approach. A Glue-free project should have the following files in its root directory:
- hexagon_deps.min, hexagon.min for building the Hexagon variant,
- android_deps.min, android.min for building the Android variant,
- UbuntuARM_deps.min, UbuntuARM.min for building the UbuntuARM variant, and
- Makefile, which includes above files.
A project's dependencies and supported variants must be defined in <>_deps.min files. The dependencies are defined using the variable DEPENDENCIES and their directory location is expressed with <DEPENDENCY NAME>_DIR. Refer to any example in the SDK for more information on the build files.

Dynamic Loading

What is dynamic loading and how can I use it?

Dynamic loading enables to load and run a shared object on DSP without rebuilding the DSP image. Dynamic shared objects are analogous to Linux .so and Windows .dll files. They are implemented as ELF files and exist as files in the HLOS file system which are loaded by the DSP via an inter-processor communication mechanism. Once loaded, all symbols publicly exported by the shared object can be referenced or called. The shared objects are loaded into DSP addressable memory on-demand basis. This helps reduce DSP image size. The creation of shared objects is supported by the Hexagon Tools version 5.0.9 and newer. The document Hexagon Application Binary Interface Specification provides more information about the structure and limitations of dynamic shared objects. The documentation introducing FastRPC also discusses in more details the process of dynamic loading.

What is the file format of the dynamic shared object files?

The dynamic shared object files are ELFs that adhere to the specification described in the document Hexagon Application Binary Interface Specification which is an addendum to the System V Application Binary Interface as described by

http://www.sco.com/developers/gabi/latest/contents.html
Do dynamic shared objects support C++?

Yes. For C++ support on Android side, refer to calculator_c++_apk example. On hexagon side, refer to calculator C++ example.
How do I build/link assembly source code to generate shared object?

Shared objects should be built to be position independent and SDK build system takes care of that already. Assembly source files should be added to .ASM_SRCS in hexagon.min files. Please refer to benchmark example in compute/addon.
Where to push the executables or shared objects to the target?

On a rooted device, push binaries as follows:

HLOS Executables * LA: push to /vendor/bin * LE: push to /usr/bin

HLOS stub libraries * LA: push to /vendor/lib(64) * LE: push to /usr/lib(64)

DSP skeleton libraries * Push to default search paths

Note: The loader paths for stub and skeleton libraries are configurable using the environment variables LD_LIRBARY_PATH and [A]DSP_LIBRARY_PATH respectively.

For example, use the command below to append /vendor/lib64 to the stub libraries loader path and /vendor/lib/rfsa/dsp/sdk to the DSP libraries loader path before running the calculator executable:
```
adb shell export LD_LIBRARY_PATH=/vendor/lib64/:$LD_LIBRARY_PATH DSP_LIBRARY_PATH="/vendor/lib/rfsa/dsp/sdk\" calculator 0 3 1000
```
How to run an application on the cDSP in an unrooted device?

It is not possible to push executables/libraries in /vendor partition in an unrooted device. Hence, users can run the application from /data partition.

In a unrooted device, push the executables to /data/nativetest(64)/vendor, and HLOS Stub and DSP skeleton libraries to any location configured using the environment variables, LD_LIRBARY_PATH and [A]DSP_LIBRARY_PATH, respectively. An application running from this location will also have access to the libraries already residing in /vendor.
```
adb shell export LD_LIBRARY_PATH=/data/nativetest64/vendor:$LD_LIBRARY_PATH DSP_LIBRARY_PATH="/data/xxx/yyy\" calculator 0 3 1000
```
Note: With the introduction of treble limitations starting with Android-P, it is not possible to run an application from /data/app. In addition to the above mentioned location, the executable can also be run from the directory /data/local/tmp. An application run from any of these locations will have access to the DSP libraries in the vendor partition as well.

How to get the load address and size of the libraries loaded in the simulator?

The load address of the library is printed in the console for a simulation.

try to load calculator_q.so from file:  HIGH:0x1E6:122:search.c
....
read headers 0x0 -> d8041000 (0x1000 B):  HIGH:0x1E6:539:map_object.c
_rtld_map_object_ex: sigverify skipped for ./calculator_q.so, no function specified!:  HIGH:0x1E6:598:map_object.c
....
mapped  [d81ed000 - d8200000] (77824 Bytes):  HIGH:0x1E6:729:map_object.c

Here, the load address of the library "calculator_q.so" is 0xd81ed000, whereas the size of the library is 77824 bytes.

FastRPC

How do I know if the remote call completed successfully?

If the remote call returns zero then it indicates remote call is succussful. Any other value is a failure, refer to error codes. Also refer to Trouble shooting fastRPC issues if you see any issues.
Can I use a buffer in a remote call as both input and output.?

Yes, we can use. Refer IDL documentation
What is the significance of using ION memory?

Refer to rpcmem header file and documentation.
What memory can be passed to a FastRPC function?

Any memory can be passed. However ION allocated memory is the only memory that will be passed to the DSP directly without a copy. Stack, general heap, and static buffers will be copied.

Even though ION memory isn't copied, cache synchronization still has to be performed. This is because DSP and application processor do not share the same cache. Also, these operations are the most significant factor in RPC performance. For more details refer to system performance documents
How much stack space is used by FastRPC framework on DSP?

FastRPC framework allocates a stack of 16KB per thread on DSP by default. It can be changed using remote_session_control API mentioned in remote.h
What is the page granularity of mappings on DSP?

The FastRPC framework maps buffers at a page granularity supported by the DSP (4K, 16K, 64K, 256K, 1M). For example, if the client passes a 512K buffer, it gets mapped with two entries of 256K each, correctly aligning the received physical address.

The mapping exists only for the duration of that remote invocation. When the DSP returns from the invocation, it unmaps the pages associated with that invocation. The mapping and unmapping happen for each RPC call made.
What happens if an application is terminated in the middle of remote invocation?

The FastRPC framework keeps track of all resources used for the remote invocation and performs the necessary cleanup such as notifying the DSP processor to kill the threads servicing the remote invocation. The application is blocked from exiting until the clean up is complete so as to guarantee that the buffers passed to the DSP are not in use before the HLOS re-allocates them.
Can more than one remote invocation be made at any given point?

Yes, there can be multiple threads that can be spawned from the user space application with each making a remote invocation simultaneously. Refer to calculator multi domain example.
What cache attribute is used to map the input and output buffers?

The input and output buffers are mapped by default with write-back cache attribute (both L1 and L2 cacheable).
How to manage the clocks when making a fastrpc call?

Refer to the header file HAP_power.h and its documentation. Refer to example in /addons/compute/examples/benchmark
HAP_perf_get_pcycles() and HAP_perf_get_time_us() are returning zero when running on hexagon simulator. What should I do?

To use HAP_perf_get_pcycles() and HAP_perf_get_time_us(), your simulator test should be running on top of QuRT. All simulator tests run on top of QuRT by default unless NO_QURT_INC variable is defined to 1 in your example makefile as shown in calculator example in examples/calculator/hexagon.min.

Please refer to the SDK simulator document page to know more about standalone simulator tests and QuRT-based simulator tests.
How to log messages from DSP?

Refer to documentation on debug.
How can I display fastRPC debug messages?

There is an error message logging support for the application processor and the DSP for a FastRPC session between a client application on the application processor and a service running on the DSP. The messages from user space and kernel space on the application processor are logged in logcat and dmesg respectively. The messages from DSP are logged to either mini-DM (please refer mini- DM) or in logcat (please refer logcat).

To search FastRPC errors from application processor or dsp(adsp/cdsp/mdsp/slpi) on logcat, use following tag names: 'adsprpc' or '', e.g : adb logcat -s adsprpc.
If the serial number of a device is retrieved by running getserial on ADSP, does it sign only ADSP?

The serial number of the device is not specific to one sub-system and represents the RPC version of all the sub-systems of the device. The serial number returned by running getserial on ADSP is the same as the one returned by CDSP. If the testsig generated with this serial number is pushed to an accessible location on the device, then it is possible to run the application on all the sub-systems.
How to resolve queries about QuRT APIs?

Refer to this for more information on QuRT.