From owner-freebsd-mips@FreeBSD.ORG Mon Apr 4 01:46:39 2011 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D467E106566B; Mon, 4 Apr 2011 01:46:39 +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 8E5A98FC15; Mon, 4 Apr 2011 01:46:39 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p341jTD5068103 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sun, 3 Apr 2011 19:45:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Sun, 3 Apr 2011 19:45:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <153BB57A-6F99-4E5C-9F39-55D6C3B210FC@bsdimp.com> To: Juli Mallett X-Mailer: Apple Mail (2.1082) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Sun, 03 Apr 2011 19:45:32 -0600 (MDT) Cc: "mips@freebsd.org" Subject: Re: Toiling away on booting the new blades X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 01:46:39 -0000 On Apr 3, 2011, at 5:19 PM, Juli Mallett wrote: > On Sun, Apr 3, 2011 at 15:07, Warner Losh wrote: >> On Apr 3, 2011, at 3:29 PM, Andrew Duane wrote: >>> Since the MIPS bootinfo structure is already part of FreeBSD, is = this code in the startup path something you'd be interested in taking = in? >>=20 >> I think I'd be interested. I think this is a decent path to explore, = but would need to see code before committing :) >=20 > Indeed, I think it's worth committing probably, or perhaps committing > a modified version that does the same thing. It's easy to imagine > that some people will eventually want to just use loader with U-Boot > on Octeon so that they can have hints, good UFS support, module > loading, etc. >=20 > Also, Warner, if you touch octeon_machdep.c, could you please move the > app boot descriptor thing to a separate header file with the Cavium > license? I believe I've touched all of the actual *source code* > there, but right now we're possibly violating the license (depending > on how big you believe a page is) which requires the license to be at > the top of the file. So I think moving the license and struct to a > separate header would be sufficient (using the structure from the > current SDK would probably be even better?) I'll look into it. I inherited the code from the Cavium folks, so if = there's a license violation, they did it to themselves :) Structurally, I think it would be better. I've wanted to have more = modularity in how we hook up the bootloader-> kernel handoff for = embedded systems for a while, and this will help that goal. Warner