Hi,
On 3/25/25 10:48, Quentin Schulz wrote:
Hi Michal,
On 3/19/25 2:08 PM, Michal Simek wrote:
u-boot.itb name is coming via CONFIG_SPL_FS_LOAD_PAYLOAD_NAME and it's
They are unrelated as far as I can tell?
Isn't CONFIG_SPL_FS_LOAD_PAYLOAD_NAME the name of the U-Boot FIT that the SPL is
going to load from some filesystem?
yes.
u-boot.itb in the binman nodes below is the name of the generated U-Boot FIT on
your disk.
Your disk FS != SPL FS, no?
I can get behind wanting the same name for the file on both FS, but the issue I
have is the additional CONFIG_SPL_FS_LOAD_PAYLOAD_NAME #ifdef will prevent the
generation of this U-Boot FIT image if the symbol isn't defined anymore (which
is possible if SPL has no support for FS (ext4, fat, squashfs, semihosting)). U-
Boot likely work just fine by trying to load u-boot.itb from another source no?
(No experience with AMD, typically only Aarch64 for me, where u-boot.itb is
usually loaded from a specific offset in the storage medium, outside of any FS).
Basically, do we really need to NOT build U-Boot FIT if SPL_FS_LOAD_PAYLOAD_NAME
is not defined?
There are couple of things here. AMD/Xilinx evaluation boards are capable to
boot from multiple devices.
On ZynqMP we have one official supported flow which is FSBL or alternative SPL.
In FSBL boot mode FIT image is not handled and boot image contains just
u-boot.elf and that's it and no matter which boot mode you use.
In SPL boot mode boot image (boot.bin) has only SPL and that's it. Then FIT
image should be created to be able to start TF-A, U-Boot, etc.
Then based on boot device there are in general two options which are raw mode
(for example SPI) and then filesystem one (SD or EMMC).
In RAW mode qspi image is created (maybe we can rename it because it can be also
used for NAND for example) and image is expected at certain offset and name
obviously doesn't matter.
But in filesystem mode names matter and image should match
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME because that's the filename which SPL is looking
for that's why these has to match.
And if I go back when FSBL is used there is no reason to generate raw boot image
as qspi.bin or fit image as u-boot.itb because all binaries are the part of
boot.bin already.
Please let me know if you have any other question.
Thanks,
Michal
