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