debug.h is a NuttX-specific, non-POSIX header. Placing it in the
top-level include/ directory creates naming conflicts with external
projects that define their own debug.h.
This commit moves the canonical header to include/nuttx/debug.h,
following the NuttX convention for non-POSIX/non-standard headers,
and updates all in-tree references.
A backward-compatibility shim is left at include/debug.h that
emits a deprecation #warning and re-includes <nuttx/debug.h>,
allowing out-of-tree code to continue building while migrating.
Signed-off-by: Piyush Patle <piyushpatle228@gmail.com>
fist free when rpmsg_port_unregister at rpmsg spi thread
<free+12>
<rpmsg_router_hub_ept_release+6>
<rpmsg_ept_decref+28>
<rpmsg_unregister_endpoint+120>
<rpmsg_destroy_ept+40>
<rpmsg_router_hub_unbind+22>
<rpmsg_device_destory+172>
<rpmsg_port_unregister+26>
this thread will free r:droid and r:audio at last;
But in this process,
rpmsg_destroy_ept "r:droid" will send NS_destroy to audio;
audio will response NS_destroy to ap; if r:droid has not been
removed from the ept list yet, the rptun_audio thread on ap will
occur as follows:
3 0x103016fa in kasan_check_report
4 0x103018b6 in __asan_store4_noabort
5 0x106ca352 in metal_list_del
6 in rpmsg_unregister_endpoint
7 0x106ca77a in rpmsg_destroy_ept
8 0x102db232 in rpmsg_router_hub_unbind
9 0x106cabb2 in rpmsg_virtio_ns_callback
10 0x106cad5c in rpmsg_virtio_rx_callback
11 0x106cc190 in virtqueue_notification
12 0x106ca064 in rproc_virtio_notified
13 0x106c9ad0 in remoteproc_get_notification
14 0x102dd4ba in rptun_worker at rptun/rptun.c:334
15 rptun_worker (arg=<optimized out>) at rptun/rptun.c:328
16 0x102dd974 in rptun_thread rptun/rptun.c:353
17 0x102cd558 in nxtask_start () at task/task_start.c:1
this will lead to r:audio be freed again.
Signed-off-by: yintao <yintao@xiaomi.com>
Use rpmsg_send_offchannel_raw to fix stuck issue avoid getting stuck
when remote destroy ept.
When send messages from ap to android in Rptun thread, Android may
have sent NS_DESTROY through rpmsg_port and changed ept->dst to
RPMSG_ADDR_ANY in rpmsg_port_ns_callback; So rptun thread may be
stuck at this time because rpmsg_send detected dst_ept's dst_addr
is RPMSG_ADDR_ANY.
rpmsg_virtio_thread(rptun audio):
rpmsg_virtio_rx_callback -> rpmsg_router_cb -> rpmsg_send(dst_ept)
send to android
rpmsg_port_thread (android send NS_DESTROY):
rpmsg_port_ns_callback -> dst_ept->dest_addr = RPMSG_ADDR_ANY
Signed-off-by: yintao <yintao@xiaomi.com>
Already copy the rpmsg_internal.h from openamp to the nuttx/include,
so do not need add the include patch for .c files.
Signed-off-by: yangao1 <yangao1@xiaomi.com>
Signed-off-by: wangshaoxin <wangshaoxin@xiaomi.com>
Now the rpmsg router transport also support get the signals, and
this signals value is modified by other physical rpmsg transport
(port, virtio) other routed by the rpmsg router.
Signed-off-by: yintao <yintao@xiaomi.com>
0x106b9ad2 in metal_list_del (node=<optimized out>) at /home/yintao/O61/nuttx/include/metal/list.h:85
rpmsg_unregister_endpoint (ept=0x1857ba30) at open-amp/lib/rpmsg/rpmsg.c:296
rpmsg_destroy_ept (ept=0x1857ba30) at open-amp/lib/rpmsg/rpmsg.c:389
0x102b871a in rpmsg_router_hub_unbind (ept=0x1857b330) at rpmsg/rpmsg_router_hub.c:139
0x102b7fec in rpmsg_device_destory (rpmsg=rpmsg@entry=0x1859e4e8) at rpmsg/rpmsg.c:486
0x102b9928 in rpmsg_port_unregister (port=port@entry=0x1859e4e8) at rpmsg/rpmsg_port.c:749
0x102b9bca in rpmsg_port_spi_process_packet (rxhdr=0x185ba718, rpspi=<optimized out>) at rpmsg/rpmsg_port_spi.c:408
rpmsg_port_spi_thread (argc=<optimized out>, argv=<optimized out>) at rpmsg/rpmsg_port_spi.c:452
0x102aa96e in nxtask_start () at task/task_start.c:111
Signed-off-by: yintao <yintao@xiaomi.com>
Most tools used for compliance and SBOM generation use SPDX identifiers
This change brings us a step closer to an easy SBOM generation.
Signed-off-by: Alin Jerpelea <alin.jerpelea@sony.com>
Rpmsg Router is new rpmsg transport layer, it can router the rpmsg
messages to a cpu that not directly connected with local cpu by Rpmsg,
For the rpmsg services, it is as if there is a real Rpmsg Channel between
the local cpu and the remote cpu.
For examples, there are three cpus: ap, cp and audio.
ap and cp, ap and audio has share memory and be connected by Rpmsg VirtIO,
so ap and cp, ap and audio can communicate with each other by Rpmsg, but
cp can not communicate with audio direclty.
[cp] <-- rpmsg virtio --> [ap] <-- rpmsg virtio --> [audio]
With rpmsg router, the cp can communicate with audip by Rpmsg dereclty because
the router in ap will forward the rpmsg message from cp/audio to audio/cp, like
this:
+<----- rpmsg router --> hub <-- rpmsg router ------>+
| | |
[cp] <-- rpmsg virtio --> [ap] <-- rpmsg virtio --> [audio]
Signed-off-by: yintao <yintao@xiaomi.com>
