Db820c : GPS not working on linux

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.

Thanks,

Hi,

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.

Thanks,
Hiren

Hi,
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 - QC_IMAGE_VERSION_STRING=BOOT.XF.1.0-00331-M8996LZB-1
S - IMAGE_VARIANT_STRING=M8996LAB
S - OEM_IMAGE_VERSION_STRING=jenkins
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.

Thanks

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

Thanks @ndec. I will try to investigate it.

I’m noticing that the pds patch for gpsd is over a year old, and hasn’t made it upstream yet. What’s the hold up? I’ve been working with gpsd upstream for just a few days now, and I’m finding them to be extremely responsive. They’ve already merged several patches that I’ve provided to them for supporting Android.

I think part of the reason is that the code does not work as expected on 820C.

I have been working with linux based system, and the file system is from
https://snapshots.linaro.org/96boards/dragonboard820c/linaro/debian/228/
And I do have installed:
qrtr-apps gnss-gpsd qdsp-config

Being new to GPS framework,need some help on how to fix:
$ systemctl start qdsp-start.service
Failed to start qdsp-start.service: Unit qdsp-start.service not found.

CGPS & GPSMON didnt print NMEA strings…
Is there anything I’m doing wrong?? Any reference/reading suggestions?? Thanks…

I’m afraid the situation hasn’t changed since Apr 1:

In other words the components needed for GPS have been enabled in the Debian snapshot images but are known not to be working.

Thanks @danielt, will continue to debug from my perspective…
Please do update if you find them(cgps & gpsmon) working.

Any update on GPS in DB820c Debian?
Can someone give pointers to debug this further?

@ndec
@Loic

Thanks,
Arun

Hello Team,

Any update on GPS in DB820c?

@Loic
@ndec

Thanks,
Arun

Hi,
Any update on GPS support on Dragonboard 820c?
Thanks,
Ashik

AFAIK, there is no plan for now.

I have tried to rebuild gpsd & after having replaced all new set of binaries (gpsd,cgps,gpsmon the systemd service & socket file also lib*.so files) to respective locations.
I found that in gpsd.service:

After=chronyd.service

But there is no such service:

systemctl status chronyd
Unit chronyd.service could not be found.

Is it the error causing gpsd service not to function properly??
I even tried reloading service with:
After=network-manager.service

This loaded /usr/bin/gpsd , still no luck with NMEA strings…
Any suggestions ?? Thanks in advance…

Hi all,

I have obtained NMEA strings working :smiley: with the updates in gpsd…
Its taking 10-20min to get proper location fix for first time. Until then it prints only PRN’s (noises).
The concerns I have are regarding effectiveness…

  1. Does gpsd have any methods to improve accuracy like in Android ?
  2. Are there any other daemons to test NMEA strings having GPS location ? (tried gpsmon, xgps & cgps all of these work on gpsd & take longer time to get location fix)…

There is nothing in Android that will improve the accuracy of GPS data.
Speed, perhaps, since most GPS HALs in Android will implement AGPS to reduce the time it takes to get a first fix, but the accuracy itself will be unaffected.

Without some kind of assistance data, 10-20 minutes for first fix seems like it could be perfectly reasonable, especially if the conditions are less than ideal, such as using a passive PCB antenna, or trying to use it from inside a building.

The last time I looked deeply at gpsd (several months ago when I wrote its Android HAL, which you will now find in gpsd’s android/ path), it didn’t implement any form of AGPS.

Hi, @ymj

I am also trying GPS with Debian (http://snapshots.linaro.org/96boards/dragonboard820c/linaro/debian/384/) release but have no success. I followed below steps:

sudo apt-get update
sudo apt-get install gnss-gpsd
sudo apt-get install qdsp-start

systemctl start gpsd
gpsdctl add /dev/ttyGPS0
OR
gpsdctl add pds://any

gpsmon

gpsmon output:

tcp://localhost:2947          JSON slave driver>
(82) {"class":"VERSION","release":"3.17","rev":"3.17","proto_major":3,"proto_min
or":12}
(172) {"class":"DEVICES","devices":[{"class":"DEVICE","path":"/dev/ttyGPS0","act
ivated":"2019-11-11T11:12:15.398Z","native":0,"bps":9600,"parity":"N","stopbits"
:1,"cycle":1.00}]}
(122) {"class":"WATCH","enable":true,"json":false,"nmea":false,"raw":2,"scaled":
false,"timing":false,"split24":false,"pps":true} 

Below is the output of Required service status:

root@linaro-alip:~# systemctl status qdsp-start
● qdsp-start.service - Start the Hexagon QDSP
Loaded: loaded (/lib/systemd/system/qdsp-start.service; enabled; vendor prese
Active: inactive (dead) since Mon 2019-11-11 10:45:35 UTC; 23min ago
Process: 2137 ExecStart=/usr/sbin/qdsp-start (code=exited, status=0/SUCCESS)
Main PID: 2137 (code=exited, status=0/SUCCESS)

root@linaro-alip:~# systemctl status gpsd
● gpsd.service - GPS (Global Positioning System) Daemon
Loaded: loaded (/lib/systemd/system/gpsd.service; disabled; vendor preset: en
Active: active (running) since Mon 2019-11-11 11:11:15 UTC; 2s ago
Process: 2712 ExecStart=/usr/sbin/gpsd $GPSD_OPTIONS $DEVICES (code=exited, st
Main PID: 2713 (gpsd)
Tasks: 1 (limit: 4445)
Memory: 1000.0K
CGroup: /system.slice/gpsd.service
└─2713 /usr/sbin/gpsd
root@linaro-alip:~#

root@linaro-alip:~# systemctl status gpsd.socket
● gpsd.socket - GPS (Global Positioning System) Daemon Sockets
Loaded: loaded (/lib/systemd/system/gpsd.socket; enabled; vendor preset: enab
Active: active (listening) since Mon 2019-11-11 10:45:34 UTC; 25min ago
Listen: /var/run/gpsd.sock (Stream)
[::1]:2947 (Stream)
127.0.0.1:2947 (Stream)
CGroup: /system.slice/gpsd.socket
root@linaro-alip:~#

What am i missing something here? can you please tell me what steps you followed to start GPS

Thanks,
Hiren

The NMEA strings where obtained after a lot of trials. According to me, major change I had to do was:

  1. To clone in latest gpsd sources which has pds support. Replace them with existing gpsd & gpsdctl.
  2. To test in proper environment(clear space) which helps by a large-factor.

I believe that guys in this forum had done a great job in helping me throughout. I have no idea why qpsd-start service is used,so forum members should be right people to solve the queries.Thanks…