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@xxxxxxxxxxxxxxxx>: > 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 -- 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
