boards: doc: native_sim: adopt zephyr-board directive

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é <[email protected]>

Author: kartben

boards/native/doc/arch_soc.rst

@@ -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>`_

boards/native/doc/bsim_boards_design.rst

@@ -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:

boards/native/native_sim/doc/index.rst

@@ -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

doc/_scripts/gen_boards_catalog.py

@@ -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)

doc/connectivity/bluetooth/autopts/autopts-linux.rst

@@ -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::
 

doc/connectivity/bluetooth/bluetooth-dev.rst

@@ -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>`.
 

doc/connectivity/bluetooth/bluetooth-tools.rst

@@ -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>

doc/connectivity/networking/api/gptp.rst

@@ -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)
 

doc/connectivity/networking/eth_bridge_native_sim_setup.rst

@@ -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.
 

doc/connectivity/networking/native_sim_setup.rst

@@ -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