From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:40:25 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 4547962E; Wed, 6 Mar 2013 21:40:25 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from smtp.dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id BA733A1C; Wed, 6 Mar 2013 21:40:24 +0000 (UTC) Received: from rnote.ddteam.net (229-39-135-95.pool.ukrtel.net [95.135.39.229]) (Authenticated sender: ray) by smtp.dlink.ua (Postfix) with ESMTPSA id CB4B9C4947; Wed, 6 Mar 2013 23:40:21 +0200 (EET) Date: Wed, 6 Mar 2013 23:40:04 +0200 From: Aleksandr Rybalko To: Warner Losh Subject: Re: GENERIC kernel issues Message-Id: <20130306234004.bf113967.ray@freebsd.org> In-Reply-To: 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> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.2 (GTK+ 2.24.5; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 21:40:25 -0000 On Wed, 6 Mar 2013 12:33:11 -0700 Warner Losh wrote: > > 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. > >> > >> Right, but can't we get that from the virtual address. > > > > 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=pc&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= > > 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=offset 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 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Maybe we should just let ubldr to enable MMU for us? Like we do for i386, IIRC. WBW -- Aleksandr Rybalko