[PATCH] doc: FIT image: Clarify format and simplify syntax

[Tom Rini]

On Tue, Dec 15, 2020 at 01:15:43PM -0600, Alexandru Gagniuc wrote:

> ** 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 <mr.nuke.me at gmail.com>

Applied to u-boot/master, thanks!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210123/967adb13/attachment.sig>