Re: [Etherboot-developers] currticks function

[<ke...@us...>]

>development board has this chip). I noticed that there is a mistake in 
>the cs89x0.h file. You have defined
>
>#define TX_AFTER_ALL    0x0060       /*  Tx packet after all bytes copied */
>
>but I think that it should be
>
>#define TX_AFTER_ALL    0x00c0

Hmm, I don't have a data sheet to double check this. Maybe Markus
Gutschke, who wrote the driver, can comment.

>Why you decided to use poll instead of interrupts ? The cs89x0 drivers 
>uses poll but I didn't check the rest of the drivers.

All of Etherboot uses polling. As explained in the history, this is the
way the original was designed, and this design aspect has not been
changed.  In practice, there isn't anything wrong with polling. If you
are thinking you are missing packets due to polling, all the protocols
involved are synchronous so interrupts don't help there.  Polling makes
the drivers easier to write and debug, especially with a system just
booted from raw metal---try debugging an asynchronous system someday.
The drawback is that it makes callbacks hard.

>All the transactions over the network seem to be fine. The problem is 
>that sometimes the tftp process of the etherboot does not "read" the 
>data of one block and the tftp server fails, because it never receives 
>an ACK. Notice that the block that the process fails is not the same for 
>all the times.

According to the RFC, in this case the server is supposed to timeout and
resend the packet. It's not supposed to start a new session.  Things to
check: Are you sure that you are generating and checking for a unique
XID in the DHCP packet? That's how the client knows if the DHCP reply is
meant for it. Have you checked that you are using the same tftp session
that's offered by the server? There is some subtlety in the way the
client switches the port number after receiving the ACK and starting the
transfer, read the TFTP RFC carefully.  If you reimplemented this part
of the code yourself, you might have missed this subtlety.