Re: bcm33xx port

[Luke -Jr]

On Saturday 07 June 2008, Maciej W. Rozycki wrote:
> On Sat, 7 Jun 2008, Luke -Jr wrote:
> > > I'm not too up on MIPS but there're a few things in the log which stand
> > > out to me:
> > >
> > > Determined physical RAM map:
> > >  memory: 00fa0000 @ 00000000 (usable)
> > > User-defined physical RAM map:
> > >  memory: 007a1200 @ 00000000 (usable)
> > >
> > > Can you confirm these sizes and locations for RAM?  Does anything
> > > change if you don't force the size constraint?
> >
> > According to
> > http://research.msrg.utoronto.ca/ece344/2007s/os161/mips.html , MIPS has
> > a pretty odd memory layout, and I'm honestly not sure how Linux usually
> > handles it. I don't feel competent to try and summarize the details on
> > that page here.
>
>  Nothing odd about the memory layout I would say unless you want to go
> beyond 512MB with a 32-bit system which is not the case here.

Well, I always imagined memory layout as being a simple flat range from 0 to 
all_memory_in_system, but this is my first experience with it at such a low 
level, so I guess I don't know what's "odd" or "normal".

> > > CPU frequency 32.00 MHz
> > >
> > > Really?  Is your bootloader setting the CPU up correctly before handing
> > > control to Linux?
> >
> > The CPU is 200 MHz, I believe. The bootloader is just a part of VxWorks,
> > not really meant to boot anything else.
>
>  CFE is pretty much standard for Broadcom platforms and far from being
> specific to VxWorks.

VxWorks, including the boot loader, is not CFE as far as I am aware. If you're 
referring to the "CFEv2" in the log, that appears to be the default of a 
switch (eg, if Linux doesn't detect anything else).

>  I'd be more concerned about:
>
> Calibrating delay loop (skipped)... 0.00 BogoMIPS preset

The calibration code was crashing, so I set it to a fixed 1 value.
Worst case, some code won't delay as long as it wants to, right?

> > > Reserved instruction in kernel code[#1]:
> > >
> > > You're compiling with an appropriate -march switch?
> >
> > I believe so... It appears to be a "reserved instruction" only because of
> > the memory area it tries to access. The instruction in question is "store
> > word", nothing complex.
>
>  You have got something seriously broken -- __bzero traps exceptions on
> stores for graceful recovery as user addresses may be accessed as is the
> case here.  If the reserved instruction exception handler is reached, then
> clearly the store instruction is not the immediate cause.

What else could it be?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/