Hi Simon,
On 12/22/22 00:07, Simon Glass wrote:
These have got out of data recently. Regenerate them.
Signed-off-by: Simon Glass sjg@chromium.org
[...]
+.. _etype_u_boot_vpl:
+Entry: u-boot-vpl: U-Boot VPL binary +------------------------------------
+Properties / Entry arguments:
- filename: Filename of u-boot-vpl.bin (default 'vpl/u-boot-vpl.bin')
+This is the U-Boot VPL (Verifying Program Loader) binary. This is a small +binary which loads before SPL, typically into on-chip SRAM. It is +responsible for locating, loading and jumping to SPL, the next-stage +loader. Note that VPL is not relocatable so must be loaded to the correct +address in SRAM, or written to run from the correct address if direct +flash execution is possible (e.g. on x86 devices).
+SPL can access binman symbols at runtime. See:
- 'Access to binman entry offsets at run time (symbols)'
You can use a ref here since there exists a _binman_syms target in the README.rst.
+in the binman README for more information.
[...]
+.. _etype_u_boot_vpl_nodtb:
+Entry: u-boot-vpl-nodtb: VPL binary without device tree appended +----------------------------------------------------------------
+Properties / Entry arguments:
- filename: Filename to include (default 'vpl/u-boot-vpl-nodtb.bin')
+This is the U-Boot VPL binary, It does not include a device tree blob at +the end of it so may not be able to work without it, assuming VPL needs +a device tree to operate on your platform. You can add a u_boot_vpl_dtb +entry after this one, or use a u_boot_vpl entry instead, which normally +expands to a section containing u-boot-vpl-dtb, u-boot-vpl-bss-pad and +u-boot-vpl-dtb
+VPL can access binman symbols at runtime. See:
- 'Access to binman entry offsets at run time (symbols)'
Ditto.
Cheers, Quentin