u-boot.git/doc/uImage.FIT, branch v2021.04

doc: FIT image: Clarify format and simplify syntax

2021-01-22T21:17:33Z

** Introduction There are currently four ways to load an OS image with u-boot 1. SPL -> u-boot -> bootm 2. SPL blue falcon mode 3. "Basic" FIT image (CONFIG_LOAD_FIT) 4. "Full-featured" FIT image (CONFIG_LOAD_FIT_FULL) These four code paths were developed independently, and share very little code. (3) and (4), behave very differently, are littered with special cases. They even have different DTS syntax and properties. The cause of this divergence is that the FIT format specification leaves a number of things open to interpretation. The purpose of this change is to enable the reduction of code size, duplication, and complexity by updating and streamlining the FIT format. We are only marginally concerned with backwards compatibility, because we don't have inter-compatibility. For example, CONFIG_LOAD_FIT is able to load images that CONFIG_LOAD_FIT_FULL won't. This is a direct result of the incompatible syntax between the two implementations. Ideally, these changes would enable "simple" FIT to be a subset of the "full" fit implementation, and share most code. These changes should also eliminate the need for falcon mode (although we are not advocating for the removal of falcon mode at this time). ** Description of changes * The "configurations" node is now mandatory Guessing how to load components based on their "os" and "type" invites confusion and superfluous heuristics. Instead, require each FIT image to be explicit on how components should be loaded. * Eliminate "ramdisk", "setup", "standalone", and "fpga" properties Having too many special purpose properties requires special-casing FIT loading code. When a special property can be handled by another property, it is redundant. - A "ramdisk" is identical to a loadable. Thus ramdisk images should be placed under "loadables". - A "setup" node can be achieved by using a "kernel" or "firmware" property instead. - "standalone" is used for u-boot nodes. The correct property to use in this case is "firmware". - "fpga" is a loadable * Prioritize control between "firmware" and "kernel" "firmware" and "kernel" are special nodes in that control is passed to the "entry-point" of the image. Both can be present, for example, an OP-TEE firmware with a linux kernel. When both are present, control is passed to the "firmware" image. ** Further generalizations (not included herein) The "firmware" and "kernel" properties could be generalized as a "next-boot-stage", or similar name. This "next" stage would be special in that it is both executable, and is the stage that is passed control. For example, "next-stage" could be an op-tee image, with linux as a loadable, or a u-boot image. Signed-off-by: Alexandru Gagniuc

doc: Fix typo in FIT documentation

2020-12-18T10:46:36Z

u_boot should be u-boot Signed-off-by: Sean Anderson Reviewed-by: Bin Meng Reviewed-by: Jagan Teki

spl: Use standard FIT entries

2020-10-27T07:13:32Z

SPL is creating fit-images DT node when loadables are recorded in selected configuration. Entries which are created are using entry-point and load-addr property names. But there shouldn't be a need to use non standard properties because entry/load are standard FIT properties. But using standard FIT properties enables option to use generic FIT functions to descrease SPL size. Here is result for ZynqMP virt configuration: xilinx_zynqmp_virt: spl/u-boot-spl:all -82 spl/u-boot-spl:rodata -22 spl/u-boot-spl:text -60 The patch causes change in run time fit image record. Before: fit-images { uboot { os = "u-boot"; type = "firmware"; size = <0xfd520>; entry-point = <0x8000000>; load-addr = <0x8000000>; }; }; After: fit-images { uboot { os = "u-boot"; type = "firmware"; size = <0xfd520>; entry = <0x8000000>; load = <0x8000000>; }; }; Replacing calling fdt_getprop_u32() by fit_image_get_entry/load() also enables support for reading entry/load properties recorded in 64bit format. Signed-off-by: Michal Simek Reviewed-by: Simon Glass

doc: verified-boot: add required-mode information

2020-10-13T01:30:37Z

Add documentation about 'required-mode' property in /signature node in U-Boot's control FDT. Signed-off-by: Thirupathaiah Annapureddy Reviewed-by: Simon Glass

doc: fit: Write hex address as hex instead of int

2020-07-17T14:47:19Z

When update_uboot.its is used directly there is syntax error for no reason. Error report: mkimage -f update_uboot.its boot Error: update_uboot.its:18.12-13 syntax error FATAL ERROR: Unable to parse input tree mkimage: Can't read boot.tmp: Invalid argument Fixes: 4bae90904b69 ("Automatic software update from TFTP server") Signed-off-by: Michal Simek

arm: ti: Remove ARCH= references from documentation

2020-06-02T21:27:04Z

When building U-Boot we select the architecture via Kconfig and not ARCH being passed in via the environment or make cmdline. Cc: Lokesh Vutla Cc: Vitaly Andrianov Signed-off-by: Tom Rini

lib: rsa: avoid overriding the object name when already specified

2020-05-15T18:47:35Z

If "object=" is specified in "keydir" when using the pkcs11 engine do not append another "object=". This makes it possible to use object names other than the key name hint. These two string identifiers are not necessarily equal. Signed-off-by: Jan Luebbe Signed-off-by: Bastian Krause Reviewed-by: George McCollister

mkimage: fit_image: Add option to make fit header align

2020-04-24T14:10:01Z

The image is usually stored in block device like emmc, SD card, make the offset of image data aligned to block(512 byte) can avoid data copy during boot process. eg. SPL boot from FIT image with external data: - SPL read the first block of FIT image, and then parse the header; - SPL read image data separately; - The first image offset is the base_offset which is the header size; - The second image offset is just after the first image; - If the offset of imge does not aligned, SPL will do memcpy; The header size is a ramdon number, which is very possible not aligned, so add '-B size'to specify the align size in hex for better performance. example usage: ./tools/mkimage -E -f u-boot.its -B 0x200 u-boot.itb Signed-off-by: Kever Yang Reviewed-by: Punit Agrawal Reviewed-by: Tom Rini

doc: Add sample uefi.its image description file

2020-01-07T17:08:21Z

This patch adds an example FIT image description file demonstrating the usage of bootm command to securely launch UEFI binaries. Signed-off-by: Cristian Ciocaltea Reviewed-by: Heinrich Schuchardt

doc: fitImage: example of a signature node

2019-12-13T18:01:53Z

Describe that a signature node can be added to a binary device tree using the mkimage tool. Provide an example device tree node. Signed-off-by: Heinrich Schuchardt