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