doc: board_porting: Extend the board extensions section

Tweak a few sentences and add a basic example, to fit in with the
overall document a little better. Also, fix an invalid cross-reference.

Signed-off-by: Grzegorz Swiderski <grzegorz.swiderski@nordicsemi.no>
This commit is contained in:
Grzegorz Swiderski 2023-09-27 09:38:59 +02:00 committed by Carles Cufí
commit f62c805a3d

View file

@ -783,21 +783,31 @@ There are some extra things you'll need to do:
Board extensions
****************
Board extensions are designed for downstream users, for example,
Boards already supported by Zephyr can be extended by downstream users, such as
``example-application`` or vendor SDKs. In some situations, certain hardware
description or `choices <devicetree-chosen-nodes>`_ can not be added in the
description or :ref:`choices <devicetree-chosen-nodes>` can not be added in the
upstream Zephyr repository, but they can be in a downstream project, where
custom bindings or driver classes can also be created. This feature may also be
useful in development phases, when the board skeleton lives upstream, but other
features are developed in a downstream module.
Board extensions are board fragments that can be present in a board root
folder, under ``${BOARD_ROOT}/boards/extensions``. The extension folder must
follow the naming structure of the original board to extend. The board extension
directory may contain Kconfig fragments and/or devicetree overlays. Board
extensions are, by default, automatically loaded and applied on top of board
Board extensions are board fragments that can be present in an out-of-tree board
root folder, under ``${BOARD_ROOT}/boards/extensions``. Here is an example
structure of an extension for the ``plank`` board and its revisions:
.. code-block:: none
boards/extensions/plank
├── plank.conf # optional
├── plank_<revision>.conf # optional
├── plank.overlay # optional
└── plank_<revision>.overlay # optional
A board extension directory must follow the naming structure of the original
board it extends. It may contain Kconfig fragments and/or devicetree overlays.
Extensions are, by default, automatically loaded and applied on top of board
files, before anything else. There is no guarantee on which order extensions are
applied, in case multiple exist. This feature shall be disabled by passing
applied, in case multiple exist. This feature can be disabled by passing
``-DBOARD_EXTENSIONS=OFF`` when building.
Note that board extensions need to follow the