doc: dts: move example to the right place
The K6X example is part of the wrong subsection (devicetree vs kconfig) currently. Move it up to the right place (the section which was recently renamed to "input and output files") Signed-off-by: Marti Bolivar <marti.bolivar@nordicsemi.no>
This commit is contained in:
parent
85fa523cf0
commit
9935fdd110
1 changed files with 55 additions and 55 deletions
|
@ -242,6 +242,61 @@ and are named ``dts_fixup.h``. These fixup files map the generated include
|
|||
information to the current driver/source usage. They exist for historical
|
||||
reasons; Zephyr is moving away from needing or using these files.
|
||||
|
||||
.. _dt_k6x_example:
|
||||
|
||||
Example: FRDM-K64F and Hexiwear K64
|
||||
===================================
|
||||
|
||||
.. Give the filenames instead of the full paths below, as it's easier to read.
|
||||
The cramped 'foo.dts<path>' style avoids extra spaces before commas.
|
||||
|
||||
The FRDM-K64F and Hexiwear K64 board devicetrees are defined in
|
||||
:zephyr_file:`frdm_k64fs.dts <boards/arm/frdm_k64f/frdm_k64f.dts>` and
|
||||
:zephyr_file:`hexiwear_k64.dts <boards/arm/hexiwear_k64/hexiwear_k64.dts>`
|
||||
respectively. Both boards have NXP SoCs from the same Kinetis SoC family, the
|
||||
K6X.
|
||||
|
||||
Common devicetree definitions for K6X are stored in :zephyr_file:`nxp_k6x.dtsi
|
||||
<dts/arm/nxp/nxp_k6x.dtsi>`, which is included by both board :file:`.dts`
|
||||
files. :zephyr_file:`nxp_k6x.dtsi<dts/arm/nxp/nxp_k6x.dtsi>` in turn includes
|
||||
:zephyr_file:`armv7-m.dtsi<dts/arm/armv7-m.dtsi>`, which has common definitions
|
||||
for Arm v7-M cores.
|
||||
|
||||
Since :zephyr_file:`nxp_k6x.dtsi<dts/arm/nxp/nxp_k6x.dtsi>` is meant to be
|
||||
generic across K6X-based boards, it leaves many devices disabled by default
|
||||
using ``status`` properties. For example, there is a CAN controller defined as
|
||||
follows (with unimportant parts skipped):
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
can0: can@40024000 {
|
||||
...
|
||||
status = "disabled";
|
||||
...
|
||||
};
|
||||
|
||||
It is up to the board :file:`.dts` or application overlay files to enable these
|
||||
devices as desired, by setting ``status = "okay"``. The board :file:`.dts`
|
||||
files are also responsible for any board-specific configuration of the device,
|
||||
such as adding nodes for on-board sensors, LEDs, buttons, etc.
|
||||
|
||||
For example, FRDM-K64 (but not Hexiwear K64) :file:`.dts` enables the CAN
|
||||
controller and sets the bus speed:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
&can0 {
|
||||
status = "okay";
|
||||
bus-speed = <125000>;
|
||||
};
|
||||
|
||||
The ``&can0 { ... };`` syntax adds/overrides properties on the node with label
|
||||
``can0``, i.e. the ``can@4002400`` node defined in the :file:`.dtsi` file.
|
||||
|
||||
Other examples of board-specific customization is pointing properties in
|
||||
``aliases`` and ``chosen`` to the right nodes (see :ref:`dt-alias-chosen`), and
|
||||
making GPIO/pinmux assignments.
|
||||
|
||||
.. _dt_vs_kconfig:
|
||||
|
||||
Devicetree vs Kconfig
|
||||
|
@ -298,61 +353,6 @@ There are two noteworthy **exceptions** to these rules:
|
|||
particular instance of a hardware device. This takes precedence over related
|
||||
Kconfig options which serve a similar purpose.
|
||||
|
||||
.. _dt_k6x_example:
|
||||
|
||||
Example: FRDM-K64F and Hexiwear K64
|
||||
===================================
|
||||
|
||||
.. Give the filenames instead of the full paths below, as it's easier to read.
|
||||
The cramped 'foo.dts<path>' style avoids extra spaces before commas.
|
||||
|
||||
The FRDM-K64F and Hexiwear K64 board devicetrees are defined in
|
||||
:zephyr_file:`frdm_k64fs.dts <boards/arm/frdm_k64f/frdm_k64f.dts>` and
|
||||
:zephyr_file:`hexiwear_k64.dts <boards/arm/hexiwear_k64/hexiwear_k64.dts>`
|
||||
respectively. Both boards have NXP SoCs from the same Kinetis SoC family, the
|
||||
K6X.
|
||||
|
||||
Common devicetree definitions for K6X are stored in :zephyr_file:`nxp_k6x.dtsi
|
||||
<dts/arm/nxp/nxp_k6x.dtsi>`, which is included by both board :file:`.dts`
|
||||
files. :zephyr_file:`nxp_k6x.dtsi<dts/arm/nxp/nxp_k6x.dtsi>` in turn includes
|
||||
:zephyr_file:`armv7-m.dtsi<dts/arm/armv7-m.dtsi>`, which has common definitions
|
||||
for Arm v7-M cores.
|
||||
|
||||
Since :zephyr_file:`nxp_k6x.dtsi<dts/arm/nxp/nxp_k6x.dtsi>` is meant to be
|
||||
generic across K6X-based boards, it leaves many devices disabled by default
|
||||
using ``status`` properties. For example, there is a CAN controller defined as
|
||||
follows (with unimportant parts skipped):
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
can0: can@40024000 {
|
||||
...
|
||||
status = "disabled";
|
||||
...
|
||||
};
|
||||
|
||||
It is up to the board :file:`.dts` or application overlay files to enable these
|
||||
devices as desired, by setting ``status = "okay"``. The board :file:`.dts`
|
||||
files are also responsible for any board-specific configuration of the device,
|
||||
such as adding nodes for on-board sensors, LEDs, buttons, etc.
|
||||
|
||||
For example, FRDM-K64 (but not Hexiwear K64) :file:`.dts` enables the CAN
|
||||
controller and sets the bus speed:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
&can0 {
|
||||
status = "okay";
|
||||
bus-speed = <125000>;
|
||||
};
|
||||
|
||||
The ``&can0 { ... };`` syntax adds/overrides properties on the node with label
|
||||
``can0``, i.e. the ``can@4002400`` node defined in the :file:`.dtsi` file.
|
||||
|
||||
Other examples of board-specific customization is pointing properties in
|
||||
``aliases`` and ``chosen`` to the right nodes (see :ref:`dt-alias-chosen`), and
|
||||
making GPIO/pinmux assignments.
|
||||
|
||||
Currently supported boards
|
||||
**************************
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue