Date: Sat, 23 May 2009 18:43:31 +0200 From: Rafal Jaworowski <raj@semihalf.com> To: Guillaume Ballet <gballet@gmail.com> Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel Message-ID: <C6332D5C-8497-4209-ABE2-C535737A589B@semihalf.com> In-Reply-To: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com> References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C6332D5C-8497-4209-ABE2-C535737A589B>