Fwd: Elks networking

Marc-François LUCCA-DANIAU
2017-01-29T13:43:34Z

Sorry to have mixed "ez-Dos" and "ez-Nos"...

Thank you very much for the pointer and the fresh archival on GitHub.

It looks like that network stack contains some interesting stuff to
have a look on for the protocol implementation. I keep it under the
hand.

But after a quick parse, it looks also like that stack does not
contain any ethernet card driver, just the layer to connect through
the old serial line modems (SLIP and so on).

Reminds me the times of the singing modems at home...
tuuut-tuuut-pouic-diii-daaa-criiiicriiiicriiii... :-)

MFLD

---------- Forwarded message ----------
From: GOliath Keet <goliath.keet@gmail.com>
Date: 2017-01-28 18:23 GMT+01:00
Subject: Re: Elks networking
To: Marc-François LUCCA-DANIAU <mfld.fr@gmail.com>

The original Author has open sourced this code, and has corresponded
with me via email and reassured me, that he would like to see it used.

https://github.com/parabyte/ez-nos/archive/master.zip

Its like a unix environment for dos.

i hope something in there is useful for someone.

On Sat, Jan 28, 2017 at 7:50 AM, Marc-François LUCCA-DANIAU
<mfld.fr@gmail.com> wrote:
>
> 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