From owner-freebsd-arm@FreeBSD.ORG Tue Mar 5 01:09:47 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 A4723674; Tue, 5 Mar 2013 01:09:47 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by mx1.freebsd.org (Postfix) with ESMTP id 791E370C; Tue, 5 Mar 2013 01:09:47 +0000 (UTC) Received: from c-24-8-232-202.hsd1.co.comcast.net ([24.8.232.202] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1UCgNx-000B7U-5k; Tue, 05 Mar 2013 01:09:41 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r2519bnD092298; Mon, 4 Mar 2013 18:09:37 -0700 (MST) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.232.202 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/94X/mmuXPv8yApyQWgqGL Subject: Re: GENERIC kernel issues From: Ian Lepore To: Tim Kientzle In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 Mar 2013 18:09:37 -0700 Message-ID: <1362445777.1195.299.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit 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: Tue, 05 Mar 2013 01:09:47 -0000 On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote: > > ** PHYSADDR/KERNPHYSADDR hardwiring. Ian has made a > lot of progress and I'm working on some related changes to > address this. I think we understand how to eliminate these > constants and replace them with run-time detection of the > load address. I'm still not sure what changes might be needed > to the loader to make this work. I don't think anything more needs to be done to the loader to be able to load a kernel built with the ldscript changes, beyond the change I did a week or two ago to make it work right with elf headers that contain physical addresses. 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. -- Ian