Date: Fri, 27 Aug 2010 12:57:18 -0700 From: Juli Mallett <jmallett@FreeBSD.org> To: Patrick Mahan <pmahan@adaranet.com> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: Now partially booting on our CN58XX eval board Message-ID: <AANLkTinBe24BAiPc=X2e2wgCGbJ8tspVEf5XGK%2B93xJP@mail.gmail.com> In-Reply-To: <4C7800E6.4060803@adaranet.com> References: <4C77EB9F.4020705@adaranet.com> <20100827.113711.641066760578782485.imp@bsdimp.com> <4C7800E6.4060803@adaranet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Aug 27, 2010 at 11:16, Patrick Mahan <pmahan@adaranet.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTinBe24BAiPc=X2e2wgCGbJ8tspVEf5XGK%2B93xJP>