michaelh/zephyr
1
0
Fork 0
Code Releases Activity

doc: board_porting: Extend the board extensions section

Browse source 
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
1 changed files with 18 additions and 8 deletions
Download patch file Download diff file Expand all files Collapse all files

26
doc/hardware/porting/board_porting.rst
View file

@ -783,21 +783,31 @@ There are some extra things you'll need to do:
Board extensions 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 ``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 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 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 useful in development phases, when the board skeleton lives upstream, but other
features are developed in a downstream module. features are developed in a downstream module.
Board extensions are board fragments that can be present in a board root Board extensions are board fragments that can be present in an out-of-tree board
folder, under ``${BOARD_ROOT}/boards/extensions``. The extension folder must root folder, under ``${BOARD_ROOT}/boards/extensions``. Here is an example
follow the naming structure of the original board to extend. The board extension structure of an extension for the ``plank`` board and its revisions:
directory may contain Kconfig fragments and/or devicetree overlays. Board
extensions are, by default, automatically loaded and applied on top of board .. 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 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. ``-DBOARD_EXTENSIONS=OFF`` when building.
Note that board extensions need to follow the Note that board extensions need to follow the