From owner-freebsd-mips@FreeBSD.ORG Mon Apr 4 13:56:11 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 40B64106564A; Mon, 4 Apr 2011 13:56:11 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by mx1.freebsd.org (Postfix) with ESMTP id CC6268FC0C; Mon, 4 Apr 2011 13:56:05 +0000 (UTC) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKTZnN9f79008CU/U5JpeNbXSWZ23fpsEZ@postini.com; Mon, 04 Apr 2011 06:56:10 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 4 Apr 2011 06:52:39 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Mon, 4 Apr 2011 09:54:18 -0400 From: Andrew Duane To: Warner Losh , Juli Mallett Date: Mon, 4 Apr 2011 09:54:17 -0400 Thread-Topic: Toiling away on booting the new blades Thread-Index: AcvyaiberMh33B3ET1GWbiFvy7B75AAZBOrb Message-ID: References: <153BB57A-6F99-4E5C-9F39-55D6C3B210FC@bsdimp.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 13:56:11 -0000 This is actually something I wanted to understand better. I'm spending a lo= t of time in octeon_machdep.c, and the file seems to be a combination of Ca= vium SDK code (or at least SDK-derived code) and some stuff FreeBSD did its= elf. I'm trying to understand which is which, and what I should try hard to= keep intact for future SDK drops. The file does seem to have a split in th= e middle, with a separate block comment about provenance, and the structure= definitions are a bit muddled. The cvmx_bootinfo_t structure is from Cavium? It has a lot of baggage that = we really don't use. About 3/4 of it is completely unused (some is used in = the Linux application stuff, but not in the kernel), and some of the rest i= s easily derived from querying the hardware. That's what we do in JUNOS. Th= ings like core count, clock speed, etc. are just register reads on the chip= . Even memory size (that dreaded phy_mem_desc_addr) is really much more eas= ily described. The u-boot provided with the SDK allows the user to carve up= memory into different spaces for various things, but that's really not use= d. You just need the "top of memory" which bootinfo provides, then use the = simulator path in octeon_memory_init (which I assume is FreeBSD code?) to a= ssign phys_avail[1], and away you go. But, if the structure is from the SDK, I will leave it be. In fact, I still= have to synthesize a structure so things like the enet driver (mac_addr) a= nd CF driver (compact_flash_common_base_addr) will work. I would just like = to know what code in there is fair game. I've spent a lot of time working o= n Octeon startup code, but we dumped pretty much all of the SDK in this are= a and rolled our own. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr aduane@juniper.net Westford, MA 01886-3418 ________________________________________ From: Warner Losh [imp@bsdimp.com] Sent: Sunday, April 03, 2011 9:45 PM To: Juli Mallett Cc: Andrew Duane; mips@freebsd.org Subject: Re: Toiling away on booting the new blades 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 c= ode in the startup path something you'd be interested in taking in? >> >> I think I'd be interested. I think this is a decent path to explore, bu= t would need to see code before committing :) > > 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. > > 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 modular= ity in how we hook up the bootloader-> kernel handoff for embedded systems = for a while, and this will help that goal. Warner