[PATCH][RFC] image: fdt: Fix DT relocation handling with multiple DRAM banks with gap

[Simon Glass]

Hi Marek,

On Fri, 11 Mar 2022 at 19:41, Marek Vasut <marex at denx.de> wrote:
>
> On 3/12/22 03:24, Simon Glass wrote:
> > Hi Marek,
> >
> > On Wed, 21 Jul 2021 at 18:05, Marek Vasut <marex at denx.de> wrote:
> >>
> >> The current implementation of boot_relocate_fdt() places DT at the
> >> highest usable DRAM address, which is calculated as:
> >>    env_get_bootm_low() + env_get_bootm_mapsize()
> >> which by default becomes gd->ram_base + gd->ram_size.
> >>
> >> Systems like i.MX53 can have multiple DRAM banks with gap between them,
> >> e.g. have DRAM at 0x70000000-0x8fffffff and 0xb0000000-0xcfffffff , so
> >> for them the calculated highest DRAM address is 0xafffffff, which is
> >> exactly in the gap and thus not usable.
> >>
> >> Fix this by iterating over all DRAM banks and tracking the remaining
> >> amount of the total mapping size obtained from env_get_bootm_mapsize().
> >> Limit the maximum LMB area size to each bank, to avoid using nonexistent
> >> DRAM.
> >>
> >> Signed-off-by: Marek Vasut <marex at denx.de>
> >> Cc: Heinrich Schuchardt <xypron.glpk at gmx.de>
> >> Cc: Simon Glass <sjg at chromium.org>
> >> Cc: Tom Rini <trini at konsulko.com>
> >> ---
> >>   common/image-fdt.c | 40 ++++++++++++++++++++++++++++++++++++----
> >>   1 file changed, 36 insertions(+), 4 deletions(-)
> >
> > Reviewed-by: Simon Glass <sjg at chromium.org>
> >
> > Should we put this behind a Kconfig option to reduce code size?
>
> Since this depends on DT content, we cannot predict what kind of DT will
> be passed to U-Boot, so no, we cannot put this behind a Kconfig option.

Doesn't it only affect boards with disjoint memory?

Regards,
Simon