From owner-freebsd-arm@FreeBSD.ORG Sat May 30 13:24:13 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33294106566B for ; Sat, 30 May 2009 13:24:13 +0000 (UTC) (envelope-from gballet@gmail.com) Received: from mail-fx0-f163.google.com (mail-fx0-f163.google.com [209.85.220.163]) by mx1.freebsd.org (Postfix) with ESMTP id B3AA18FC12 for ; Sat, 30 May 2009 13:24:12 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by mail-fx0-f163.google.com with SMTP id 7so210948fxm.43 for ; Sat, 30 May 2009 06:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/+EKCOvaYVfWlJjyVDhwrVrjnSl1OLpf4uBIDFfvKFY=; b=kRR4zIjv7wodglrjsbUaWL8gj+yZ4j9/0hGYhfOXo73eHGCxHkPMsE2fFSqrR0HSaX Wh/sXjvXU+jzARse4YtDAF7j+NUcBQY5w1zbj1yQ9ene4geGyh4cR0YgzxiDKNRcPhU/ qaUvgcwV87UfXCprBQuSJ99MAmPb9RqS8drBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AfQ/uzd413wO56KRV9PEsI32rHBuaVZVGsS00ntGRoCBwREfDNG255HYQ/nd9nEpDn /5SpVllRRBU67CbuFnwsQ17VcgylvySOm7qrGUzK5g2ktSkAQR3gM447YnrYaPG2zD+Z LBryewFSpkTC47IYIzYnSgdNyzFItLgwGiHHo= MIME-Version: 1.0 Received: by 10.204.66.135 with SMTP id n7mr3549504bki.155.1243689852325; Sat, 30 May 2009 06:24:12 -0700 (PDT) In-Reply-To: <20090521.145552.410235390.imp@bsdimp.com> References: <20090521.145552.410235390.imp@bsdimp.com> Date: Sat, 30 May 2009 13:24:12 +0000 Message-ID: From: Guillaume Ballet To: "M. Warner Losh" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: LMA != VMA when compiling a kernel X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2009 13:24:13 -0000 > : 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