18.01 OE gps / hexagon not working?

Products Support DragonBoard410c
#1

When trying the latest (18.01) OE image, I noticed the gps/hexagon not working. Could this be something wrong with my setup, or image related?

When running systemctl start qdsp-start this is in the logs:

Jan 30 08:58:07 dragonboard-410c systemd[1]: Starting QRTR service...
Jan 30 08:58:07 dragonboard-410c systemd[1]: Started QRTR service.
Jan 30 08:58:07 dragonboard-410c qrtr-ns[3214]: qrtr-ns: sock(AF_QIPCRTR): Address family not supported by protocol
Jan 30 08:58:07 dragonboard-410c qrtr-ns[3214]: qrtr-ns: unable to create control socket
Jan 30 08:58:07 dragonboard-410c systemd[1]: Starting RMTFS setup...
Jan 30 08:58:07 dragonboard-410c systemd[1]: qrtr.service: Main process exited, code=exited, status=1/FAILURE
Jan 30 08:58:07 dragonboard-410c systemd[1]: qrtr.service: Unit entered failed state.
Jan 30 08:58:07 dragonboard-410c systemd[1]: qrtr.service: Failed with result 'exit-code'.
Jan 30 08:58:07 dragonboard-410c systemd[1]: Started RMTFS setup.
Jan 30 08:58:07 dragonboard-410c rmtfs[3220]: E|qrtr: socket(AF_QIPCRTR): Address family not supported by protocol
Jan 30 08:58:07 dragonboard-410c rmtfs[3220]: failed to create qrtr socket
Jan 30 08:58:07 dragonboard-410c systemd[1]: Starting Start the Hexagon QDSP...
Jan 30 08:58:07 dragonboard-410c systemd[1]: Started Start the Hexagon QDSP.

some more info:
root@dragonboard-410c:~# uname -a Linux dragonboard-410c 4.14.15+linaro #1 SMP PREEMPT Thu Feb 8 19:23:14 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

When building the image myself, I see the same issue. The logs makes sense as in kernel .config there is:
# CONFIG_QRTR is not set

Best, Thors.

#2

Sorry, just reading in release notes now that is was disabled. Any particular reason?

I created a patch to re-enable it again, but hexagon seems to stop every time after 40 secs:

Jan 01 00:06:21 db410c kernel: remoteproc remoteproc0: remote processor 4080000.hexagon is now up Jan 01 00:06:21 db410c kernel[2756]: [ 383.616096] remoteproc remoteproc0: remote processor 4080000.hexagon is now up Jan 01 00:07:01 db410c kernel: qcom-q6v5-pil 4080000.hexagon: fatal error received: dog.c:1498:Watchdog detects stalled initialization

#3

The “initialization watchdog” will crash the Hexagon (modem) firmware if it’s OS isn’t running within 40 seconds. In our case this is typically caused by a failure to initialize the internal file system, which depends on QRTR and rmtfs to access the block storage.

So you need to run:
qrtr-cfg 1
qrtr-ns
rmtfs &

And you need to have some files for rmtfs to serve, the following commands should do the trick if you’re missing these files:
truncate -s 1536K /boot/modem_fs1
truncate -s 1536K /boot/modem_fs2
truncate -s 1K /boot/modem_fsc
truncate -s 1536K /boot/modem_fsg

PS, once you have started rmtfs you should be able to see a entry in the output of “qrtr-lookup” indicating that the filesystem service is registered. And you can pass -v to rmtfs to get it to inform you about requests from the remote and their outcome.

Regards,
Bjorn

#4

Thank you. After some manual stopping and starting it worked once, but I can’t reproduce yet. All the commands and files are also present in the regular init files/image (qrtr/rmtfs services). Maybe something with the order or something, I’ll have to look into later.

For reference, these changes against the 18.01 OE build were used:
patch: enable_gps.patch - Pastebin.com
kernel conf fragment: kernel conf fragment gps - Pastebin.com

#5

Hi Thors,

I managed to reproduce this issue and found a race condition causing this. A fix has been merged into the LT release branch and upstream kernel. So this should be much improved in the upcoming release.

Regards,
Bjorn

#6

Hi Bjorn,

Silly question, I am having the same issues with OE. How can I check your patches are in my kernel, or where do I find those, so that I can fix things…

Thanks and Regards,

Matthias