Re: Elks networking

["Georg Potthast" <nospam@georgpotthast.de>]

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@gmail.com>:
> 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@gmail.com>
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html