michael/zephyr
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

boards: doc: native_sim: adopt zephyr-board directive

Browse Source 
Update documentation of native_sim to leverage zephyr-board Shinx magic,
in particular the ability to generate the table of supported HW
features.

Signed-off-by: Benjamin Cabé <benjamin@zephyrproject.org>
This commit is contained in:
Benjamin Cabé
2025-09-05 11:56:14 +02:00
committed by Anas Nashif
parent 3c1f7f1c71
commit 6de7702910
47 changed files with 83 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
boards/native/doc/arch_soc.rst
View File

@@ -34,7 +34,7 @@ Types of POSIX arch based boards
================================
Today there are two types of POSIX boards:
:ref:`native_sim<native_sim>`, and the :ref:`bsim boards<bsim boards>`.
:zephyr:board:`native_sim<native_sim>`, and the :ref:`bsim boards<bsim boards>`.
While they share the main objectives and principles, the first is intended as
a HW agnostic test platform which in some cases utilizes the host OS
peripherals, while the second intend to simulate a particular HW platform,
@@ -320,8 +320,8 @@ Architecture and design
Relationship between Zephyr, the native_sim target and the native simulator
When building targeting Zephyr's :ref:`native_sim<native_sim>` board, we build our embedded SW,
that is, our application, the Zephyr kernel, and any subsystems and drivers we have selected,
When building targeting Zephyr's :zephyr:board:`native_sim<native_sim>` board, we build our embedded
SW, that is, our application, the Zephyr kernel, and any subsystems and drivers we have selected,
with the :ref:`POSIX architecture<posix_arch_design_archl>` and the
:ref:`inf_clock<posix_arch_design_socl>` SOC layers.
The result of this build is a pre-linked elf library, which contains what we can call the
@@ -449,9 +449,9 @@ Busy waits
==========
Busy waits work thanks to logic provided by the board and native simulator.
This does not need to be the same for all boards, but both :ref:`native_sim<native_sim>` and the
:ref:`nrf*bsim boards<bsim boards>` work similarly through the combination of a board specific
:c:func:`arch_busy_wait()` and an special fake HW timer provided by the native simulator.
This does not need to be the same for all boards, but both :zephyr:board:`native_sim<native_sim>`
and the :ref:`nrf*bsim boards<bsim boards>` work similarly through the combination of a board
specific :c:func:`arch_busy_wait()` and an special fake HW timer provided by the native simulator.
Please check the
`native simulator busy wait design documentation <https://github.com/BabbleSim/native_simulator/blob/main/docs/Design.md#busy-waits>`_

6
boards/native/doc/bsim_boards_design.rst
View File

@@ -60,7 +60,7 @@ These tests are run in workstation, that is, without using real embedded HW.
The intention being to be able to run tests much faster than real time,
without the need for real HW, and in a deterministic/reproducible fashion.
Unlike :ref:`native_sim <native_sim>`, bsim boards do not interact directly with any host
Unlike :zephyr:board:`native_sim <native_sim>`, bsim boards do not interact directly with any host
peripherals, and their execution is independent of the host load, or timing.
These boards are also designed to be used as prototyping and development environments,
@@ -106,12 +106,12 @@ to these boards.
an special driver that handles the EDTT communication (its RPC transport)
and an embedded application that handles the RPC calls themselves, while
the python test scripts provide the test logic.
- Using Zephyr's :ref:`native_sim <native_sim>` board: It also allows integration testing of
- Using Zephyr's :zephyr:board:`native_sim <native_sim>` board: It also allows integration testing of
the embedded code, but without any specific HW. In that way, many embedded
components which are dependent on the HW would not be suited for testing in
that platform. Just like the bsim boards, this Zephyr target board can
be used with or without Zephyr's ztest system and twister.
The :ref:`native_sim <native_sim>` board shares the :ref:`POSIX architecture<Posix arch>`,
The :zephyr:board:`native_sim <native_sim>` board shares the :ref:`POSIX architecture<Posix arch>`,
and native simulator runner with the bsim boards.
- Zephyr's ztest infrastructure and Zephyr's twister:

14
boards/native/native_sim/doc/index.rst
View File

@@ -1,12 +1,4 @@
.. _native_sim:
native_sim
##########
.. contents::
:depth: 1
:backlinks: entry
:local:
.. zephyr:board:: native_sim
Overview
********
@@ -293,7 +285,9 @@ All times are kept in microseconds.
Peripherals
***********
The following peripherals are currently provided with this board:
.. zephyr:board-supported-hw::
Here are more details on the peripherals that are currently provided with this board:
**Interrupt controller**
A simple yet generic interrupt controller is provided. It can nest interrupts

5
doc/_scripts/gen_boards_catalog.py
View File

@@ -302,8 +302,9 @@ def get_catalog(generate_hw_features=False, hw_features_vendor_filter=None):
if node.matching_compat is None:
continue
# skip "zephyr,xxx" compatibles
if node.matching_compat.startswith("zephyr,"):
# skip "zephyr,xxx" compatibles (unless board is native_sim, since in this
# case the "zephyr,"-prefixed peripherals are legitimate)
if node.matching_compat.startswith("zephyr,") and board.name != "native_sim":
continue
description = DeviceTreeUtils.get_cached_description(node)

6
doc/connectivity/bluetooth/autopts/autopts-linux.rst
View File

@@ -13,11 +13,11 @@ Supported methods to test zephyr bluetooth host:
- Testing Zephyr Host Stack on QEMU
- Testing Zephyr Host Stack on :ref:`native_sim <native_sim>`
- Testing Zephyr Host Stack on :zephyr:board:`native_sim <native_sim>`
- Testing Zephyr combined (controller + host) build on Real hardware (such as nRF52)
For running with QEMU or :ref:`native_sim <native_sim>`, see :ref:`bluetooth_qemu_native`.
For running with QEMU or :zephyr:board:`native_sim <native_sim>`, see :ref:`bluetooth_qemu_native`.
.. contents::
:local:
@@ -325,7 +325,7 @@ Testing Zephyr Host Stack on QEMU:
~/zephyrproject/build/zephyr/zephyr.elf -i SERVER_IP -l LOCAL_IP
Testing Zephyr Host Stack on :ref:`native_sim <native_sim>`:
Testing Zephyr Host Stack on :zephyr:board:`native_sim <native_sim>`:
.. code-block::

8
doc/connectivity/bluetooth/bluetooth-dev.rst
View File

@@ -76,7 +76,7 @@ This setup relies on a "dual-chip" :ref:`configuration <bluetooth-configs>`
which is comprised of the following devices:
#. A :ref:`Host-only <bluetooth-build-types>` application running in the
:ref:`QEMU <application_run_qemu>` emulator or the :ref:`native_sim <native_sim>` native
:ref:`QEMU <application_run_qemu>` emulator or the :zephyr:board:`native_sim <native_sim>` native
port of Zephyr
#. A Controller, which can be one of the following types:
@@ -117,7 +117,7 @@ native_sim
.. note::
This is currently only available on GNU/Linux
The :ref:`native_sim <native_sim>` target builds your Zephyr application
The :zephyr:board:`native_sim <native_sim>` target builds your Zephyr application
with the Zephyr kernel, and some minimal HW emulation as a native Linux
executable.
@@ -146,8 +146,8 @@ These boards, use:
* The POSIX arch and native simulator to emulate the processor, and run natively on your host.
* `Models of the nrf5x HW <https://github.com/BabbleSim/ext_NRF_hw_models/>`_
Just like with the :ref:`native_sim <native_sim>` target, the build result is a normal Linux
executable.
Just like with the :zephyr:board:`native_sim <native_sim>` target, the build result is a normal
Linux executable.
You can find more information on how to run simulations with one or several
devices in either of :ref:`these boards's documentation <nrf52bsim_build_and_run>`.

6
doc/connectivity/bluetooth/bluetooth-tools.rst
View File

@@ -84,7 +84,7 @@ Running on QEMU or native_sim
*****************************
It's possible to run Bluetooth applications using either the :ref:`QEMU
emulator<application_run_qemu>` or :ref:`native_sim <native_sim>`.
emulator<application_run_qemu>` or :zephyr:board:`native_sim <native_sim>`.
In either case, a Bluetooth controller needs to be exported from
the host OS (Linux) to the emulator. For this purpose you will need some tools
@@ -103,7 +103,7 @@ The host OS's Bluetooth controller is connected in the following manner:
command-line option passed to the native_sim executable: ``--bt-dev=hci0``
On the host side, BlueZ allows you to export its Bluetooth controller
through a so-called user channel for QEMU and :ref:`native_sim <native_sim>` to use.
through a so-called user channel for QEMU and :zephyr:board:`native_sim <native_sim>` to use.
.. note::
You only need to run ``btproxy`` when using QEMU. native_sim handles
@@ -147,7 +147,7 @@ building and running a sample:
the :literal:`bt-server-bredr` UNIX socket, letting the application
access the Bluetooth controller.
* To run a Bluetooth application in :ref:`native_sim <native_sim>`, first build it:
* To run a Bluetooth application in :zephyr:board:`native_sim <native_sim>`, first build it:
.. zephyr-app-commands::
:zephyr-app: samples/bluetooth/<sample>

2
doc/connectivity/networking/api/gptp.rst
View File

@@ -40,7 +40,7 @@ Boards supported:
- :zephyr:board:`nucleo_h745zi_q`
- :zephyr:board:`nucleo_f767zi`
- :zephyr:board:`sam_e70_xplained`
- :ref:`native_sim` (only usable for simple testing, limited capabilities
- :zephyr:board:`native_sim` (only usable for simple testing, limited capabilities
due to lack of hardware clock)
- :zephyr:board:`qemu_x86` (emulated, limited capabilities due to lack of hardware clock)

4
doc/connectivity/networking/eth_bridge_native_sim_setup.rst
View File

@@ -8,12 +8,12 @@ Ethernet bridge with native_sim board
:depth: 2
This document describes how to set up a bridged Ethernet network between a (Linux) host
and a Zephyr application running in a :ref:`native_sim <native_sim>` board.
and a Zephyr application running in a :zephyr:board:`native_sim <native_sim>` board.
This setup is useful when testing the Ethernet bridging feature that can be enabled with
:kconfig:option:`CONFIG_NET_ETHERNET_BRIDGE` Kconfig option. In this setup, the net-tools
configuration creates two host network interfaces ``zeth0`` and ``zeth1`` and connects them
to Zephyr's :ref:`native_sim <native_sim>` application.
to Zephyr's :zephyr:board:`native_sim <native_sim>` application.
First create the host interfaces. In this example two interfaces are created.

2
doc/connectivity/networking/native_sim_setup.rst
View File

@@ -11,7 +11,7 @@ Using virtual/TAP Ethernet driver
*********************************
This paragraph describes how to set up a virtual network between a (Linux) host
and a Zephyr application running in a :ref:`native_sim <native_sim>` board.
and a Zephyr application running in a :zephyr:board:`native_sim <native_sim>` board.
In this example, the :zephyr:code-sample:`sockets-echo-server` sample application from
the Zephyr source distribution is run in native_sim board. The Zephyr

2
doc/connectivity/usb/device/usb_device.rst
View File

@@ -459,7 +459,7 @@ Testing over USBIP in native_sim
A virtual USB controller implemented through USBIP might be used to test the USB
device stack. Follow the general build procedure to build the USB sample for
the :ref:`native_sim <native_sim>` configuration.
the :zephyr:board:`native_sim <native_sim>` configuration.
Run built sample with:

2
doc/connectivity/usb/host/usbip.rst
View File

@@ -63,7 +63,7 @@ USB/IP with native_sim
**********************
The preferred method to develop with USB/IP support enabled is to use
:ref:`native_sim <native_sim>`. Use on real hardware is not really tested yet.
:zephyr:board:`native_sim <native_sim>`. Use on real hardware is not really tested yet.
USB/IP requires a network connection, see :ref:`networking_with_native_sim`
for how to set up the interface on the client side.

4
doc/develop/beyond-GSG.rst
View File

@@ -181,7 +181,7 @@ Build and Run an Application
You can build, flash, and run Zephyr applications on real
hardware using a supported host system. Depending on your operating system,
you can also run it in emulation with QEMU, or as a native application with
:ref:`native_sim <native_sim>`.
:zephyr:board:`native_sim <native_sim>`.
Additional information about building applications can be found in the
:ref:`build_an_application` section.
@@ -308,7 +308,7 @@ Run a Sample Application natively (Linux)
=========================================
You can compile some samples to run as host programs
on Linux. See :ref:`native_sim` for more information. On 64-bit host operating systems, you
on Linux. See :zephyr:board:`native_sim` for more information. On 64-bit host operating systems, you
need to install a 32-bit C library, or build targeting :ref:`native_sim/native/64<native_sim32_64>`.
First, build Hello World for ``native_sim``.

2
doc/develop/test/bsim.rst
View File

@@ -34,7 +34,7 @@ Tests without radio activity: bsim tests with twister
The :ref:`bsim boards<bsim boards>` can be used without radio activity, and in that case, it is not
necessary to connect them to a physical layer simulation. Thanks to this, these target boards can
be used just like :ref:`native_sim<native_sim>` with :ref:`twister <twister_script>`,
be used just like :zephyr:board:`native_sim<native_sim>` with :ref:`twister <twister_script>`,
to run all standard Zephyr twister tests, but with models of a real SOC HW, and their drivers.
Tests with radio activity

2
doc/hardware/emulator/index.rst
View File

@@ -53,7 +53,7 @@ Available Emulators
* Emulate an EEPROM on RAM
* Main Kconfig option: :kconfig:option:`CONFIG_EEPROM_SIMULATOR`
* DT binding: :dtcompatible:`zephyr,sim-eeprom`
* Note: For :ref:`native targets <native_sim>` it is also possible to keep the content
* Note: For :zephyr:board:`native targets <native_sim>` it is also possible to keep the content
as a file on the host filesystem.
**External bus and bus connected peripheral emulators**

2
doc/hardware/peripherals/eeprom/shell.rst
View File

@@ -21,7 +21,7 @@ In order to enable the EEPROM shell, the following :ref:`Kconfig <kconfig>` opti
* :kconfig:option:`CONFIG_EEPROM`
* :kconfig:option:`CONFIG_EEPROM_SHELL`
For example, building the :zephyr:code-sample:`hello_world` sample for the :ref:`native_sim` with the EEPROM shell:
For example, building the :zephyr:code-sample:`hello_world` sample for the :zephyr:board:`native_sim` with the EEPROM shell:
.. zephyr-app-commands::
:zephyr-app: samples/hello_world

4
doc/introduction/index.rst
View File

@@ -154,7 +154,7 @@ Zephyr offers a large and ever growing number of features including:
**Native Linux, macOS, and Windows Development**
A command-line CMake build environment runs on popular developer OS
systems. A native port (:ref:`native_sim <native_sim>`) lets you build and run Zephyr as a native
systems. A native port (:zephyr:board:`native_sim <native_sim>`) lets you build and run Zephyr as a native
application on Linux, aiding development and testing.
**Virtual File System Interface with ext2, FatFs, and LittleFS Support**
@@ -181,7 +181,7 @@ Zephyr offers a large and ever growing number of features including:
combination of these.
**Native port**
:ref:`Native sim <native_sim>` allows running Zephyr as a Linux application with support
:zephyr:board:`Native sim <native_sim>` allows running Zephyr as a Linux application with support
for various subsystems and networking.

2
doc/releases/migration-guide-3.6.rst
View File

@@ -242,7 +242,7 @@ Controller Area Network (CAN)
=============================
* The native Linux SocketCAN driver, which can now be used in both ``native_posix``
and :ref:`native_sim<native_sim>` with or without an embedded C-library, has been renamed to
and :zephyr:board:`native_sim<native_sim>` with or without an embedded C-library, has been renamed to
reflect this:
* The devicetree compatible was renamed from ``zephyr,native-posix-linux-can`` to

2
doc/releases/migration-guide-4.0.rst
View File

@@ -34,7 +34,7 @@ Boards
******
* ``native_posix`` has been deprecated in favour of
:ref:`native_sim<native_sim>` (:github:`76898`).
:zephyr:board:`native_sim<native_sim>` (:github:`76898`).
* Nordic nRF53 and nRF91 based boards can use the common devicetree overlays in ``dts/common/nordic``
to define default flash and ram partitioning based on TF-M.

5
doc/releases/migration-guide-4.2.rst
View File

@@ -469,8 +469,9 @@ Video
size on a per driver basis. Existing applications will not be broken by this change but can be
simplified as performed in the sample in the commit ``33dcbe37cfd3593e8c6e9cfd218dd31fdd533598``.
* Samples and projects using the :ref:`native simulator <native_sim>` now require specifying the
``--snippet`` :ref:`video-sw-generator <snippet-video-sw-generator>` to build correctly.
* Samples and projects using the :zephyr:board:`native simulator <native_sim>` now require
specifying the ``--snippet`` :ref:`video-sw-generator <snippet-video-sw-generator>` to build
correctly.
* :c:func:`video_query_ctrl` now takes a single argument with the :c:struct:`video_ctrl_query`,
which now contains a ``video_ctrl_query.dev`` field to specify and read back which device is

2
doc/releases/release-notes-3.5.rst
View File

@@ -344,7 +344,7 @@ Boards & SoC Support
* Added support for these POSIX boards:
* :ref:`native_sim(_64) <native_sim>`
* :zephyr:board:`native_sim(_64) <native_sim>`
* nrf5340bsim_nrf5340_cpu(net|app). A simulated nrf5340 SOC, which uses Babblesim for its radio
traffic.

6
doc/releases/release-notes-3.6.rst
View File

@@ -18,8 +18,8 @@ Major enhancements with this release include:
* Userspace support extended to Xtensa architecture.
* Build system now supports Link Time Optimization (LTO), reducing the size of the final image.
* Bluetooth Mesh protocol 1.1 now supported by default.
* Major updates to the documentation of the :ref:`native simulator <native_sim>`, clarifying
supported peripherals and how to use them.
* Major updates to the documentation of the :zephyr:board:`native simulator <native_sim>`,
clarifying supported peripherals and how to use them.
* Over 30 new supported boards, spanning all Zephyr-supported architectures.
An overview of the changes required or recommended when migrating your application from Zephyr
@@ -1301,7 +1301,7 @@ Additionally, the following changes in Zephyr were done:
Tests and Samples
*****************
* :ref:`native_sim<native_sim>` has replaced ``native_posix`` as the default
* :zephyr:board:`native_sim<native_sim>` has replaced ``native_posix`` as the default
test platform.
``native_posix`` remains supported and used in testing but will be deprecated
in a future release.

4
doc/releases/release-notes-3.7.rst
View File

@@ -30,8 +30,8 @@ Major enhancements with this release include:
data flows than the previous fetch/get APIs.
* A new :ref:`LLEXT Extension Developer Kit (EDK) <llext_build_edk>` makes it easier to develop and
integrate custom extensions into Zephyr, including outside of the Zephyr tree.
* :ref:`Native simulator <native_sim>` now supports leveraging the native host networking stack
without having to rely on a complex setup of the host environment.
* :zephyr:board:`Native simulator <native_sim>` now supports leveraging the native host networking
stack without having to rely on a complex setup of the host environment.
* Trusted Firmware-M (TF-M) 2.1.0 and Mbed TLS 3.6.0 have been integrated into Zephyr.
Both of these versions are LTS releases. What's more, :ref:`psa_crypto` has been adopted as a replacement
for TinyCrypt and provides enhanced security and performance.

4
doc/releases/release-notes-4.0.rst
View File

@@ -113,7 +113,7 @@ Deprecated in this release
* Deprecated the TinyCrypt shim driver ``CONFIG_CRYPTO_TINYCRYPT_SHIM``.
* ``native_posix`` has been deprecated in favour of
:ref:`native_sim<native_sim>`.
:zephyr:board:`native_sim<native_sim>`.
* ``include/zephyr/net/buf.h`` is deprecated in favor of
``include/zephyr/net_buf.h>``. The old header will be removed in future releases
@@ -1542,7 +1542,7 @@ Tests and Samples
*****************
* Together with the deprecation of ``native_posix``, many tests which were
explicitly run in native_posix now run in :ref:`native_sim<native_sim>` instead.
explicitly run in native_posix now run in :zephyr:board:`native_sim<native_sim>` instead.
native_posix as a platform remains tested though.
* Extended the tests of counter_basic_api with a testcase for counters without alarms
* Added support for testing SDMMC devices to the fatfs API test

4
doc/services/tracing/index.rst
View File

@@ -499,8 +499,8 @@ Using Tracing
The sample :zephyr_file:`samples/subsys/tracing` demonstrates tracing with
different formats and backends.
To get started, the simplest way is to use the CTF format with the :ref:`native_sim <native_sim>`
port, build the sample as follows:
To get started, the simplest way is to use the CTF format with the
:zephyr:board:`native_sim <native_sim>` port, build the sample as follows:
.. zephyr-app-commands::
:tool: all

2
samples/basic/hash_map/README.rst
View File

@@ -16,7 +16,7 @@ This is a simple example that repeatedly:
Building
********
This application can be built on :ref:`native_sim <native_sim>` as follows:
This application can be built on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/basic/hash_map

2
samples/basic/sys_heap/README.rst
View File

@@ -12,7 +12,7 @@ prints system heap usage to the console.
Building
********
This application can be built on :ref:`native_sim <native_sim>` as follows:
This application can be built on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/basic/sys_heap

2
samples/bluetooth/bluetooth.rst
View File

@@ -6,7 +6,7 @@
To build any of the Bluetooth samples, follow the same steps as building
any other Zephyr application. Refer to :ref:`bluetooth-dev` for more information.
Many Bluetooth samples can be run on QEMU or :ref:`native_sim <native_sim>` with support for
Many Bluetooth samples can be run on QEMU or :zephyr:board:`native_sim <native_sim>` with support for
external Bluetooth Controllers. Refer to the :ref:`bluetooth-hw-setup` section
for further details.

2
samples/bluetooth/hci_uart/README.rst
View File

@@ -59,7 +59,7 @@ For example, to build for the nRF52832 Development Kit:
Using the controller with QEMU or native_sim
============================================
In order to use the HCI UART controller with QEMU or :ref:`native_sim <native_sim>` you will need
In order to use the HCI UART controller with QEMU or :zephyr:board:`native_sim <native_sim>` you will need
to attach it to the Linux Host first. To do so simply build the sample and
connect the UART to the Linux machine, and then attach it with this command:

2
samples/bluetooth/hci_uart_3wire/README.rst
View File

@@ -59,7 +59,7 @@ For example, to build for the nRF52840 Development Kit:
Using the controller with QEMU or native_sim
============================================
In order to use the HCI UART H:5 controller with QEMU or :ref:`native_sim <native_sim>` you will
In order to use the HCI UART H:5 controller with QEMU or :zephyr:board:`native_sim <native_sim>` you will
need to attach it to the Linux Host first. To do so simply build the sample and
connect the UART to the Linux machine, and then attach it with this command:

2
samples/bluetooth/hci_uart_async/README.rst
View File

@@ -59,7 +59,7 @@ For example, to build for the nRF52832 Development Kit:
Using the controller with QEMU or native_sim
============================================
In order to use the HCI UART controller with QEMU or :ref:`native_sim <native_sim>` you will need
In order to use the HCI UART controller with QEMU or :zephyr:board:`native_sim <native_sim>` you will need
to attach it to the Linux Host first. To do so simply build the sample and
connect the UART to the Linux machine, and then attach it with this command:

2
samples/drivers/display/README.rst
View File

@@ -41,7 +41,7 @@ Below is an example on how to build for a :zephyr:board:`nrf52840dk` board with
:shield: adafruit_2_8_tft_touch_v2
:compact:
For testing purpose without the need of any hardware, the :ref:`native_sim <native_sim>`
For testing purpose without the need of any hardware, the :zephyr:board:`native_sim <native_sim>`
board is also supported and can be built as follows;
.. zephyr-app-commands::

2
samples/drivers/eeprom/README.rst
View File

@@ -15,7 +15,7 @@ Building and Running
In case the target board has defined an EEPROM with alias ``eeprom-0`` the
sample can be built without further ado. This applies for example to the
:ref:`native_sim` board:
:zephyr:board:`native_sim` board:
.. zephyr-app-commands::
:zephyr-app: samples/drivers/eeprom

2
samples/drivers/uart/native_tty/README.rst
View File

@@ -34,7 +34,7 @@ Requirements
Building and Running
********************
This application can be built and executed on :ref:`native_sim <native_sim>` as follows:
This application can be built and executed on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/drivers/uart/native_tty

2
samples/kernel/condition_variables/condvar/README.rst
View File

@@ -20,7 +20,7 @@ the console.
Building and Running
********************
This application can be built and executed on :ref:`native_sim <native_sim>` as follows:
This application can be built and executed on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/kernel/condition_variables/condvar

2
samples/kernel/condition_variables/simple/README.rst
View File

@@ -21,7 +21,7 @@ the console.
Building and Running
********************
This application can be built and executed on :ref:`native_sim <native_sim>` as follows:
This application can be built and executed on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/kernel/condition_variables/simple

6
samples/net/tftp_client/README.rst
View File

@@ -44,7 +44,7 @@ The easiest way to setup this sample application is to build and run it
as a native_sim application or as a QEMU target using the default configuration :file:`prj.conf`.
This requires a small amount of setup described in :ref:`networking_with_eth_qemu`, :ref:`networking_with_qemu` and :ref:`networking_with_native_sim`.
Build the tftp-client sample application for :ref:`native_sim <native_sim>` like this:
Build the tftp-client sample application for :zephyr:board:`native_sim <native_sim>` like this:
.. zephyr-app-commands::
:zephyr-app: samples/net/tftp_client
@@ -74,8 +74,8 @@ configurations in ``prj.conf``:
Sample output
==================================
This sample can be run on :ref:`native_sim<native_sim>` while running a TFTP server on the host
machine.
This sample can be run on :zephyr:board:`native_sim<native_sim>` while running a TFTP server on the
host machine.
Launch :command:`net-setup.sh` in net-tools:

6
samples/subsys/display/lvgl/README.rst
View File

@@ -48,9 +48,9 @@ or a board with an integrated display:
- :zephyr:board:`esp_wrover_kit`
- :zephyr:board:`adafruit_feather_esp32s3_tft`
or a simulated display environment in a :ref:`native_sim <native_sim>` application:
or a simulated display environment in a :zephyr:board:`native_sim <native_sim>` application:
- :ref:`native_sim`
- :zephyr:board:`native_sim`
- `SDL2`_
or
@@ -74,7 +74,7 @@ Example building for :zephyr:board:`nrf52840dk`:
:shield: adafruit_2_8_tft_touch_v2
:goals: build flash
Example building for :ref:`native_sim <native_sim>`:
Example building for :zephyr:board:`native_sim <native_sim>`:
.. zephyr-app-commands::
:zephyr-app: samples/subsys/display/lvgl

2
samples/subsys/input/draw_touch_events/README.rst
View File

@@ -22,7 +22,7 @@ Below is an example on how to build the sample for :zephyr:board:`stm32f746g_dis
:goals: build
:compact:
For testing purposes without the need of any hardware, the :ref:`native_sim <native_sim>`
For testing purposes without the need of any hardware, the :zephyr:board:`native_sim <native_sim>`
board is also supported and can be built as follows:
.. zephyr-app-commands::

2
samples/subsys/sensing/simple/README.rst
View File

@@ -26,7 +26,7 @@ The program runs in the following sequence:
Building and Running
********************
This application can be built and executed on :ref:`native_sim <native_sim>` as follows:
This application can be built and executed on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/subsys/sensing/simple

6
samples/subsys/shell/fs/README.rst
View File

@@ -20,7 +20,7 @@ Building
native_sim
==========
You can build this sample for :ref:`native_sim <native_sim>` with:
You can build this sample for :zephyr:board:`native_sim <native_sim>` with:
.. zephyr-app-commands::
:zephyr-app: samples/subsys/shell/fs
@@ -223,8 +223,8 @@ Remove a file or directory
Flash Host Access
=================
For the :ref:`native sim board <native_sim>` the flash partitions can be accessed from the host
Linux system.
For the :zephyr:board:`native sim board <native_sim>` the flash partitions can be accessed from the
host Linux system.
By default the flash partitions are accessible through the directory *flash*
relative to the directory where the build is started.

2
samples/subsys/smf/smf_calculator/README.rst
View File

@@ -69,7 +69,7 @@ a :ref:`adafruit_2_8_tft_touch_v2`.
:shield: adafruit_2_8_tft_touch_v2
:compact:
For testing purpose without the need of any hardware, the :ref:`native_sim <native_sim>`
For testing purpose without the need of any hardware, the :zephyr:board:`native_sim <native_sim>`
board is also supported and can be built as follows;
.. zephyr-app-commands::

4
samples/subsys/zbus/remote_mock/README.rst
View File

@@ -16,7 +16,7 @@ Building and Running
********************
This project outputs to the console. It can be built and executed
on :ref:`native_sim <native_sim>` as follows:
on :zephyr:board:`native_sim <native_sim>` as follows:
.. zephyr-app-commands::
:zephyr-app: samples/subsys/zbus/remote_mock
@@ -64,7 +64,7 @@ The :file:`remote_mock.py` script can be executed using the following command:
Note the run command above prints the value of pts port because it is running in
:ref:`native_sim <native_sim>`.
:zephyr:board:`native_sim <native_sim>`.
Look at the line indicating ``uart_1 connected to pseudotty: /dev/pts/2``.
It can be different in your case. If you are using a board, read the documentation to get the
correct port destination (in Linux is something like ``/dev/tty...`` or in Windows ``COM...``).

2
samples/subsys/zbus/uart_bridge/README.rst
View File

@@ -69,7 +69,7 @@ The :file:`decoder.py` script can be executed using the following command:
Note the run command above prints the value of pts port because it is running in
:ref:`native_sim <native_sim>`.
:zephyr:board:`native_sim <native_sim>`.
Look at the line indicating ``uart_1 connected to pseudotty: /dev/pts/2``.
It can be different in your case. If you are using a board, read the documentation to get the
correct port destination (in Linux is something like ``/dev/tty...`` or in Windows ``COM...``).

2
snippets/socketcan-native-sim/README.rst
View File

@@ -11,7 +11,7 @@ Overview
********
This snippet allows to configure Controller Area Network (CAN) samples with Linux SocketCAN support
on :ref:`native_sim`.
on :zephyr:board:`native_sim`.
By default, the native simulator expects a SocketCAN network device called ``zcan0`` (specified in
:zephyr_file:`boards/native/native_sim/native_sim.dts`). This name can be added as an alternative

2
tests/drivers/can/host/README.rst
View File

@@ -46,7 +46,7 @@ Building and Running
Running on native_sim
=====================
Running the test suite on :ref:`native_sim` relies on the `Linux SocketCAN`_ virtual CAN driver
Running the test suite on :zephyr:board:`native_sim` relies on the `Linux SocketCAN`_ virtual CAN driver
(vcan) providing a virtual CAN interface named ``zcan0``.
On the host PC, a virtual SocketCAN interface needs to be created and brought up before running the

2
tests/ztest/fail/README.rst
View File

@@ -8,7 +8,7 @@ Overview
In order to test the actual framework's failure cases, this test suite has to do something unique.
There's a subdirectory to this test called 'core'. This project builds a sample as a
:ref:`native_sim <native_sim>` or :ref:`unit_testing <ztest_unit_testing>`
:zephyr:board:`native_sim <native_sim>` or :ref:`unit_testing <ztest_unit_testing>`
binary which is expected to fail by calling one of the following:
- ``ztest_test_fail()`` during either the ``after`` or ``teardown`` phase of the test suite
- ``ztest_test_skip()`` during either the ``after`` or ``teardown`` phase of the test suite