Date: Sun, 3 Apr 2011 16:07:37 -0600 From: Warner Losh <imp@bsdimp.com> To: Andrew Duane <aduane@juniper.net> Cc: "mips@freebsd.org" <mips@freebsd.org> Subject: Re: Toiling away on booting the new blades Message-ID: <153BB57A-6F99-4E5C-9F39-55D6C3B210FC@bsdimp.com> In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB52F1950D0@EMBX01-WF.jnpr.net> References: <AC6674AB7BC78549BB231821ABF7A9AEB52F1950D0@EMBX01-WF.jnpr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 3, 2011, at 3:29 PM, Andrew Duane wrote: > I've made real progress on getting our Octeon blades to boot with the = other bootstraps. After learning all about the app_descriptors and the = octeon_bootinfo structures, I've decided on a slightly more modular = approach. Rather than faking out the code by hand-crafting these = structures, I've decided to teach the Octeon startup code how decode a = standard MIPS bootinfo structure. FreeBSD already has this defined, and = I can make it do pretty much everything I want. It's also completely = deterministic as to which structure you have in "a3" based on the other = registers. >=20 > It turns out this is pretty simple. I added a parallel routine to = octeon_process_app_desc_ver_6 to parse a bootinfo and call = cvmx_sysinfo_minimal_initialize with the info I get from it. Very clean = and tidy, and minimal disruption. After that, everything else "just = works". I even found a routine to craft a phy_mem_desc structure, but it = doesn't look like I need it. >=20 > 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? I think I'd be interested. I think this is a decent path to explore, = but would need to see code before committing :) Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?153BB57A-6F99-4E5C-9F39-55D6C3B210FC>