[U-Boot-Users] eth_rx implementation

[U-Boot-Users] eth_rx implementation

[Rodel Miguel]

Hi All, 

I am having problems implementing my eth_rx function.  I have seen
from other implementations that eth_rx will return any packet that has
been received from the network, however, if there are no data to
retrieve, i.e. NetReceive(NetRxPackets[0], 0),  the PING function
re-sends the ping request in at most two times.

I have implemented a polling eth_rx function.  Of course there should
be no packet type checking on this level, however, is the network loop
function checking if the packets for a specific network command is
satisfied, and if not, what does our network loop do?

Thank you for your time.

Best Regards,
Rodel

[U-Boot-Users] eth_rx implementation

[Wolfgang Denk]

In message <698a2fda0503060044189b8b1c@mail.gmail.com> you wrote:
> 
> I am having problems implementing my eth_rx function.  I have seen

And what exactly is your problem?

> from other implementations that eth_rx will return any packet that has
> been received from the network, however, if there are no data to

Rigth.

> retrieve, i.e. NetReceive(NetRxPackets[0], 0),  the PING function
> re-sends the ping request in at most two times.

Yes, but this is a different issue and  unrelated  to  the  implemen-
tation of eth_rx.

> I have implemented a polling eth_rx function.  Of course there should
> be no packet type checking on this level, however, is the network loop

OK.

> function checking if the packets for a specific network command is
> satisfied, and if not, what does our network loop do?

I'm not exactly sure what you are asking here. Are there any problems
with your eth_rx code  as  you  claimed  above,  or  did  you  modify
anything in the NetLoop() function, or what?

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 witty saying proves nothing, but saying  something  pointless  gets
people's attention.

[U-Boot-Users] eth_rx implementation

[Rodel Miguel]

Hi Wolfgang, 

I'm sorry I wasnt clear enough with my query.  

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

Questions:

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?

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?

3. Do you need to enable a U-Boot configuration flag to support my
implementation of eth_rx?

I am currently having problems with my eth_send implementation, so
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.

Thank you very much for your help.

Best Regards,
Rodel

On Sun, 06 Mar 2005 10:26:00 +0100, Wolfgang Denk <wd@denx.de> wrote:
> In message <698a2fda0503060044189b8b1c@mail.gmail.com> you wrote:
> >
> > I am having problems implementing my eth_rx function.  I have seen
> 
> And what exactly is your problem?
> 
> > from other implementations that eth_rx will return any packet that has
> > been received from the network, however, if there are no data to
> 
> Rigth.
> 
> > retrieve, i.e. NetReceive(NetRxPackets[0], 0),  the PING function
> > re-sends the ping request in at most two times.
> 
> Yes, but this is a different issue and  unrelated  to  the  implemen-
> tation of eth_rx.
> 
> > I have implemented a polling eth_rx function.  Of course there should
> > be no packet type checking on this level, however, is the network loop
> 
> OK.
> 
> > function checking if the packets for a specific network command is
> > satisfied, and if not, what does our network loop do?
> 
> I'm not exactly sure what you are asking here. Are there any problems
> with your eth_rx code  as  you  claimed  above,  or  did  you  modify
> anything in the NetLoop() function, or what?
> 
> 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 witty saying proves nothing, but saying  something  pointless  gets
> people's attention.
>

[U-Boot-Users] eth_rx implementation

[Wolfgang Denk]

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

[U-Boot-Users] eth_rx implementation

[Rodel Miguel]

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
>