Db820c : GPS not working on linux



I am using latest OpenEmbedded Release on DragonBoard820c(p4).
Release: http://snapshots.linaro.org/96boards/dragonboard820c/linaro/openembedded/rocko/latest/rpb/1

root@dragonboard-820c:~# uname -a
Linux dragonboard-820c 4.11.12+linaro #1 SMP PREEMPT Fri Apr 6 14:43:11 IST 2018 aarch64 aarch64 aarch64 GNU/Linux

Issue : We have been trying to bring GPS up on Open Embedded but some how we are not able to capture anything in gpsmon.

We understood to enabled GPS, we will need qmi-gps-proxy app, gps_proxy driver, qrtr apps and qrtr driver enabled so we have done below changes:

  • Added user space qmi-gps-proxy apps
  • Added “qrtr-apps gnss-gpsd qdsp-config”
  • Added gps_proxy driver in kernel

Below is the status of QRTR service, which stats that QRTR is running perfectly fine:

[[0;1;32m��●[[0m qrtr.service - QRTR service
Loaded: loaded (/lib/systemd/system/qrtr.service; enabled; vendor preset: ena
Active: [[0;1;32mactive (exited)[[0m since Thu 2018-03-22 06:15:32 UTC; 1h 3m
in ago
Main PID: 2747 (code=exited, status=0/SUCCESS)
Tasks: 1 (limit: 4915)
Memory: 1.1M
CPU: 17ms
CGroup: /system.slice/qrtr.service
��└��─2748 /usr/bin/qrtr-ns

Mar 22 06:15:32 dragonboard-820c systemd[1]: Starting QRTR service…
Mar 22 06:15:32 dragonboard-820c systemd[1]: Started QRTR service.

We have followed below steps and we are able to execute all the command successfully but we are not able to capture anything in gpsmon

$ systemctl start gpsd.socket
$ systemctl start gpsd
$ systemctl start gnss-gpsd
$ gpsdctl add /dev/ttyGPS0
$ gpsmon

gpsmon output:

tcp://localhost:2947 JSON slave driver>
(82) {“class”:“VERSION”,“release”:“3.16”,“rev”:“3.16”,“proto_major”:3,“proto_min
(111) {“class”:“DEVICES”,“devices”:[{“class”:“DEVICE”,“path”:"/dev/ttyGPS0",“act
(122) {“class”:“WATCH”,“enable”:true,“json”:false,“nmea”:false,“raw”:2,“scaled”:

Please let us know if we are missing anything



we haven’t enabled GPS on 820c yet. So this is pretty much expected that it won’t work. We have done big changes in the s/w stack for GPS which we are going to release for 410c soon. then we will need to plan GPS for 820c…


Thank you for your response !

Seems that for 410c GPS was enabled in open embedded 17.09 but it has been disabled in open embedded 18.01, any particular reason ? Also please let us know if you have any idea about expected date of GPS enabled release for either 410c or 820c.



the GPS software stack has been re-implemented, and will be released very soon. Instead of using a custom kernel driver and custom user space daemon, as it was before, the GPS stack will now rely on a gpsd driver. the code is right now in a working state, and we are about to start discussing the driver with upstream gpsd project. if that works out well, that should enable GPS with vanilla upstream kernel and gpsd, without any hack or custom s/w.

if anyone if willing to test the current state of what we have , we can provide pointers/recipes to integrate these work in progress changes…


Thank you !

We would like to test the current state, please provide us the pointers.



ok, right now it is being tested with OpenEmbedded, but it’s straight forward to test with any linux distro.

For OE, we have the following patch https://hastebin.com/ohesubezuk.http. It basically updates qrtr, qmic and rmtfs project with their latest version.

Then you will need the top level commit in this gpsd tree: https://github.com/andersson/gpsd/commits/master


Thank a lot!

Then you will need the top level commit in this gpsd tree: https://github.com/andersson/gpsd/commits/master2

I have one query here, for gpsd open-embedded is using gpsd-3.16.tar.gz downloaded from http://download.savannah.gnu.org/releases/gpsd/ and applying few patches on top of it. Do you mean we need to apply last commit from gpsd tree: https://github.com/andersson/gpsd/commits/master on top of gpsd-3.16.tar.gz source or scrap the gpsd-3.16.tar.gz method and update recipe of gpsd such that it download gpsd source from https://github.com/andersson/gpsd/commits/master ?

Also it would be great if you can share the commands to enable gps with updated gps s/w stack!




I have applied the patch that you have suggested and updated “meta-oe/recipes-navigation/gpsd/gpsd_3.16.bb” to take the top level commit changes of gpsd tree: https://github.com/andersson/gpsd/commits/master

But now I am getting below compilation errors.

Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 4 LDFLAGS=-Wl,-O1 -Wl,–hash-style=gnu -Wl,–as-needed -L/mnt/workspace/db410c/openEmbedded18.01/build-rpb/tmp-rpb-glibc/work/aarch64-linaro-linux/qmi-gps-proxy/0.0+0+df3b976-6-r0/recipe-sysroot/usr/lib64 -lqrtr
| aarch64-linaro-linux-gcc --sysroot=/mnt/workspace/db410c/openEmbedded18.01/build-rpb/tmp-rpb-glibc/work/aarch64-linaro-linux/qmi-gps-proxy/0.0+0+df3b976-6-r0/recipe-sysroot -Wall -g -I…/qrtr/lib -c -o gps_proxy.o gps_proxy.c
| gps_proxy.c:70:8: error: redefinition of ‘struct sockaddr_qrtr’
| struct sockaddr_qrtr {
| ^~~~~~~~~~~~~
| In file included from /mnt/workspace/db410c/openEmbedded18.01/build-rpb/tmp-rpb-glibc/work/aarch64-linaro-linux/qmi-gps-proxy/0.0+0+df3b976-6-r0/recipe-sysroot/usr/include/libqrtr.h:4:0,
| from gps_proxy.c:38:
| /mnt/workspace/db410c/openEmbedded18.01/build-rpb/tmp-rpb-glibc/work/aarch64-linaro-linux/qmi-gps-proxy/0.0+0+df3b976-6-r0/recipe-sysroot/usr/include/linux/qrtr.h:7:8: note: originally defined here
| struct sockaddr_qrtr {
| ^~~~~~~~~~~~~
| gps_proxy.c: In function ‘main’:
| gps_proxy.c:385:8: warning: implicit declaration of function ‘qrtr_lookup’; did you mean ‘qrtr_new_lookup’? [-Wimplicit-function-declaration]
| ret = qrtr_lookup(gps_fd, QMI_LOC_SERVICE, QMI_LOC_VERSION,
| ^~~~~~~~~~~
| qrtr_new_lookup
| make: *** [gps_proxy.o] Error 1
| ERROR: oe_runmake failed
| WARNING: /mnt/workspace/db410c/openEmbedded18.01/build-rpb/tmp-rpb-glibc/work/aarch64-linaro-linux/qmi-gps-proxy/0.0+0+df3b976-6-r0/temp/run.do_compile.14363:1 exit 1 from ‘exit 1’
| ERROR: Function failed: do_compile (log file is located at /mnt/workspace/db410c/openEmbedded18.01/build-rpb/tmp-rpb-glibc/work/aarch64-linaro-linux/qmi-gps-proxy/0.0+0+df3b976-6-r0/temp/log.do_compile.14363)

After the gps sw stack changes, do we really need to build qmi-gps-proxy now ?




sorry about the delay… but i have good news. the ‘new’ gps stack is ready now, and integrated into our OE builds. here is what was done:

  • this is based on our ‘rocko’ manifest branch
  • there is a GPSd patch to add a driver for Qualcomm GPS in GPSd. This driver will be upstream, hopefully soon, in the mean time, we have a patch in meta-qcom for gpsd. Since we didn’t want to backport our patch to 3.16, we have brough 3.17 into our builds (in meta-backports)
  • qrtr and rmtfs have been upgraded to their latest version
  • a few kernel patches have been added, including a patch to make sure the DSP will be started (the GPS firmware is running on the DSP)

All the changes are available in the layers, so doing a repo sync and rebuild for DB410c should give you a working GPS.

On boot, you can check with “qrtr-lookup” that the Location/PDS service is available. You should see:

16 2 0 0 14 Location service (~ PDS v2)

Note that it might 1 minute for the DSP to start properly.

and then you can register the Qualcomm GPS to GPSd, using:

/usr/sbin/gpsdctl add pds://any

from there, you can use any GPSd client, such as gpsmon.

We expect the very same software stack to work on DB820c. However we have an issue when starting the DSP on 820c, that we need to fix first.



Thank you @ndec for your reply and sorry for being late !

Any update on this ?


not yet. for a few reasons (including travelling) this was put on hold for a bit… i don’t expect much progress this week , but hopefully next week.



is there already a planned release date for the new version with GPS enabled ?
thanks in advace for the information,



there is no date set yet, it has been postponed. the release is tied to board availability , to some extends. until the board is available and can be purchased, there is no incentive to make full releases.

now, the question is about GPS enablement, which is still not done in the ‘daily/snapshots’ builds available on linaro.org. We don’t have a good estimate for that neither. The software stack with GPS was tested, but the GPS wouldn’t return any valid data. This needs to be debugged further.


Any update on GPS would be helpful.

Does that mean all patches already exists in DB820c Debian releases? or do we need to build packages on OE and install separately?

I guess we need to follow similar steps mentioned in section “Using the onboard GPS” at https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/17.09/ and debug this further on DB820c. Correct?



I don’t understand why you are mentioning both Debian and OE. anyways, all patches are in our releases, both for debian and OE. On the user space there are a few tools needed to bring up the remote services (qrtr, rmtfs) and 1 patch in GPSd. But our builds have everything.


Sorry for the confusion.
Understand that everything needed for GPS is available in 820 Debian builds. Just need to install relevant packages and debug it to make the GPS working.




I am trying to test GPS with OE release from https://snapshots.linaro.org/96boards/dragonboard820c/linaro/openembedded/rocko/212/rpb/ in DB820c board, but i am not able to start GPS. Can you please provide steps to start and test GPS or i need to add/change something to enable GPS.

I am trying to start DSP and gnss services, but it seems this services is not present.

$ systemctl start qdsp-start.service
Failed to start qdsp-start.service: Unit qdsp-start.service not found.

$ systemctl start gnss-gpsd
Failed to start gnss-gpsd.service: Unit gnss-gpsd.service not found.



I am trying to make the GPS working on 820 Debian build. I tried the same steps as mentioned in " Using the onboard GPS" in https://releases.linaro.org/96boards/dragonboard410c/linaro/debian/19.01/. But there was no response from modem. Later I understood that the modem DSP firmware is not loaded and modem DSP is not running. So, I copied mba.mbn and modem.* firmware from Android to /lib/firmware and enabled the the remoteproc@2080000 node in device tree.

On boot up i can see below logs and system resets after some time.

[ 13.521921] remoteproc remoteproc0: 2080000.remoteproc is available
[ 13.543867] remoteproc remoteproc0: powering up 2080000.remoteproc
[ 13.552088] remoteproc remoteproc0: Booting fw image mba.mbn, size 213888

[ 13.661032] qcom-q6v5-pil 2080000.remoteproc: MBA booted, loading mpss

[ 54.204859] qcom-q6v5-pil 2080000.remoteproc: fatal error without message
[ 54.204948] remoteproc remoteproc0: crash detected in 2080000.remoteproc: type fatal error
[ 54.210898] remoteproc remoteproc0: handling crash #1 in 2080000.remoteproc
[ 54.218956] remoteproc remoteproc0: recovering 2080000.remoteproc
[ 56.004939] qcom-q6v5-pil 2080000.remoteproc: watchdog without message
[ 56.005067] remoteproc remoteproc0: crash detected in 2080000.remoteproc: type watchdog
[ 59.361137] qcom-q6v5-pil 2080000.remoteproc: failed receiving QMI response
[ 64.481126] qcom-q6v5-pil 2080000.remoteproc: timed out on wait
[ 64.493032] remoteproc remoteproc0: stopped remote processor 2080000.remoteproc
[ 64.553106] qcom-q6v5-pil 2080000.remoteproc: MBA booted, loading mpss

Format: Log Type - Time(microsec) - Message - Optional Info
Log Type: B - Since Boot(Power On Reset), D - Delta, S - Statistic
S - Boot Interface: UFS
S - Secure Boot: Off
S - Boot Config @ 0x00076044 = 0x000001c9
S - JTAG ID @ 0x000760f4 = 0x4003e0e1
S - OEM ID @ 0x000760f8 = 0x00000000
S - Serial Number @ 0x00074138 = 0x28b7d3b4
S - OEM Config Row 0 @ 0x00074188 = 0x0000000000000000
S - OEM Config Row 1 @ 0x00074190 = 0x0000000000000000
S - Feature Config Row 0 @ 0x000741a0 = 0x0050000010000100
S - Feature Config Row 1 @ 0x000741a8 = 0x00fff00001ffffff
S - Core 0 Frequency, 1228 MHz
B - 0 - PBL, Start

Please let me know if any pointer to debug this further.



Any update on GPS support on Dragonboard 820c?


unfortunately, no. all the drivers and user space are “in place”, but it’s not working, and we haven’t investigated further (and are not planning to investigate in the very short term).