Problems with MontaVista Linux on a Memec Virtex-II pro ff672 board

[Mark A. Greer]

S. van Beek wrote:

> Hello there,
>  
> This is our first post on this list, hi all!
> We're two Dutch students working with a Virtex-II pro ff672 board from 
> Memec with the Communications 2 module. We've compiled a simple kernel 
> wich comes with MontaVista Linux 3.1 (2.4.20) with ethernet and a 
> serial port. It mounts its root filesystem over NFS and everything 
> seems to work nicely. The next step we wanted to make was 
> adding support for the Flash on the com board. We added the IP to the 
> hardware and loaded the new bitstream in the FPGA. Next thing, we 
> enabled support for MTD devices in the kernel. After that, the kernel 
> did not seem to boot anymore. It stopped at the message 'Now booting 
> the kernel'. So we read some documentation about debugging. We 
> recompiled this kernel with the -g -ggdb options and removed the -O 
> (optimalization) flag. Then we did not even see the ppc boot loader 
> messages anymore when trying to boot. So we tried to compile the first 
> kernel (with only serial and ethernet support) -wich worked fine 
> before- with debugging and it gave us the same result.. no output at all.
> Can anyone give us some hints on what we can try more to find out what 
> is going wrong?

There are lots of possible problems that may be causing this but my 
guess is that you are accessing some piece of hardware that you don't 
have ioremap'd/io_block_mapping'd.  IOW, you don't have a virt->phys 
translation set up for the hardware register you're trying to access.  
If you can find a COPS/JTAG debugger and your board has a connector, set 
it up and run your kernel again.  When it hangs stop the processor and 
dump the 'log_buf' that's in memory (you can get the address from your 
System.map file).  That's where printk msgs are logged before the 
console is set up.  In there you will likely see a panic msg and a 
register dump.  That should point you to where things went wrong.

If you don't have access to a debugger like that, you could try running 
KGDB.  If the kernel is running long enough to reach the initial 
breakpoint and you have correctly configured your code so that KGDB will 
work, that can be big help too.

Mark