All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.