From: Marek Vasut <marek.vasut@mailbox.org>
To: Tom Rini <trini@konsulko.com>
Cc: "Marek Vasut" <marek.vasut+renesas@mailbox.org>,
u-boot@lists.denx.de,
"João Paulo Gonçalves" <joao.goncalves@toradex.com>,
"Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
"Sam Protsenko" <semen.protsenko@linaro.org>,
"Sughosh Ganu" <sughosh.ganu@linaro.org>
Subject: Re: [PATCH] boot: Warn users about fdt_high=~0 usage
Date: Wed, 19 Nov 2025 18:27:42 +0100 [thread overview]
Message-ID: <41203080-e331-4203-bd52-02a02b72dc5f@mailbox.org> (raw)
In-Reply-To: <20251117143245.GH2125796@bill-the-cat>
On 11/17/25 3:32 PM, Tom Rini wrote:
Hello Tom,
>>> Maybe? I was thinking it should be around this in boot/image-fdt.c:
>>> /* If fdt_high is set use it to select the relocation address */
>>> fdt_high = env_get("fdt_high");
>>> if (fdt_high) {
>>> ulong high_addr = hextoul(fdt_high, NULL);
>>>
>>> if (high_addr == ~0UL) {
>>> /* All ones means use fdt in place */
>>
>> This is exactly the code that this patch modifies . Where in the above do
>> you think this change should be ?
>
> You're right and I did post the last line of context that's the first
> line of your patch. I really meant that we shouldn't even be checking if
> the current location is misaligned. We should tell people to stop
> disabling relocation.
I see, and in that case, I don't particularly care either way, whether
we warn always, or only in case of actual problem.
>>> I think really. I am loath to break ABI like this but I'm not entirely
>>> sure we have a choice.
>>
>> We do, we simply warn users and remove the usage and fdt_high=~0 assignments
>> from the tree. The functionality itself does not have to be removed.
>
> The problem is the functionality has always been for a hack workaround
> and bootm_low/bootm_size/etc were the right answer.
>
> But maybe step one is just remove the in-tree usage and a big loud
> warning when it's set telling people to not do that.
This is fine by me.
>>> Maybe we detect disabled relocation and
>>> misaligned device tree and fall back to prompt? Or if it's too late,
>>> panic with an explanation? Or maybe we just move it 4 bytes higher. The
>>> device is in a going to fail state anyhow, so trying to recover it might
>>> be OK, and since the device tree needs to be modified by us it has to be
>>> in writable memory.
>> Keep in mind, on arm32 it may not necessarily fail to boot with 4-byte
>> aligned DT.
>
> I'm pretty sure it is. It's not a problem about doing misaligned reads
> it's that the data structure and it's accessors require 8 byte
> alignment.
I think my knowledge of this corner case was from around this time, so
old kernel versions might work, new ones will likely break. That is fine
too.
prev parent reply other threads:[~2025-11-19 17:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-13 14:29 [PATCH] boot: Warn users about fdt_high=~0 usage Marek Vasut
2025-11-13 15:49 ` Tom Rini
2025-11-15 17:34 ` Marek Vasut
2025-11-16 14:09 ` Tom Rini
2025-11-16 21:43 ` Marek Vasut
2025-11-17 14:32 ` Tom Rini
2025-11-19 17:27 ` Marek Vasut [this message]
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=41203080-e331-4203-bd52-02a02b72dc5f@mailbox.org \
--to=marek.vasut@mailbox.org \
--cc=ilias.apalodimas@linaro.org \
--cc=joao.goncalves@toradex.com \
--cc=marek.vasut+renesas@mailbox.org \
--cc=semen.protsenko@linaro.org \
--cc=sughosh.ganu@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox