Skip to contentSkip to conversation

More 5282 network issues-development

U-Boot-Users NZG 3 participants 4 messages Apr 12, 2005

lore
Share & tools
lore

NZG

author
#0 lore raw

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.

author
#1 lore raw
Quoted 6 lines

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.

#2 lore raw
Quoted 4 lines · In message <[email protected]> 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

Signature · 4 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A conservative is a man who believes that nothing should be done for
the first time.                                   - Alfred E. Wiggam
#3 lore raw
In reply to NZG
Quoted 10 lines

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.

Quoted 6 lines

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.

Quoted 5 lines

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.

Signature · 1 line
Zachary P. Landau <[email protected]>