Lines Matching +full:vendor +full:- +full:specific
21 - Support for multi-core, multi-arch AMP (Asymmetrical Multi Processing) SoCs
22 - Support for multi-SoC boards
23 - Support for reusing the SoC and board Kconfig trees outside of the Zephyr
25 - Support for advanced use cases with :ref:`sysbuild`
26 - Removal of all existing arbitrary and inconsistent uses of Kconfig and folder
38 Some non-critical features, enhancements and improvements of the new hardware
47 with two options if they have an out-of-tree board (or SoC):
49 #. Convert the out-of-tree board to the current hardware model (recommended)
57 can then use the `example-application conversion Pull Request`_ as an example on
59 and works reliably in many cases (though multi-core SoCs may not be handled
64 .. _hardware model v2 commit: https://github.com/zephyrproject-rtos/zephyr/commit/8dc3f856229ce083c…
65 .. _example-application conversion Pull Request: https://github.com/zephyrproject-rtos/example-appl…
66 .. _conversion script: https://github.com/zephyrproject-rtos/zephyr/blob/main/scripts/utils/board_v…
93 …--------------------------------------------+--------------------------+-------------+------------…
96 … | nRF52832 | nRF52 | Nordic nRF | Arm Cortex-M4 | ARMv7-M |
97 …--------------------------------------------+--------------------------+-------------+------------…
98 … | MK64F12 | Kinetis K6x | NXP Kinetis | Arm Cortex-M4 | ARMv7-M |
99 …--------------------------------------------+--------------------------+-------------+------------…
100 … | RV32M1 | (Not used) | (Not used) | RI5CY | RISC-V RV32 |
101 …--------------------------------------------+--------------------------+-------------+------------…
102 … | nRF5340 | nRF53 | Nordic nRF | Arm Cortex-M33 | ARMv8-M |
103 … +--------------------------+-------------+--------------------+--------------------+…
104 … | nRF5340 | nRF53 | Nordic nRF | Arm Cortex-M33 | ARMv8-M |
105 …--------------------------------------------+--------------------------+-------------+------------…
106 … | i.MX8M Plus | i.MX8M | NXP i.MX | Arm Cortex-A53 | ARMv8-A |
107 … +--------------------------+-------------+--------------------+--------------------+…
108 … | i.MX8M Plus | i.MX8M | NXP i.MX | Arm Cortex-M7 | ARMv7-M |
109 … +--------------------------+-------------+--------------------+--------------------+…
111 …--------------------------------------------+--------------------------+-------------+------------…
128 .. figure:: board/board-terminology.svg
137 - The :term:`board name`: ``bl5340_dvk``
138 - The optional :term:`board revision`: ``1.2.0``
139 - The :term:`board qualifiers`, that optionally describe the :term:`SoC`,
141 - The :term:`board target`, which uniquely identifies a combination of the above
149 If a board contains only one single-core SoC, then the SoC can be omitted from
153 by leaving it out but including the corresponding forward-slashes: ``//``.
157 the CPU clusters, ``cpuapp``, additionally defines a non-secure board variant,
163 - ``nrf5340``: The SoC, which is a Nordic nRF5340 dual-core SoC
164 - ``cpuapp``: The CPU cluster ``cpuapp``, which consists of a single Cortex-M33
167 - ``ns``: a variant, in this case ``ns`` is a common variant name is
168 Zephyr denoting a non-secure build for boards supporting :ref:`tfm`.
175 - ``thingy52``: board name.
176 - ``nrf52832``: The board qualifiers, in this case identical to the SoC, which
184 :ref:`create-your-board-directory`. If you don't know, try:
186 - checking :ref:`boards` for names that look relevant, and reading individual
188 - asking your SoC vendor
213 Zephyr SoC support files are in architecture-specific subdirectories of
216 When adding a new SoC family or series for a vendor that already has SoC
218 files to avoid duplication. If there is no support for your vendor yet, you can
219 add it in a new directory ``zephyr/soc/<VENDOR>/<YOUR-SOC>``; please use
220 self-explanatory directory names.
222 .. _create-your-board-directory:
235 Start by creating the board directory ``zephyr/boards/<VENDOR>/plank``, where
236 ``<VENDOR>`` is your vendor subdirectory. (You don't have to put your
242 A ``<VENDOR>`` subdirectory is mandatory if contributing your board
244 structure under ``<your-repo>/boards`` is permitted.
245 If the vendor is defined in the list in
246 :zephyr_file:`dts/bindings/vendor-prefixes.txt` then you must use
247 that vendor prefix as ``<VENDOR>``. ``others`` may be used as vendor prefix if
248 the vendor is not defined.
257 .. code-block:: none
259 boards/<VENDOR>/plank
276 #. :file:`board.yml`: a YAML file describing the high-level meta data of the
278 CPU clusters for multi-core SoCs are not described in this file as they are
282 in :ref:`devicetree <dt-guide>` format. This declares your SoC, connectors,
294 - :file:`Kconfig`, :file:`Kconfig.defconfig` software configuration in
297 - :file:`plank_defconfig` and :file:`plank_<qualifiers>_defconfig`: software
299 - :file:`board.cmake`: used for :ref:`flash-and-debug-support`
300 - :file:`CMakeLists.txt`: if you need to add additional source files to
302 - :file:`doc/index.rst`, :file:`doc/plank.webp`: documentation for and a picture
303 of your board. You only need this if you're :ref:`contributing-your-board` to
305 - :file:`plank_<qualifiers>.yaml`: a YAML file with miscellaneous metadata used
325 .. code-block:: yaml
328 name: <board-name>
329 vendor: <board-vendor>
332 default: <default-revision-value>
335 - name: <revA>
336 - name: <revB>
339 - name: <soc-1>
341 - name: <variant-1>
342 - name: <variant-2>
344 - name: <sub-variant-2-1>
346 - name: <soc-2>
353 .. code-block:: yaml
356 - name: <board-name-1>
357 vendor: <board-vendor>
359 - name: <board-name-2>
360 vendor: <board-vendor>
370 The devicetree file :file:`boards/<vendor>/plank/plank.dts` or
371 :file:`boards/<vendor>/plank/plank_<qualifiers>.dts` describes your board
373 your board's name). If you're new to devicetree, see :ref:`devicetree-intro`.
377 .. code-block:: devicetree
379 /dts-v1/;
393 * Your board-specific hardware: buttons, LEDs, sensors, etc.
397 compatible = "gpio-leds";
406 compatible = "gpio-keys";
425 Only one ``.dts`` file will be used, and the most specific file which exists
434 or write specific devicetree files for a given board's SoC or variant.
443 Example: FRDM-K64F and Hexiwear K64
452 The FRDM-K64F and Hexiwear K64 board devicetrees are defined in
461 :zephyr_file:`armv7-m.dtsi<dts/arm/armv7-m.dtsi>`, which has common definitions
462 for Arm v7-M cores.
465 generic across K6X-based boards, it leaves many devices disabled by default
469 .. code-block:: devicetree
479 files are also responsible for any board-specific configuration of the device,
480 such as adding nodes for on-board sensors, LEDs, buttons, etc.
482 For example, FRDM-K64 (but not Hexiwear K64) :file:`.dts` enables the CAN
485 .. code-block:: devicetree
494 Other examples of board-specific customization is pointing properties in
495 ``aliases`` and ``chosen`` to the right nodes (see :ref:`dt-alias-chosen`), and
513 .. code-block:: none
515 boards/<vendor>/plank
527 Kconfig settings. This file must not select anything outside the re-usable
532 .. code-block:: kconfig
544 This file can add Kconfig settings which are specific to the current board.
548 A board specific setting should be defining a custom setting and usually with
551 .. code-block:: kconfig
554 bool "Board specific feature"
561 Board-specific default values for Kconfig options.
568 .. code-block:: kconfig
583 A Kconfig fragment that is merged as-is into the final build directory
587 qualifiers specific :file:`plank_<qualifiers>_defconfig` files exist, then
591 place the adjustments specific for a given SoC or board variant in the
595 console, etc. The results are architecture-specific, but typically look
598 .. code-block:: cfg
604 A Kconfig fragment that is merged as-is into the final build directory
616 .. code-block:: console
618 west build -b plank samples/hello_world
621 For ``west flash`` to work, see :ref:`flash-and-debug-support` below. You can
625 .. _porting-general-recommendations:
631 that are not board specific for your board, please follow these guidelines
634 - Unless explicitly recommended otherwise by this section, leave peripherals
637 - Configure and enable a system clock, along with a tick source.
639 - Provide pin and driver configuration that matches the board's valuable
641 such as USB, Ethernet connector, or Bluetooth/Wi-Fi chip.
643 - If your board uses a well-known connector standard (like Arduino, Mikrobus,
647 - Configure components that enable the use of these pins, such as
650 - If available, configure and enable a serial output for the console
652 Development boards with a built-in debug adapter or USB-to-UART adapter should
662 - If your board supports networking, configure a default interface.
664 - Enable all GPIO ports connected to peripherals or expansion connectors.
666 - If available, enable pinmux and interrupt controller drivers.
668 - It is recommended to enable the MPU by default, if there is support for it
675 .. _flash-and-debug-support:
680 Zephyr supports :ref:`west-build-flash-debug` via west extension commands.
687 "Runners" are Zephyr-specific Python classes that wrap :ref:`flash and debug
688 host tools <flash-debug-host-tools>` and integrate with west and the zephyr build
694 .. code-block:: cmake
696 board_runner_args(jlink "--device=nrf52" "--speed=4000")
697 board_runner_args(pyocd "--target=nrf52" "--frequency=4000000")
708 runner wraps Segger's J-Link tools, and so on. But the runner command line
709 options like ``--speed`` etc. are specific to the Python scripts.
717 Linux) special udev rules installed, do not assume one specific ``/dev/X``
725 - Run ``west flash --context`` to see a list of available runners which support
726 flashing, and ``west flash --context -r <RUNNER>`` to view the specific options
728 - Run ``west debug --context`` and ``west debug --context <RUNNER>`` to get
730 - Run ``west flash --help`` and ``west debug --help`` for top-level options
732 - See :ref:`west-runner` for Python APIs.
733 - Look for :file:`board.cmake` files for other boards similar to your own for
739 .. code-block:: sh
741 west --verbose flash
742 west --verbose debug
763 .. code-block:: yaml
768 default: <default-revision-value>
771 - name: <revA>
772 - name: <revB>
776 - ``major.minor.patch``: match a three digit revision, such as ``1.2.3``.
777 - ``number``: matches integer revisions
778 - ``letter``: matches single letter revisions from ``A`` to ``Z`` only
794 .. code-block:: console
796 -- Board: plank, Revision: 0.7.0 (Active: 0.5.0)
814 .. code-block:: console
828 When building for a specific board revision, the above files are used as a
831 - :file:`<board>_<qualifiers>_<revision>_defconfig`: a specific revision
835 - :file:`<board>_<revision>_defconfig`: a specific revision defconfig which is
838 - :file:`<board>_<qualifiers>_<revision>.overlay`: a specific revision dts
842 - :file:`<board>_<revision>.overlay`: a specific revision dts overlay which is
845 This split allows boards with multiple SoCs, multi-core SoCs, or variants to
847 single file, while still providing the ability to place SoC or variant specific
853 .. code-block:: none
879 .. code-block:: yaml
902 .. _contributing-your-board:
907 If you want to contribute your board to Zephyr, first -- thanks!
911 #. Make sure you've followed all the :ref:`porting-general-recommendations`.
922 .. _extend-board:
937 :ref:`create-your-board-directory`.
941 .. code-block:: yaml
944 extend: <existing-board-name>
946 - name: <new-variant>
947 qualifier: <existing-qualifier>
951 .. code-block:: none
953 boards/<VENDOR>/plank
955 ├── plank_<new-qualifiers>_defconfig
956 └── plank_<new-qualifiers>.dts
965 .. code-block:: none
967 boards/<VENDOR>/plank
972 └── plank_<new-qualifiers>.yaml
981 feature described in :ref:`extend-board`.
984 ``example-application`` or vendor SDKs. In some situations, certain hardware
985 description or :ref:`choices <devicetree-chosen-nodes>` can not be added in the
991 Board extensions are board fragments that can be present in an out-of-tree board
995 .. code-block:: none
1008 ``-DBOARD_EXTENSIONS=OFF`` when building.
1011 :ref:`same guidelines <porting-general-recommendations>` as regular boards. For