LMA != VMA when compiling a kernel

[Rafal Jaworowski]

On 2009-05-21, at 22:18, Guillaume Ballet wrote:

> I am still working on a port of FreeBSD to the beagleboard, and am
> currently working on enabling the VM. So far, I have loaded the kernel
> at phys_addr = virt_addr = 0x80000000, because that is where the RAM
> is. However, when enabling the VM, I would like the kernel virtual
> addresses to start with 0xC0000000 as they do on most other platform.
>
> Hence, I have been trying to set the ELF file sections' VMAs to
> something starting with 0xC and the LMAs to something starting with
> 0x8. It turns out that just setting KERNPHYSADDR and KERNVIRTADDR is
> not enough >.< If found a way to do this by chaning the script linker
> and adding AT after each section declaration, and it works fine. But
> it's tedious, hacky and lots of hardcoded values only work with my
> platform.

What exactly are your problems with getting 0xC0000000 as the KVA  
base? It seems that all our current ARM variations follow this route  
and they all use a single linker script, so there shouldn't be major  
problems doing likewise with yet another port..

> Googling for ideas, I found that there has been some discussion about
> it barely a year ago. Yet, it doesn't seem to have yielded any
> tangible result. Would someone have addressed the progress in the mean
> time?
>
> I guess another way to look at it would be to work it around by also
> porting a full-fledged loader(8). A task which I have delayed to until
> I get a booting kernel - maybe not the wisest move :) Still, I'm
> curious about the possibility of specifying distinct LMAs and VMAs for
> the kernel executable.


The loader(8) entity is separate from how the kernel is linked, so I  
don't think that problems with kernel virtual addresses you mention  
could be worked around at the loader(8) level. Kernel linking/mapping  
should be addressed independently of any booting method involved.

Rafal