From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 17:51:50 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B9347AA9 for ; Wed, 6 Mar 2013 17:51:50 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 832B0AED for ; Wed, 6 Mar 2013 17:51:50 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id x4so3739583obh.16 for ; Wed, 06 Mar 2013 09:51:50 -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=i1Zh0/QzyOGcCH/D2DK5PaxHaHzS9qtGG/nslgg5rjQ=; b=bfqxAQpbnr0bJxBXaJMsYJOrWC+5rBMjGgC8kkOlncNzq3nipBLtTE16lqFVRGrEX2 vd2NFnD4+zAlWQP2pmQfU0JOpxkci+O0o5pSj5COKyXnRnrHqhIO1ZgTVqy5nWWP2YGE QzmAAOM6DbR5mDWsrhY40eptisjSC94kp1b+jS3CXapd1ia+4vSwnwe9ZaQ8Q3/3hluo O4OJdwdbkA0UVtmRDdY6eEezkgOmlTkQ0MSR2WIZChKv9ifJSezFOQi5jchihFwGdLIy Ii79EwrYFuHG7KDiEA3+AkoK34FJFmWjfvrx+xgXAil2JUYVpAEspnLawO6T+qIJ6/Wr Outw== X-Received: by 10.60.10.102 with SMTP id h6mr23276818oeb.14.1362592310078; Wed, 06 Mar 2013 09:51:50 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id ri1sm38496653obc.12.2013.03.06.09.51.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 09:51:48 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Warner Losh In-Reply-To: Date: Wed, 6 Mar 2013 10:51:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQlEO4o6mm/Rhzq5Fd0Js3bqC9ewT2D3FMH/smXLSR8kN+r2tSlTq4qk/wm8a76unwzVaW4N Cc: freebsd-arm@FreeBSD.org, Ian Lepore 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:51:50 -0000 On Mar 6, 2013, at 10:36 AM, Tim Kientzle wrote: >>>>>=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. >>=20 >> 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. >>=20 >>> 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. >>=20 >> Right, but can't we get that from the virtual address. >>=20 >>> 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. >>=20 >> 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. >>=20 >> I guess I'm being dense this morning.. I'm not sure I understand what = the big deal is=85 >=20 > Ian is NOT talking about the kernel here. >=20 > He's talking about UBLDR, which is an ELF image > loaded by U-Boot. >=20 > The techniques used for the kernel (which we > all agree on and which Ian has partly implemented > already) don't seem to be applicable here. (I don't want > to change U-Boot's ELF loader, nor should UBLDR > be messing with the MMU.) >=20 > So we're stuck for now with linking UBLDR separately > for each memory address at which UBLDR gets run. > The obvious answer is to have UBLDR be a static PIC > binary and not ELF. If you see another approach, I'm > interested. OK. I'm back with you now, and I agree. ubldr does run in PA, and what = I've said don't apply... Unless we make ubldr PIC, so I think we're on = the same page here... We could create our own mapping, but we'd have to totally trash that = just before jumping to the kernel, which I'm at best luke warm to since = that kind of code has to be in assembler... I think that static PIC = binary would be easier... Warner=