Date: Mon, 4 Apr 2011 09:54:17 -0400 From: Andrew Duane <aduane@juniper.net> To: Warner Losh <imp@bsdimp.com>, Juli Mallett <jmallett@FreeBSD.org> Cc: "mips@freebsd.org" <mips@FreeBSD.org> Subject: RE: Toiling away on booting the new blades Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB52F1950D3@EMBX01-WF.jnpr.net> In-Reply-To: <F63B0665-6215-4190-B9E3-DE6A34F5AA40@bsdimp.com> References: <AC6674AB7BC78549BB231821ABF7A9AEB52F1950D0@EMBX01-WF.jnpr.net> <153BB57A-6F99-4E5C-9F39-55D6C3B210FC@bsdimp.com> <BANLkTi=%2B0W8%2BCgpfXVtSwA7wzqcQu4T1vw@mail.gmail.com>, <F63B0665-6215-4190-B9E3-DE6A34F5AA40@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <imp@bsdimp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC6674AB7BC78549BB231821ABF7A9AEB52F1950D3>