| Message ID | 1500401659-5836-1-git-send-email-trini@konsulko.com |
|---|---|
| State | Accepted |
| Commit | 25fa0b930fc43fd147d9d4951cb379fa73abf33b |
| Delegated to: | Tom Rini |
| Headers | show |
On Tue, Jul 18, 2017 at 02:14:19PM -0400, Tom Rini wrote: > 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> Applied to u-boot/master, thanks!
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
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(-)