From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 23:15:12 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 517E4C27 for ; Sat, 2 Mar 2013 23:15:12 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 222518B3 for ; Sat, 2 Mar 2013 23:15:12 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id c13so4992423ieb.9 for ; Sat, 02 Mar 2013 15:15:11 -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=RE2/nGtqrUyvRRBT3mb+5rZT3961THfJpkch4R5zqk0=; b=bVw02NUURFNKE0PJhNG72TlqZsi/2HXAmopRgDuyjxPOPEC+QVVS/N2XyhTmgHmytO WOcGzR9QLa1sDZqHzxWOa9NYqb0PqMan7P6pFq712/5vv6/dgxdFsTojd1VS7uEvw5Ap rI+njchynw+iowpsVtITYvVf3PLOMK8tne3wh01i+MGNW1Oe5l1jOjuRT1fbSO7vLni2 RgO6Uqoe1qRzW6tjzeVNyGfYGTuWBKbqEzqVF7NKjQ0IH0nMRF67kzxsT5IB/l/tZxjS EVe2ff5rrp5NvNJYcU8m4XNe9mnHZCrwWG7S8nnbKUljpGrCAqgy6hkrLLyI4UroXEUU RNqw== X-Received: by 10.43.125.199 with SMTP id gt7mr17324575icc.48.1362266111487; Sat, 02 Mar 2013 15:15:11 -0800 (PST) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPS id l2sm3963608igb.1.2013.03.02.15.15.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 15:15:10 -0800 (PST) Sender: Warner Losh Subject: Re: PHYSADDR Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1362246634.1195.178.camel@revolution.hippie.lan> Date: Sat, 2 Mar 2013 16:15:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07E4A3AF-DC56-4BD6-B564-3370C9716329@bsdimp.com> References: <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> <1362155632.1195.120.camel@revolution.hippie.lan> <5B622D1B-4EAE-4184-A194-DD14083A48B6@kientzle.com> <1362246634.1195.178.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQk8WBCJSX2pyip1Rx02gSOojzSU0JURNDyxQHsBuCFPLsZu5VL1afHQpfcy8PnBjNj2C0SF Cc: Tim Kientzle , 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: Sat, 02 Mar 2013 23:15:12 -0000 On Mar 2, 2013, at 10:50 AM, Ian Lepore wrote: > I'm not sure its safe to assume that (entry-pc & 0xfffff000) is the > beginning of the kernel; it's true now but need not be so. But that's > no big deal, we can tweak the linker script to give us the offset of = the > _start symbol so it'll work no matter what. We have total control over this, since we control the linker script that = puts locore.S at the front. > The more I ponder the fixed offset concept for a generic kernel the = more > it seems that it might be viable, providing that we require the use of > ubldr. Then we can make sure that ubldr is always linked at an offset > that doesn't overlap the kernel load offset. An offset number like = 1mb > or 4mb might work well for the kernel; it leaves lots of space for = ubldr > to be loaded down low in memory. I think putting the loader at a = lower > address than the kernel is required, because there's no upper bound on > the kernel size (I did a 27MB kernel last month -- it contains a huge > embedded md filesystem image). >=20 > This just pushes the real problem into ubldr, though, and that becomes > the non-generic component that has to be linked at a different = physical > address for each SoC. A kernel could still be loaded without ubldr, = but > it may need to be built in a non-generic way for some platforms. Why not compile ubldr -pic? Then it wouldn't matter where we get loaded, = we'll work... > So if we declare that this scheme is for generic kernels loaded by a > loader (ubldr or other) that is aware of the generic kernel scheme, > there's no need for the physical address fields in the elf headers to = be > interpretted as a real physical address that would work for a standard > elf loader. You can build kernels that work with a standard elf = loader, > but the generic kernel is not such a thing. =20 Correct. BTW, what do latter-day universal-boot linux kernels do? > In that case, the physical address and entry address fields in the > headers are all offsets. If physical ram on a given chip starts at > zero, then the headers would accidentally be right for a standard elf > loader. Otherwise the generic-aware loader is responsible for filling > in some high-order bits when interpretting the headers. >=20 > The PHYSADDR symbol (and its several name variations) at build time = now > becomes zero for a generic kernel or non-zero to generate a = SoC-specific > kernel that can be loaded by a standard elf loader. The symbol = doesn't > exist at all in the compilation, it's used only by the build system = and > is passed as a parameter to the linker. >=20 > There's another problem constant we haven't talked about yet: > STARTUP_PAGETABLE_ADDR, used by locore to build the early page tables. > It's the absolute physical address of an area of memory that doesn't > have any other important data in it, and won't get overwritten by > something before initarm() builds the real page tables. I think most > SoCs now put it way up high in memory "safely out of the way", but = that > won't work generically. We need 16K aligned to a 16K boundary, and > maybe it would work to use the area immediately preceeding the start = of > the kernel. We could require the kernel to be linked on a 16k = boundary > so that we can just blindly subtract 16K from the starting physaddr we > calculate; nice and easy. Maybe have ubldr responsible for this? And if you aren't booting with = ubldr using a custom loader, you're already into the land of unique = kernel build anyway, and can wire it there... Warner=