Skip to main content.

20. Common Mistakes and Problems

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.

20.2. Leaving the Watchdog enabled

The watchdog is enabled by default, and needs to be disabled at reset for anything including BDM to work.

20.3. Mixing code compiled for software and hardware floating point

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.

20.4. Using an unmodified glibc

In particular, remember to remove (or correct the cache line assumptions in) sysdeps/powerpc/memset.S before building glibc-2.1.3.

20.5. "Kernel Mode Software FPU Emulation" panic

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.

20.6. NFS gives "neighbour table overflow"

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.

20.7. "Kernel panic: No init found..." on startup

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 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

19. Performance 1. Introduction 21. Alternatives
Prev Home Next