Re: Elks networking

Marc-François LUCCA-DANIAU
2017-01-30T20:08:24Z

Thanks Georg for the notes, I captured them in the file
/elks/elks/Documentation/text/networking.txt, that will be part of my
next commit.

MFLD

2017-01-29 20:51 GMT+01:00 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
> --
> 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