All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zachary Landau <kapheine@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: More 5282 network issues-development
Date: Tue, 12 Apr 2005 13:51:52 -0400	[thread overview]
Message-ID: <a04f56da050412105153de0e21@mail.gmail.com> (raw)
In-Reply-To: <200504121014.42518.ngustavson@emacinc.com>

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

      parent reply	other threads:[~2005-04-12 17:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-12 15:14 [U-Boot-Users] More 5282 network issues-development NZG
2005-04-12 15:51 ` [U-Boot-Users] " NZG
2005-04-12 20:05   ` Wolfgang Denk
2005-04-12 17:51 ` Zachary Landau [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a04f56da050412105153de0e21@mail.gmail.com \
    --to=kapheine@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.