| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
* ne2000/ne2000.c: Remove #define __INSIDE_RTEMS_BSD_TCPIP_STACK__.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* ne2000/ne2000.c: Fix some errors in the driver.
1. There was no sufficient check of data in ethernet header.
The code in ne_rx_daemon() was:
inport_word (dport, len);
...
len -= 4;
...
if (len > 0)
ne_read_data (sc, startaddr, len, p);
Unfortunately, sometimes my NIC gave me too big len value,
the result was memory override. To fix this, I added ethernet
header data checking.
2. The way overrides were serviced was not good. It was complex
but sometimes did not provide reliable continuing of NIC working.
I had the situation of an endless loop in ne_check_status()
after override processing.
3. There was conceptual error of porting. The old method of
overrides curing was ported from the OS-s, where override-processing
did start immediately. But RTEMS-version uses events, and cleaning
of the overrides can start later.
I selected the way of ne2000 programming that is used
in freebsd kernel (v4.0).
Because of both problems, incorrect data in header of raw packet
and receiver override, it went through ne_reset() and fully
reset the ne2000.
So, in summary
- added detecting of the incorrect data in ethernet header;
- replaced handling of receiver overrides with new scheme,
via resetting of NIC, this method is used also in case of
invalid header detecting.
|
| |
|
| |
|
| |
|
|
|
|
| |
register support to this driver.
|
|
|
|
|
|
| |
Erik Ivanenko pointed out a problem in the ne2000.c driver I
submitted: it did not work correctly with bootp. Here is a patch,
based on a patch he sent me.
|
| |
|
|
Both the ne2000 and the wd80x3 are based on the National Semiconductor
8390 chip, so there is a fair amount of overlap between the two
drivers. It would be possible in principle to combine some code into
a separate set of subroutines called by both. In fact, the drivers in
both OpenBSD and Linux work this way. I didn't bother, because for
the relatively simple drivers used by RTEMS, the overlap is not
especially large, and any reasonable use of subroutines would lead to
slightly less efficient code.
This ne2000 driver uses two transmit buffers. While one packet is
being transmitted over the Ethernet, RTEMS will upload another. Since
uploading a packet to the ne2000 is rather slow, I don't think there
is any point to having more than two transmit buffers. However, the
code does make it possible, by changing NE_TX_BUFS, although that
would of course reduce the number of receive buffers.
I suspect that the wd80x3 driver would benefit slightly from copying
the multiple transmit buffer code. However, I have no way to test
that.
|