mzanders opened a new pull request, #18410:
URL: https://github.com/apache/nuttx/pull/18410
## Summary
Add Linux-compatible rpmsg UART driver for NuttX that interoperates with
Linux's `rpmsg_tty` driver.
**Problems:**
- The existing `uart_rpmsg.c` uses a custom protocol with headers (command,
response, result, cookie fields and flow control) that is incompatible with
Linux's `rpmsg_tty` driver, which expects raw byte streams.
- When using this UART for console operation (TERMIOS settings), we don't
necessarily want to register it as /dev/console
**Solution:** Made `/dev/console` registration conditional via
`CONFIG_RPMSG_UART_CONSOLE`
Modify `uart_rpmsg.c` to support both protocols:
- Original protocol for NuttX-to-NuttX or to patched-linux communication
- Raw protocol (Linux-compatible mode) via `CONFIG_RPMSG_UART_RAW`
**Key changes:**
- Raw data transmission without protocol headers when in RAW mode
- Use "rpmsg-tty" as endpoint name for RAW mode (as expected by linux driver)
- Maintains backward compatibility with existing NuttX rpmsg deployments
**Alternative considered:** Separate driver file. Rejected due to
significant code duplication (~80% shared logic). Single file with conditional
compilation preferred but not very clean. Downside of this approach is that the
two implementations cannot be used in parallel. I'm open to opinions on this
and change if required.
## Impact
**Users:** Enables heterogeneous vanilla Linux/NuttX systems to communicate
via rpmsg serial ports.
**Build:** Kconfig options:
- New: `CONFIG_RPMSG_UART_RAW` - Enable Linux-compatible raw protocol,
defaults to N (backwards compatible)
- `CONFIG_RPMSG_UART_CONSOLE` - Control /dev/console registration inside
driver
**Compatibility:** Fully backward compatible. Existing configurations work
unchanged.
## Testing
**Hardware:** NXP i.MX93-EVK (Cortex-A55 running Linux + Cortex-M33 running
NuttX 12.12.0), currently under development for NuttX support
**Test setup:**
1. M33 (NuttX): `uart_rpmsg_init("netcore", "-nsh", 4096, true)` &
`uart_rpmsg_init("netcore", "-test", 4096, false)` with
`CONFIG_RPMSG_UART_LINUX_RAW=y`, NSH instance started on tty-nsh.
2. A55 (Linux 6.6): Standard `rpmsg_tty` driver
3. Linux userspace: minicom on `/dev/ttyRPMSG0`
**Tests performed:**
- Bidirectional echo test (echo/cat on both sides) on ttyRPMSG1 / tty-test
- NSH over rpmsg raw mode from Linux minicom
**Logs:** NSH prompt accessible via minicom, commands execute correctly
From linux:
```
root@imx93-9x9-lpddr4-qsb:~# echo start >
/sys/class/remoteproc/remoteproc0/state
root@imx93-9x9-lpddr4-qsb:~# dmesg -c
[ 3585.494190] remoteproc remoteproc0: powering up imx-rproc
[ 3585.502081] remoteproc remoteproc0: Booting fw image rproc-imx-rproc-fw,
size 2519164
[ 3586.015227] rproc-virtio rproc-virtio.1.auto: assigned reserved memory
node vdevbuffer@a4020000
[ 3586.024788] virtio_rpmsg_bus virtio0: rpmsg host is online
[ 3586.030357] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr
0x400
[ 3586.031239] rproc-virtio rproc-virtio.1.auto: registered virtio0 (type 7)
[ 3586.037642] virtio_rpmsg_bus virtio0: creating channel rpmsg-tty addr
0x401
[ 3586.046800] remoteproc remoteproc0: remote processor imx-rproc is now up
root@imx93-9x9-lpddr4-qsb:~# echo "hello" > /dev/ttyRPMSG1
root@imx93-9x9-lpddr4-qsb:~# minicom -D /dev/ttyRPMSG0
Welcome to minicom 2.9
OPTIONS: I18n
Compiled on Sep 22 2023, 21:10:41.
Port /dev/ttyRPMSG0, 13:34:38
Press CTRL-A Z for help on special keys
NuttShell (NSH) NuttX-12.12.0
nsh>
nsh> ls /dev
/dev:
console
kmsg
null
rptun/
tty-nsh
tty-test
ttyS1
zero
nsh>
nsh> echo "Hello from NuttX" > /dev/tty-test
nsh> cat /dev/tty-test
hello
#exit minicom
root@imx93-9x9-lpddr4-qsb:~# cat /dev/ttyRPMSG1
Hello from NuttX
```
**Quirks:**
RPMSG endpoint only becomes "ready" when Linux side has sent a first message
to NuttX, so upon connecting, you need to press a key before terminal comes
alive. NuttX greeting has been buffered before this. This behaviour is inherent
to the RPMSG implementation and can only be solved on Linux side - if required.
--
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]
