Re: [RFC v4 1/2] doc: Remove FIT documentation that is elsewhere

[Simon Glass]

On Mon, 8 Jul 2024 at 17:48, Sam Povilus  wrote:
>
> FIT documentation is now a separate project, instead of having a
> duplicate, we should point at the other project.
>
> Signed-off-by: Sam Povilus 
> ---
>  doc/usage/fit/index.rst  |   4 +-
>  doc/usage/fit/source_file_format.rst | 682 +--
>  2 files changed, 5 insertions(+), 681 deletions(-)
>

Reviewed-by: Simon Glass 

[RFC v4 1/2] doc: Remove FIT documentation that is elsewhere

[Sam Povilus]

FIT documentation is now a separate project, instead of having a
duplicate, we should point at the other project.

Signed-off-by: Sam Povilus 
---
 doc/usage/fit/index.rst  |   4 +-
 doc/usage/fit/source_file_format.rst | 682 +--
 2 files changed, 5 insertions(+), 681 deletions(-)

diff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst
index bd25bd30b2..52b7d90bbc 100644
--- a/doc/usage/fit/index.rst
+++ b/doc/usage/fit/index.rst
@@ -4,8 +4,8 @@ Flat Image Tree (FIT)
 =
 
 U-Boot uses Flat Image Tree (FIT) as a standard file format for packaging
-images that it it reads and boots. Documentation about FIT is available at
-doc/uImage.FIT
+images that it reads and boots. Documentation about FIT is available in 
+`the Flattened Image Tree project `_.
 
 .. toctree::
 :maxdepth: 1
diff --git a/doc/usage/fit/source_file_format.rst 
b/doc/usage/fit/source_file_format.rst
index b2b1e42bd7..0c44329a82 100644
--- a/doc/usage/fit/source_file_format.rst
+++ b/doc/usage/fit/source_file_format.rst
@@ -3,682 +3,6 @@
 Flattened Image Tree (FIT) Format
 =
 
-Introduction
-
-
-The number of elements playing a role in the kernel booting process has
-increased over time and now typically includes the devicetree, kernel image and
-possibly a ramdisk image. Generally, all must be placed in the system memory 
and
-booted together.
-
-For firmware images a similar process has taken place, with various binaries
-loaded at different addresses, such as ARM's ATF, OpenSBI, FPGA and U-Boot
-itself.
-
-FIT provides a flexible and extensible format to deal with this complexity. It
-provides support for multiple components. It also supports multiple
-configurations, so that the same FIT can be used to boot multiple boards, with
-some components in common (e.g. kernel) and some specific to that board (e.g.
-devicetree).
-
-Terminology
-~~~
-
-This document defines FIT by providing FDT (Flat Device Tree) bindings. These
-describe the final form of the FIT at the moment when it is used. The user
-perspective may be simpler, as some of the properties (like timestamps and
-hashes) are filled in automatically by the U-Boot mkimage tool.
-
-To avoid confusion with the kernel FDT the following naming convention is used:
-
-FIT
-Flattened Image Tree
-
-FIT is formally a flattened devicetree (in the libfdt meaning), which conforms
-to bindings defined in this document.
-
-.its
-image tree source
-
-.itb
-flattened image tree blob
-
-Image-building procedure
-
-
-The following picture shows how the FIT is prepared. Input consists of
-image source file (.its) and a set of data files. Image is created with the
-help of standard U-Boot mkimage tool which in turn uses dtc (device tree
-compiler) to produce image tree blob (.itb). The resulting .itb file is the
-actual binary of a new FIT::
-
-tqm5200.its
-+
-vmlinux.bin.gz mkimage + dtc   xfer to target
-eldk-4.2-ramdisk  --> tqm5200.itb --> boot
-tqm5200.dtb  /|\
-  |
- 'new FIT'
-
-Steps:
-
-#. Create .its file, automatically filled-in properties are omitted
-
-#. Call mkimage tool on a .its file
-
-#. mkimage calls dtc to create .itb image and assures that
-   missing properties are added
-
-#. .itb (new FIT) is uploaded onto the target and used therein
-
-
-Unique identifiers
-~~
-
-To identify FIT sub-nodes representing images, hashes, configurations (which
-are defined in the following sections), the "unit name" of the given sub-node
-is used as it's identifier as it assures uniqueness without additional
-checking required.
-
-
-External data
-~
-
-FIT is normally built initially with image data in the 'data' property of each
-image node. It is also possible for this data to reside outside the FIT itself.
-This allows the 'FDT' part of the FIT to be quite small, so that it can be
-loaded and scanned without loading a large amount of data. Then when an image 
is
-needed it can be loaded from an external source.
-
-External FITs use 'data-offset' or 'data-position' instead of 'data'.
-
-The mkimage tool can convert a FIT to use external data using the `-E` 
argument,
-optionally using `-p` to specific a fixed position.
-
-It is often desirable to align each image to a block size or cache-line size
-(e.g. 512 bytes), so that there is no need to copy it to an aligned address 
when
-reading the image data. The mkimage tool provides a `-B` argument to support
-this.
-
-Root-node properties
-
-
-The root node of the FIT should have the following layout::
-
-/ o image-tree
-|- description = "image description"
-|- timestamp = <12399321>
-|- #address-cells = <1>
-|
-o