From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:03:32 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A3C2F7F6 for ; Wed, 6 Mar 2013 17:03:32 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id 63373813 for ; Wed, 6 Mar 2013 17:03:32 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id k1so12854043oag.19 for ; Wed, 06 Mar 2013 09:03:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=snkWLHm0PmZJLcZVGIAAt+GypHn392iPX/MTB8NIbu0=; b=GuhrmLMVPpzQKoW9cSRPpqwHAff8/bbH+ar/3nmSkATFFYNRwktkCGpjhYjfztzEhR NRO4Gm3lbyqx8KJY7n69RwMMVHQuO8taoDwxFfJk97SZ7AbmKVN/HVqb1kZFEDUCldl9 m5MSvh7Gvw75UdouWzi6Ut3zyl7JJ2cDsi2fXqQmNJchgv/chb1iosNfRO1Ul+wdRr1u aEj2jkfg2j72mGtneAY2FNIAXVOvrUDvc8Mf4mBkTvqkf1IZTk6EsXNR5Bj5cPn8nnW/ OWEGCkJ06dwgbRUWTztITUrI5TYlFZin3eVGVNOdIG/tWW9HDuhmr5o0xIVUN4RZ/HCv B8cA== X-Received: by 10.60.3.10 with SMTP id 10mr24049156oey.61.1362589411761; Wed, 06 Mar 2013 09:03:31 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id ad19sm39507352oec.0.2013.03.06.09.03.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 09:03:30 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362542286.1291.94.camel@revolution.hippie.lan> Date: Wed, 6 Mar 2013 10:03:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlUhemW/lklDlfeJjhEaNnNzE1pYQJSOPDOkhLYxJOFVtchfbwDHg+i+PD7kMAzJD4pjwHL Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:03:32 -0000 On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > On Mon, 2013-03-04 at 21:30 -0700, Warner Losh wrote:=20 >> On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote: >>> On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: >>>>=20 >>>> ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a >>>> lot of progress and I'm working on some related changes to >>>> address this. I think we understand how to eliminate these >>>> constants and replace them with run-time detection of the >>>> load address. I'm still not sure what changes might be needed >>>> to the loader to make this work.=20 >>>=20 >>> I don't think anything more needs to be done to the loader to be = able to >>> load a kernel built with the ldscript changes, beyond the change I = did a >>> week or two ago to make it work right with elf headers that contain >>> physical addresses. >>>=20 >>> On the other hand, I haven't got anything to offer on the problem of = the >>> loader needing to be linked differently for each board or SoC, since >>> they all have physical memory in differing address ranges. >>=20 >> Well, the Phyiscal memory load address is just a hint after all. Any = way to leave it blank and have ubldr cope by putting it in the first = available phyiscal memory slot from the FDT? >>=20 >> Warner >>=20 >=20 > It's not just a hint, the executable is linked to run at that address > and no other. There is no relocation info in the file at all. That's > true of both the kernel and ubldr. It's also true of any old > static-linked executable, but in that case the object is just mapped = at > the virtual address it's linked for by the kern/imgact_elf.c code. It is just a hint, since we can load it at any physical address. Well, = almost any. But we can get the almost from the virtual part. > We essentially pull off the same mapping trick with the kernel, except > that very early in locore.s the code is carefully crafted to work = right > whether on physical or virtual addressing, just long enough to get the > MMU turned off. Then it sets up page tables to map the physical pages > the kernel has been loaded into to match the virtual addresses it was > linked for. All of that only works if the low-order bits of the = virtual > address it was linked for match the physical address it was loaded at. > That is, if linked for 0xC0001000 it must be loaded at 0xNNNN1000 > physical, where the N bits can be anything. Right, but can't we get that from the virtual address. > Unfortunately, I don't think we can pull the same kind of trick with > ubldr. In locore.s for the kernel we build simple page tables which = are > just enough to get us to the code in initarm() that builds them for > real. No SoC-specific stuff has to happen along the way (or if it = does, > SoC-specific code is invoked via various hooks to board support > routines). In ubldr we mess with the hardware (via the u-boot = drivers), > so if we turn on the MMU to map the memory ubldr is running from, we > also have to map the hardware va=3Dpa for those drivers to work. I = don't > know that there's any way to get the needed info for that from u-boot. So long as the code is PIC up until the time we turn on the MMU, then = we're fine. We can and should still do this in locore.S. I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is... Warner