doc: develop: application: Fix missed HWMv2 changes
Fixes outdated information that was missed with the HWMv2 migration Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
This commit is contained in:
parent
c8e301ad78
commit
3d48ad90c9
|
@ -128,7 +128,7 @@ The initial configuration for an application comes from merging configuration
|
|||
settings from three sources:
|
||||
|
||||
1. A ``BOARD``-specific configuration file stored in
|
||||
:file:`boards/<architecture>/<BOARD>/<BOARD>_defconfig`
|
||||
:file:`boards/<VENDOR>/<BOARD>/<BOARD>_defconfig`
|
||||
|
||||
2. Any CMake cache entries prefix with ``CONFIG_``
|
||||
|
||||
|
@ -155,9 +155,6 @@ used.
|
|||
:file:`prj_<build>.conf`, the result of merging :file:`prj_<build>.conf` and
|
||||
:file:`boards/<BOARD>_<build>.conf` is used.
|
||||
|
||||
#. Otherwise, :file:`prj_<BOARD>.conf` is used if it exists in the application
|
||||
configuration directory.
|
||||
|
||||
#. Otherwise, if :file:`boards/<BOARD>.conf` exists in the application
|
||||
configuration directory, the result of merging it with :file:`prj.conf` is
|
||||
used.
|
||||
|
@ -200,7 +197,7 @@ Configuring invisible Kconfig symbols
|
|||
|
||||
When making changes to the default configuration for a board, you might have to
|
||||
configure invisible symbols. This is done in
|
||||
:file:`boards/<architecture>/<BOARD>/Kconfig.defconfig`, which is a regular
|
||||
:file:`boards/<VENDOR>/<BOARD>/Kconfig.defconfig`, which is a regular
|
||||
:file:`Kconfig` file.
|
||||
|
||||
.. note::
|
||||
|
|
|
@ -494,13 +494,11 @@ Make sure to follow these steps in order.
|
|||
as described in this step, this value will be used.
|
||||
|
||||
#. If your application uses a configuration file or files other than
|
||||
the usual :file:`prj.conf` (or :file:`prj_YOUR_BOARD.conf`, where
|
||||
``YOUR_BOARD`` is a board name), add lines setting the
|
||||
:makevar:`CONF_FILE` variable to these files appropriately.
|
||||
If multiple filenames are given, separate them by a single space or
|
||||
semicolon. CMake lists can be used to build up configuration fragment
|
||||
files in a modular way when you want to avoid setting :makevar:`CONF_FILE`
|
||||
in a single place. For example:
|
||||
the usual :file:`prj.conf`, add lines setting the :makevar:`CONF_FILE`
|
||||
variable to these files appropriately. If multiple filenames are given,
|
||||
separate them by a single space or semicolon. CMake lists can be used to
|
||||
build up configuration fragment files in a modular way when you want to
|
||||
avoid setting :makevar:`CONF_FILE` in a single place. For example:
|
||||
|
||||
.. code-block:: cmake
|
||||
|
||||
|
@ -1144,7 +1142,7 @@ where the ``boards`` directory hosts the board you are building for:
|
|||
|
||||
.
|
||||
├── boards
|
||||
│ └── x86
|
||||
│ └── vendor
|
||||
│ └── my_custom_board
|
||||
│ ├── doc
|
||||
│ │ └── img
|
||||
|
@ -1157,9 +1155,9 @@ supported by a SOC that is available in the Zephyr tree.
|
|||
Boards
|
||||
======
|
||||
|
||||
Use the proper architecture folder name (e.g., ``x86``, ``arm``, etc.)
|
||||
under ``boards`` for ``my_custom_board``. (See :ref:`boards` for a
|
||||
list of board architectures.)
|
||||
Use the vendor name as the folder name (which must match the vendor prefix in
|
||||
:zephyr_file:`dts/bindings/vendor-prefixes.txt` if submitting upstream to Zephyr, or be
|
||||
``others`` if it is not a vendor board) under ``boards`` for ``my_custom_board``.
|
||||
|
||||
Documentation (under ``doc/``) and support files (under ``support/``) are optional, but
|
||||
will be needed when submitting to Zephyr.
|
||||
|
@ -1174,9 +1172,8 @@ Zephyr board, and provide the following files::
|
|||
board.h
|
||||
CMakeLists.txt
|
||||
doc/
|
||||
Kconfig.board
|
||||
Kconfig.my_custom_board
|
||||
Kconfig.defconfig
|
||||
pinmux.c
|
||||
support/
|
||||
|
||||
|
||||
|
@ -1215,11 +1212,10 @@ the Zephyr tree, for example:
|
|||
.. code-block:: none
|
||||
|
||||
soc
|
||||
└── arm
|
||||
└── st_stm32
|
||||
├── common
|
||||
└── stm32l0
|
||||
|
||||
└── st
|
||||
└── stm32
|
||||
├── common
|
||||
└── stm32l0x
|
||||
|
||||
|
||||
The file :zephyr_file:`soc/Kconfig` will create the top-level
|
||||
|
@ -1235,8 +1231,9 @@ more SoCs into the menu.
|
|||
.. code-block:: none
|
||||
|
||||
soc
|
||||
└── arm
|
||||
└── st_stm32
|
||||
└── st
|
||||
└── stm32
|
||||
└── stm32l0x
|
||||
├── Kconfig
|
||||
├── Kconfig.soc
|
||||
└── Kconfig.defconfig
|
||||
|
@ -1248,17 +1245,17 @@ An example of loading ``stm31l0`` specific Kconfig files in this structure:
|
|||
.. code-block:: none
|
||||
|
||||
soc
|
||||
└── arm
|
||||
└── st_stm32
|
||||
├── Kconfig.soc
|
||||
└── stm32l0
|
||||
└── Kconfig.series
|
||||
└── st
|
||||
└── stm32
|
||||
├── Kconfig.soc
|
||||
└── stm32l0x
|
||||
└── Kconfig.soc
|
||||
|
||||
can be done with the following content in ``st_stm32/Kconfig.soc``:
|
||||
can be done with the following content in ``st/stm32/Kconfig.soc``:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
rsource "*/Kconfig.series"
|
||||
rsource "*/Kconfig.soc"
|
||||
|
||||
Once the SOC structure is in place, you can build your application
|
||||
targeting this platform by specifying the location of your custom platform
|
||||
|
|
Loading…
Reference in New Issue