Searched full:devicetree (Results 1 – 25 of 1012) sorted by relevance
12345678910>>...41
| /Zephyr-Core-3.6.0/doc/build/dts/ |
| D | intro-scope-purpose.rst | 6 A *devicetree* is primarily a hierarchical data structure that describes
7 hardware. The `Devicetree specification`_ defines its source and binary
10 .. _Devicetree specification: https://www.devicetree.org/
12 Zephyr uses devicetree to describe:
17 As such, devicetree is both a hardware description language and a configuration
19 devicetree and Zephyr's other main configuration language, Kconfig.
21 There are two types of devicetree input files: *devicetree sources* and
22 *devicetree bindings*. The sources contain the devicetree itself. The bindings
24 <build_overview>` uses devicetree sources and bindings to produce a generated C
25 header. The generated header's contents are abstracted by the ``devicetree.h``
[all …]
|
| D | index.rst | 3 Devicetree chapter
6 A *devicetree* is a hierarchical data structure primarily used to describe
7 hardware. Zephyr uses devicetree in two main ways:
12 This page links to a high level guide on devicetree as well as reference
17 Devicetree Guide
20 The pages in this section are a high-level guide to using devicetree for Zephyr
38 Devicetree Reference
41 These pages contain reference material for Zephyr's devicetree APIs and
44 For the platform-independent details, see the `Devicetree specification`_.
46 .. _Devicetree specification: https://www.devicetree.org/
|
| D | dt-vs-kconfig.rst | 3 Devicetree versus Kconfig
6 Along with devicetree, Zephyr also uses the Kconfig language to configure the
7 source code. Whether to use devicetree or Kconfig for a particular purpose can
12 * Use devicetree to describe **hardware** and its **boot-time configuration**.
19 In other words, devicetree mainly deals with hardware, and Kconfig with
26 nodes in the devicetree. These provide the UART type (via the ``compatible``
30 devicetree. This could include configuration such as the RX IRQ line's
32 their boot-time configuration is described in devicetree.
36 board's devicetree still includes UART nodes.
41 * Devicetree should be used to describe the presence of the radio **hardware**,
[all …]
|
| D | intro-input-output.rst | 7 :ref:`devicetree-scope-purpose` in more detail.
12 Devicetree input (green) and output (yellow) files
19 There are four types of devicetree input files:
26 The devicetree files inside the :file:`zephyr` directory look like this:
46 include file for defining a complete devicetree. Architecture-specific
50 The C preprocessor is run on all devicetree files to expand macro references,
56 their purpose clear. Overlays adapt the base devicetree for different purposes:
68 :ref:`set-devicetree-overlays` for details.
72 allows merging overlapping definitions of nodes in the devicetree. See
79 the contents of devicetree sources, includes, and overlays in a way that allows
[all …]
|
| D | howtos.rst | 3 Devicetree HOWTOs
6 This page has step-by-step advice for getting things done with devicetree.
10 .. _get-devicetree-outputs:
12 Get your devicetree and generated header
15 A board's devicetree (:ref:`BOARD.dts <devicetree-in-out-files>`) pulls in
17 includes the SoC's ``.dtsi``. One way to figure out the devicetree's contents
21 If you just want to see the "final" devicetree for your board, build an
26 You can build :ref:`hello_world` to see the "base" devicetree for your board
47 The :file:`zephyr.dts` file is the final devicetree in DTS format.
51 See :ref:`devicetree-in-out-files` for details about these files.
[all …]
|
| D | design.rst | 6 Zephyr's use of devicetree has evolved significantly over time, and further
15 configurable hardware descriptions from devicetree.
20 - New device drivers shall use devicetree APIs to determine which :ref:`devices
29 devicetree-based pinctrl driver
36 devicetree instead.
39 particular compatible are enabled. This can and should be done with devicetree
44 board level devicetree instead.
47 information obtained from devicetree, e.g. for device power management.
54 Zephyr's devicetree tooling is based on a generic layer which is interoperable
55 with other devicetree users, such as the Linux kernel.
[all …]
|
| D | intro-syntax-structure.rst | 6 As the name indicates, a devicetree is a tree. The human-readable text format
7 for this tree is called DTS (for devicetree source), and is defined in the
8 `Devicetree specification`_.
10 .. _Devicetree specification: https://www.devicetree.org/
12 This page's purpose is to introduce devicetree in a more gradual way than the
24 .. code-block:: devicetree
42 Like any tree data structure, a devicetree has a hierarchy of *nodes*.
54 can use node labels to refer to the node elsewhere in the devicetree.
56 Devicetree nodes have *paths* identifying their locations in the tree. Like
57 Unix file system paths, devicetree paths are strings separated by slashes
[all …]
|
| D | bindings.rst | 3 Devicetree bindings
6 A devicetree on its own is only half the story for describing hardware, as it
7 is a relatively unstructured format. *Devicetree bindings* provide the other
10 A devicetree binding declares requirements on the contents of nodes, and
12 devicetree bindings are YAML files in a custom format (Zephyr does not use the
|
| D | troubleshooting.rst | 3 Troubleshooting devicetree
6 Here are some tips for fixing misbehaving devicetree related code.
20 This is general advice which is especially applicable to debugging devicetree
24 Make sure <devicetree.h> is included
27 Unlike Kconfig symbols, the :file:`devicetree.h` header must be included
30 Many Zephyr header files rely on information from devicetree, so including some
31 other API may transitively include :file:`devicetree.h`, but that's not
44 no device driver has allocated a ``struct device`` for this devicetree node.
67 To find the devicetree node you need to check, use the number ``<N>`` from the
92 devicetree for your application build. (See :ref:`get-devicetree-outputs` for
[all …]
|
| D | zephyr-user-node.rst | 7 Zephyr's devicetree scripts handle the ``/zephyr,user`` node as a special case:
21 be configurable at build time via devicetree.
23 For example, with this devicetree overlay:
25 .. code-block:: devicetree
56 using devicetree overlays.
58 For example, with this devicetree overlay:
60 .. code-block:: devicetree
101 GPIOs that you want to be able to reconfigure with a devicetree overlay.
103 For example, with this devicetree overlay:
105 .. code-block:: devicetree
|
| D | api-usage.rst | 3 Devicetree access from C/C++
6 This guide describes Zephyr's ``<zephyr/devicetree.h>`` API for reading the
7 devicetree from C source files. It assumes you're familiar with the concepts in
8 :ref:`devicetree-intro` and :ref:`dt-bindings`. See :ref:`dt-reference` for
14 Linux developers familiar with devicetree should be warned that the API
15 described here differs significantly from how devicetree is used on Linux.
17 Instead of generating a C header with all the devicetree data which is then
19 devicetree data structure in its binary form. The binary representation is
22 Zephyr does not work this way because the size of the devicetree binary and
31 To get information about a particular devicetree node, you need a *node
[all …]
|
| /Zephyr-Core-3.6.0/include/zephyr/drivers/i3c/ |
| D | devicetree.h | 11 * @brief I3C Devicetree related bits
12 * @defgroup i3c_devicetree I3C Devicetree related bits
27 * @brief Structure initializer for i3c_device_id from devicetree
30 * i3c_device_id</tt> by reading the relevant device data from devicetree.
32 * @param node_id Devicetree node identifier for the I3C device whose
42 * @brief Structure initializer for i3c_device_id from devicetree instance
47 * @param inst Devicetree instance number
53 * @brief Structure initializer for i3c_device_desc from devicetree
57 * from the devicetree.
59 * @param node_id Devicetree node identifier for the I3C device whose
[all …]
|
| /Zephyr-Core-3.6.0/doc/build/dts/api/ |
| D | api.rst | 3 Devicetree API
6 This is a reference page for the ``<zephyr/devicetree.h>`` API. The API is macro
30 A *node identifier* is a way to refer to a devicetree node at C preprocessor
32 devicetree data in C rvalue form using, for example, the
33 :ref:`devicetree-property-access` API.
36 identifiers for other devicetree nodes using :c:func:`DT_PATH`,
45 .. doxygengroup:: devicetree-generic-id
53 There are special-purpose APIs for accessing the :ref:`devicetree-ranges-property`,
54 :ref:`devicetree-reg-property` and :ref:`devicetree-interrupts-property`.
59 .. doxygengroup:: devicetree-generic-prop
[all …]
|
| /Zephyr-Core-3.6.0/scripts/dts/ |
| D | README.txt | 5 The libraries and tests have now been moved to the 'python-devicetree'
14 https://pypi.org/project/devicetree/
15 https://python-devicetree.readthedocs.io/en/latest/
16 https://github.com/zephyrproject-rtos/python-devicetree
18 The 'python-devicetree' subdirectory you find here next to this
19 README.txt matches the standalone python-devicetree repository linked
27 devicetree.edtlib from now on, but the code will continue to be found
30 Eventually, as APIs stabilize, the python-devicetree code in this
|
| /Zephyr-Core-3.6.0/tests/lib/devicetree/memory_region/ |
| D | testcase.yaml | 3 libraries.devicetree.memory_region:
5 tags: devicetree
7 libraries.devicetree.memory_region.linker_generator:
9 tags: devicetree
|
| /Zephyr-Core-3.6.0/samples/basic/custom_dts_binding/ |
| D | README.rst | 2 :name: GPIO with custom Devicetree binding
3 :relevant-api: gpio_interface devicetree-generic-id devicetree-generic-exist
5 Use custom Devicetree binding to control a GPIO.
10 In Zephyr, all hardware-specific configuration is described in the devicetree.
12 Consequently, also GPIO pins are configured in the devicetree and assigned to a specific purpose
21 This sample demonstrates how to use a GPIO pin for other purposes with a custom devicetree binding.
24 custom devicetree binding for the power output controlled via a GPIO pin is specified in the file
|
| /Zephyr-Core-3.6.0/cmake/modules/ |
| D | dts.cmake | 12 # This module makes information from the devicetree available to
16 # defined in <zephyr/devicetree.h>
22 # - To users as a final devicetree source (DTS) file which can
26 # devicetree extensions defined in cmake/modules/extensions.cmake
35 # We rely on the C preprocessor, the devicetree python package, and
46 # - DTS_SOURCE: set to the path to the devicetree file which
50 # 2. The following has happened if a devicetree was found and
60 # - the build system will be regenerated if any devicetree files
62 # - the devicetree extensions in the extensions.cmake module
74 # devicetree overlay file in BOARD_DIR
[all …]
|
| /Zephyr-Core-3.6.0/samples/basic/blinky/ |
| D | README.rst | 14 #. Get a pin specification from the :ref:`devicetree <dt-guide>` as a
30 #. Have the LED configured using the ``led0`` devicetree alias.
63 To add support for your board, add something like this to your devicetree:
87 in devicetree.
90 use the same SoC as your target. See :ref:`get-devicetree-outputs` for details.
93 in devicetree.
96 your :ref:`BOARD.dts file <devicetree-in-out-files>`. Otherwise, you can
97 define one in a :ref:`devicetree overlay <set-devicetree-overlays>`.
|
| /Zephyr-Core-3.6.0/samples/basic/button/ |
| D | README.rst | 19 The button must be configured using the ``sw0`` :ref:`devicetree <dt-guide>`
20 alias, usually in the :ref:`BOARD.dts file <devicetree-in-out-files>`. You will
25 Unsupported board: sw0 devicetree alias is not defined
30 The sample additionally supports an optional ``led0`` devicetree alias. This is
35 Devicetree details
38 This section provides more details on devicetree configuration.
40 Here is a minimal devicetree fragment which supports this sample. This only
44 .. code-block:: devicetree
70 As shown, the ``sw0`` devicetree alias must point to a child node of a node
81 node, and that the GPIO controller's devicetree binding names those two cells
|
| /Zephyr-Core-3.6.0/samples/basic/rgb_led/ |
| D | README.rst | 14 indicated in Devicetree. Such period should be fast enough to be above the
25 The LED PWM channels must be configured using the following :ref:`devicetree
27 <devicetree-in-out-files>`:
38 Unsupported board: red-pwm-led devicetree alias is not defined
39 Unsupported board: green-pwm-led devicetree alias is not defined
40 Unsupported board: blue-pwm-led devicetree alias is not defined
48 No additional wiring is necessary if the required devicetree aliases refer to
|
| /Zephyr-Core-3.6.0/soc/xtensa/intel_adsp/common/include/ |
| D | intel_adsp_ipc_devtree.h | 7 #include <zephyr/devicetree.h>
18 * devicetree (if one exists!). The device will be initialized and
26 * This macro retrieves host IPC register address from devicetree.
38 * This macro retrieves IDC register address from devicetree.
|
| /Zephyr-Core-3.6.0/soc/arm/atmel_sam/common/ |
| D | atmel_sam_dt.h | 8 * @brief Atmel SAM MCU family devicetree helper macros
14 #include <zephyr/devicetree.h>
16 /* Devicetree macros related to clock */
|
| /Zephyr-Core-3.6.0/include/zephyr/devicetree/ |
| D | can.h | 3 * @brief CAN devicetree macro public API header file.
20 * @defgroup devicetree-can Devicetree CAN API
21 * @ingroup devicetree
29 * controller. If no CAN transceiver is present in the devicetree, the maximum
32 * Example devicetree fragment:
|
| /Zephyr-Core-3.6.0/snippets/cdc-acm-console/ |
| D | README.rst | 14 which should be used is configured using :ref:`devicetree`.
27 A devicetree node with node label ``zephyr_udc0`` that points to an enabled USB
29 :ref:`your devicetree <get-devicetree-outputs>`:
|
| /Zephyr-Core-3.6.0/doc/hardware/porting/ |
| D | shields.rst | 26 * **<shield>.overlay**: This file provides a shield description in devicetree
27 format that is merged with the board's :ref:`devicetree <dt-guide>`
41 board level, it is advised, specifically for shields devicetree descriptions,
44 .. code-block:: devicetree
64 * Devicetree: A board :ref:`devicetree <dt-guide>` file,
68 .. code-block:: devicetree
151 node`_ that looks like the following into the board devicetree file:
154 …https://github.com/devicetree-org/devicetree-specification/blob/4b1dac80eaca45b4babf5299452a951008…
156 .. code-block:: devicetree
193 devicetree. In some cases it's necessary to use a non-zero flag value
[all …]
|
12345678910>>...41
