From owner-freebsd-mips@FreeBSD.ORG Fri Aug 27 19:57:45 2010 Return-Path: Delivered-To: freebsd-mips@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37D35106567A for ; Fri, 27 Aug 2010 19:57:45 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CC4448FC12 for ; Fri, 27 Aug 2010 19:57:44 +0000 (UTC) Received: by wwb34 with SMTP id 34so2092895wwb.31 for ; Fri, 27 Aug 2010 12:57:43 -0700 (PDT) Received: by 10.216.131.161 with SMTP id m33mr1388637wei.13.1282939058329; Fri, 27 Aug 2010 12:57:38 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.216.5.5 with HTTP; Fri, 27 Aug 2010 12:57:18 -0700 (PDT) In-Reply-To: <4C7800E6.4060803@adaranet.com> References: <4C77EB9F.4020705@adaranet.com> <20100827.113711.641066760578782485.imp@bsdimp.com> <4C7800E6.4060803@adaranet.com> From: Juli Mallett Date: Fri, 27 Aug 2010 12:57:18 -0700 X-Google-Sender-Auth: 01cIHIf5dyBSCvynx1kCClDhn-Q Message-ID: To: Patrick Mahan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-mips@freebsd.org" Subject: Re: Now partially booting on our CN58XX eval board 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: Fri, 27 Aug 2010 19:57:45 -0000 On Fri, Aug 27, 2010 at 11:16, Patrick Mahan wrote: > I have an engineer that thinks this would be fun to resolve, so I am lett= ing > him run with this for now. =A0Is this an address coming from the mii laye= r? I looked at the code and Warner's output a few weeks ago and it seems to be an address coming from the command queue code (cvmx-cmd-queue.{c,h} in the Simple Executive) or maybe it was the FPA code. I think I told Warner that it was happening because mbufs are put into the FPA and we don't have a way to create an ephemeral mapping given a physical address that is not direct-mappable. Making it so that your system won't allocate mbufs above 0x2.... is a quick hack to test that theory and a reasonable workaround for o32 (since Octeon really makes more sense with n64 kernels, at minimum) so I'd suggest modifying the memory setup code in octeon_machdep.c to not add any memory above 512M or whatever. If you have an engineer with some time, though, I'd suggest having them work on COMPAT_FREEBSD32 for o32, which should be around a day or two worth of work and would let you use an n64 kernel. :) Juli.