[ECOS] Ethernet and Serial drivers for Linux target?

[ECOS] Ethernet and Serial drivers for Linux target?

[Grant Edwards]

Hi,

I told management that it should be possible to write serial port and
Ethernet device drivers for the Linux eCos target, thus allowing
people to do eCos application development on Linux boxes.  Of course
the performance and timing won't be the same, but for basic application
functionality it should be good enough for many things.

Has anybody done this?  I assume that all you have to do is to map
cyg_io_read() and cyg_io_write() into read() and write() calls, and
map cyg_io_get_config() and cyg_io_set_config() into appropriate
ioctl() calls?

The serial driver should be able to use the standard /dev/ttySx
devices and the Ethernet driver can use the af_packet module to send
and receive Ethernet packets.  Is this going to be as straight-forward
as I think it is, or have I dug myself into a hole?

TIA

-- 
Grant Edwards
grante@visi.com

RE: [ECOS] Ethernet and Serial drivers for Linux target?

[Gary Thomas]

On 10-Nov-99 Grant Edwards wrote:
> 
> Hi,
> 
> I told management that it should be possible to write serial port and
> Ethernet device drivers for the Linux eCos target, thus allowing
> people to do eCos application development on Linux boxes.  Of course
> the performance and timing won't be the same, but for basic application
> functionality it should be good enough for many things.
> 
> Has anybody done this?  I assume that all you have to do is to map
> cyg_io_read() and cyg_io_write() into read() and write() calls, and
> map cyg_io_get_config() and cyg_io_set_config() into appropriate
> ioctl() calls?
> 
> The serial driver should be able to use the standard /dev/ttySx
> devices and the Ethernet driver can use the af_packet module to send
> and receive Ethernet packets.  Is this going to be as straight-forward
> as I think it is, or have I dug myself into a hole?
> 

It absolutely should be that simple (or we did a poor job designing it :-)

The serial device driver has two layers, one which is platform independent
and one is hardware dependent.  You'll want to creat a platform/hardware
dependent module that implements the basic functionalities.
 o Serial output is simple, no interrupts required
 o Serial input is a little harder if you want to support an interrupt
   driven model (i.e. other threads in your eCos application can run while
   one or more threads waits for input).  In this case, you'll need to use
   signals (SIGIO) to get indicate that data is ready and then use the
   interrupt model to send data to the upper levels of the driver.  This is
   not hard, just a little more work.  If you don't care, you can just blow
   this off and make input non-interrupt driven as well.
 o Control functions map directly onto Linux 'ioctl' calls.

For a purely non-interrupt driven driver, look at:
  .../io/serial/XXX/src/arm/pid_serial.c
Or the interrupt driven version
  .../io/serial/XXX/src/arm/pid_serial_with_ints.c

Note: the non-interrupt version may be a little "crusty", I haven't used it
in quite a while, but you'll get the idea.

As for the ethernet, I'd like to see what you come up with.

If you have questions or problems, be sure to let me (or the eCos team/list)
know;  we're glad to try and help.

[ECOS] Re: Ethernet and Serial drivers for Linux target?

[Bart Veer]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> I told management that it should be possible to write
    Grant> serial port and Ethernet device drivers for the Linux eCos
    Grant> target, thus allowing people to do eCos application
    Grant> development on Linux boxes. Of course the performance and
    Grant> timing won't be the same, but for basic application
    Grant> functionality it should be good enough for many things.

    Grant> Has anybody done this? I assume that all you have to do is
    Grant> to map cyg_io_read() and cyg_io_write() into read() and
    Grant> write() calls, and map cyg_io_get_config() and
    Grant> cyg_io_set_config() into appropriate ioctl() calls?

    Grant> The serial driver should be able to use the standard
    Grant> /dev/ttySx devices and the Ethernet driver can use the
    Grant> af_packet module to send and receive Ethernet packets. Is
    Grant> this going to be as straight-forward as I think it is, or
    Grant> have I dug myself into a hole?

In addition to Gary's response, you may want to look at a short thread
on the ecos-discuss mailing list "Serial device driver for linux
synthetic target!" last month,
http://sourceware.cygnus.com/ml/ecos-discuss/1999-10/
This discussed a couple of ways of tackling the problem. So far I have
not received any contributions in this area.

Bart Veer // eCos net maintainer

Re: [ECOS] Ethernet and Serial drivers for Linux target?

[Jonathan Larmour]

Grant Edwards wrote:
> 
> I told management that it should be possible to write serial port and
> Ethernet device drivers for the Linux eCos target, thus allowing
> people to do eCos application development on Linux boxes.  Of course
> the performance and timing won't be the same, but for basic application
> functionality it should be good enough for many things.
> 
> Has anybody done this?  I assume that all you have to do is to map
> cyg_io_read() and cyg_io_write() into read() and write() calls, and
> map cyg_io_get_config() and cyg_io_set_config() into appropriate
> ioctl() calls?

One other issue that no-one else has mentioned is that you can't make calls
to the system read() and write(), ioctl() etc. directly. To do that would
involve linking with glibc, and that would simply not work.

Instead all the current interfacing is done using kernel system calls
directly. Of course, this doesn't prevent you having a separate native linux
program acting as a server for the client requests, communicating using
fd's. And that's where Bart's solution would come in, in the thread in
October he mentioned.

Jifl
-- 
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK.  Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
 my brains kept falling out."    || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/  These opinions are all my own fault

Re: [ECOS] Ethernet and Serial drivers for Linux target?

[Grant Edwards]

On Thu, Nov 11, 1999 at 05:10:35PM +0000, Jonathan Larmour wrote:
> Grant Edwards wrote:
> > 
> > I told management that it should be possible to write serial port and
> > Ethernet device drivers for the Linux eCos target, thus allowing
> > people to do eCos application development on Linux boxes.  Of course
> > the performance and timing won't be the same, but for basic application
> > functionality it should be good enough for many things.
> > 
> > Has anybody done this?  I assume that all you have to do is to map
> > cyg_io_read() and cyg_io_write() into read() and write() calls, and
> > map cyg_io_get_config() and cyg_io_set_config() into appropriate
> > ioctl() calls?
> 
> One other issue that no-one else has mentioned is that you can't make calls
> to the system read() and write(), ioctl() etc. directly. To do that would
> involve linking with glibc, and that would simply not work.

I presume I could grab the source for Linux glibc read() write() and
ioctl(), strip out the stuff I don't need, and impliment my own
eCos-friendly versions of those calls...

> Instead all the current interfacing is done using kernel system calls
> directly. 

Ah. That's one question about which I had begun to wonder.  I haven't
looked at Linux system calls very closely, but there shouldn't be that
much of a difference in abstraction bewteen what the kernel provides
and what I need to make an eCos serial driver work.  

> Of course, this doesn't prevent you having a separate native linux
> program acting as a server for the client requests, communicating using
> fd's. And that's where Bart's solution would come in, in the thread in
> October he mentioned.

I suppose I could also just use the eCos 16550 driver and diddle the
hardware directly, but I'd rather let the Linux drivers worrry about
that so that I can utilize other types of serial ports.

-- 
Grant Edwards

Re: [ECOS] Ethernet and Serial drivers for Linux target?

[Gary Thomas]

On 11-Nov-99 Grant Edwards wrote:
> On Thu, Nov 11, 1999 at 05:10:35PM +0000, Jonathan Larmour wrote:
>> Grant Edwards wrote:
>> > 
>> > I told management that it should be possible to write serial port and
>> > Ethernet device drivers for the Linux eCos target, thus allowing
>> > people to do eCos application development on Linux boxes.  Of course
>> > the performance and timing won't be the same, but for basic application
>> > functionality it should be good enough for many things.
>> > 
>> > Has anybody done this?  I assume that all you have to do is to map
>> > cyg_io_read() and cyg_io_write() into read() and write() calls, and
>> > map cyg_io_get_config() and cyg_io_set_config() into appropriate
>> > ioctl() calls?
>> 
>> One other issue that no-one else has mentioned is that you can't make calls
>> to the system read() and write(), ioctl() etc. directly. To do that would
>> involve linking with glibc, and that would simply not work.
> 
> I presume I could grab the source for Linux glibc read() write() and
> ioctl(), strip out the stuff I don't need, and impliment my own
> eCos-friendly versions of those calls...
>

There is a very simple mapping of functions onto the actual system calls.
Beware of the glibc code though, it's full of macros that do all of this work :-)
 
>> Instead all the current interfacing is done using kernel system calls
>> directly. 
> 
> Ah. That's one question about which I had begun to wonder.  I haven't
> looked at Linux system calls very closely, but there shouldn't be that
> much of a difference in abstraction bewteen what the kernel provides
> and what I need to make an eCos serial driver work.  
> 
>> Of course, this doesn't prevent you having a separate native linux
>> program acting as a server for the client requests, communicating using
>> fd's. And that's where Bart's solution would come in, in the thread in
>> October he mentioned.
> 
> I suppose I could also just use the eCos 16550 driver and diddle the
> hardware directly, but I'd rather let the Linux drivers worrry about
> that so that I can utilize other types of serial ports.
> 

IMHO you should definitely stay away from touching the hardware.  Let
Linux do it for you. If you do things right, you'll be able to convince
eCos that you have access to the real hardware anyway.

[ECOS] Re: Ethernet and Serial drivers for Linux target?

[Bart Veer]

>>>>> "Grant" == Grant Edwards <grante@visi.com> writes:

    Grant> On Thu, Nov 11, 1999 at 05:10:35PM +0000, Jonathan Larmour wrote:
    >> Grant Edwards wrote:
    >> > 
    >> > I told management that it should be possible to write serial port and
    >> > Ethernet device drivers for the Linux eCos target, thus allowing
    >> > people to do eCos application development on Linux boxes.  Of course
    >> > the performance and timing won't be the same, but for basic application
    >> > functionality it should be good enough for many things.
    >> > 
    >> > Has anybody done this?  I assume that all you have to do is to map
    >> > cyg_io_read() and cyg_io_write() into read() and write() calls, and
    >> > map cyg_io_get_config() and cyg_io_set_config() into appropriate
    >> > ioctl() calls?
    >> 
    >> One other issue that no-one else has mentioned is that you
    >> can't make calls to the system read() and write(), ioctl() etc.
    >> directly. To do that would involve linking with glibc, and that
    >> would simply not work.

    Grant> I presume I could grab the source for Linux glibc read()
    Grant> write() and ioctl(), strip out the stuff I don't need, and
    Grant> impliment my own eCos-friendly versions of those calls...

It may be better to look at syscall-i386-linux-1.0.S in the synthetic
target HAL sources. Note that if you want more realistic device driver
behaviour, with interrupts etc., then you will want to experiment with
asynchronous I/O, SIGIO signals, etc. If an eCos thread performs a
blocking Linux read() syscall then you will block the entire eCos
application, which is probably not what you want. Of course this makes
the problem a bit more challenging :-)

    >> Instead all the current interfacing is done using kernel system
    >> calls directly.

    Grant> Ah. That's one question about which I had begun to wonder.
    Grant> I haven't looked at Linux system calls very closely, but
    Grant> there shouldn't be that much of a difference in abstraction
    Grant> bewteen what the kernel provides and what I need to make an
    Grant> eCos serial driver work.

    >> Of course, this doesn't prevent you having a separate native
    >> linux program acting as a server for the client requests,
    >> communicating using fd's. And that's where Bart's solution
    >> would come in, in the thread in October he mentioned.

    Grant> I suppose I could also just use the eCos 16550 driver and
    Grant> diddle the hardware directly, but I'd rather let the Linux
    Grant> drivers worrry about that so that I can utilize other types
    Grant> of serial ports.

I would certainly recommend you avoid messing about with PC hardware
directly, except as an absolute last resort. The current synthetic
target provides a safe and stable development environment, not unlike
a sandbox. Fiddling with real hardware would upset this.

Bart Veer // eCos net maintainer

Re: [ECOS] Ethernet and Serial drivers for Linux target?

[Grant Edwards]

On Thu, Nov 11, 1999 at 10:31:57AM -0700, Gary Thomas wrote:

[regarding writing eCos serial/ethernet drivers for Linux target] 

> >> > Has anybody done this?  I assume that all you have to do is to map
> >> > cyg_io_read() and cyg_io_write() into read() and write() calls, and
> >> > map cyg_io_get_config() and cyg_io_set_config() into appropriate
> >> > ioctl() calls?
> >> 
> >> One other issue that no-one else has mentioned is that you can't make calls
> >> to the system read() and write(), ioctl() etc. directly. To do that would
> >> involve linking with glibc, and that would simply not work.
> > 
> > I presume I could grab the source for Linux glibc read() write() and
> > ioctl(), strip out the stuff I don't need, and impliment my own
> > eCos-friendly versions of those calls...
> 
> There is a very simple mapping of functions onto the actual system calls.
> Beware of the glibc code though, it's full of macros that do all of this work :-)

Oh goody.  Macros are the most obsfucating things in most of the C
code I've ever worked on (though darned useful, they can easily get
out of control).  In my "spare time" I'll start looking at Linux
system calls and glibc source code.

> IMHO you should definitely stay away from touching the hardware.
> Let Linux do it for you.

Agreed. I'd like to be able to use several different types of serial
boards on the Linux target, and I really don't want to have to write a
new driver for each one.  The ARM target will be limited to just one
or two different types of UARTS.

-- 
Grant Edwards
Principal Engineer
Comtrol Corporation

Re: [ECOS] Re: Ethernet and Serial drivers for Linux target?

[Grant Edwards]

On Thu, Nov 11, 1999 at 05:37:29PM +0000, Bart Veer wrote:

> It may be better to look at syscall-i386-linux-1.0.S in the synthetic
> target HAL sources. 

I've browsed through there already, and that looks like a good
starting point.

> Note that if you want more realistic device driver behaviour, with
> interrupts etc.,

Naturally one would.

> then you will want to experiment with asynchronous I/O, SIGIO
> signals, etc. 

Never done async I/O before, never done direct system calls before,
been using eCOS for two weeks.  I'm practically an expert.

> If an eCos thread performs a blocking Linux read() syscall then you
> will block the entire eCos application, which is probably not what
> you want.

Of course not.

> Of course this makes the problem a bit more challenging :-)

If was easy everybody could do it, and then how could I walk around
feeling so superior?

-- 
Grant