public inbox for u-boot@lists.denx.de
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox