[U-Boot] ppc4xx:tftp error

[Tim Rachman]

Dear Stefan

Thank you very much for your replay!



Hi Tim,

On Sunday 24 October 2010 11:42:51 Tim Rachman wrote:
> According to your useful guides in our previous Emails, I examined again my
> ddr sdram parameters that i had set in u-boot. I'm interfacing
> HYB25D512160AT–7 to PPC440EP, with 133MHz plb frequency.

What SDRAM/DDR init code are you using? Is it arch/powerpc/cpu/ppc4xx/sdram.c?


Yes, I am. But I changed some parameters according to HYB25D512160AT–7 
datasheet.

> unfortunately, I couldn't reach to an stable state, without error, in tftp
> a file . So I have two questions:
> 
> At first: Would you mind to introduce me some useful links/Docs about
> initializing ddr sdram specially about testing memory in burst mode?

This is a complex subject. One of the best tests we've found so far, is 
running Linux and compiling a Linux kernel on an NFS mounted file system. This 
generates all kinds of access patterns to and from the SDRAM interface. This 
test showed problems on boards that previously ran all kind of "normal" RAM 
tests without errors.

I understand that this is not possible for you right now, since you will have 
problems loading a Linux kernel and especially mounting an NFS file system.



You're right. I changed DDR SDRAM parameters but error remains , 
error occurs randomly. I need to find a way for testing ram in similar condition 
(burst mode) rather than tftp, I haven't run OS, but I think even I run an OS , 
I will have error, specially in net related operations. 

> 2. I wrote for you " I monitored  *(hw_p->rx[user_index].data_ptr) data in
> ppc_4xx_eth_rx() function    in \driver\net\4xx_enet.c , and data was
> incorrect too at this stage. " , Is hw_p->rx[user_index].data_ptr the
> memory location of DMAing eth packets directly?

Yes, data_ptr as part of the mal_desc_t struct points to the data buffer. And 
the EMAC DMA controller (MAL) will transfer the data directly to and from this 
buffer.

Note that the PPC4xx ethernet driver is used on many platforms without any 
such problems. So I don't think that this driver is responsible for the 
problem you're facing. I share Wolfgangs feelings, that an SDRAM 
configuation/setup related problem is more likely. 


A point: Our custom board doesn't have PCI , Is it possible that some setting in 
PCI routins of yosemite BSP has effect on their shared PLB BUS?
BTW, I focus on SDRAM configuration more, Hopefully problem will be solved.
 
Again, I thank for your consideration!

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de