Hi,
On 7 June 2018 at 06:18, Michal Simek <[email protected]> wrote: > Hi, > > On 5.6.2018 09:20, Siva Durga Prasad Paladugu wrote: >> Fill initial ram top with DDR base addr value from DT as not filling >> it here always assumes it as zero while calculating relocation >> offset and hence lead to failures in somecases. This will assumed >> as zero if CONFIG_SYS_SDRAM_BASE is not defined. >> >> Signed-off-by: Siva Durga Prasad Paladugu <[email protected]> >> Signed-off-by: Michal Simek <[email protected]> >> --- >> lib/fdtdec.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/lib/fdtdec.c b/lib/fdtdec.c >> index f4e8dbf..34ef9b8 100644 >> --- a/lib/fdtdec.c >> +++ b/lib/fdtdec.c >> @@ -1172,6 +1172,7 @@ int fdtdec_setup_memory_size(void) >> } >> >> gd->ram_size = (phys_size_t)(res.end - res.start + 1); >> + gd->ram_top = (unsigned long)res.start; >> debug("%s: Initial DRAM size %llx\n", __func__, >> (unsigned long long)gd->ram_size); >> >> > > I am curious about ram_top meaning. It is used more as ram_base. > > I expect we can workaround it by board_get_usable_ram_top() where we > decode it exactly the same as patched fdtdec_setup_memory_size() but I > don't think it is better solution than this one. > > Simon/Tom: any comment? I wonder why it is not set to res.end in this patch? Comments from global_data.h: unsigned long ram_top; /* Top address of RAM used by U-Boot */ phys_size_t ram_size; /* RAM size */ Regards, Simon _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
