From owner-freebsd-arm@FreeBSD.ORG Tue May 26 17:13:23 2009 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FBAC10656AA for ; Tue, 26 May 2009 17:13:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5FA4B8FC08 for ; Tue, 26 May 2009 17:13:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id n4QHAaAx081800; Tue, 26 May 2009 11:10:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 26 May 2009 11:10:55 -0600 (MDT) Message-Id: <20090526.111055.1849561573.imp@bsdimp.com> To: tinguely@casselton.net From: "M. Warner Losh" In-Reply-To: <200905261551.n4QFpt1w084810@casselton.net> References: <20090524.163838.113805925.imp@bsdimp.com> <200905261551.n4QFpt1w084810@casselton.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: at91 SoC separation X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 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, 26 May 2009 17:13:24 -0000 In message: <200905261551.n4QFpt1w084810@casselton.net> Mark Tinguely writes: : : As a side, slightly off-topic note, I have been thinking of the whole boot : process. : : The different ARM architecture/board boot sequences are basically the same. : I agree that the main difference between the different ARM boards are the : difference in the locations of devices map. : : Right now, the init_arm() manually allocates the "level one" page tables : so they are available for the pmap_devmap_bootstrap() call. : : The devmap bootstrap can be modified to automatically allocate any missing : "level one" page tables from the end of the free memory pointer. The : updated end of free memory is sent back to the initialation routine. : Add a few calls for architecture initialization and ever board can use : the same boot routine. That's another can of worms that we need to detangle :) I rather like this idea. I also like the idea of having different boot loader front ends that drive this rather than having the SoC code drive it. We are a little too tightly coupled between boot loader and soc at the moment as well. The work isn't horribly hard, just tedious because you have to run down a bunch of different boards we support and see why the routines are different and account for those differences, or hopefully, eliminate them. It is the latter that's going to be a challenge. Warner