[U-Boot-Users] More 5282 network issues-development

[U-Boot-Users] More 5282 network issues-development

[NZG]

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.





 

[U-Boot-Users] Re: More 5282 network issues-development

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

[U-Boot-Users] Re: More 5282 network issues-development

[Zachary Landau]

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

-- 
Zachary P. Landau <kapheine@gmail.com>

[U-Boot-Users] Re: More 5282 network issues-development

[Wolfgang Denk]

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

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