[U-Boot-Users] More 5282 network issues-development
I'm currently working with Zachary Landau's port of the 5282, trying to get the network running correctly on a new 5282 based board with no pre-loader that boots from external flash. I'm running into some generic u-boot issues and I was running if anyone could help point me in the right direction. Any general comments or discussion on the items below would be helpful.
FEC_STRUCTURE This seems to be the subject of some debate, but looking over it, the fec structure in the CVS does appear to be incorrect. For instance, it only defines a single hash table uint fec_hash_table_high; /* upper 32-bits of hash table */ uint fec_hash_table_low; /* lower 32-bits of hash table */] Even thought the datasheet clearly indicates that there are two. How could this possibly be correct? Zach's structure does appear to be the correct one, and in fact is the only one I've had any success with at all.
HASH TABLES: Zach's code was clearing the individual hash table, but not the group hash table, The new code is currently clearing both tables, although I'm not technically sure this is correct as I'm really not that experienced with ethernet hash tables.
SPEED: The new code can download intact linux images with tftp, but it only works if ET_DEBUG is enabled. If it's not everything seems to run too fast and the code chokes itself(sends out big bursts of packets and then doesn't respond to the big bursts it gets back). How can I tell it to slow down and wait for responses without debug statements? Is there a place for this?
ICMP: Once the TFTP transaction gags, my tftpd server turns around and starts trying to ping the client to see if it's alive, but it never responds. Should it be? does the stack support this?
thx, NZG.
SPEED: The new code can download intact linux images with tftp, but it only works if ET_DEBUG is enabled. If it's not everything seems to run too fast and the code chokes itself(sends out big bursts of packets and then doesn't respond to the big bursts it gets back). How can I tell it to slow down and wait for responses without debug statements? Is there a place for this?
I think I see the problem, the network is expecting to be able to do ulong delays, while the timer is only 16 bits. I'm going to monkey with the timer code and see if I can get something set up.
NZG.
In message 200504121051.07764.ngustavson@emacinc.com you wrote:
I think I see the problem, the network is expecting to be able to do ulong delays, while the timer is only 16 bits. I'm going to monkey with the timer code and see if I can get something set up.
No matter how your timer is implemented internally, the external interface (at least as used by any code outside your cpu/*/ directory) should be based on the following rules:
* Arguments are unsigned long * CFG_HZ is set to 1000 * get_timer() and udelay() operate in milliseconds
Best regards,
Wolfgang Denk
FEC_STRUCTURE This seems to be the subject of some debate, but looking over it, the fec structure in the CVS does appear to be incorrect. For instance, it only defines a single hash table uint fec_hash_table_high; /* upper 32-bits of hash table */ uint fec_hash_table_low; /* lower 32-bits of hash table */] Even thought the datasheet clearly indicates that there are two. How could this possibly be correct? Zach's structure does appear to be the correct one, and in fact is the only one I've had any success with at all.
There's no debate. The structure is wrong. Wolfgang has requested a patch be submitted for it. I haven't had time to do it, but go for it if you do.
SPEED: The new code can download intact linux images with tftp, but it only works if ET_DEBUG is enabled. If it's not everything seems to run too fast and the code chokes itself(sends out big bursts of packets and then doesn't respond to the big bursts it gets back). How can I tell it to slow down and wait for responses without debug statements? Is there a place for this?
As you mentioned in your next email, this is probably an issue with the 5282 timer. The code I sent to you works for me, although I will not claim it is completely correct. I mucked around a bit with net.c while debugging, so there may or may not be things I changed in there that make it work. That isn't to say that net.c was wrong, but rather that my timer code may have been acting differently from how net.c expects.
ICMP: Once the TFTP transaction gags, my tftpd server turns around and starts trying to ping the client to see if it's alive, but it never responds. Should it be? does the stack support this?
I am able to use the 'ping' command once networking was setup. This is probably directly related to the timer issue.
participants (3)
-
NZG -
Wolfgang Denk -
Zachary Landau