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