Re: [microblaze-uclinux] Porting help

[aurash <aurelian.lazarut@xxxxxxxxxxx>]

Rich,

please try the attached c code for testing the SDRAM
I still belive that you have a SDRAM aliasing (could be something wrong 
in your ucf file)
Try it out and let me know.



Aurash


Richard Klosinski wrote:

>You image works on my vertex based system, but not on the Spartan 3 system.
>I got the spartain3 xilinx image by doing the following:
>
>1) Changing the ucf srdam pins to those of my design.
>2) changing the ucf console and debug pins to those of my design.
>3) changing the project setting to a spartan3-400
>4) killing the existing ram component in the mhs, and adding the one that
>fits the board (copied from a project build for the spartain 3 board).
>
>OK. Here is what we know:
>
>A) printk and console does not work. I tested each by adding a call to the
>sendbyte routines somewhere at the beginning of main.c, and I got stuff on
>my terminal screen. 
>
>B) The kernel is hung in machine_halt. Call stack is:
>Main.c/start_kernel calls mem_init (after calibrate_delay) 
>Init.c/mem_init calls create_memmap_holes
>Init.c/create_memmap_holes calls free_boot_node
>Bootmem.c/free_bootmem_node calls free_bootmem_core
>Bootmem.c/ free_bootmem_core calls __bug which end up at machine_halt.
>
>C) I tested the memory outside of linux with a alternating pattern and a
>walking 1x17. Also, I did a stupid test of writing and reading from memory
>using gdb with the image.elf loaded. All work.
>
>So:
>
>A) What does printk rely on to work? 
>B) Why is the memory failing?
>
>I agree, I bet its something stupid and will require me to type a character
>or two to fix it.
>
>Rich
>
>-----Original Message-----
>From: owner-microblaze-uclinux@itee.uq.edu.au
>[mailto:owner-microblaze-uclinux@itee.uq.edu.au] On Behalf Of John Williams
>Sent: Thursday, October 07, 2004 3:21 AM
>To: microblaze-uclinux@itee.uq.edu.au
>Subject: Re: [microblaze-uclinux] Porting help
>
>Hi Richard,
>
>John Williams wrote:
>
>  
>
>>Today's been megahectic - if I get a chance tonight or tomorrow I'll 
>>shrink a stock mbvanilla_net down to 8MB and see if I can duplicate your 
>>problem.
>>    
>>
>
>OK, here's what I did:
>
>Take a clean CVS uClinux-2.4.x kernel
>Modify the mbvanilla link script to 8MB of RAM
>Modify include/asm-microblaze/mbvanilla.h ERAM_SIZE to 8MB
>copy your .config file into linux-2.4.x/.config
>make menuconfig, save and exit etc etc
>make
>
>I download this image.bin to my regular (ie 32MB) mbvanilla platform - 
>it worked first time, clean boot, no errors, shell prompt etc etc.
>
>This image.bin is attached, give it a go on your platform.  If it works, 
>it means you've accidentally broken something in your local kernel - 
>just repeat my steps above and you'll be laughing.
>
>(One thing I'm curious about, in your first messaegs to the uclinux-dev 
>list, you had a booting kernel, but it broke on entry to userland. 
>what's changed?)
>
>Anyway next, I tweaked a standard mbvanilla_net MHS file by just 
>truncating the external RAM (DDR, but it shouldn't matter) down to 8MB. 
>  Built this system, configured it, downloaded the same kernel image, 
>and again everything works - snippet of bootlog to prove it:
>
>Linux version 2.4.27-uc0 (jwilliam@g435-9029) (gcc version 2.94
>On node 0 totalpages: 2048
>zone(0): 2048 pages.
>zone(1): 0 pages.
>zone(2): 0 pages.
>CPU: MICROBLAZE
>Console: xmbserial on UARTLite
>Kernel command line:
>Calibrating delay loop... 1.77 BogoMIPS
>Memory: 8MB = 8MB total
>Memory: 6336KB available (1084K code, 674K data, 44K init)
>Dentry cache hash table entries: 1024 (order: 1, 8192 bytes)
>Inode cache hash table entries: 512 (order: 0, 4096 bytes)
>Mount cache hash table entries: 512 (order: 0, 4096 bytes)
>Buffer cache hash table entries: 1024 (order: 0, 4096 bytes)
>Page-cache hash table entries: 2048 (order: 1, 8192 bytes)
>POSIX conformance testing by UNIFIX
>...
>
>So, if my image.bin works for you, problem solved.  If my image.bin 
>*doesn't* work, then it seems there's still an issue in your hardware 
>somewhere.  We'll just keep chipping away until you find it.  The fact 
>that you got an OK kernel boot late last week but not now suggests 
>hardware is probably fine - chances are you've just nudged something in 
>the kernel and forgotten about it - a fresh start will probably solve 
>the problem.
>
>  
>
>>Once we solve this, it really, really, really needs to be a FAQ!
>>    
>>
>
>I'm thinking I should just parameterise the ERAM_START and ERAM_SIZE 
>into the kernel config - any comments from interested parties?
>
>Regards,
>
>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/
>
>
>  
>

#include "stdio.h"
#include "xparameters.h"
#include "xuartlite_l.h"
#include "mb_interface.h"

int main(void)
{
int i,j,k;
int *mem;
int fill_value = 0x00000001;

//basic uart test
print ("hello world\r\n");
for (k=0;k<1;k++){

  //fill in values at consecutive addresses
mem= (int*)0x80000000;
for (i=0;i<4194304;i++)
	{
	*mem = i;
	//j= *mem;
	//putnum(i);
	//print("\t");
	//putnum(j);
	//print("\r\n");
	mem++;
	}
//read back these values
mem = (int*)0x80000000;
for (i=0;i<4194304;i++)
	{
	j= *mem;
	if (i != j){
	print("ADDRESS=");
	putnum (mem);
	print("\tfill_value=");
	putnum(i);
	print("\tread=");
	putnum(j);
	print("\r\n");
	}
	mem++;
	}

print("\n\r done OK!");
}
print("\n\rdone!");
for (;;);
}