[PATCH 00/11] imx: convert to DM_SERIAL

[PATCH 00/11] imx: convert to DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

This patchset is to convert mx6ull/z_evk, mx6sl[l]evk, mx6sxsbareauto,
mx6sabreauto, mx6sabresd to DM_SERIAL

Patch 1 is a fix found when testing mx6sllevk

Peng Fan (11):
  imx: implement get_effective_memsize
  imx: mx6ull_14x14_evk: select DM_SERIAL
  imx: mx6ulz: select DM_SERIAL
  imx: mx6ull/z_14x14_evk: clean up UART iomux
  imx: mx6sllevk: correct pmic name
  imx: mx6sllevk: select DM_SERIAL
  imx: mx6slevk: select DM_SERIAL
  imx: mx6ul_evk: select DM_SERIAL
  imx: mx6sxsabreauto: select DM_SERIAL
  imx: mx6sabreauto_defconfig: select DM_SERIAL
  imx: mx6sabresd: select DM_SERIAL

 arch/arm/dts/imx6sll-evk-u-boot.dtsi           |  8 ++++++++
 arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi      |  4 ++++
 arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi     |  8 ++++++++
 arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi     |  8 ++++++++
 arch/arm/mach-imx/cache.c                      | 14 ++++++++++++++
 board/freescale/mx6sllevk/mx6sllevk.c          | 18 +-----------------
 .../freescale/mx6sxsabreauto/mx6sxsabreauto.c  | 16 ----------------
 board/freescale/mx6ullevk/mx6ullevk.c          | 16 ----------------
 configs/mx6sabreauto_defconfig                 |  1 +
 configs/mx6sabresd_defconfig                   |  1 +
 configs/mx6slevk_defconfig                     |  1 +
 configs/mx6slevk_spinor_defconfig              |  1 +
 configs/mx6slevk_spl_defconfig                 |  1 +
 configs/mx6sllevk_defconfig                    |  1 +
 configs/mx6sllevk_plugin_defconfig             |  1 +
 configs/mx6sxsabreauto_defconfig               |  1 +
 configs/mx6ul_14x14_evk_defconfig              |  1 +
 configs/mx6ul_9x9_evk_defconfig                |  1 +
 configs/mx6ull_14x14_evk_defconfig             |  1 +
 configs/mx6ull_14x14_evk_plugin_defconfig      |  1 +
 configs/mx6ulz_14x14_evk_defconfig             |  1 +
 21 files changed, 56 insertions(+), 49 deletions(-)
 create mode 100644 arch/arm/dts/imx6sll-evk-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi

-- 
2.36.0

[PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@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@nxp.com>
---
 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

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Pali Rohár]

On Monday 07 November 2022 16:00:06 Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@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@nxp.com>

Should not just configuring CONFIG_MAX_MEM_MAPPED properly avoid that issue?

> ---
>  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
> 

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

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@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@nxp.com>
> 
> Should not just configuring CONFIG_MAX_MEM_MAPPED properly avoid that issue?

No, unless I decrease PHYS_SDRAM_SIZE.

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
>>

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Pali Rohár]

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@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@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?

> 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
> > > 

RE: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

> 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@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@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.

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
> > > >

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Pali Rohár]

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@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@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. 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
> > > > >

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

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@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@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
>>>>>>

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Pali Rohár]

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@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@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.

> 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
> > > > > > > 

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

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@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@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.

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
>>>>>>>>

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Pali Rohár]

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@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@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.

> 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
> > > > > > > > > 

Re: [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@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@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
>>>>>>>>>>

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Pali Rohár]

On Tuesday 15 November 2022 16:28:20 Peng Fan wrote:
> 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@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@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?

It did not work, u-boot at that time hanged during reserving memory
space.

> 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
> > > > > > > > > > > 

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

+Tom

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@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@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.

With your commit
Ram size: 80000000
Ram top: FFFFF000

Your patch would break all i.MX6/7 boards that 2GB memory with
base starts at 0x80000000.

After apply this patch, It works, even if RAM top is 0.
Ram size: 80000000
Ram top: 00000000
full log below:
U-Boot 2022.10-00346-gd80f7fc140a-dirty (Nov 16 2022 - 11:24:56 +0800)

initcall: 8780f549
U-Boot code: 87800000 -> 878562BC  BSS: -> 8785D998
initcall: 8780f43d
initcall: 87801fe1
CPU:   Freescale i.MX6SLL rev1.0 at 792MHz
CPU:   Commercial temperature grade (0C to 95C)
Reset cause: POR
initcall: 8780fb21
Model: Freescale i.MX6SLL EVK Board
Board: MX6SLL EVK
initcall: 8780f5b9
initcall: 8780f5a9
DRAM:  initcall: 8780356d
initcall: 8780f87d
Monitor len: 0005D998
Ram size: 80000000
Ram top: 00000000
initcall: 8780f429
initcall: 87801d17
initcall: 8780f5eb
initcall: 8780f5ef
initcall: 8780f501
Reserving 374k for U-Boot at: fff92000
initcall: 8780f611
Reserving 16392k for malloc() at: fef90000
initcall: 8780f56d
Reserving 68 Bytes for Board Info at: fef8ffb0
initcall: 8780f63d
Reserving 248 Bytes for Global Data at: fef8feb0
initcall: 8780f669
Reserving 25600 Bytes for FDT at: fef89ab0
initcall: 8780f5f3
initcall: 8780f5f7
initcall: 8780f607
initcall: 8780f8e1
initcall: 8780f441
initcall: 8780f6c1

RAM Configuration:
Bank #0: 80000000 2 GiB

DRAM:  2 GiB
initcall: 8780f8f3
initcall: 8780f4ed
New Stack Pointer is: fef89a90
initcall: 8780f45b
initcall: 8780f5fb
initcall: 8780f5ff
initcall: 8780f48d
Relocation Offset is: 78792000
Relocating to fff92000, new gd at fef8feb0, sp at fef89a90
initcall: 8780f60b
initcall: 8780f5e3
Core:  74 devices, 16 uclasses, devicetree: separate
MMC:   FSL_SDHC: 0, FSL_SDHC: 2
Loading Environment from MMC... MMC: no card present
*** Warning - No block device, using default environment

In:    serial@2020000
Out:   serial@2020000
Err:   serial@2020000
Net:   No ethernet found.
Hit any key to stop autoboot:  0


> 
>> 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
>>>>>>>>

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Stefan Roese]

Hi Peng,

please find one late comment from me below...

On 16.11.22 03:43, Peng Fan wrote:
> 
> +Tom
> 
> 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@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@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.
> 
> With your commit
> Ram size: 80000000
> Ram top: FFFFF000

Looks good to me.

> Your patch would break all i.MX6/7 boards that 2GB memory with
> base starts at 0x80000000.

Why is this the case?

> After apply this patch, It works, even if RAM top is 0.
> Ram size: 80000000
> Ram top: 00000000

Ughhh. This looks broken to me. Address 0x0000.0000 is a valid address
and points to 0! In this case the code just seems to work (as seen
below) as 0 is wrapped around since it's a 32bit value.

> full log below:
> U-Boot 2022.10-00346-gd80f7fc140a-dirty (Nov 16 2022 - 11:24:56 +0800)
> 
> initcall: 8780f549
> U-Boot code: 87800000 -> 878562BC  BSS: -> 8785D998
> initcall: 8780f43d
> initcall: 87801fe1
> CPU:   Freescale i.MX6SLL rev1.0 at 792MHz
> CPU:   Commercial temperature grade (0C to 95C)
> Reset cause: POR
> initcall: 8780fb21
> Model: Freescale i.MX6SLL EVK Board
> Board: MX6SLL EVK
> initcall: 8780f5b9
> initcall: 8780f5a9
> DRAM:  initcall: 8780356d
> initcall: 8780f87d
> Monitor len: 0005D998
> Ram size: 80000000
> Ram top: 00000000
> initcall: 8780f429
> initcall: 87801d17
> initcall: 8780f5eb
> initcall: 8780f5ef
> initcall: 8780f501
> Reserving 374k for U-Boot at: fff92000

Here we've got the wrap around.

So why does it not work with the Pali's original code leading to a
ram-top of 0xFFFFF000? Where does it fail? Could you please post
this bootlog as well?

Thanks,
Stefan

> initcall: 8780f611
> Reserving 16392k for malloc() at: fef90000
> initcall: 8780f56d
> Reserving 68 Bytes for Board Info at: fef8ffb0
> initcall: 8780f63d
> Reserving 248 Bytes for Global Data at: fef8feb0
> initcall: 8780f669
> Reserving 25600 Bytes for FDT at: fef89ab0
> initcall: 8780f5f3
> initcall: 8780f5f7
> initcall: 8780f607
> initcall: 8780f8e1
> initcall: 8780f441
> initcall: 8780f6c1
> 
> RAM Configuration:
> Bank #0: 80000000 2 GiB
> 
> DRAM:  2 GiB
> initcall: 8780f8f3
> initcall: 8780f4ed
> New Stack Pointer is: fef89a90
> initcall: 8780f45b
> initcall: 8780f5fb
> initcall: 8780f5ff
> initcall: 8780f48d
> Relocation Offset is: 78792000
> Relocating to fff92000, new gd at fef8feb0, sp at fef89a90
> initcall: 8780f60b
> initcall: 8780f5e3
> Core:  74 devices, 16 uclasses, devicetree: separate
> MMC:   FSL_SDHC: 0, FSL_SDHC: 2
> Loading Environment from MMC... MMC: no card present
> *** Warning - No block device, using default environment
> 
> In:    serial@2020000
> Out:   serial@2020000
> Err:   serial@2020000
> Net:   No ethernet found.
> Hit any key to stop autoboot:  0
> 
> 
>>
>>> 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
>>>>>>>>>

Viele Grüße,
Stefan Roese

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

Hi Stefan,

On 11/16/2022 2:03 PM, Stefan Roese wrote:
> Hi Peng,
> 
> please find one late comment from me below...
> 
> On 16.11.22 03:43, Peng Fan wrote:
>>
>> +Tom
>>
>> 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@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@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.
>>
>> With your commit
>> Ram size: 80000000
>> Ram top: FFFFF000
> 
> Looks good to me.
> 
>> Your patch would break all i.MX6/7 boards that 2GB memory with
>> base starts at 0x80000000.
> 
> Why is this the case?
> 
>> After apply this patch, It works, even if RAM top is 0.
>> Ram size: 80000000
>> Ram top: 00000000
> 
> Ughhh. This looks broken to me. Address 0x0000.0000 is a valid address
> and points to 0! In this case the code just seems to work (as seen
> below) as 0 is wrapped around since it's a 32bit value.
> 
>> full log below:
>> U-Boot 2022.10-00346-gd80f7fc140a-dirty (Nov 16 2022 - 11:24:56 +0800)
>>
>> initcall: 8780f549
>> U-Boot code: 87800000 -> 878562BC  BSS: -> 8785D998
>> initcall: 8780f43d
>> initcall: 87801fe1
>> CPU:   Freescale i.MX6SLL rev1.0 at 792MHz
>> CPU:   Commercial temperature grade (0C to 95C)
>> Reset cause: POR
>> initcall: 8780fb21
>> Model: Freescale i.MX6SLL EVK Board
>> Board: MX6SLL EVK
>> initcall: 8780f5b9
>> initcall: 8780f5a9
>> DRAM:  initcall: 8780356d
>> initcall: 8780f87d
>> Monitor len: 0005D998
>> Ram size: 80000000
>> Ram top: 00000000
>> initcall: 8780f429
>> initcall: 87801d17
>> initcall: 8780f5eb
>> initcall: 8780f5ef
>> initcall: 8780f501
>> Reserving 374k for U-Boot at: fff92000
> 
> Here we've got the wrap around.
> 
> So why does it not work with the Pali's original code leading to a
> ram-top of 0xFFFFF000? Where does it fail? Could you please post
> this bootlog as well?

Not has board at hand for now.

0xFFFFF000 only has the top 4KB cut-off, but when we
set up MMU mapping, we use section mapping, so the top 1MB will
be cut off when do the mmu mapping.

         for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT;
              i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) +
                  (bd->bi_dram[bank].size >> MMU_SECTION_SHIFT);
              i++)
                 set_section_dcache(i, DCACHE_DEFAULT_OPTION);

Then the code/data between 0xFF000000 - 0xFFFFF000 are not mapped,
cause boot hang.

Thanks,
Peng.

> 
> Thanks,
> Stefan
> 
>> initcall: 8780f611
>> Reserving 16392k for malloc() at: fef90000
>> initcall: 8780f56d
>> Reserving 68 Bytes for Board Info at: fef8ffb0
>> initcall: 8780f63d
>> Reserving 248 Bytes for Global Data at: fef8feb0
>> initcall: 8780f669
>> Reserving 25600 Bytes for FDT at: fef89ab0
>> initcall: 8780f5f3
>> initcall: 8780f5f7
>> initcall: 8780f607
>> initcall: 8780f8e1
>> initcall: 8780f441
>> initcall: 8780f6c1
>>
>> RAM Configuration:
>> Bank #0: 80000000 2 GiB
>>
>> DRAM:  2 GiB
>> initcall: 8780f8f3
>> initcall: 8780f4ed
>> New Stack Pointer is: fef89a90
>> initcall: 8780f45b
>> initcall: 8780f5fb
>> initcall: 8780f5ff
>> initcall: 8780f48d
>> Relocation Offset is: 78792000
>> Relocating to fff92000, new gd at fef8feb0, sp at fef89a90
>> initcall: 8780f60b
>> initcall: 8780f5e3
>> Core:  74 devices, 16 uclasses, devicetree: separate
>> MMC:   FSL_SDHC: 0, FSL_SDHC: 2
>> Loading Environment from MMC... MMC: no card present
>> *** Warning - No block device, using default environment
>>
>> In:    serial@2020000
>> Out:   serial@2020000
>> Err:   serial@2020000
>> Net:   No ethernet found.
>> Hit any key to stop autoboot:  0
>>
>>
>>>
>>>> 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
>>>>>>>>>>
> 
> Viele Grüße,
> Stefan Roese
> 

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Fabio Estevam]

Hi Peng,

On Mon, Nov 7, 2022 at 4:13 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
>
> From: Peng Fan <peng.fan@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")

This commit has been reverted in master for non-Power PC platforms:

commit d1f4b090dd17ee11373859f2c91af94bf254af7a
Author: Pali Rohár <pali@kernel.org>
Date:   Sat Jan 7 22:55:26 2023 +0100

    common/memsize.c: Check for overflow in get_effective_memsize()
only for mpc85xx

    This reverts commit 777aaaa706bc ("common/memsize.c: Fix
    get_effective_memsize() to check for overflow") for non-mpc85xx platforms.

    The changes to this generic function, which is intended to help with
    32bit platforms with large amounts of memory has unintended side effects
    (which in turn lead to boot failures) on other platforms which were
    previously functional.

    For now do overflow check only for powerpc mpc85xx platform. It is needed
    to prevent crashing of P1/P2 boards with 4GB DDR module in 32-bit mode.

    Fixes: 777aaaa706bc ("common/memsize.c: Fix
get_effective_memsize() to check for overflow")
    Signed-off-by: Pali Rohár <pali@kernel.org>

Can this patch be discarded then?

I just noticed that Stefano applied it to u-boot-imx master-next branch.

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Stefano Babic]

On 31.01.23 12:02, Fabio Estevam wrote:
> Hi Peng,
> 
> On Mon, Nov 7, 2022 at 4:13 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
>>
>> From: Peng Fan <peng.fan@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")
> 
> This commit has been reverted in master for non-Power PC platforms:
> 
> commit d1f4b090dd17ee11373859f2c91af94bf254af7a
> Author: Pali Rohár <pali@kernel.org>
> Date:   Sat Jan 7 22:55:26 2023 +0100
> 
>      common/memsize.c: Check for overflow in get_effective_memsize()
> only for mpc85xx
> 
>      This reverts commit 777aaaa706bc ("common/memsize.c: Fix
>      get_effective_memsize() to check for overflow") for non-mpc85xx platforms.
> 
>      The changes to this generic function, which is intended to help with
>      32bit platforms with large amounts of memory has unintended side effects
>      (which in turn lead to boot failures) on other platforms which were
>      previously functional.
> 
>      For now do overflow check only for powerpc mpc85xx platform. It is needed
>      to prevent crashing of P1/P2 boards with 4GB DDR module in 32-bit mode.
> 
>      Fixes: 777aaaa706bc ("common/memsize.c: Fix
> get_effective_memsize() to check for overflow")
>      Signed-off-by: Pali Rohár <pali@kernel.org>
> 
> Can this patch be discarded then?
> 
> I just noticed that Stefano applied it to u-boot-imx master-next branch.


Yes, it is in test - I could let it out for the moment, waiting for 
Peng's answer.

Regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

Re: [PATCH 01/11] imx: implement get_effective_memsize

[Peng Fan]

On 1/31/2023 7:10 PM, Stefano Babic wrote:
> On 31.01.23 12:02, Fabio Estevam wrote:
>> Hi Peng,
>>
>> On Mon, Nov 7, 2022 at 4:13 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> 
>> wrote:
>>>
>>> From: Peng Fan <peng.fan@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")
>>
>> This commit has been reverted in master for non-Power PC platforms:
>>
>> commit d1f4b090dd17ee11373859f2c91af94bf254af7a
>> Author: Pali Rohár <pali@kernel.org>
>> Date:   Sat Jan 7 22:55:26 2023 +0100
>>
>>      common/memsize.c: Check for overflow in get_effective_memsize()
>> only for mpc85xx
>>
>>      This reverts commit 777aaaa706bc ("common/memsize.c: Fix
>>      get_effective_memsize() to check for overflow") for non-mpc85xx 
>> platforms.
>>
>>      The changes to this generic function, which is intended to help with
>>      32bit platforms with large amounts of memory has unintended side 
>> effects
>>      (which in turn lead to boot failures) on other platforms which were
>>      previously functional.
>>
>>      For now do overflow check only for powerpc mpc85xx platform. It 
>> is needed
>>      to prevent crashing of P1/P2 boards with 4GB DDR module in 32-bit 
>> mode.
>>
>>      Fixes: 777aaaa706bc ("common/memsize.c: Fix
>> get_effective_memsize() to check for overflow")
>>      Signed-off-by: Pali Rohár <pali@kernel.org>
>>
>> Can this patch be discarded then?
>>
>> I just noticed that Stefano applied it to u-boot-imx master-next branch.
> 
> 
> Yes, it is in test - I could let it out for the moment, waiting for 
> Peng's answer.


Yes, this patch could dropped, since the common code already has fix.

Thanks,
Peng.

> 
> Regards,
> Stefano
> 

[PATCH 02/11] imx: mx6ull_14x14_evk: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 configs/mx6ull_14x14_evk_defconfig        | 1 +
 configs/mx6ull_14x14_evk_plugin_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/mx6ull_14x14_evk_defconfig b/configs/mx6ull_14x14_evk_defconfig
index 65db621f156..b13918c2699 100644
--- a/configs/mx6ull_14x14_evk_defconfig
+++ b/configs/mx6ull_14x14_evk_defconfig
@@ -59,6 +59,7 @@ CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
diff --git a/configs/mx6ull_14x14_evk_plugin_defconfig b/configs/mx6ull_14x14_evk_plugin_defconfig
index 55ddd7eabbd..e601056d277 100644
--- a/configs/mx6ull_14x14_evk_plugin_defconfig
+++ b/configs/mx6ull_14x14_evk_plugin_defconfig
@@ -58,6 +58,7 @@ CONFIG_MII=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

[PATCH 02/11] imx: mx6ull_14x14_evk: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 03/11] imx: mx6ulz: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 configs/mx6ulz_14x14_evk_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mx6ulz_14x14_evk_defconfig b/configs/mx6ulz_14x14_evk_defconfig
index 0c1b442b682..2df2ccd2681 100644
--- a/configs/mx6ulz_14x14_evk_defconfig
+++ b/configs/mx6ulz_14x14_evk_defconfig
@@ -48,6 +48,7 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

[PATCH 03/11] imx: mx6ulz: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 04/11] imx: mx6ull/z_14x14_evk: clean up UART iomux

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

After DM_SERIAL, and set pinctrl_uart1 as pre-reloc, no need initialize
iomux at board file.

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi |  8 ++++++++
 arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi |  8 ++++++++
 board/freescale/mx6ullevk/mx6ullevk.c      | 16 ----------------
 3 files changed, 16 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
 create mode 100644 arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi

diff --git a/arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi b/arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
new file mode 100644
index 00000000000..d283e815e6a
--- /dev/null
+++ b/arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 NXP
+ */
+
+&pinctrl_uart1 {
+	u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi b/arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi
new file mode 100644
index 00000000000..d283e815e6a
--- /dev/null
+++ b/arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2022 NXP
+ */
+
+&pinctrl_uart1 {
+	u-boot,dm-pre-reloc;
+};
diff --git a/board/freescale/mx6ullevk/mx6ullevk.c b/board/freescale/mx6ullevk/mx6ullevk.c
index 86c11c7bd3a..87bdbe51c6d 100644
--- a/board/freescale/mx6ullevk/mx6ullevk.c
+++ b/board/freescale/mx6ullevk/mx6ullevk.c
@@ -24,10 +24,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |		\
-	PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |		\
-	PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
 int dram_init(void)
 {
 	gd->ram_size = imx_ddr_size();
@@ -35,16 +31,6 @@ int dram_init(void)
 	return 0;
 }
 
-static iomux_v3_cfg_t const uart1_pads[] = {
-	MX6_PAD_UART1_TX_DATA__UART1_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
-	MX6_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
-};
-
-static void setup_iomux_uart(void)
-{
-	imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
-}
-
 int board_mmc_get_env_dev(int devno)
 {
 	return devno;
@@ -57,8 +43,6 @@ int mmc_map_to_kernel_blk(int devno)
 
 int board_early_init_f(void)
 {
-	setup_iomux_uart();
-
 	return 0;
 }
 
-- 
2.36.0

Re: [PATCH 04/11] imx: mx6ull/z_14x14_evk: clean up UART iomux

[Peter Robinson]

On Mon, Nov 7, 2022 at 7:14 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
>
> From: Peng Fan <peng.fan@nxp.com>
>
> After DM_SERIAL, and set pinctrl_uart1 as pre-reloc, no need initialize
> iomux at board file.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
>  arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi |  8 ++++++++
>  arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi |  8 ++++++++
>  board/freescale/mx6ullevk/mx6ullevk.c      | 16 ----------------
>  3 files changed, 16 insertions(+), 16 deletions(-)
>  create mode 100644 arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
>  create mode 100644 arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi
>
> diff --git a/arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi b/arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
> new file mode 100644
> index 00000000000..d283e815e6a
> --- /dev/null
> +++ b/arch/arm/dts/imx6ull-14x14-evk-u-boot.dtsi
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022 NXP
> + */
> +
> +&pinctrl_uart1 {
> +       u-boot,dm-pre-reloc;
> +};
> diff --git a/arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi b/arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi
> new file mode 100644
> index 00000000000..d283e815e6a
> --- /dev/null
> +++ b/arch/arm/dts/imx6ulz-14x14-evk-u-boot.dtsi
> @@ -0,0 +1,8 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2022 NXP
> + */
> +
> +&pinctrl_uart1 {
> +       u-boot,dm-pre-reloc;
> +};
> diff --git a/board/freescale/mx6ullevk/mx6ullevk.c b/board/freescale/mx6ullevk/mx6ullevk.c
> index 86c11c7bd3a..87bdbe51c6d 100644
> --- a/board/freescale/mx6ullevk/mx6ullevk.c
> +++ b/board/freescale/mx6ullevk/mx6ullevk.c
> @@ -24,10 +24,6 @@
>
>  DECLARE_GLOBAL_DATA_PTR;
>
> -#define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |            \
> -       PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |               \
> -       PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
> -
>  int dram_init(void)
>  {
>         gd->ram_size = imx_ddr_size();
> @@ -35,16 +31,6 @@ int dram_init(void)
>         return 0;
>  }
>
> -static iomux_v3_cfg_t const uart1_pads[] = {
> -       MX6_PAD_UART1_TX_DATA__UART1_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
> -       MX6_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
> -};
> -
> -static void setup_iomux_uart(void)
> -{
> -       imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
> -}
> -
>  int board_mmc_get_env_dev(int devno)
>  {
>         return devno;
> @@ -57,8 +43,6 @@ int mmc_map_to_kernel_blk(int devno)
>
>  int board_early_init_f(void)
>  {
> -       setup_iomux_uart();
> -
>         return 0;
>  }

Can you not just drop the entire board_early_init_f function and also
the matching CONFIG_BOARD_EARLY_INIT_F=y option too?

[PATCH 04/11] imx: mx6ull/z_14x14_evk: clean up UART iomux

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> After DM_SERIAL, and set pinctrl_uart1 as pre-reloc, no need initialize
> iomux at board file.
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 05/11] imx: mx6sllevk: correct pmic name

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

The prefix 0 has been dropped in dts, so correct in board file

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 board/freescale/mx6sllevk/mx6sllevk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/mx6sllevk/mx6sllevk.c b/board/freescale/mx6sllevk/mx6sllevk.c
index b4fddafe640..d9574623300 100644
--- a/board/freescale/mx6sllevk/mx6sllevk.c
+++ b/board/freescale/mx6sllevk/mx6sllevk.c
@@ -58,7 +58,7 @@ int power_init_board(void)
 	u32 switch_num = 6;
 	u32 offset = PFUZE100_SW1CMODE;
 
-	ret = pmic_get("pfuze100@08", &dev);
+	ret = pmic_get("pfuze100@8", &dev);
 	if (ret == -ENODEV)
 		return 0;
 
-- 
2.36.0

[PATCH 05/11] imx: mx6sllevk: correct pmic name

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> The prefix 0 has been dropped in dts, so correct in board file
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 06/11] imx: mx6sllevk: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm/dts/imx6sll-evk-u-boot.dtsi  |  8 ++++++++
 board/freescale/mx6sllevk/mx6sllevk.c | 16 ----------------
 configs/mx6sllevk_defconfig           |  1 +
 configs/mx6sllevk_plugin_defconfig    |  1 +
 4 files changed, 10 insertions(+), 16 deletions(-)
 create mode 100644 arch/arm/dts/imx6sll-evk-u-boot.dtsi

diff --git a/arch/arm/dts/imx6sll-evk-u-boot.dtsi b/arch/arm/dts/imx6sll-evk-u-boot.dtsi
new file mode 100644
index 00000000000..14d0b58949a
--- /dev/null
+++ b/arch/arm/dts/imx6sll-evk-u-boot.dtsi
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2019, 2021 NXP
+ */
+
+&pinctrl_uart1 {
+	u-boot,dm-pre-reloc;
+};
diff --git a/board/freescale/mx6sllevk/mx6sllevk.c b/board/freescale/mx6sllevk/mx6sllevk.c
index d9574623300..10a00095aff 100644
--- a/board/freescale/mx6sllevk/mx6sllevk.c
+++ b/board/freescale/mx6sllevk/mx6sllevk.c
@@ -24,10 +24,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |		\
-	PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |		\
-	PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
 int dram_init(void)
 {
 	gd->ram_size = imx_ddr_size();
@@ -35,20 +31,10 @@ int dram_init(void)
 	return 0;
 }
 
-static iomux_v3_cfg_t const uart1_pads[] = {
-	MX6_PAD_UART1_TXD__UART1_DCE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
-	MX6_PAD_UART1_RXD__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
-};
-
 static iomux_v3_cfg_t const wdog_pads[] = {
 	MX6_PAD_WDOG_B__WDOG1_B | MUX_PAD_CTRL(NO_PAD_CTRL),
 };
 
-static void setup_iomux_uart(void)
-{
-	imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
-}
-
 #ifdef CONFIG_DM_PMIC_PFUZE100
 int power_init_board(void)
 {
@@ -94,8 +80,6 @@ int power_init_board(void)
 
 int board_early_init_f(void)
 {
-	setup_iomux_uart();
-
 	return 0;
 }
 
diff --git a/configs/mx6sllevk_defconfig b/configs/mx6sllevk_defconfig
index 39a15ae830e..ea46071626a 100644
--- a/configs/mx6sllevk_defconfig
+++ b/configs/mx6sllevk_defconfig
@@ -51,6 +51,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_IMX_THERMAL=y
 CONFIG_USB=y
diff --git a/configs/mx6sllevk_plugin_defconfig b/configs/mx6sllevk_plugin_defconfig
index 47d82540aca..885dda716c1 100644
--- a/configs/mx6sllevk_plugin_defconfig
+++ b/configs/mx6sllevk_plugin_defconfig
@@ -52,6 +52,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_IMX_THERMAL=y
 CONFIG_USB=y
-- 
2.36.0

[PATCH 06/11] imx: mx6sllevk: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 07/11] imx: mx6slevk: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 configs/mx6slevk_defconfig        | 1 +
 configs/mx6slevk_spinor_defconfig | 1 +
 configs/mx6slevk_spl_defconfig    | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/mx6slevk_defconfig b/configs/mx6slevk_defconfig
index 018df1bbfaf..3dba1b357e1 100644
--- a/configs/mx6slevk_defconfig
+++ b/configs/mx6slevk_defconfig
@@ -59,6 +59,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
diff --git a/configs/mx6slevk_spinor_defconfig b/configs/mx6slevk_spinor_defconfig
index 5351d03510d..c970271dae8 100644
--- a/configs/mx6slevk_spinor_defconfig
+++ b/configs/mx6slevk_spinor_defconfig
@@ -59,6 +59,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
diff --git a/configs/mx6slevk_spl_defconfig b/configs/mx6slevk_spl_defconfig
index 85dc039347e..4863c729097 100644
--- a/configs/mx6slevk_spl_defconfig
+++ b/configs/mx6slevk_spl_defconfig
@@ -74,6 +74,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

[PATCH 07/11] imx: mx6slevk: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 08/11] imx: mx6ul_evk: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 configs/mx6ul_14x14_evk_defconfig | 1 +
 configs/mx6ul_9x9_evk_defconfig   | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/mx6ul_14x14_evk_defconfig b/configs/mx6ul_14x14_evk_defconfig
index 1f1bff1e0c7..bd7b4211c76 100644
--- a/configs/mx6ul_14x14_evk_defconfig
+++ b/configs/mx6ul_14x14_evk_defconfig
@@ -85,6 +85,7 @@ CONFIG_PINCTRL_IMX6=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
diff --git a/configs/mx6ul_9x9_evk_defconfig b/configs/mx6ul_9x9_evk_defconfig
index 0b9c1003cdc..8bc7bf4f5e5 100644
--- a/configs/mx6ul_9x9_evk_defconfig
+++ b/configs/mx6ul_9x9_evk_defconfig
@@ -80,6 +80,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

[PATCH 08/11] imx: mx6ul_evk: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 09/11] imx: mx6sxsabreauto: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi       |  4 ++++
 board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 16 ----------------
 configs/mx6sxsabreauto_defconfig                |  1 +
 3 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi b/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi
index 549461df71e..7812aa34ee1 100644
--- a/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi
+++ b/arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi
@@ -14,3 +14,7 @@
 		compatible = "jedec,spi-nor";
 	};
 };
+
+&pinctrl_uart1 {
+	u-boot,dm-pre-reloc;
+};
diff --git a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
index 7340a344023..c7fe11fff0b 100644
--- a/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
+++ b/board/freescale/mx6sxsabreauto/mx6sxsabreauto.c
@@ -33,10 +33,6 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define UART_PAD_CTRL  (PAD_CTL_PKE | PAD_CTL_PUE |		\
-	PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED |		\
-	PAD_CTL_DSE_40ohm   | PAD_CTL_SRE_FAST  | PAD_CTL_HYS)
-
 #define ENET_PAD_CTRL  (PAD_CTL_PUS_100K_UP | PAD_CTL_PUE |     \
 	PAD_CTL_SPEED_HIGH   |                                   \
 	PAD_CTL_DSE_48ohm   | PAD_CTL_SRE_FAST)
@@ -59,11 +55,6 @@ int dram_init(void)
 	return 0;
 }
 
-static iomux_v3_cfg_t const uart1_pads[] = {
-	MX6_PAD_GPIO1_IO04__UART1_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
-	MX6_PAD_GPIO1_IO05__UART1_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
-};
-
 static iomux_v3_cfg_t const fec2_pads[] = {
 	MX6_PAD_ENET1_MDC__ENET2_MDC | MUX_PAD_CTRL(ENET_PAD_CTRL),
 	MX6_PAD_ENET1_MDIO__ENET2_MDIO | MUX_PAD_CTRL(ENET_PAD_CTRL),
@@ -81,11 +72,6 @@ static iomux_v3_cfg_t const fec2_pads[] = {
 	MX6_PAD_RGMII2_TXC__ENET2_RGMII_TXC | MUX_PAD_CTRL(ENET_PAD_CTRL),
 };
 
-static void setup_iomux_uart(void)
-{
-	imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
-}
-
 static int setup_fec(void)
 {
 	struct iomuxc *iomuxc_regs = (struct iomuxc *)IOMUXC_BASE_ADDR;
@@ -216,8 +202,6 @@ int board_ehci_hcd_init(int port)
 
 int board_early_init_f(void)
 {
-	setup_iomux_uart();
-
 	return 0;
 }
 
diff --git a/configs/mx6sxsabreauto_defconfig b/configs/mx6sxsabreauto_defconfig
index 78780a8c706..3e8ba780929 100644
--- a/configs/mx6sxsabreauto_defconfig
+++ b/configs/mx6sxsabreauto_defconfig
@@ -64,6 +64,7 @@ CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_PFUZE100=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_DM_REGULATOR_GPIO=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

[PATCH 09/11] imx: mx6sxsabreauto: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 10/11] imx: mx6sabreauto_defconfig: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 configs/mx6sabreauto_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig
index bf6aff8e48e..2566f2a97fc 100644
--- a/configs/mx6sabreauto_defconfig
+++ b/configs/mx6sabreauto_defconfig
@@ -96,6 +96,7 @@ CONFIG_PINCTRL_IMX6=y
 CONFIG_POWER_LEGACY=y
 CONFIG_DM_REGULATOR=y
 CONFIG_POWER_I2C=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

[PATCH 10/11] imx: mx6sabreauto_defconfig: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================

[PATCH 11/11] imx: mx6sabresd: select DM_SERIAL

[Peng Fan (OSS)]

From: Peng Fan <peng.fan@nxp.com>

Select DM_SERIAL

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 configs/mx6sabresd_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/mx6sabresd_defconfig b/configs/mx6sabresd_defconfig
index 26cee0eae60..43c668ce5af 100644
--- a/configs/mx6sabresd_defconfig
+++ b/configs/mx6sabresd_defconfig
@@ -104,6 +104,7 @@ CONFIG_POWER_LEGACY=y
 CONFIG_DM_REGULATOR=y
 CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_POWER_I2C=y
+CONFIG_DM_SERIAL=y
 CONFIG_MXC_UART=y
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
-- 
2.36.0

Re: [PATCH 11/11] imx: mx6sabresd: select DM_SERIAL

[Fabio Estevam]

Hi Peng,

On Mon, Nov 7, 2022 at 4:14 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
>
> From: Peng Fan <peng.fan@nxp.com>
>
> Select DM_SERIAL

When converting to DM_SERIAL, please also remove setup_iomux_uart()
from the board code.

Re: [PATCH 11/11] imx: mx6sabresd: select DM_SERIAL

[Peng Fan]

On 11/15/2022 2:58 AM, Fabio Estevam wrote:
> Hi Peng,
> 
> On Mon, Nov 7, 2022 at 4:14 AM Peng Fan (OSS) <peng.fan@oss.nxp.com> wrote:
>>
>> From: Peng Fan <peng.fan@nxp.com>
>>
>> Select DM_SERIAL
> 
> When converting to DM_SERIAL, please also remove setup_iomux_uart()
> from the board code.

No, the SPL not use DM_SERIAL. For mx6sabresd, it supports 3 boards,
limited SRAM made is hard to enable the DM feature.

Thanks,
Peng.

Re: [PATCH 11/11] imx: mx6sabresd: select DM_SERIAL

[Fabio Estevam]

Hi Peng,

On Tue, Nov 15, 2022 at 6:17 AM Peng Fan <peng.fan@oss.nxp.com> wrote:
>
> No, the SPL not use DM_SERIAL. For mx6sabresd, it supports 3 boards,
> limited SRAM made is hard to enable the DM feature.

setup_iomux_uart() is not called in SPL. It is called inside U-Boot proper.

[PATCH 11/11] imx: mx6sabresd: select DM_SERIAL

[sbabic]

> From: Peng Fan <peng.fan@nxp.com>
> Select DM_SERIAL
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
Applied to u-boot-imx, master, thanks !

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,        Managing Director: Erika Unter  
HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@denx.de
=====================================================================