1234567891011121314151617181920212223242526272829303132333435363738394041424344 |
- .. SPDX-License-Identifier: GPL-2.0+
- Devicetree Introduction
- =======================
- U-Boot uses a devicetree for configuration. This includes the devices used by
- the board, the format of the image created with binman, which UART to use for
- the console, public keys used for secure boot and many other things.
- See :doc:`control` for more information.
- Why does U-Boot put <thing> in the devicetree?
- ----------------------------------------------
- This question comes up a lot with people new to U-Boot, particular those coming
- from Linux who are used to quite strict rules about what can go into the
- devicetree.
- U-Boot uses the same devicetree as Linux but adds more things necessary for the
- bootloader environment (see :ref:`dttweaks`).
- U-Boot does not have a user space to provide policy and configuration. It cannot
- do what Linux does and run programs and look up filesystems to figure out how to
- boot. So configuration and runtime information goes into the devicetree in
- U-Boot.
- Of course it is possible to:
- - add tables into the rodata section of the U-Boot binary
- - append some info to the end of U-Boot in a different format
- - modify the linker script to bring in a file with some info in it
- - put things in ACPI tables
- - link in a UEFI hand-off block structure and put things in there
- but *please don't*. In general, devicetree is the sane place to hold U-Boot's
- configuration.
- So, please, do NOT ask why U-Boot puts <thing> in the devicetree. It is the only
- place it can go. It is a highly suitable data structure for just about anything
- that U-Boot needs to know at runtime.
- Note, it is possible to use platdata directly so drivers avoid devicetreee in
- SPL. But of-platdata is the modern way of avoiding devicetree overhead, so
- please use that instead.
|