path: root/Documentation
diff options
authorAhmad Fatoum <>2022-02-06 00:19:30 +0100
committerSascha Hauer <>2022-02-07 09:36:27 +0100
commitcd2f8d107728a919bddca09cf744c4c87463023b (patch)
tree026b95f72c98c9a35aa9d1e0f387fd1aa02072dc /Documentation
parent4a5c42b878db45a001d0ef93d2f9f5b6f9a5b78f (diff)
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 <> Link: Signed-off-by: Sascha Hauer <>
Diffstat (limited to 'Documentation')
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
+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