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 ?
