[U-Boot] ppc4xx:tftp error

Tim Rachman
2010-10-26T07:21:50Z

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!