CV-Bowen opened a new pull request, #21139:
URL: https://github.com/apache/nuttx/pull/21139
## Summary
Two rptun fixes:
- `rptun_send_command()` dereferenced the command area of the resource
table without checking that the table is set. `rptun_initialize()`
registers the panic notifier and adds the instance to the global list
even when the remote is not auto-started, but `rproc.rsc_table` is
only set in `rptun_do_start()`. A panic, or an `RPTUNIOC_RESET` on a
transport without its own reset op, in that window dereferences
`RPTUN_RSC2CMD(NULL)`. Return early while the table is not set.
- The rptun_ivshmem polling watchdog re-armed itself with `wd_start()`
from its own callback, so every period started when the callback ran
and the callback latency accumulated as drift. Use `wd_start_next()`,
which re-arms relative to the last expiration.
The first commit only fixes existing nxstyle errors in
`rptun_ivshmem.c`.
## Impact
None beyond the two fixes. No API or Kconfig change.
## Testing
Host: Ubuntu 22.04.5 LTS x86_64, QEMU version 10.2.1, sim: cc (Ubuntu
13.1.0-8ubuntu1~22.04) 13.1.0, qemu-armv8a: aarch64-none-elf-gcc (Arm GNU
Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205
**rsc table not set yet (sim, before/after).** No in-tree configuration
registers an rptun instance that is not auto-started, so a test-only
overlay (not part of this PR) adds a second, never-started instance
`idle` to sim:rpserver. `sim_rptun` has no reset op, so
`rptun reset` goes through `rptun_send_command()`:
<details><summary>test-only overlay</summary>
```diff
--- a/arch/sim/src/sim/sim_rptun.c
+++ b/arch/sim/src/sim/sim_rptun.c
@@ -288,7 +288,10 @@
static bool sim_rptun_is_autostart(struct rptun_dev_s *dev)
{
- return true;
+ struct sim_rptun_dev_s *priv = container_of(dev,
+ struct sim_rptun_dev_s, rptun);
+
+ return strcmp(priv->cpuname, "idle") != 0;
}
static bool sim_rptun_is_master(struct rptun_dev_s *dev)
--- a/boards/sim/sim/sim/src/sim_bringup.c
+++ b/boards/sim/sim/sim/src/sim_bringup.c
@@ -512,6 +512,8 @@
# ifdef CONFIG_SIM_RPMSG_MASTER
sim_rptun_init("server-proxy", "proxy",
SIM_RPTUN_MASTER | SIM_RPTUN_NOBOOT);
+ sim_rptun_init("server-idle", "idle",
+ SIM_RPTUN_MASTER | SIM_RPTUN_NOBOOT);
# else
sim_rptun_init("server-proxy", "server", SIM_RPTUN_SLAVE);
# endif
```
</details>
```
server> ls /dev/rptun
/dev/rptun:
idle
proxy
server> rptun reset /dev/rptun/idle 1
server> rpmsg ping all 3 64 3 0
```
| | `rptun reset /dev/rptun/idle 1` | `rpmsg ping all 3 64 3 0` afterwards |
|---|---|---|
| master | server process dies (NULL dereference) | - |
| this PR | returns | `ping times: 3` |
**ivshmem polling timer.** On qemu-armv8a the proxy side has no ivshmem
interrupt and starts the polling watchdog
(`rptun_ivshmem_probe: Start the wdog` in the boot log), so all rpmsg
traffic to the proxy in the baseline below is driven by the
`wd_start_next()` timer.
Baseline (`test.sh`, cases: baseline.yaml):
- host: Ubuntu 22.04.5 LTS x86_64, QEMU version 10.2.1, sim: cc (Ubuntu
13.1.0-8ubuntu1~22.04) 13.1.0, qemu-armv8a: aarch64-none-elf-gcc (Arm GNU
Toolchain 12.2.Rel1 (Build arm-12.24)) 12.2.1 20221205
- tested: nuttx 849e0e17222 apps f183bba3d
- qemu-armv8a built with test-only overlay: disabled LIBC_ENVPATH
BINFMT_CHECKEXEC
- sim:rpserver + sim:rpproxy: PASS
- [x] `uname -a` (server)
- [x] `rpmsg dump all` (server)
- [x] `rpmsg ping all 10 1024 3 0` (server)
- [x] `uname -a` (proxy)
- [x] `rpmsg ping all 10 1024 3 0` (proxy)
- [x] `mount -t rpmsgfs -o cpu=server,fs=/proc /sp` (proxy)
- [x] `cat /sp/version` (proxy)
- [x] `rpmsg dump all` (proxy)
- qemu-armv8a:rpserver + qemu-armv8a:rpproxy: PASS
- [x] `uname -a` (server)
- [x] `uname -a` (proxy)
- [x] `rpmsg dump all` (server)
- [x] `rpmsg ping all 10 1024 3 0` (server)
- [x] `rpmsg ping all 10 1024 3 0` (proxy)
- [x] `mount -t rpmsgfs -o cpu=server,fs=/proc /sp` (proxy)
- [x] `cat /sp/version` (proxy)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
