Options which deal with memory locations and have a default value of 0x0
are dangerous, as that is often not a valid memory location. Rework
SPL_LOAD_FIT_ADDRESS as follows:
- Add SPL_HAS_LOAD_FIT_ADDRESS to guard prompting the question as the
  case of loading a FIT image does not strictly require setting an
  address and allows for a malloc()'d area to be used.
- For SPL_RAM_SUPPORT, select the new guard symbol if SPL_LOAD_FIT is
  enabled because in that case an address must be provided.
- Update defconfigs for these new changes. Largely this means some
  defconfigs need to enable SPL_HAS_LOAD_FIT_ADDRESS to maintain their
  current status. In the case of sandbox, we also need to set
  SPL_LOAD_FIT_ADDRESS to 0x0.

Signed-off-by: Tom Rini <trini@konsulko.com>

This series from Marek Vasut <marek.vasut@mailbox.org> brings some
enhancements to use cases using OPTEE-OS on ARMv7a platforms, some of
which already existed on ARMv8.

Link: https://lore.kernel.org/r/20251030212359.12824-1-marek.vasut@mailbox.org

Add support for jumping to Linux kernel through OPTEE-OS on ARMv7a to SPL.
This is already supported on ARMv8a, this patch adds the ARMv7a support.
Extend the SPL fitImage loader to record OPTEE-OS load address and in case
the load address is non-zero, use the same bootm-optee.S code used by the
U-Boot fitImage jump code to start OPTEE-OS first and jump to Linux next.

Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>

Technically, commit 24bf44cf88e7 ("spl: fit: Do not fail immediately if
an overlay is not available") introduced that regression as the code
will never advance if spl_fit_get_image_name() will return an error. But
at that time, spl_fit_get_image_node() was used in spl_fit_append_fdt()
which calls fdt_subnode_offset() to get the image node. And I presume
the commit was about the latter failing gracefully and trying the next
one.

But with commit b13eaf3bb4e6 ("spl: fit: Add board level function to
decide application of DTO") that behavior changed and the loop in
spl_fit_append_fdt() no longer uses spl_fit_get_image_node() but
spl_fit_get_image_name() directly. Thus it doesn't make any sense to not
break the loop if that fails.

Also, the original use case of commit 24bf44cf88e7 ("spl: fit: Do not
fail immediately if an overlay is not available") is preserved because
spl_subnode_offset() is now called within the loop and errors are
handled gracefully (and advancing the index).

Fixes: b13eaf3bb4e6 ("spl: fit: Add board level function to decide application of DTO")
Signed-off-by: Michael Walle <mwalle@kernel.org>

I had trouble booting some am335x boards (both
beagleboneblack and a custom board). SPL would start just fine, and
apparently load U-Boot proper, but it would hang when jumping to
U-Boot.

While debugging, I stumbled on this memcpy() which from code
inspection very much looked to have overlapping src and dst, and
indeed a simple printf revealed

  calling memcpy(0x8087bf68, 0x8087bf80, 0xf7f8)

Now, it will always be with src > dst, our memcpy()
implementations "most likely" do forward-copying, and in the end it
turned out that this wasn't the culprit after all [*].

But to avoid me or others barking up the wrong tree in the future, and
because this use of memcpy() is technically undefined, use memmove()
instead.

[*] That was 358d1cc232c ("spl: Align FDT load address"), which has
since been fixed in master but not the v2025.07 I worked of by
52caad0d14a ("ARM: Align image end to 8 bytes to fit DT alignment").

Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@gmx.de>

A malformed FIT image could have an image name property that is not NUL
terminated. Reject such images.

Reported-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: E Shattow <e@freeshell.de>

The change in commit 3704b888a4ca ("common/spl: fix potential out of buffer
access in spl_fit_get_image_name function") led to function
spl_fit_get_image_name() no longer detecting if a property does not exist
at a non-zero buffer.

Link: https://lore.kernel.org/u-boot/38f5d078-3328-4bdb-9c95-4fb5fe89ddc2@gmx.de/T/#m59f3a23e675daa992c28d12236de71cae2ca2bb9
Fixes: 3704b888a4ca ("common/spl: fix potential out of buffer access in spl_fit_get_image_name function")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Tested-by: E Shattow <e@freeshell.de>

This fix a possible NULL pointer dereference.

There is also a risk of memory leaking within the same portion of code.
The leak will happen if loaded image is bad or damaged. In this case
u-boot-spl will try booting from the other available media. Unfortunately
resources allocated for previous boot media will NOT be freed.

We can't fix that issue as the memory allocation mechanism used here
is unknown. It can be different kinds of malloc() or something else.

To somewhat reduce memory consumption, one can try to reuse previously
allocated memory as it's done in board_spl_fit_buffer_addr() from
test/image/spl_load.c.

The corresponding comment was put to the code as well.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Anshul Dalal <anshuld@ti.com>

load_simple_fit() returns -EPERM for the images with broken signatures.
Unfortunately this may conflict with image loaging selection on the base
of boot phase. See commit 873112db9ce68c38984ff25808dde726f8dd5573
("spl: Support selecting images based on phase in simple FIT").

Thus loading of

	configurations {
		uboot {
			description = "u-boot";
			firmware = "atf";
			loadables = "atf", "tee", "uboot";
		};
	};

with damaged "tee" image may finish without errors. This may results in
board bricking.

This patch fixes commit 873112db9ce68c38984ff25808dde726f8dd5573
("spl: Support selecting images based on phase in simple FIT")
by replacing EPERM with EBADSLT places where it should be done.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>

The current code have two issues:
1) ineffective NULL pointer check

	str = strchr(str, '\0') + 1
	if (!str || ...

   The str here will never be NULL (because we add 1 to result of strchr())

2) strchr() may go out of the buffer for the special forms of name variable.
   It's better use memchr() function here.

   According to the code the property is a sequence of C-string like
   shown below:

     'h', 'e', 'l', 'l', 'o', '\0', 'w', 'o', 'r', 'l', 'd', '\0', '!', '\0'

   index is the string number we are interested, so

     index = 0   =>  "hello",
     index = 1   =>  "world",
     index = 2   =>  "!"

   The issue will arrise if last string for some reason have no terminating
   '\0' character. This can happen for damaged or specially crafted dtb.

Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Tom Rini <trini@konsulko.com>