[PATCH v1 3/3] common: Allow relocations on the top of the last bank

[Marek Vasut]

On 3/28/26 8:11 AM, Ilias Apalodimas wrote:
> On Sat, 28 Mar 2026 at 08:44, Marek Vasut <marek.vasut at mailbox.org> wrote:
>>
>> On 3/27/26 1:23 PM, Ilias Apalodimas wrote:
>>
>> Hello Ilias,
>>
>>>>> Add a Kconfig option and allow the common code to relocate U-Boot
>>>>> to the top of the last discovered bank.
>>>>
>>>> The commit message should really clarify the current pitfalls of
>>>> enabling this symbol, including the part where ethernet transfers above
>>>> 4 GiB used to work because of the packet buffer built into U-Boot, and
>>>> they will break because the buffer is now relocated above 4 GiB too.
>>>
>>> Shall I just add your note from the RFC with a few adjustments? I.e
>>>
>>> NOTE: This currently might break platforms. If the ethernet
>>>         controller cannot DMA above 4 GiB, and once U-Boot does
>>>         get relocated above 4 GiB, the packet buffer which is built
>>>         into the U-Boot binary is also relocated above 4 GiB.
>>
>> This patch should not be applied in the first place, this DOES break
>> things. I think when this patch is safe to be applied, the note will not
>> be needed.
> 
> The patch obviously will not get applied. I was referring to the note
> in the commit message only.
> I'll just add it with slight changes in the commit

OK . Maybe keep sending the patches as RFC , so they won't accidentally 
be picked ?

>> [...]
>>>>> +++ b/common/board_f.c
>>>>> @@ -321,6 +321,8 @@ __weak phys_addr_t board_get_usable_ram_top(phys_size_t total_size)
>>>>>                  */
>>>>>                 return 0;
>>>>>     #endif
>>>>> +     if (IS_ENABLED(CONFIG_RELOCATE_LAST_BANK))
>>>>> +             fdtdec_setup_mem_ram_top();
>>>> Return value may need checking ?
>>>
>>> sure, but should we panic ? Or print a message and silently keep the
>>> old reloc address?
>> Print a message and relocate below 4 GiB , for maximum compatibility maybe ?
> 
> Yea that's what I currently have on my local branch
OK