remarkable: ~/ uname -a
Linux remarkable 4.1.28-zero-gravitas-01897-g7f82abb869aa-dirty #256 Tue Sep 12 08:53:59 CEST 2017 armv7l GNU/Linux

https://github.com/reMarkable/linux/blob/zero-gravitas/arch/arm/configs/zero-gravitas_defconfig

remarkable: ~/ uname -a
Linux reMarkable 4.14.78 #1 SMP PREEMPT Fri Sep 4 14:30:06 UTC 2020 armv7l GNU/Linux

https://github.com/reMarkable/linux/blob/zero-sugar/arch/arm/configs/zero-sugar_defconfig

TODO: document notes on the existing kernel config

The kernel has himem set. When an arm device has enough ram this impacts the ability to allocate virtual memory and use all of ram. The Remarkable and Remarkable 2 both have no reason to have this on, and it impacts performance. A small change makes the system more responsive and have more throughput:

CONFIG_HIGHMEM=n

with this change we can see the virutal memory layout on boot has no impact to available memory. Nothing running on this device likely needs more than a gig of virtual memory on top, though if you are trying to run GHC you may have issues It may be prudent to change the kernel-userspace memory split as well, the remarkable stock has a 2G/2G split. A 1G/3G split would allow ~2G of virtually addressed space for user programs on top of available ram, which probably is sufficient for any reasonable processes on this device.

[    0.000000] Memory: 697656K/1048576K available (8192K kernel code, 585K rwdata, 2124K rodata, 1024K init, 407K bss, 23240K reserved, 327680K cma-reserved)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xc0800000 - 0xff800000   (1008 MB)
[    0.000000]     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
[    0.000000]     modules : 0x7f000000 - 0x80000000   (  16 MB)
[    0.000000]       .text : 0x80008000 - 0x80900000   (9184 kB)
[    0.000000]       .init : 0x80c00000 - 0x80d00000   (1024 kB)
[    0.000000]       .data : 0x80d00000 - 0x80d927c8   ( 586 kB)
[    0.000000]        .bss : 0x80d94000 - 0x80df9ea0   ( 408 kB)

The kernel has defaults from arch/arm for the contiguous memory allocator (CMA). This is a memory reservation in RAM that allows hardware to reserve places where memory is physically (rather than virtually) contiguous so that DMA may be more optimum. The default on arch/arm was set by google engineers in 2015 to be tailored for smartphone like devices, at 320 MB to allow big transfer regions between high density pixel planes like cameras, screens, GPU and accelerators. The Remarkable has no such hardware, and uses maybe a bit more than 32MB. Setting the option below recovers 256MB of active ram (and is still probably wasting like 31MB, but that is better than 287!!):

CONFIG_CMA_SIZE_MBYTES=64

Disclaimer: this information is only a rough examination and quite likely wrong. Please feel free to update and improve upon it.

Initial inspection of the kernel changes between the upstream 4.14.78 release and the patches applied by the remarkable team show mostly small changes in a few places. The biggest work seems to be in handling USB, with a custom module called otgcontrol added. Some of the work seems to be back ports of other patches to relevant hardware for the freescale SOC and the wifi chipset. More examination is needed.

This is a remarkable made module that acts as a state machine to change the OTG port modes. The USB-C port PHY acts as a ethernet gadget, and this module has a state machine to detect and change some conditions. From initial examination it seems to be a product of wanting to allow the Remarkable to act as a ethernet client and be able to receive charge from the host while doing so. It uses its state detection to push onewire bus changes to set the pinctrl and usb states so that the device will flow power in. This seems to be incomplete work leaving out the needed detection to act as an OTG host. Disabling their usb gadget interface and this module may make it possible to use the device as an OTG host in a more stock kernel without too much difficulty.