x86: apl: Use devicetree for FSP-M configuration
[oweals/u-boot.git] / doc / README.fdt-control
index 29fd56a815f8086d28e340f030b5a6e6b1755227..424d13fc5b11284fcf0fd36f837316467e74c5fb 100644 (file)
@@ -1,8 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
 #
 # Copyright (c) 2011 The Chromium OS Authors.
-#
-# SPDX-License-Identifier:     GPL-2.0+
-#
 
 Device Tree Control in U-Boot
 =============================
@@ -33,12 +31,6 @@ the features of each board in the device tree file, and have a single
 generic source base.
 
 To enable this feature, add CONFIG_OF_CONTROL to your board config file.
-It is currently supported on ARM, x86 and Microblaze - other architectures
-will need to add code to their arch/xxx/lib/board.c file to locate the
-FDT. Alternatively you can enable generic board support on your board
-(with CONFIG_SYS_GENERIC_BOARD) if this is available (as it is for
-PowerPC). For ARM, Tegra and Exynos5 have device trees available for
-common devices.
 
 
 What is a Flat Device Tree?
@@ -64,7 +56,11 @@ In case you are wondering, OF stands for Open Firmware.
 Tools
 -----
 
-To use this feature you will need to get the device tree compiler here:
+To use this feature you will need to get the device tree compiler. This is
+provided by U-Boot automatically. If you have a system version of dtc
+(typically in the 'device-tree-compiler' package), it is currently not used.
+
+If you want to build your own dtc, it is kept here:
 
        git://git.kernel.org/pub/scm/utils/dtc/dtc.git
 
@@ -126,16 +122,21 @@ the U-Boot image (including u-boot.bin). This is suitable for debugging
 and development only and is not recommended for production devices.
 
 If CONFIG_OF_SEPARATE is defined, then it will be built and placed in
-a u-boot.dtb file alongside u-boot.bin. A common approach is then to
+a u-boot.dtb file alongside u-boot-nodtb.bin. A common approach is then to
 join the two:
 
-       cat u-boot.bin u-boot.dtb >image.bin
+       cat u-boot-nodtb.bin u-boot.dtb >image.bin
 
 and then flash image.bin onto your board. Note that U-Boot creates
-u-boot-dtb.bin which does the above step for you also. If you are using
+u-boot-dtb.bin which does the above step for you also. Resulting
+u-boot.bin is a copy of u-boot-dtb.bin in this case. If you are using
 CONFIG_SPL_FRAMEWORK, then u-boot.img will be built to include the device
 tree binary.
 
+If CONFIG_OF_BOARD is defined, a board-specific routine will provide the
+device tree at runtime, for example if an earlier bootloader stage creates
+it and passes it to U-Boot.
+
 If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on
 startup. This is only useful for sandbox. Use the -d flag to U-Boot to
 specify the file to read.
@@ -174,20 +175,32 @@ After board configuration is done, fdt supported u-boot can be build in two ways
     $ make DEVICE_TREE=<dts-file-name>
 
 
-Configuration Options
----------------------
+Relocation, SPL and TPL
+-----------------------
+
+U-Boot can be divided into three phases: TPL, SPL and U-Boot proper.
 
-A number of run-time configuration options are provided in the /config node
-of the control device tree. You can access these using fdtdec_get_config_int(),
-fdtdec_get_config_bool() and fdtdec_get_config_string().
+The full device tree is available to U-Boot proper, but normally only a subset
+(or none at all) is available to TPL and SPL. See 'Pre-Relocation Support' and
+'SPL Support' in doc/driver-model/design.rst for more details.
 
-Available options are:
 
-silent-console
-       If present and non-zero, the console is silenced by default on boot.
+Using several DTBs in the SPL (CONFIG_SPL_MULTI_DTB)
+----------------------------------------------------
+In some rare cases it is desirable to let SPL be able to select one DTB among
+many. This usually not very useful as the DTB for the SPL is small and usually
+fits several platforms. However the DTB sometimes include information that do
+work on several platforms (like IO tuning parameters).
+In this case it is possible to use CONFIG_SPL_MULTI_DTB. This option appends to
+the SPL a FIT image containing several DTBs listed in SPL_OF_LIST.
+board_fit_config_name_match() is called to select the right DTB.
 
-no-keyboard
-       Tells U-Boot not to expect an attached keyboard with a VGA console
+If board_fit_config_name_match() relies on DM (DM driver to access an EEPROM
+containing the board ID for example), it possible to start with a generic DTB
+and then switch over to the right DTB after the detection. For this purpose,
+the platform code must call fdtdec_resetup(). Based on the returned flag, the
+platform may have to re-initiliaze the DM subusystem using dm_uninit() and
+dm_init_and_scan().
 
 
 Limitations