[PATCH] MIPS: ralink: mt7621: add memory detection support

[Ilya Lipnitskiy]

On Sat, Mar 27, 2021 at 2:46 AM Thomas Bogendoerfer
<tsbogend at alpha.franken.de> wrote:
>
> On Thu, Mar 25, 2021 at 07:45:23PM -0700, Ilya Lipnitskiy wrote:
> > On Thu, Mar 25, 2021 at 3:01 AM Thomas Bogendoerfer
> > <tsbogend at alpha.franken.de> wrote:
> > >
> > > On Tue, Mar 16, 2021 at 10:59:02PM -0700, Ilya Lipnitskiy wrote:
> > > > From: Chuanhong Guo <gch981213 at gmail.com>
> > > >
> > > > mt7621 has the following memory map:
> > > > 0x0-0x1c000000: lower 448m memory
> > > > 0x1c000000-0x2000000: peripheral registers
> > > > 0x20000000-0x2400000: higher 64m memory
> > > >
> > > > detect_memory_region in arch/mips/kernel/setup.c only adds the first
> > > > memory region and isn't suitable for 512m memory detection because
> > > > it may accidentally read the memory area for peripheral registers.
> > > >
> > > > This commit adds memory detection capability for mt7621:
> > > >   1. Add the highmem area when 512m is detected.
> > > >   2. Guard memcmp from accessing peripheral registers:
> > > >      This only happens when a user decided to change kernel load address
> > > >      to 256m or higher address. Since this is a quite unusual case, we
> > > >      just skip 512m testing and return 256m as memory size.
> > > >
> > > > [...]
> > >
> > > I get
> > >
> > > WARNING: modpost: vmlinux.o(.text+0x132c): Section mismatch in reference from the function prom_soc_init() to the function .init.text:mt7621_memory_detect()
> > > The function prom_soc_init() references
> > > the function __init mt7621_memory_detect().
> > > This is often because prom_soc_init lacks a __init
> > > annotation or the annotation of mt7621_memory_detect is wrong.
> > >
> > > Can you please fix this ?
> > Thanks, I will fix it. Having trouble reproducing the error, but I
> > clearly see the issue. Are you building on a MIPS target or
> > cross-compiling (I'm cross-compiling and no errors).
>
> I'm cross compiling, I can provide you the .config, if you want.
Yeah, that would help. I spent quite a bit of time trying to reproduce
- tried different options with GCC 8 and GCC 10 to no avail. Maybe you
are using clang?

Ilya