In the source_file_format.txt file we talk about how to construct a valid FIT image. While it already says to look at the source for the full list, add kernel_noload to the explicit list of types. This is arguably the most important type to use as most often we are including a kernel that will run from wherever it is loaded into memory and execute.
This for example, allows you to create a single FIT image for Linux that can be used on both OMAP and i.MX devices as the kernel will not need to be moved in memory.
Signed-off-by: Tom Rini trini@konsulko.com --- doc/uImage.FIT/source_file_format.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/uImage.FIT/source_file_format.txt b/doc/uImage.FIT/source_file_format.txt index afff301c8859..136d3d7078ee 100644 --- a/doc/uImage.FIT/source_file_format.txt +++ b/doc/uImage.FIT/source_file_format.txt @@ -159,8 +159,8 @@ the '/images' node should have the following layout: Mandatory properties: - description : Textual description of the component sub-image - type : Name of component sub-image type, supported types are: - "standalone", "kernel", "ramdisk", "firmware", "script", "filesystem", - "flat_dt" and others (see uimage_type in common/image.c). + "standalone", "kernel", "kernel_noload", "ramdisk", "firmware", "script", + "filesystem", "flat_dt" and others (see uimage_type in common/image.c). - data : Path to the external file which contains this node's binary data. - compression : Compression used by included data. Supported compressions are "gzip" and "bzip2". If no compression is used compression property