[PATCH] imx: Fix usable memory ranges for imx8m SOCs

[Sughosh Ganu]

On Thu, 19 Dec 2024 at 04:23, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > Date: Wed, 18 Dec 2024 10:17:54 +0100
> > From: Frieder Schrempf <frieder.schrempf at kontron.de>
>
> Hi,
>
> > On 18.12.24 10:00 AM, Ilias Apalodimas wrote:
> > > In the long run we should change all of the above and have 32b and 64b
> > > platforms define ram_top identically.
> >
> > Some more ideas for cleaning up the situation in the long run:
> >
> > * Get rid of board_get_usable_ram_top() and fix the drivers that require
> >   address space below SZ_4G.
>
> Note that in many cases there are hardware limitations that restrict
> access to memory above SZ_4G by these devices.  So the only way to
> "fix" the drivers would be to add bounce buffer support to them.  That
> typically isn't trivial and adds complexity, especially when dealing
> with things like DMA rings.  And it will make things slower.
>
> These boards all seem to have plenty of memory below SZ_4G, so I think
> board_get_usable_ram_top() is actually a very reasonable solution for
> the problem.

Up until now, most issues have cropped up because of the addition of
RAM above ram_top to LMB's memory map. And I believe that is primarily
down to different, often conflicting requirements of platforms. The
addition of memory above ram_top is being done so that the memory
above ram_top gets registered in the EFI memory map. But with all
these issues that platforms are encountering, I think it will be best
to have this addition above ram_top done from the EFI memory module.
The LMB module will then be concerned only about memory till ram_top,
which platforms are free to set to a correct value considering their
limitations, or placement of images in RAM memory. I will be working
on this change for the next release, and send the patches out once I
have tested them on some of the boards that I have.

As an aside, I believe, there needs to be some kind of an audit of the
value of ram_top that is set by platforms. By default, ram_top is set
to an address one higher than the actual highest used address. That is
what is being done in the setup_dest_addr() function. The LMB function
to reserve the U-Boot image region also works with this assumption.
However, some platforms are not working with this rule. The imx8m is
one such platform. Considering the fact that we have 32 bit systems,
the ram_top should be changed to a u64 type so that we can have this
consistency among platforms.

-sughosh

>
> > * Parse the 'dma-ranges' property in the SoC node of the devicetree
> >   which already tells us what address space is usable (at least for
> >   i.MX8M).
>
> We do this in OpenBSD to determine a memory range that is "DMA-safe".
> It isn't entirely trivial though.  Not all boards have the relevant
> 'dma-ranges' property in the SoC node, and some boards have a
> 'dma-ranges' on nodes further down the tree that are very restrictive
> and not really relevant for what U-Boot wants to do.  So you'd
> probably need a Kconfig option to override this.
>
> Cheers,
>
> Mark