This is an automated email from the ASF dual-hosted git repository.
xiaoxiang781216 pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/nuttx.git
The following commit(s) were added to refs/heads/master by this push:
new e34cf854cba Documentation/nxinit: document per-core trigger key
e34cf854cba is described below
commit e34cf854cbafc26c65ecae4693d2e94d7be26b45
Author: wangjianyu3 <[email protected]>
AuthorDate: Fri Oct 16 19:36:01 2026 +0800
Documentation/nxinit: document per-core trigger key
Document the init.trigger[.<core>] property that trigger and on use,
how its name is chosen, and how to trigger across instances.
Assisted-by: Kiro:claude-opus-5.5
Signed-off-by: wangjianyu3 <[email protected]>
---
Documentation/applications/system/nxinit/index.rst | 36 +++++++++++++++++++---
1 file changed, 32 insertions(+), 4 deletions(-)
diff --git a/Documentation/applications/system/nxinit/index.rst
b/Documentation/applications/system/nxinit/index.rst
index 16f030bf586..053e5a55d07 100644
--- a/Documentation/applications/system/nxinit/index.rst
+++ b/Documentation/applications/system/nxinit/index.rst
@@ -128,11 +128,11 @@ forwards ``setprop`` to the action manager.
Built-in Properties
====================
-NXInit sets one built-in property on its own, before the ``boot`` event
-fires:
+NXInit sets the following built-in properties on its own:
-- ``sys.boot.reason``: the cause of the last board reset. It is queried
- once at startup via ``boardctl(BOARDIOC_RESET_CAUSE, ...)``; applications
+- ``sys.boot.reason``: the cause of the last board reset, set before the
+ ``boot`` event fires. It is queried once at startup via
+ ``boardctl(BOARDIOC_RESET_CAUSE, ...)``; applications
do not need to set it themselves. This requires
``CONFIG_BOARDCTL_RESET_CAUSE`` and a board-provided
``board_reset_cause()`` implementation.
@@ -168,6 +168,34 @@ fires:
on init && property:sys.boot.reason=bootloader|recovery|thermal
...
+- ``init.trigger[.<core>]``: the key that ``trigger <event>`` writes, with
+ ``<event>`` as the value; ``on <event>`` matches it. Each init instance
+ uses its own key, so instances that share a property backend do not run
+ each other's actions:
+
+ - ``init.trigger.core<N>`` with ``CONFIG_BMP``, where ``<N>`` is the CPU
+ the instance runs on;
+ - ``init.trigger.<cpuname>`` with ``CONFIG_RPMSG_LOCAL_CPUNAME``;
+ - ``init.trigger`` otherwise.
+
+ With a shared backend, an instance can wait for another instance's event
+ through that instance's key, or trigger an event on it by setting the key.
+ For example, audio waits for ap's ``appinit``:
+
+ .. code-block::
+ :caption: init.audio.rc
+
+ on property:init.trigger.ap=appinit
+ ...
+
+ and ap triggers audio's ``appinit``:
+
+ .. code-block::
+ :caption: init.ap.rc
+
+ on boot
+ setprop init.trigger.audio appinit
+
Commands
========
The commands supported by an action fall into three types: the built-in
