Date: Thu, 26 May 2011 15:44:14 -0400 From: Andrew Duane <aduane@juniper.net> To: "mips@freebsd.org" <mips@FreeBSD.org> Subject: More ramblings/work on Octeon Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB57B1D924A@EMBX01-WF.jnpr.net>
next in thread | raw e-mail | index | archive | help
I've completed the first stage of my work on our Octeon blades, and have 2 ramblings to ramble about before I send out some diffs. 1) I still constantly get the KASSERT panic "sched_priority: invalid priority". I don't really know why this is a KASSERT, so I just changed it to bound the computed priority at PRI_MIN_BATCH and PRI_MAX_BATCH (it was always going over the MAX). Nothing has caught fire yet after 24 hours (as opposed to <5 minutes to KASSERT). This isn't really a MIPS issue, but has anyone seen it, or know why this is a KASSERT and not just a limit check? 2) I also have to work around a panic in pmap_pte that was trying to reference something at 0x9800000010100800. This is in the PCPU area, but I think it's out of range and causes a bus error. Only bringing up one CPU makes the system stable. On to the work I've finished: I've completed support for using either the octeon_bootinfo structure currently used by the octeon port, or the generic MIPS bootinfo structure from bootinfo.h (which our bootstraps use). The entire boot path is now completely agnostic, and has a switch point to determine the boot interface by looking at the magic numbers in the a0-a3 registers passed in at start and calling the appropriate init routine. Right now, octeon_bootinfo and bootinfo are the only two options, but there's an architecture in place to add more as needed. This also includes a more open architecture to add new platforms. The bootinfo structure now has an optional platform extension structure that can be defined in a platform-specific file along with defining BOOTINFO_PEXT. That triggers the main bootinfo.h to add the field to the main structure. This seems a better way to manage additions, and I am going to move our in-house code to use it. All traces of octeon_bootinfo are now gone from outside octeon_machdep.c (it is made static to insure it doesn't creep out again). Everything needed is copied into the cvmx_sysinfo structure (available through cvmx_sysinfo_get() in the Octeon SDK), or read directly from the hardware as needed. Some of the fields are really just hardware registers, and it's actually faster to read from them than reference a structure member. There are some things not included in cvmx_sysinfo_minimal_initialize from the SDK, I just added the other fields we need directly. Maybe someone has a better idea. There is some other cleanup work such as platform_start_ap now checks to see if cores are still in reset and releases them first. Some bootstraps do not start all cores before calling the kernel. -- Andrew Duane Juniper Networks 978-589-0551 10 Technology Park Dr aduane@juniper.net Westford, MA 01886-3418
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC6674AB7BC78549BB231821ABF7A9AEB57B1D924A>