[U-Boot-Users] eth_rx implementation
wd at denx.de
Sun Mar 6 13:49:26 CET 2005
in message <698a2fda05030604151688be50 at 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, len)
> - return len
> 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
> 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
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.
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
More information about the U-Boot