Re: [microblaze-uclinux] (RNH) Real Novice Here

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Wade,

Wade.Maxfield@computalog.com wrote:

>    I'm new to this list.  I'm working with a "nu horizons" board, and have
> yet to get linux to boot past the "calibrating delay loop."  One of our
> hardware gurus built a microblaze into the Spartan II - 400 on this board,
> and made the dynamic ram refresh work.

Welcome!

>   I have the toolset on RedHat 8 under VMWARE 4.5, and have compiled the
> kernel.  As I said before, image.bin runs until the calibrating delay loop.
> I download using the latest for EDK release 6.2 using mbconnect mdm.

Sounds like you've got a reasonable build environment. that's a good start.

>   If anyone has a working mbvanilla to nu-horizons port of hardware, I
> would appreciate it very, very much.  

I'm not aware of one.  Looking at your MHS file though, I think you're 
almost there, see below.

>   Here is the linux sign on. I did a cvs update today so that I'd be sure
> to have the latest. It did have a multiple page allocation issue in the
> past, but not now:
> 
> Linux version 2.4.26-uc0 (root@cfwghost) (gcc version 2.95.3-4 Xilinx EDK
> 6.2.1
> Build EDK_Gm.12.3) #1 Mon Aug 2 11:33:23 CDT 2004
> On node 0 totalpages: 8192
> zone(0): 8192 pages.
> zone(1): 0 pages.
> zone(2): 0 pages.
> CPU: MICROBLAZE
> Console: xmbserial on UARTLite
> Kernel command line:
> Calibrating delay loop...
> 
> 
>   Any help would be _much_ appreciated. I'll add the mhs file, so you can
> see if we left something obvious out of our current almost working
> nu-horizons port.

Two things stand out.  Firstly, the kernel still thinks you have 32MB of 
physical memory (8192 pages).   However, in your MHS file, the address 
range of your SDRAM is only 8MB (0x80000000 - 0x807fffff).  So, assuming 
you are modifying the mbvanilla platform in the uClinux sources, you 
should edit linux-2.4.x/include/asm-microblaze/mbvanilla.h and change 
the ERAM_SIZE #define accordingly.

You should also get your hardware guys to tweak the system.mhs settings 
on icache and dcache.  There is some inconsistency that should be 
corrected (differing # of tag bits for icache vs dcache, stuff like 
that).  Unfortunately EDK/platgen doesn't yet do a sanity check on cache 
settings (or at least not last time I looked).

Secondly (and most critically), in your MHS file your declaration of the 
interrupt controller:

PORT Intr = timer_interrupt & console_uart_interrupt & debug_uart_interrupt

This is the reverse of the order expected by the mbvanilla uClinux 
target.  In your setup, timer is IRQ2, console_uart is IRQ1, debug_uart 
is IRQ0.  You want it the other way around.  This is almost certainly 
what is causing your delay loop calibration hang.

BTW You can start xmd and mb-gdb after the board has booted and hung. 
Just launch xmd, do your mbconnect, then follow the mb-gdb kernel 
debugging instructions on the website.  Once it connects, it will 
magically trap the microblaze where in the kernel source it is currently 
hung, great for doing retrospective "what went wrong?" analysis. 
Commands like "info stack" will show you the stack unwind, how you got 
into the current predicament!  "frame nn" where is is the stack frame 
number allow you to inspect local variables and parameters in the 
various stack frames etc.

Anyway hope this helps to get you moving again.

Cheers,

John

___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/