X-Git-Url: https://repo.jachan.dev/J-u-boot.git/blobdiff_plain/b27eeca112c1b9eef6f06a320a4310d766ac5659..ddec4cae624e48c3678ea856fa7d6292a7104238:/doc/develop/bootstd.rst

diff --git a/doc/develop/bootstd.rst b/doc/develop/bootstd.rst
index c47de273ab1..e8b90752f08 100644
--- 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