Many new developers are likely to encounter at least half of the following
common problems, which are raised often on the
mailinglist.
Keep this section in mind to refer to when you spot the symptom.
You don't ever want to change
KERNELLOAD or
KERNELBASE, otherwise the
virtual memory and
MMU code will all break. Search for
KERNELBASE.
The watchdog is enabled by default, and needs to be disabled at reset for
anything including
BDM to work.
The usual non-obvious cause of this is combining executables compiled with
-fsoft-float and shared libraries compiled with
-fhard-float, or
vice-versa. See
FloatingPoint.
In particular, remember to remove (or correct the cache line assumptions in)
sysdeps/powerpc/memset.S before building
glibc-2.1.3.
This has little to do with floating point. Nearly all instructions the
processor can't decode are vectored to this function. It assumes the primary
reason you are here is to emulate floating point instructions. If the function
can't decode the instruction as a floating point operation, it is really
something the processor can't execute, so the panic message spews forth.
This can be either a software or hardware bug. If it is a software bug, just
unravel the stack backtrace and debug it. It could be a trashed stack frame,
resulting in a bad function return address, or some indirect function call that
was not properly computed.
It could also happen because of a hardware bug while fetching instructions from
memory. Verify the NIP instruction that it tried to decode is what is really
supposed to be at that location in memory. This is a typical failure when the
UPM is not programmed correctly. On a custom board in particular, verify all
memory cycles an a logic analyser. Disable the cache and try again, you will
probably get a different result.
This message is the result of some changes to the IP stack software in Linux
version 2.2.x +. This simply means that you are unable to connect to your NFS
server. It may be related to the driver, but it may also be related to other
issues, such as NFS server not running or incorrectly installed, no physical
connectivity to NFS server, etc. Check the configuration of your NFS server and
IP network before diving into the driver.
Either you don't have an
init program of some type (even
/bin/sh) in your
root filesystem, or you don't have enough shared libraries and the program
can't be loaded properly, although you often get messages about not able to
load some
.so. Usually the problem is missing or misplaced shared libraries.
To start up
/bin/sh, which is a good thing to try initially, you need the
entire set of glibc shared libraries and
libtermcap.so. If you're using the
MontaVista
CDK, you get these from the
glibc and
termcap
RPMs, and remember you also need that funky sym link:
/opt/hardhat/devkit/ppc/8xx/powerpc-hardhat-linux -> / in the target
filesystem.
You can find out which shared libraries any binary requires using
ldd(1), but
it only runs on the target and isn't much use if you're cross-developing and
can't even start a shell yet. A shell script which runs on the host and does
much the same thing is available at
http://lists.linuxppc.org/listarcs/linuxppc-embedded/200102/msg00011.html
