All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodel Miguel <rodelfmiguel@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] eth_rx implementation
Date: Mon, 7 Mar 2005 07:47:28 +0800	[thread overview]
Message-ID: <698a2fda0503061547795133fd@mail.gmail.com> (raw)
In-Reply-To: <20050306124931.017E1C1510@atlas.denx.de>

Hi Wolfgang,

I was thinking that if you send an ARP request, the NetworkLoop will
wait for incoming data, i.e. block and wait for the correct ARP reply.
 That is why I was asking how many times that the NetworkLoop would
retry to send the data if an error in the receiving of ARP replies
occur.

Ok, I got to check the network layer code and throw a better question later.

Thank you very much for your help.

Best Regards,
Rodel


On Sun, 06 Mar 2005 13:49:26 +0100, Wolfgang Denk <wd@denx.de> wrote:
> Dear Rodel,
> 
> in message <698a2fda05030604151688be50@mail.gmail.com> you wrote:
> >
> > My implementation of eth_rx is somewhat like the ff:
> >
> > - check if data is available
> > - if not, return 0
> > - call NetReceive(NetRxPackets[0], len)
> > - return len
> 
> OK.
> 
> > 1. If network data is not available, eth_rx returns 0 and does not
> > call NetReceive(), how many times does NetworkLoop retry to send the
> > first data it requested?
> 
> What has sending to do with receiving?
> 
> > 2. If data is available, eth_rx calls NetReceive, however, if it is
> > not intended for the initial U-Boot request, how many times does does
> > NetworkLoop retry to send the first data it requested?
> 
> What exactly do you want to know? The transmit side (sendign of data)
> is completely independend from the receive side. If any data is sent,
> or if it might be resent, is only dependent on the current  state  of
> the protocol machine, i. e. which command is being executed.
> 
> You cannot make any statements about this from just  looking  at  the
> receive code.
> 
> > 3. Do you need to enable a U-Boot configuration flag to support my
> > implementation of eth_rx?
> 
> I don't even understand this question.
> 
> > I am currently having problems with my eth_send implementation, so
> 
> Arghhh. Now what exactly is it you re  asking  for?  First  you  talk
> about  ethernet  receive, then you raise protocol issues, and now you
> mention the transmit side?
> 
> > there are really no network requests done on the PHY layer yet,
> > however, the eth_rx can receive data, I just noticed that there's not
> > much error handlers on the higher layers.  The ARP requests are only
> > done twice, at least in PING command.
> 
> The network code contains a  small  (you  may  even  say  a  minimal)
> implementation  of some UDP based network protocols like BOOTP, DHCP,
> TFTP, and NFS. For details of the protocols please see  the  relevant
> RFC's.
> 
> Please be specific if you have any concerns that this  implementation
> might be incomplete or buggy.
> 
> If it's just that your ethernet transmit code doesn't  work  -  well,
> it's trivial to hook a debugger in the transmit routine and a network
> sniffer  (like  ethereal)  on  the  wire.  Same for the receive side.
> Retransmission of data does not play any role here.
> 
> 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
> I'm a programmer: I don't buy software, I write it.
>                                                   -- Tom Christiansen
>

      reply	other threads:[~2005-03-06 23:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-06  8:44 [U-Boot-Users] eth_rx implementation Rodel Miguel
2005-03-06  9:26 ` Wolfgang Denk
2005-03-06 12:15   ` Rodel Miguel
2005-03-06 12:49     ` Wolfgang Denk
2005-03-06 23:47       ` Rodel Miguel [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=698a2fda0503061547795133fd@mail.gmail.com \
    --to=rodelfmiguel@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.