[U-Boot] ppc4xx:tftp error

Stefan Roese
2010-10-25T08:40:12Z

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?

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

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