On 1 April 2014 11:05, Peter Maydell <peter.mayd...@linaro.org> wrote: > But note that there seems to be a bug or two in > the DATA read logic: our cutoff for tx frame too > long is tx_frame_len > 2032, but for the limit > case of 2032, if we add 14 for the ethernet header > and 4 for explicit CRC then we get 2050, which is > slightly larger than the tx_fifo buffer... I think > we either need to wind that 2032 value down or > enlarge the tx_fifo buffer, or possibly just tweak > the logic not to try to actually write the CRC bytes > into the FIFO since we promptly ignore them -- need > to check the h/w datasheet to find out which.
The datasheet isn't entirely clear on this point. It is fairly definite that the TX overrun check is done for tx_frame_len written as >2032, but it doesn't really say what happens if there's not enough space for the CRC. I rather suspect everybody is using this device with auto-CRC enabled anyway, and I have neither the hardware nor the time to experiment with it. I'll put together a patch that does something plausible and doesn't allow data buffer overruns; roughly, we separate the check for "can we put this word into the FIFO?" from the one for "should we transmit the packet now?". This is actually closer to the h/w behaviour, because the h/w doesn't auto-transmit the packet on a full FIFO in all cases -- unless you set the transmit-start threshold you have to explicitly write to a different register to say "now start transmitting". thanks -- PMM
