On Tue, Feb 2, 2021 at 11:50 PM Arnd Bergmann <arnd@xxxxxxxxxx> wrote: > > On Wed, Feb 3, 2021 at 3:37 AM Alistair Francis <alistair23@xxxxxxxxx> wrote: > > > > On Thu, Jan 28, 2021 at 11:13 PM Shawn Guo <shawnguo@xxxxxxxxxx> 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
