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 priori= ty". I don't really know why this is a KASSERT, so I just changed it to bou= nd 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 refere= nce 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 th= e system stable. On to the work I've finished: I've completed support for using either the octeon_bootinfo structure curre= ntly used by the octeon port, or the generic MIPS bootinfo structure from b= ootinfo.h (which our bootstraps use). The entire boot path is now completel= y agnostic, and has a switch point to determine the boot interface by looki= ng at the magic numbers in the a0-a3 registers passed in at start and calli= ng the appropriate init routine. Right now, octeon_bootinfo and bootinfo ar= e 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 tha= t can be defined in a platform-specific file along with defining BOOTINFO_P= EXT. That triggers the main bootinfo.h to add the field to the main structu= re. 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 (i= t is made static to insure it doesn't creep out again). Everything needed i= s copied into the cvmx_sysinfo structure (available through cvmx_sysinfo_ge= t() 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 se= e if cores are still in reset and releases them first. Some bootstraps do n= ot 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 =20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC6674AB7BC78549BB231821ABF7A9AEB57B1D924A>