u-boot.git/doc/uImage.FIT/source_file_format.txt, branch master

doc: Convert FIT source-file format to rST

2023-06-23T14:28:12+00:00

Move this document and convert it to rST. Make minimal changes, enough
for it to build successfully.

Future patches will tidy this up.

Signed-off-by: Simon Glass

cmd: source: Support specifying config name

2022-12-31T18:35:19+00:00

As discussed previously [1,2], the source command is not safe to use with
verified boot unless there is a key with required = "images" (which has its
own problems). This is because if such a key is absent, signatures are
verified but not required. It is assumed that configuration nodes will
provide the signature. Because the source command does not use
configurations to determine the image to source, effectively no
verification takes place.

To address this, allow specifying configuration nodes. We use the same
syntax as the bootm command (helpfully provided for us by fit_parse_conf).
By default, we first try the default config and then the default image. To
force using a config, # must be present in the command (e.g. `source
$loadaddr#my-conf`). For convenience, the config may be omitted, just like
the address may be (e.g. `source \#`). This also works for images
(`source :` behaves exactly like `source` currently does).

[1] https://lore.kernel.org/u-boot/7d711133-d513-5bcb-52f2-a9dbaa9eeded@prevas.dk/
[2] https://lore.kernel.org/u-boot/042dcb34-f85f-351e-1b0e-513f89005fdd@gmail.com/

Signed-off-by: Sean Anderson 
Reviewed-by: Simon Glass

image: Add the concept of a phase to FIT

2022-10-31T15:02:44+00:00

We want to be able to mark an image as related to a phase, so we can
easily load all the images for SPL or for U-Boot proper.

Add this to the FIT specification, along with some access functions.

Signed-off-by: Simon Glass

treewide: Drop image_header_t typedef

2022-09-29T20:07:57+00:00

This is not needed and we should avoid typedefs. Use the struct instead
and rename it to indicate that it really is a legacy struct.

Signed-off-by: Simon Glass

fpga: zynqmp: support loading encrypted bitfiles

2022-07-26T07:34:21+00:00

Add supporting new compatible string "u-boot,zynqmp-fpga-enc" to
handle loading encrypted bitfiles.

This feature requires encrypted FSBL, as according to UG1085:
"The CSU automatically locks out the AES key, stored in either BBRAM
 or eFUSEs, as a key source to the AES engine if the FSBL is not
 encrypted. This prevents using the BBRAM or eFUSE as the key source
 to the AES engine during run-time applications."

Signed-off-by: Adrian Fiergolski 
Co-developed-by: Oleksandr Suvorov 
Signed-off-by: Oleksandr Suvorov 
Tested-by: Adrian Fiergolski 
Link: https://lore.kernel.org/r/20220722141614.297383-14-oleksandr.suvorov@foundries.io
Signed-off-by: Michal Simek

fpga: zynqmp: support loading authenticated images

2022-07-26T07:34:21+00:00

Add supporting new compatible string "u-boot,zynqmp-fpga-ddrauth" to
handle loading authenticated images (DDR).

Based on solution by Jorge Ramirez-Ortiz 

Signed-off-by: Oleksandr Suvorov 
Tested-by: Ricardo Salveti 
Link: https://lore.kernel.org/r/20220722141614.297383-13-oleksandr.suvorov@foundries.io
Signed-off-by: Michal Simek

doc: FIT image: Introduce "u-boot, fpga-legacy" property

2021-04-14T19:23:01+00:00

Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify
syntax") introduced a "compatible" property for loadable images.
It did not define its contents. Use "u-boot,fpga-legacy" compatible
string to specify that fpga_load() should be used to load the image.

Signed-off-by: Alexandru Gagniuc

doc: FIT image: Clarify format and simplify syntax

2021-01-22T21:17:33+00:00

** 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:36+00:00

u_boot should be u-boot

Signed-off-by: Sean Anderson 
Reviewed-by: Bin Meng 
Reviewed-by: Jagan Teki

mkimage: fit_image: Add option to make fit header align

2020-04-24T14:10:01+00:00

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