doc: usage: cmd: load: null-block-device

Document the dispatch path added by the former commit

    fs: dispatch null_dev_desc_ok filesystems before lookup

Add a null-block-device interfaces section that:

  * lists the three fstypes that can benefit of it (semihosting, ubifs,
    sandbox) and the CONFIG option that builds each
  * explains the '-' convention for the unused <dev[:part]> field

Suggested-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Vincent Jardin <vjardin@free.fr>
Reviewed-by: Simon Glass <sjg@chromium.org>

doc/usage/cmd/load.rst

@@ -63,6 +63,39 @@ Example
     16 bytes read in 1 ms (15.6 KiB/s)
     =>
 
+Null-block-device interfaces
+----------------------------
+
+A few ``<interface>`` values have no underlying block device. Their
+filesystem implementations directly call a back-end (JTAG
+debugger, UBI volume, host running U-Boot under sandbox, ...) and
+ignore the ``<dev[:part]>`` field, which may be given as ``-``. So
+``load <iface> - <addr> <filename>`` works.
+
+semihosting
+    Read files from the host filesystem of an attached JTAG debugger
+    using the ARM semihosting protocol. Useful with OpenOCD.
+    Built when ``CONFIG_SEMIHOSTING=y``.
+
+ubifs
+    Read files from a UBIFS volume that has already been attached
+    and mounted with the ``ubi part`` + ``ubifsmount`` commands.
+    Built when ``CONFIG_CMD_UBIFS=y``.
+
+sandbox
+    Read files from the host filesystem the sandbox binary is
+    running under. Available on sandbox builds.
+
+The ``<dev[:part]>`` argument is conventionally written as ``-`` for
+these interfaces, to make it visible at the call site that the field
+is unused. The filesystem layer never looks at it.
+
+Example::
+
+    => load semihosting - ${kernel_addr_r} kernel.itb
+    9437184 bytes read in 412 ms (21.8 MiB/s)
+    =>
+
 Configuration
 -------------