On 8.6.2018 23:59, Simon Glass wrote:
> Hi,
>
>
> On 7 June 2018 at 06:18, Michal Simek <michal.si...@xilinx.com> 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 <siva.durga.palad...@xilinx.com>
>>> Signed-off-by: Michal Simek <michal.si...@xilinx.com>
>>> ---
>>> 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 */
I am aware about this but in common/ but I have incorrectly read this
code in setup_dest_addr()
DP: Can you please check this again why you have created this patch?
Thanks,
Michal
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
