More ramblings/work on Octeon

[Andrew Duane]

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 at juniper.net       Westford, MA  01886-3418