Date: Sat, 30 May 2009 13:34:22 +0000 From: Guillaume Ballet <gballet@gmail.com> To: Rafal Jaworowski <raj@semihalf.com> Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel Message-ID: <fd183dc60905300634q17c390bdwe1301d57d4ab83fc@mail.gmail.com> In-Reply-To: <C6332D5C-8497-4209-ABE2-C535737A589B@semihalf.com> References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com> <C6332D5C-8497-4209-ABE2-C535737A589B@semihalf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 23, 2009 at 6:43 PM, Rafal Jaworowski <raj@semihalf.com> wrote: > > 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.. The problem is not setting 0xC0000000 as the KVA base, it's that when KVA != KPA, the ELF header creates a file that has KVA == KLA anyway. Now, as I found out, most of the problems can be circumvented by setting up a temporary TLB system so that the startup code can still access its data segments even though the final VM system has not been initialized. The last remaining problem I face is that the loader (not loader(8) at the moment) needs to know the physical address at which the kernel must be loaded. But since KVA==LMA in the ELF header, some information is lost as far as I know. Now, if the loader for other boards is indeed able to extract that piece of information from the ELF header itself, I would love to get some pointers to the solution :) > > 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. > I agree, they should :P I am surely not searching at the right location, but I haven't found anything like a complete loader + boot stages in the source tree. Where should I look? I wonder if most system start in locore.S with the MMU already enabled from the loader, or most of them use the one that is built from scratch in that file?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60905300634q17c390bdwe1301d57d4ab83fc>