From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 19:33:18 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 B63AEE59 for ; Wed, 6 Mar 2013 19:33:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mx1.freebsd.org (Postfix) with ESMTP id 6A4BF179 for ; Wed, 6 Mar 2013 19:33:17 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id j6so13306239oag.36 for ; Wed, 06 Mar 2013 11:33:17 -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=6rCackKKNBCzrY8GXZuP5LlcA8l9Rr01aHQ3X9CR2/w=; b=L6LRLY9y1AI71i7qL6cK7M7iE7ZPSUy997Rf3x8OiVQbVip9IaB00mgvLDdKHbC2pe lZKV8iPO2stZAnQKe7qVmEzxBK8g/zCRVgjVOL4g2Q8jMlv64uV+ANy9OafEvwyH/Jpr QMxDDowg9kjapUZXAudr0grKVKBo8P8gBoTWYGaJSYJ5A3J2FOi1wCrUrw6/irIq/KR3 MAk67CH64NslNqkCQVHMUq8HrpOcMyEGFAQB2bQYzVg2W4t1h6UVzgSgVwAV2h+6Ph2y NF2Rzn4O4oL9xtkPqENgAn2dG3axLdZVj9/6WWWmE5U+cyLKdzyi9DL04TkrQvBvnWD7 /r0g== X-Received: by 10.60.25.35 with SMTP id z3mr23339942oef.98.1362598396725; Wed, 06 Mar 2013 11:33:16 -0800 (PST) Received: from fusionlt2834a.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id ri1sm38827181obc.12.2013.03.06.11.33.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 11:33:15 -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: <1362594744.1291.132.camel@revolution.hippie.lan> Date: Wed, 6 Mar 2013 12:33:11 -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> <1362594744.1291.132.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQnxAJC8oHxW1WfkeNoq4e6Ydfc/y2oPYLbq8Y7ZO/BxzconriaKKSHPvQcFJz/aDQuaUyg4 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 19:33:18 -0000 On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote: > On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: >> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: > [...] >>> 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 > Not always. You can always figure out the right virtual address if = you > have the physical (you just OR-in 0xC0000000), but you can't always go > the other way. If all you know is 0xC0010000 you have no idea whether > the underlying physical address might be 0x00010000 or 0x80010000. = Our > current code that assumes you can do phys=3Dpc&0xf0000000 is wrong for = the > same reason (but has been working okay by accident). The phys segment is pc & 0xf0000000 before you turn on the MMU (assuming = 256MB chip select offsets, adding another F would get that down to 16MB = chip selects, which is definitely good enough). After we MMU start, it = isn't, and our code shouldn't do that, unless it is followed by oring in = the physical segment... > That's part of why I've been working towards getting our arm ldscript = to > put proper physical addresses in the elf headers instead of virtual, = in > the fields that are supposed to have phsyical addresses in them (entry > and program-header paddr fields). But that doesn't matter for the kernel so much... > With this scheme SoC-specific kernels will be linked with PHYSADDR=3D = the > real physical address and can be loaded by any standard elf loader > because the headers are correct. A generic kernel will be linked with > PHYSADDR=3Doffset where offset is just the low-order part of the = address > and ubldr can load the kernel into whatever physical memory is = available > as long as the offset part stays the same. OK. That part makes perfect sense now. Warner=