Merge tag 'v2023.10-rc4' into next

[J-u-boot.git] / doc / develop / bootstd.rst

diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index c47de273ab18543c46d7d9bcc6773541ed5d17ee..e8b90752f0831c2e703cc07868d6dff9f10974ad 100644 (file)
--- a/doc/develop/bootstd.rst
+++ b/doc/develop/bootstd.rst
@@ -683,11 +683,12 @@ Assuming the bootmeth is happy, or at least indicates that it is willing to try
 partition. If that works it tries to detect a file system. If that works then it
 calls the bootmeth device once more, this time to read the bootflow.
 
-Note: At present a filesystem is needed for the bootmeth to be called on block
-devices, simply because we don't have any examples where this is not the case.
-This feature can be added as needed. Note that sandbox is a special case, since
-in that case the host filesystem can be accessed even though the block device
-is NULL.
+Note: Normally a filesystem is needed for the bootmeth to be called on block
+devices, but bootmeths which don't need that can set the BOOTMETHF_ANY_PART
+flag to indicate that they can scan any partition. An example is the ChromiumOS
+bootmeth which can store a kernel in a raw partition. Note also that sandbox is
+a special case, since in that case the host filesystem can be accessed even
+though the block device is NULL.
 
 If we take the example of the `bootmeth_extlinux` driver, this call ends up at
 `extlinux_read_bootflow()`. It has the filesystem ready, so tries various