Now partially booting on our CN58XX eval board

[Juli Mallett]

On Fri, Aug 27, 2010 at 11:16, Patrick Mahan <pmahan at adaranet.com> wrote:
> I have an engineer that thinks this would be fun to resolve, so I am letting
> him run with this for now.  Is this an address coming from the mii layer?

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.