Documentation: user: barebox: mention generic dt 2nd stage support

Most users interested in chainloading barebox will probably want to use
the generic DT format for that: It will pass the checks the boot command
may have and it will ensure the system is in the correct state, e.g.
that caches are disabled.

Signed-off-by: Ahmad Fatoum <ahmad@a3f.at>
Link: https://lore.barebox.org/20220205231930.2948516-2-ahmad@a3f.at
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

1 files changed, 15 insertions, 3 deletions

diff --git a/Documentation/user/barebox.rst b/Documentation/user/barebox.rst
index 8634d8e48e..4abcf79c6d 100644
--- a/Documentation/user/barebox.rst
+++ b/Documentation/user/barebox.rst
@@ -203,9 +203,21 @@ Starting barebox
 Bringing barebox to a board for the first time is highly board specific, see your
 board documentation for initial bringup.
 
-barebox binaries are, where possible, designed to be startable second stage from another
-bootloader. For example, if you have U-Boot running on your board, you can start barebox
-with U-Boot's ``bootm`` command:
+For ARM and RISC-V, the barebox build can additionally generate a generic DT image
+(enable ``CONFIG_BOARD_ARM_GENERIC_DT`` or ``CONFIG_BOARD_RISCV_GENERIC_DT``,
+respectively). The resulting ``images/barebox-dt-2nd.img`` can be booted just
+like a Linux kernel that is passed an external device tree. For example:
+
+.. code-block:: console
+
+  U-Boot: tftp $kernel_addr barebox-dt-2nd.img
+  U-Boot: tftp $fdt_addr my-board.dtb
+  U-Boot: booti $kernel_addr - $fdt_addr
+
+For non-DT enabled-bootloaders or other architectures, often the normal barebox
+binaries can also be used as they are designed to be startable second stage
+from another bootloader, where possible. For example, if you have U-Boot running
+on your board, you can start barebox with U-Boot's ``bootm`` command:
 
 .. code-block:: console