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?
