Date: Sat, 30 May 2009 13:24:12 +0000 From: Guillaume Ballet <gballet@gmail.com> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel Message-ID: <fd183dc60905300624r64914527wd7700a22a797a645@mail.gmail.com> In-Reply-To: <20090521.145552.410235390.imp@bsdimp.com> References: <fd183dc60905211318v67d77378t4100f3a0035124ed@mail.gmail.com> <20090521.145552.410235390.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> : 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?
There's not much to share actually: I tried to use the AT keyword in
the script linker. What I did was essentially:
--- conf/ldscript.arm 2009-05-30 14:05:44.000000000 +0000
+++ conf/ldscript.arm.lma 2009-05-30 14:05:24.000000000 +0000
@@ -8,7 +8,7 @@
{
/* Read-only sections, merged into text segment: */
. = KERNVIRTADDR + SIZEOF_HEADERS;
- .text : AT(KERNPHYSADDR + SIZEOF_HEADERS)
+ .text :
{
*(.text)
*(.stub)
Doing so, I was able to change the LMA for the text section. The
problem is that address arithmetic doesn't seem to work that well
inside AT() - so at this moment I am unable to do this for _every_
section. I'm sure it should be possible, but haven't found the time to
study this just yet. I don't think I will investigate this any
further: Indeed, locore.S sets up a temporary TLB system to be able to
access virtual addresses during boot.
If someones knows the syntax to do address calculations inside AT(),
however, I am interested nonetheless :) I was thinking about using
something like MEMORY, but that idea needs some thinking through.
>
> 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.
I am indeed running from SD card. I face two choices: My first choice
is to load everything with u-boot prior to starting the kernel. The
other one is to have the whole loader(8) facility. Since the first
choice requires some tedious typing in u-boot, I would love to have a
loader(8) script to do all the dirty work for me :D But it can wait.
Cheers,
Guillaume
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fd183dc60905300624r64914527wd7700a22a797a645>