Snapdragon build fails at runtime (related to time functions)

[karliss]

Describe the bug
Snapdragon build fails at runtime due to dynamic linking problems.

To Reproduce

1. make eagle_default upload
2. start px4
3. observe large amount of errors

Log Files and Screenshots

[08500/03]  08:15.385  HAP:4158:undefined PLT symbol px4_usleep (96) /libpx4.so  0303  symbol.c
[08500/03]  08:15.385  HAP:4158:undefined PLT symbol px4_sleep (822) /libpx4.so  0303  symbol.c
[08500/03]  08:15.385  HAP:4158:undefined PLT symbol px4_clock_settime (220) /libpx4.so  0303  symbol.c
[08500/03]  08:15.385  HAP:4158:undefined PLT symbol px4_pthread_cond_timedwait (354) /libpx4.so  0303  symbol.c

Additional context
I am guessing that this might be related to 547dd85 and following commits. @julianoes

[karliss]

d1b44e5 before all the clock/sleep change works.

[dagar]

I'm wondering if we could also produce a fake qurt executable to catch these linking issues at build time. This is incredibly annoying.

[dagar]

Looks like yes - https://github.com/PX4/Firmware/blob/master/platforms/qurt/CMakeLists.txt#L24-L39

[dagar]

@karliss care to help with a qurt test target? #11111

[karliss]

@dagar will try to take a look once I get back to work.

[julianoes]

Thanks for the issue @karliss. Looks like some #define for the DSP are missing then.

[julianoes]

I can't reproduce the linking issue but it also doesn't actually run correctly (uorb top is empty).

I run:

./px4 -s mainapp.config rootfs/

The appsproc (Linux) side output is:

INFO  [px4] Creating symlink rootfs/ -> /home/linaro/etc
sh: 1: cannot create /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor: Directory nonexistent

______  __   __    ___ 
| ___ \ \ \ / /   /   |
| |_/ /  \ V /   / /| |
|  __/   /   \  / /_| |
| |     / /^\ \ \___  |
\_|     \/   \/     |_/

px4 starting.

INFO  [px4] Calling startup script: /bin/sh mainapp.config 0
INFO  [logger] logger started (mode=all)
INFO  [dataman] Unknown restart, data manager file '/home/linaro/dataman' size is 11405132 bytes
INFO  [mavlink] mode: Normal, data rate: 1000000 B/s on udp port 14556 remote port 14550
INFO  [px4] Startup script returned successfully
pxh> WARN  [mavlink] no broadcasting address found

The DSP (Qurt) side is:

  15412756: HAP:63:adsp memory mapped (shmem_qurt.cpp:148)
  15412767: HAP:60:In dspal_entry (main.cpp:196)
  15412768: HAP:60:adsp memory mapped (shmem_qurt.cpp:148)
  15413593: HAP:50:TEST px4muorb_topic_advertised of [telemetry_status] on remote side... (px4muorb.cpp:160)

[julianoes]

Ok, I then started all commands from px4.config in pxh> using qshell <command> and at that point everything seemed running:

TOPIC NAME                       INST #SUB #MSG #LOST #QSIZE
actuator_outputs                    0    2  248   248 1
vehicle_rates_setpoint              0    2  218   213 1
vehicle_attitude_setpoint           0    2  218   213 1
ekf2_timestamps                     0    1  248     0 1
sensor_bias                         0    1  123    74 1
estimator_status                    0    2  123     0 1
ekf_gps_drift                       0    1    4     0 1
ekf2_innovations                    0    1  123     0 1
actuator_controls_0                 0    1  248     0 1
rate_ctrl_status                    0    1  248     0 1
sensor_preflight                    0    1  248     0 1
vehicle_magnetometer                0    2  149    99 1
sensor_combined                     0    2  248   199 1
vehicle_attitude                    0    3  248   199 1
vehicle_gps_position                0    3    4     3 1
vehicle_local_position              0    3  123   107 1
vehicle_air_data                    0    3   49     0 1

[karliss]

How can it work if only definition of px4_sleep is in drv_hrt.c under #if defined(ENABLE_LOCKSTEP_SCHEDULER) but choice of macro vs function uses defined(ENABLE_LOCKSTEP_SCHEDULER) || defined(__PX4_QURT)? Maybe you had ENABLE_LOCKSTEP_SCHEDULER enabled or dirty checkout?

[julianoes]

Ha, sorry. I should merge and not only fetch. Let me try again.

[julianoes]

Ok, now I can reproduce it!

[julianoes]

Should be fixed with #11115.

[karliss]

After #11115 works.