Date: Thu, 21 May 2009 14:55:52 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: gballet@gmail.com Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel Message-ID: <20090521.145552.410235390.imp@bsdimp.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
In message: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com>
Guillaume Ballet <gballet@gmail.com> writes:
: 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.
This isn't a bad idea...
: 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.
Want to share?
: 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.
Its already there, but requires a lot of code in the primary boot
loader to call back into to do things like loading files and doing
network I/O.
Also, while a secondary boot loader makes sense in the higher end
booting environment where you have lots of storage (say an SD or CF
card), it doesn't make so much sense for a more constrained boot a
ramdisk from flash setup.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090521.145552.410235390.imp>