Allan,
I was also looking into adding an ne2000 driver to ELKS but if you do that
it is even better. This is the template I intended to start from:
https://github.com/RTEMS/rtems/blob/5eb769ca8b553b4378a773967f08de20847794db/c/src/lib/libbsp/i386/pc386/ne2000/ne2000.c
As a quick and dirty solution you could just replace the calls to the slip
driver with calls to your ne2000 driver. This could be done with a
compile-time option for a start. Making a proper layer with different
network interfaces to choose from including an ifconfig utility can then be
added later.
The slip driver exposes the functions slip_init(), slip_process() (i.e.
Read) and slip_send(). These functions are called by the ktcp driver, in
part via some other functions. So as you mentioned it is relatively easy to
modify these function calls to call an ne2000 driver instead of slip.c.
Georg
--------------------------------------------------------------------------------------------------
Here are my notes about a tour of the network code in ELKS:
At system boot the code in „init/main.c“ is run which calls sock_init() in
socket.c. This initializes, depending on the kernel configuration, the
kernel interfaces in the files af_init.c (internet), af_unix.c (unix domain
sockets) and af_nano.c.
These again call sock_register() in socket.c passing a structure with the
functions they have implemented and their family name, e.g. „AF_INET“.
The common socket commands that ELKS supports i.e. socket, accept, bind,
connect and listen are implemented in libc. In libc there are wrappers
around kernel system calls which are implemented in socket.c. These system
calls are sys_socket, sys_accept, sys_bind, sys_connect and sys_listen. The
application passes the family name with the command and this selects which
of the kernel interfaces above will execute the command.
You can also use the read, write, select and close commands with the socket
handle. These are executed with the sock_read, sock_write, sock_select and
sock_close functions in socket.c.
So if the application executes a „write“ with the family „AF_INET“ the
sock_write function in socket.c will translate this via structures of
pointers into the function inet_write() in af_inet.c and execute that. This
calls the function tcpdev_inetwrite() in our char/tcpdev driver which writes
it into the „tdout_buf“ buffer. This buffer is then copied to memory in the
tcpdev_read() function for the ktcp user space driver to pick up and send.
On the other hand, the char/tcpdev driver will use the tcpdev_write function
to copy received data to the kernel interface af_inet.c by calling the
function inet_process_tcpdev() in that code.
There are two tcpdev.c files in the code. One, the „char/tcpdev“, is linked
as a kernel driver and the other, „ktcp/tcpdev“, handles the tcp part for
the ktcp user mode driver.
When ktcp is started, it initializes several modules, first it calls
tcpdev_init() which is implemented in ktcp/tcpdev.c. This opens the
dev/tcpdev device that the kernel mode char/tcpdev driver has provided and
receives the „tcpdevfd“ handle. Then the slip interface, ip, icmp, tcp and
netconf are initialized. At the end ktcp calls its ktcp_run() function which
does a while loop frequently calling tcp_process() in ktcp/tcpdev. The
tcp_process() function queries the tcpdev device of the char/tcpdev driver
for tasks to execute. In case of a write task, the function calls
tcpdev_write which again calls tcp_output that implements retransmissions if
necessary. It calls the function ip_sendpacket() in ip.c. This function
again uses the function slip_send() in slip.c.
The loop in ktcp_run() also calls slip_process() in slip.c which handles the
data received by calling ip_recvpacket() in ip.c.
HTH :)
-----Ursprüngliche Nachricht-----
From: Marc-François LUCCA-DANIAU
Sent: Saturday, January 28, 2017 8:50 AM
To: ELKS
Subject: Re: Elks networking
Perhaps you meant "ez-dos" ?
As stated in a previous post by Alan, driving the old-fashion NE2K
chip (and compatible) through the ISA bus (or equivalent on embedded
system) is quite easy. I am currently writing the driver from scratch,
after reading the datasheet and being inspired by some other driver
implementations (DOS packet driver, BIOS diag, etc), to avoid any
license concern.
Any pointer to other implementation is welcome, for background
information and benchmarking purpose.
About integration of such driver in ELKS, the discussion is still open
today. Initial intent is to replace the low-level layer of KTCP that
sends / receives the packet on the /tty interface for SLIP, but it
appears that program needs to be reworked, to implement an ARP
transponder, and the driver needs to implement the select / poll
operations for efficient processing (as /tty that is selectable).
So I am focusing now on having a code that is able to configure the
PHY, to control the MAC to stack / unstack packets, and being notified
of packet reception. After this first step, I would deliver to Jody's
master and ask the community for guidelines for ELKS integration.
MFLD
2017-01-27 5:19 GMT+01:00 GOliath Keet <goliath.keet@xxxxxxxxx>:
would any of the networking code from ez-nos be any good? that was open
sourced a few years ago,
I do have somewhere a email from the original author with permission to
use
his code,
how difficult would it be to get a dos network driver to load as intended
on
elks? and then interface with that ?
On Mon, Jan 23, 2017 at 7:48 PM, Marc-F. LUCCA-DANIAU <mfld.fr@xxxxxxxxx>
wrote:
Not forgotten, and now tracked by:
https://github.com/mfld-fr/elks/issues/1
MFLD
Le 31/05/2016 à 12:50, Alan a écrit :
I am also interested in such NE2000 driver, because the ETH chip on my
SBC is an Asix AX88796-L, and according to its datasheet, it claims
"register level compatibility with NE2000".
The best place to start are the DOS packet drivers which are GPL but in
8086 asm. Unlike the rather convoluted SMP aware IRQ driven Linux
drivers they implement IRQ based receive notification and blocking
transmit in a tiny driver, which is the kind of model needed for a low
end CPU and something like ELKS.
As a chip it is pretty easy to drive although it is best to debug on an
emulator until it works as the real NE2000 has a very antisocial
attitude to incorrect I/O accesses (it hangs the machine solid).
On top of that you need an implementation of ARP and then the TCP/IP
stack.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
