When one xPL phase wants to jump to the next, the next phase must be
loaded into its required address. This means that the TEXT_BASE for the
two phases must be different and there cannot be any memory overlap
between the code used by the two phases. It also can mean that phases
need to be moved around to accommodate any size growth.

Having two xPL phases in SRAM at the same time can be tricky if SRAM
is limited, which it often is. It would be better if the second phase
could be loaded somewhere else, then decompressed into place over the
top of the first phase.

Introduce a relocating jump for xPL to support this. This selects a
suitable place to load the (typically compressed) next phase, copies
some decompression code out of the first phase, then jumps to this code
to decompress and start the next phase.

This feature makes it much easier to support Verified Boot for Embedded
(VBE) on RK3399 boards, which have 192KB of SRAM.

Signed-off-by: Simon Glass <sjg@chromium.org>

Use PHASE_ as the symbol to select a particular XPL build. This means
that SPL_TPL_ is no-longer set.

Update the comment in bootstage to refer to this symbol, instead of
SPL_

Signed-off-by: Simon Glass <sjg@chromium.org>

Complete this rename for all directories outside arch/ board/ drivers/
and include/

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass <sjg@chromium.org>

Add the basic code to create a handoff structure in SPL, so it can be
passed to the next phase. For now this is not plumbed in.

Signed-off-by: Simon Glass <sjg@chromium.org>

Replace instances of http://www.ti.com with https://www.ti.com

Signed-off-by: Nishanth Menon <nm@ti.com>

To facilitate testing loading i.MX8 container images, move the
parse-container code to common/spl.

Signed-off-by: Sean Anderson <seanga2@gmail.com>

Add support to load the next stage image from an NVMe disk which may
be formatted as an EXT or FAT filesystem.

Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>
[trini: Drop hunk changing disk/part.c as that breaks other users]
Signed-off-by: Tom Rini <trini@konsulko.com>

Add a generic API to support loading of SPL payload from any supported
filesystem on a given partition of a block device.

Signed-off-by: Mayuresh Chitale <mchitale@ventanamicro.com>

This matches what this support is called in the non-SPL case. The postfix
_SUPPORT is redundant as enabling Kconfig options implies support.
With this we can use CONFIG_IS_ENABLED() as needed.

Signed-off-by: Andrew Davis <afd@ti.com>
Reviewed-by: Tom Rini <trini@konsulko.com>

This adds a boot method for loading the next stage from the host. It is
mostly modeled off of spl_load_image_ext. I am not really sure why/how
spl_load_image_fat uses three different methods to load the image, but
the simple case seems to work OK for now.

To control the presence of this boot method, we add a config symbol.
While we're at it, we update the original semihosting config symbol.

I think semihosting has some advantages of other forms of JTAG boot.
Common other ways to boot from JTAG include:

- Implementing DDR initialization through JTAG (typically with dozens of
  lines of TCL) and then loading U-Boot. The DDR initialization
  typically uses hard-coded register writes, and is not easily adapted
  to different boards. BOOT_DEVICE_SMH allows booting with SPL,
  leveraging U-Boot's existing DDR initialization code. This is the
  method used by NXP's CodeWarrior IDE on Layerscape processors (see
  AN12270).
- Loading a bootloader into SDRAM, waiting for it to initialize DDR, and
  then loading U-Boot. This is tricky, because the debugger must stop the
  boot after the bootloader has completed its work. Trying to load
  U-Boot too early can cause failure to boot. This is the method used by
  Xilinx with its Zynq(MP) processors.
- Loading SPL with BOOT_DEVICE_RAM and breaking before SPL loads the
  image to load U-Boot at the appropriate place. This can be a bit
  tricky, because the load address is dependent on the header size. An
  elf with symbols must also be used in order to stop at the appropriate
  point. BOOT_DEVICE_SMH can be viewed as an extension of this process,
  where SPL automatically stops and tells the host where to place the
  image.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>