From owner-freebsd-mips@FreeBSD.ORG Thu May 26 19:47:04 2011 Return-Path: Delivered-To: mips@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EEEA106564A for ; Thu, 26 May 2011 19:47:04 +0000 (UTC) (envelope-from aduane@juniper.net) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by mx1.freebsd.org (Postfix) with ESMTP id 981978FC18 for ; Thu, 26 May 2011 19:47:03 +0000 (UTC) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP ID DSNKTd6uNhJe3uan5V3zFhigFEhSiSLwymoq@postini.com; Thu, 26 May 2011 12:47:03 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 26 May 2011 12:44:16 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 26 May 2011 15:44:15 -0400 From: Andrew Duane To: "mips@freebsd.org" Date: Thu, 26 May 2011 15:44:14 -0400 Thread-Topic: More ramblings/work on Octeon Thread-Index: Acwb3UsT936muxajSYGWfuD6+bEg8w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: More ramblings/work on Octeon X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2011 19:47:04 -0000 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