From owner-freebsd-arm@FreeBSD.ORG Sat Mar 2 21:53:25 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 B6538296; Sat, 2 Mar 2013 21:53:25 +0000 (UTC) (envelope-from Daan@vitsch.nl) Received: from Prakkezator.VEHosting.nl (Prakkezator6.VEHosting.nl [IPv6:2001:1af8:2100:b020::142]) by mx1.freebsd.org (Postfix) with ESMTP id 39FA8396; Sat, 2 Mar 2013 21:53:24 +0000 (UTC) Received: from [192.168.45.11] (Alk01.VEHosting.nl [85.17.51.130]) (authenticated bits=0) by Prakkezator.VEHosting.nl (8.14.2/8.14.2) with ESMTP id r22LrKSd066765; Sat, 2 Mar 2013 22:53:20 +0100 (CET) (envelope-from Daan@vitsch.nl) From: Daan Vreeken Organization: Vitsch Electronics To: Ian Lepore Subject: Re: PHYSADDR Date: Sat, 2 Mar 2013 22:53:21 +0100 User-Agent: KMail/1.9.10 References: <1362155645-2157952719.da2bf251f6@bliksem.vehosting.nl> <1362155632.1195.120.camel@revolution.hippie.lan> In-Reply-To: <1362155632.1195.120.camel@revolution.hippie.lan> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201303022253.21210.Daan@vitsch.nl> x-ve-auth-version: mi-1.1.7 2011-02-21 - Copyright (c) 2008, 2011 - Daan Vreeken - VEHosting x-ve-auth: authenticated as 'pa4dan' on Prakkezator.VEHosting.nl 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 21:53:25 -0000 Hi all, On Friday 01 March 2013 17:33:52 Ian Lepore wrote: > On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: > > On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: > > > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > > >> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > > >>> Starting to look at what is needed for a Generic ARM kernel. > > >>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > > >>> > > >>> First up: Can we get rid of PHYSADDR? > > >> > > >> If you mean, can we get rid of it within the runtime kernel, I'd say > > >> yes, because we can use a global variable instead which is easily > > >> settable in the entry code. > > > > > > It doesn't seem to be used in the runtime kernel. As far as > > > I can see, it's purely a bootstrap concept. > > Well, it's used to set up the early-init page tables in locore.s then > again to set up the real page tables and related things in initarm() and > then I think it isn't used after that, so I should have said "within the > kernel init". The main point I was getting at is that I don't think we > need a compile-time constant of any sort related to the physical address > at which the kernel is loaded. We can get the physical address of the > entry point (_start) using pc-relative math, and we can get the linker > to give us a constant symbol which is the offset of the _start symbol > within the load image. So we can get the load address at runtime > without guessing what low-order bits to mask. I like this approach. We have a board on which the bootloader loads a small= =20 binary blob that's in front of the kernel together with the kernel, all in= =20 one go. This results in the kernel living at an offset of a number of pages= =20 from the start of RAM. This means that this : > > _kpa_base =3D pc & 0xF0000000; wouldn't work. Calculating the exact location of the start of the kernel im= age=20 would work on all boards and memory/loader configurations. Regards, =2D-=20 Daan Vreeken Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 =2D- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/