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>

doc/build/kconfig/setting.rst

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

doc/develop/application/index.rst

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