Hi Marek, On Fri, 11 Mar 2022 at 19:41, Marek Vasut <ma...@denx.de> wrote: > > On 3/12/22 03:24, Simon Glass wrote: > > Hi Marek, > > > > On Wed, 21 Jul 2021 at 18:05, Marek Vasut <ma...@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 <ma...@denx.de> > >> Cc: Heinrich Schuchardt <xypron.g...@gmx.de> > >> Cc: Simon Glass <s...@chromium.org> > >> Cc: Tom Rini <tr...@konsulko.com> > >> --- > >> common/image-fdt.c | 40 ++++++++++++++++++++++++++++++++++++---- > >> 1 file changed, 36 insertions(+), 4 deletions(-) > > > > Reviewed-by: Simon Glass <s...@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
