[PATCH 01/11] imx: implement get_effective_memsize

Peng Fan peng.fan at oss.nxp.com
Wed Nov 9 02:48:53 CET 2022



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.

Regards,
Peng.

Could you check how is gd->ram_top
> configured with and without this change?
> 
>> 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
>>>>>>


More information about the U-Boot mailing list