Make provision for gdb debugging in kernel (VMA != LMA)

[jrrk]

When vmlinux is created it expects to load at a virtual address high in memory, but a physical address of zero, this confuses gdb if you try to load the kernel using openocd/jtag, since most platforms do not have memory at a physical address of zero. This kernel config (LMA_OFFSET) allows loading into a physical memory address with virtual memory off (the normal case). The default case is to give the same behaviour as before.

[palmer-dabbelt]

While I'm not opposed to this an an idea, it looks like there are no other architectures that do this. I'm also not really sure this is a sane thing to do, as in general it's not possible to just load Linux like this -- for example, firmware and some devices could get confused. I think the right solution here will involve either kexec or re-loading Linux from the bootloader.

[sorear]

It's also not very compatible with KASLR (implementations of which move the kernel in physical memory so that the virtual address can be fully randomized and still use large pages).

[jrrk]

I don't think we should rule out a patch because other architectures don't do it that way. One of the benefits of RISCV is that we don't have to worry about the implementation limitations of legacy architectures. Forthermore this patch only affects the RISCV architecture. Right now the starting LMA field in the ELF file is zero, and we never use this address as a valid address in machine mode, because of the need to trap out NULL pointer accesses. If it seems like it would confuse users it could always be moved to the experimental CONFIG subset. I appreciate that the technique is incomplete unless necessary parts of firmware (such as the machine mode trap handler from coreboot or Berkeley-boot-loader) are moved to the head of the kernel, which breaks the model of having one kernel image that can run in simulation and in FPGA with completely different peripherals, but now that run/halt debug from gdb/openocd is available in Rocket (and presumably eventually other RISCV HDL implementations), we can allow ourselves the luxury of direct visibility of kernel booting, instead of having to resort to the indirect methods of the past. I realise KASLR is important in production but it will surely be turned off during initial kernel bring up on new hardware.