Unlike barebox, U-Boot's go command doesn't have any provisions for cache handling and as such, bootstrapping barebox via go can cause stale data to be erroneously executed as instructions. The official documentation[1] suggests use of bootm instead, which does the necessary flushing and invalidation. Update our documentation accordingly. [1]: http://www.denx.de/wiki/view/DULG/UBootStandalone#Section_5.12.3. Signed-off-by: Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx> --- Documentation/user/barebox.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/user/barebox.rst b/Documentation/user/barebox.rst index 1927fe4efcc5..d82163a88634 100644 --- a/Documentation/user/barebox.rst +++ b/Documentation/user/barebox.rst @@ -206,12 +206,12 @@ 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 'go' command: +with U-Boot's ``bootm`` command: .. code-block:: console U-Boot: tftp $load_addr barebox.bin - U-Boot: go $load_addr + U-Boot: bootm $load_addr With barebox already running on your board, this can be used to chainload another barebox. For instance, if you mounted a TFTP server to ``/mnt/tftp`` -- 2.20.1 _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
