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>