[PATCH v2 3/3] arch/arm/configs: Enable VMSPLIT_2G in imx_v6_v7_defconfig

[Alistair Francis]

On Tue, Feb 2, 2021 at 11:50 PM Arnd Bergmann <arnd at kernel.org> wrote:
>
> On Wed, Feb 3, 2021 at 3:37 AM Alistair Francis <alistair23 at gmail.com> wrote:
> >
> > On Thu, Jan 28, 2021 at 11:13 PM Shawn Guo <shawnguo at kernel.org> wrote:
> > >
> > > On Sun, Jan 17, 2021 at 10:03:01AM -0800, Alistair Francis wrote:
> > > > The reMarkable2 requires VMSPLIT_2G, so lets set this in the
> > > > imx_v6_v7_defconfig.
> > >
> > > Hmm, why is VMSPLIT_2G required by reMarkable2?
> >
> > I'm not too sure. It's difficult to debug problems as I only have a
> > UART but without this I don't see any kernel prints so it seems like
> > the kernel doesn't get very far. I haven't had any luck with earlycon
> > on the device so I don't know how I can get more information.
>
> In the dts file, I can see that the machine has 1GB of RAM at
> contiguous addresses. My first guess would be a problem with
> highmem, as this configuration means that with VMSPLIT_3G
> there are 768MB of lowmem and 256MB of highmem.
>
> Can you try these two things to narrow the problem down
> further?
>
> a) disable CONFIG_HIGHMEM when using VMSPLIT_3G
> b) use VMSPLIT_3G_OPT

Thanks Arnd,

I was working on testing the config changes you mentioned, but it
seems like all of them work now.

VMSPLIT_2G: Boots to userspace

VMSPLIT_3G && HIGHMEM: Boots to userspace

VMSPLIT_3G && !HIGHMEM: Boots to userspace

VMSPLIT_3G_OPT && HIGHMEM:Boots to userspace

>
> If both of them solve the problem, then highmem is likely
> the root cause. One possible issue might be that the boot
> loader loads the initramfs or the dtb into a location outside
> of the first 768 MB of lowmem where it is unreachable
> in the VMSPLIT_3G configuration.

It boots with u-boot, which I am building so I can change these addresses.

I'm guessing that I have changed the addresses at some point and now
it works. I'm going to drop this patch.

Alistair

>
>         Arnd