From: Quentin Schulz <quentin.schulz@cherry.de>
To: Michal Simek <michal.simek@amd.com>,
u-boot@lists.denx.de, git@xilinx.com
Cc: Prasad Kummari <prasad.kummari@amd.com>, Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH] arm64: zynqmp: Use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME in binman
Date: Tue, 25 Mar 2025 10:48:44 +0100 [thread overview]
Message-ID: <421afd11-7a50-415d-b43b-9db62e416dd9@cherry.de> (raw)
In-Reply-To: <022449eaa99ce8b96bd1c0af9bece2241180be6d.1742389724.git.michal.simek@amd.com>
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?
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?
Cheers,
Quentin
next prev parent reply other threads:[~2025-03-25 9:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-19 13:08 [PATCH] arm64: zynqmp: Use CONFIG_SPL_FS_LOAD_PAYLOAD_NAME in binman Michal Simek
2025-03-25 9:48 ` Quentin Schulz [this message]
2025-03-27 9:11 ` Michal Simek
2025-03-28 15:08 ` Quentin Schulz
2025-03-28 15:19 ` Michal Simek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=421afd11-7a50-415d-b43b-9db62e416dd9@cherry.de \
--to=quentin.schulz@cherry.de \
--cc=git@xilinx.com \
--cc=michal.simek@amd.com \
--cc=prasad.kummari@amd.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.