[PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

On 11/15/2022 3:47 PM, Pali Rohár wrote:
> On Tuesday 15 November 2022 11:06:23 Peng Fan wrote:
>> On 11/9/2022 3:40 PM, Pali Rohár wrote:
>>> On Wednesday 09 November 2022 09:48:53 Peng Fan wrote:
>>>> On 11/8/2022 4:03 PM, Pali Rohár wrote:
>>>>> On Tuesday 08 November 2022 07:56:59 Peng Fan wrote:
>>>>>>> Subject: Re: [PATCH 01/11] imx: implement get_effective_memsize
>>>>>>>
>>>>>>> On Tuesday 08 November 2022 09:38:01 Peng Fan wrote:
>>>>>>>> On 11/7/2022 3:55 PM, Pali Rohár wrote:
>>>>>>>>> On Monday 07 November 2022 16:00:06 Peng Fan (OSS) wrote:
>>>>>>>>>> From: Peng Fan <peng.fan at nxp.com>
>>>>>>>>>>
>>>>>>>>>> To i.MX6/7 which has 2GB memory, the upper 4KB cut off, will cause
>>>>>>>>>> the top 1MB not mapped as normal memory, because ARMV7-A use
>>>>>>>>>> section mapping. So implement i.MX6/7 specific
>>>>>>>>>> get_effective_memsize to fix the issue.
>>>>>>>>>>
>>>>>>>>>> Fixes: 777aaaa706bc("common/memsize.c: Fix get_effective_memsize()
>>>>>>>>>> to check for overflow")
>>>>>>>>>> Signed-off-by: Peng Fan <peng.fan at nxp.com>
>>>>>>>>>
>>>>>>>>> Should not just configuring CONFIG_MAX_MEM_MAPPED properly avoid
>>>>>>> that issue?
>>>>>>>>
>>>>>>>> No, unless I decrease PHYS_SDRAM_SIZE.
>>>>>>>
>>>>>>> So, what is the issue? I just do not see what happens after 777aaaa706bc
>>>>>>> that RAM size is calculated incorrectly in your case. I did not catch the
>>>>>>> description from commit message. What are your gd->ram_size and
>>>>>>> CONFIG_MAX_MEM_MAPPED values that current code does not work?
>>>>>>
>>>>>> The base is 2GB, the size is 2GB. With CONFIG_MAX_MEM_MAPPED,
>>>>>> the ram_size already decreased by 4KB.
>>>>>
>>>>> If base is 2GB and size is 2GB then ram_top is 4GB which cannot be
>>>>> represented in 32-bit phys_size_t type and hence some of other u-boot
>>>>> functions use 0 as ram_top. Mentioned commit tries to fix this issue.
>>>>> I guess that you have some other hidden problem and my change just
>>>>> showed implication of that.
>>>>
>>>> The issue is with higher 4KB cut off, the MMU mapping will cut off
>>>> 1MB or 2MB(section mapping), so after MMU enabled, the PC instruction will
>>>> not able to fetch instruction in the higher 1MB area because of U-Boot
>>>> relocated to
>>>> top of DRAM.
>>>
>>> But it is not possible to represent whole 4GB of RAM size in 32-bit
>>> phys_size_t type. So some cut-off for this storage is required.
>>
>> I understand this. But this means I have to reserve the higher 2MB section
>> because of the 4KB cut off.
>>
>> Even the ram_top is 0 in my case, it does not matter. The relocaddr
>> is unsigned long, when reserve other memory, it will back to the
>> high address.
> 
> Well, zero ram_top did not work, that is why I introduced that commit.
> Better to cut off 4kB/2MB of RAM size and have working u-boot, as having
> issues with reserving parts of RAM.

But it worked before, right? Is there any changes that cause ram_top as 
0 not work?

Thanks,
Peng.
> 
>> Regards,
>> Peng.
>>
>>>
>>>> Regards,
>>>> Peng.
>>>>
>>>> Could you check how is gd->ram_top
>>>>> configured with and without this change?
>>>
>>> Could you check this?
>>>
>>>>>> Regards,
>>>>>> Peng.
>>>>>>
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Peng.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>      arch/arm/mach-imx/cache.c | 14 ++++++++++++++
>>>>>>>>>>      1 file changed, 14 insertions(+)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-imx/cache.c b/arch/arm/mach-imx/cache.c
>>>>>>>>>> index ab9b621a2a6..69a085abee7 100644
>>>>>>>>>> --- a/arch/arm/mach-imx/cache.c
>>>>>>>>>> +++ b/arch/arm/mach-imx/cache.c
>>>>>>>>>> @@ -7,10 +7,24 @@
>>>>>>>>>>      #include <cpu_func.h>
>>>>>>>>>>      #include <asm/armv7.h>
>>>>>>>>>>      #include <asm/cache.h>
>>>>>>>>>> +#include <asm/global_data.h>
>>>>>>>>>>      #include <asm/pl310.h>
>>>>>>>>>>      #include <asm/io.h>
>>>>>>>>>>      #include <asm/mach-imx/sys_proto.h>
>>>>>>>>>> +DECLARE_GLOBAL_DATA_PTR;
>>>>>>>>>> +
>>>>>>>>>> +phys_size_t get_effective_memsize(void) { #ifndef
>>>>>>>>>> +CONFIG_MAX_MEM_MAPPED
>>>>>>>>>> +	return gd->ram_size;
>>>>>>>>>> +#else
>>>>>>>>>> +	/* limit stack to what we can reasonable map */
>>>>>>>>>> +	return ((gd->ram_size > CONFIG_MAX_MEM_MAPPED) ?
>>>>>>>>>> +		CONFIG_MAX_MEM_MAPPED : gd->ram_size); #endif }
>>>>>>>>>> +
>>>>>>>>>>      void enable_ca7_smp(void)
>>>>>>>>>>      {
>>>>>>>>>>      	u32 val;
>>>>>>>>>> --
>>>>>>>>>> 2.36.0
>>>>>>>>>>