[PATCH] lmb: Reinstate access to memory above ram_top

Marek Vasut marek.vasut at mailbox.org
Sat May 30 16:34:38 CEST 2026


On 5/30/26 4:22 PM, Tom Rini wrote:
> On Sat, May 30, 2026 at 04:16:34PM +0200, Marek Vasut wrote:
>> On 5/30/26 4:06 PM, Tom Rini wrote:
>>
>>>> The revert is wrong as that breaks other things , like use of DRAM above 4
>>>> GiB boundary, which is exactly why this change was implemented. If RPi has
>>>> limitations, then those limitations should be imposed on RPi, not globally,
>>>> so add the LMB reservations on RPi.
>>>
>>> Isn't the case you describe still a theoretical and not used in tree
>>> case?
>>
>> No, this is used by the Sparrow Hawk board, which depends on it.
> 
> Since when, and can we just also revert that to it's old behavior?

Since the inception of this patch, i.e. beginning of this thread.

And no, we cannot revert to any old behavior, because then we wouldn't 
be able to load large images on Sparrow Hawk, which is necessary.

>>> And note that Ilias' patches to relocate to the top of memory also
>>> fail on Pi. So there's something to be debugged here and worked out
>>> before we add this seemingly enhanced behavior. Hence, the need to
>>> revert it for now until it can be fixed.
>> We still have two RCs to go, so I don't see the need for a hasty revert that
>> breaks other systems, esp. if Ilias is looking into the RPi situation now,
>> and I already offered a way to fix the RPi in the short term without
>> breaking the other systems.
> 
> Ilias is not (yet) looking in to the problem with his series. I'm just
> noting that Pi is showing examples of the complicated memory map with
> things above and below 4G. And yes, we have a month between now and the
> release so a revert (or several, to return Sparrow Hawk to working) is
> currently on the table, if no one can work out how to fix things.

I sent a way to fix the RPi in this thread a few minutes ago, so that is 
the "work out" part there.

We could probably even make that generic enough and gate it behind some 
Kconfig option to let users select whether their memory above 4 GiB is 
broken or not. For SH it is not broken, for RPi it is, so we would have 
to work out some default value of that Kconfig option.

What do you think ?


More information about the U-Boot mailing list