From owner-freebsd-arm@FreeBSD.ORG Sat May 30 13:34:23 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 C2CE5106566B for ; Sat, 30 May 2009 13:34:23 +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 46FE28FC17 for ; Sat, 30 May 2009 13:34:23 +0000 (UTC) (envelope-from gballet@gmail.com) Received: by fxm7 with SMTP id 7so214783fxm.43 for ; Sat, 30 May 2009 06:34:22 -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=kkkdYcq/vxMVymEc4COjRYAK6zRA4YruzG2A4K63ELk=; b=kZ8HLYYBSuPfc3rlfsDXY1n2C9Ttmd0NvNUMLMH1rzrU+6LrRyTPRoxMYtw2d0Bb0u Eo6fYPVL1JSpmOIlqSZORnn1DWbMUl4hpxSQvbujLkYEVzk8CQZp5tiTlgX6bQMDeVw+ N0qosf6g75HNZt0wmz39U2Ano24zZvBpr3tZo= 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=mrJ3CDdWRHfSXiPPWKRhC7QXMYnI4FnSm9PEBvEtMKvY2uPKBYS+Ev4BTKmAZvt780 HuSqoFY/1BjK2ZCAoBtsI9sejZcdAQicXoPsTzCqQHKwMSXJaDGQNz7js7evOzE8qANA jYDIFKpyKncMU/5IRagk/bjQQZX1aDp7o3XxU= MIME-Version: 1.0 Received: by 10.204.55.200 with SMTP id v8mr3559573bkg.54.1243690462342; Sat, 30 May 2009 06:34:22 -0700 (PDT) In-Reply-To: References: Date: Sat, 30 May 2009 13:34:22 +0000 Message-ID: From: Guillaume Ballet To: Rafal Jaworowski 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:34:24 -0000 On Sat, May 23, 2009 at 6:43 PM, Rafal Jaworowski 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?