[ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[Horvath Gyorgy]

Hi all,

First, I would like to introduce a new harware -
SGA155D Dual STM-1/OC3 Telecommunications PCI Adapter.
You can obtain a short catalog from www.aitia.ai.
(www.aitia.ai/document/upload/200307/sga155.pdf)
I think it is a little bit expensive - but very flexy.
Errrr... actually the card was entirelly developed by me -
including the cores for the FPGA.
It is in low scale production, and working in the
fields well. Its current application is implemented for
DOS ;->

Second, I am going to turn to Linux, and I have decided to
write the driver(s) myself (huhh) under GPL.
It is turned out quickly, that I have some problems
at the very beginning of the development.

1. The new target application requires N pieces of SGA155D adapters
   for telephony application - multiple E1's carried in STM-1.
   Also, we need M additional pieces of SGA155D loaded with
   IP-Core for Packet-Over-SONET (WAN) application.
   Moreover - several hard-disks can be attached to the
   adapters for capture and playback application.

   As I see - SGA155D is a multifunction adapter in this context.
   Are there any driver model or technique for this situation?

   My guess is that I write a core driver for the hardware itself
   that can be compiled in the kernel (or can be modularized).
   This driver allows manipulating the IP-Core for the FPGA.
   Functional drivers are then modularized on demand.
   BTW Can I insmod other drivers from a kernel driver?
   Let say I have firstapp.o and firstapp.bin for the first
   three cards, and secondapp.o plus secondapp.bin for the rest.
   (.o is the driver and .bin is the IP-Core having the same
   filename) The core driver loads the IP-Core first, then loads
   the driver for that core. Hmmmm?

2. Packet over SONET...
   There were rumours about a Lucent card, and a driver for it -
   but I can't reach that now (a link to the void) - just
   for reference.
   What model shall I use - syncppp.o and my_driver.o - or
   I have to implement the ppp stuff entirelly in hardware
   - according to RFC's (I used to use RFC's and ITU-T's
   for cross compilation into VHDL :-).
   Is syncppp conforming RFC1619, RFC1662, RFC2615?
   I can't find notes on this in syncppp.c...

3. The telephony part is not yet clear for me.
   For the new application in question - there is not much to do
   in Linux, since the mass will be driven/sunk by the
   hard-disks.  But it might be useful elsewhere...
   Anyway - I will dig-up the Linux telephony project for advice
   before bothering this list.

4. Optionally - and if I have enough time - I'd like
   to develop a twin-linear filesystem driver for
   time-stamped capture/playback for multiple channels
   of data - like a multi-band magnetic tape.
   BTW do you know an existing one?


Best regards,


Gyorgy Horvath,        Technical University of Budapest
--------------         Dept. of Telecom. and Telematics

Tel.: +36-1-463-1865,  Fax.: +36-1-463-1865
Mail: horvaath@bme-tel.ttt.bme.hu
FTP:  ttt-pub.ttt.bme.hu  ./income

Re: [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[Alan Cox]

On Maw, 2003-09-09 at 15:27, Horvath Gyorgy wrote:
>    As I see - SGA155D is a multifunction adapter in this context.
>    Are there any driver model or technique for this situation?
>    My guess is that I write a core driver for the hardware itself
>    that can be compiled in the kernel (or can be modularized).
>    This driver allows manipulating the IP-Core for the FPGA.
>    Functional drivers are then modularized on demand.

That is probably the right model. We do something similar with dual
function parallel/serial cards and of course on a huge scale with USB
where a USB hub means loading many other drivers to use the devices 
attached to it.

>    BTW Can I insmod other drivers from a kernel driver?

Yes. request_module() and the hotplug interface let you do that in
various kernels. Right now for example the USB layer goes back to the
userspace /sbin/hotplug and says "I need a driver for one of these" and
the hotplug layer figures out what to do.

> 2. Packet over SONET...
>    Is syncppp conforming RFC1619, RFC1662, RFC2615?
>    I can't find notes on this in syncppp.c...

Syncppp is pretty basic and obsoleted by the hdlc driver stuff.

> 3. The telephony part is not yet clear for me.
>    For the new application in question - there is not much to do
>    in Linux, since the mass will be driven/sunk by the
>    hard-disks.  But it might be useful elsewhere...
>    Anyway - I will dig-up the Linux telephony project for advice
>    before bothering this list.

Take a look at the Zaptel stuff, thats basically the T1 version of a
winmodem but might have some interesting ideas in it.

> 4. Optionally - and if I have enough time - I'd like
>    to develop a twin-linear filesystem driver for
>    time-stamped capture/playback for multiple channels
>    of data - like a multi-band magnetic tape.
>    BTW do you know an existing one?

I've seen people do this in user space (just interleaving the disk in
big chunks in the app and driving it with O_DIRECT raw access) but not
in kernel file system space.

Alan

Re: [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[Francois Romieu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=unknown-8bit, Size: 333 bytes --]

Greetings,

Horvath Gyorgy <HORVAATH@tmit.bme.hu> :
[...]
> 2. Packet over SONET...
>    There were rumours about a Lucent card, and a driver for it -
>    but I can't reach that now (a link to the void) - just
>    for reference.

Né Optistar (TM) ?

<URL:http://www.fr.zoreil.com/people/francois/misc/oclinux1_0_tar.gz>

--
Ueimor

Re: [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[Stewart Smith]

On Wed, 2003-09-10 at 00:55, Alan Cox wrote:
> > 4. Optionally - and if I have enough time - I'd like
> >    to develop a twin-linear filesystem driver for
> >    time-stamped capture/playback for multiple channels
> >    of data - like a multi-band magnetic tape.
> >    BTW do you know an existing one?
> 
> I've seen people do this in user space (just interleaving the disk in
> big chunks in the app and driving it with O_DIRECT raw access) but not
> in kernel file system space.

(from memory) I think that ext2/ext3 does (or at least did) this - they
lacked any smart logic for rapid allocations - at least for inodes in
the same cylinder group. I think this was mentioned in the "Journaling
the ext2 filesystem" paper.

This could probably be faked by taking out any intelligence in block
allocation (allocate last block+1 or some such thing). Even as a mount
option (seq_alloc), this could be useful (for this type of streaming).
This will give you great write throughput, but if you don't read things
off the same way you read them - reading is going to suck.

I read in a discussion of multimedia filesystems (for PVRs) that a block
size of 256KB helped in throughput when playback configurations weren't
known (the more data you read before seeking the better). google for
"multimedia filesystems" - you'll find a fair few papers on such things.

Things like XFS were designed for large, high bandwidth systems, so
that's also worth looking into as a zero-effort approach :)

Re: [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[Horvath Gyorgy]

Hi,

> ====> From Stewart Smith
> On Wed, 2003-09-10 at 00:55, Alan Cox wrote:
> > > 4. Optionally - and if I have enough time - I'd like
> > >    to develop a twin-linear filesystem driver for
> > >    time-stamped capture/playback for multiple channels
> > >    of data - like a multi-band magnetic tape.
> > >    BTW do you know an existing one?
> >
> > I've seen people do this in user space (just interleaving the disk in
> > big chunks in the app and driving it with O_DIRECT raw access) but not
> > in kernel file system space.
>
> (from memory) I think that ext2/ext3 does (or at least did) this - they
> lacked any smart logic for rapid allocations - at least for inodes in
> the same cylinder group. I think this was mentioned in the "Journaling
> the ext2 filesystem" paper.

Unfortunatelly, I have to deal with the file-system from
the FPGA as well - as from the Linux.
Probably I have not enough room to implement ext2/ext3
in the FPGA.
Anyway - I will see what...

Actually - I have my driver-skeleton up, and I can now load
firmware into the card.
That's a movement ... but lot more to do.

Sep 11 14:53:01 westel9 kernel: SGA155D[x] is a dual STM-1/OC3
Telecom. PCI adapter 0.01
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: AMCC is at F3800000
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: CPLD is at F3000000
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: FPGA is at F2800000
Sep 11 14:53:01 westel9 kernel: PCI: Found IRQ 9 for device 02:0b.0
Sep 11 14:53:01 westel9 kernel: PCI: Sharing IRQ 9 with 00:1f.4
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: AMCC mapped to f0818000
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: AMCC S5933 Reset, MCSR=
00000026
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: AMCC MCSR Initialization
failed
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: AMCC S5933 Cold,
INTCSR=00000000
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: CPLD mapped to f081a000
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: CPLD Test,    CPLD_TEST =
 AA55
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: CPLD Test,    CPLD_TEST =
 3CF0
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: Firmware loaded,
running...
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: FPGA mapped to f081c000
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: FPGA Firmware ID is
D155FF02
Sep 11 14:53:01 westel9 kernel: SGA155D[0]: FPGA TEST =  AA553CF0

I don't know why AMCC said that stupid 0x26 instead of 0xE6...
Others seemed OK - and the LED's blinking :-)

Best regards,
Gyuri

Gyorgy Horvath,        Technical University of Budapest
--------------         Dept. of Telecom. and Telematics

Tel.: +36-1-463-1865,  Fax.: +36-1-463-1865
Mail: horvaath@bme-tel.ttt.bme.hu
FTP:  ttt-pub.ttt.bme.hu  ./income

Re: [ANNOUNCE] New hardware - SGA155D dual STM-1/OC3 PCI ad

[Horvath Gyorgy]

Hi all,

thank you for your advise!

>====> From Justin Cormack <justin@street-vision.com>
>
>
>You can have a driver core module that finds the cards, then
>subdrivers
>that the user can load, each with a firmware loader interface such
>that
>loading the firmware for a particular card sets the function on that
>card (and registers the devices etc). Probably best to have the
>firmware
>loading from userspace.

OK. But loading from the user-space will be used for development only
-
to see how the new FPGA stuff going. I think it can be done by using
simple device writes to the core driver, and some IOCTLs.

>====> From  Alan Cox <alan@lxorguk.ukuu.org.uk>
>
>On Maw, 2003-09-09 at 15:27, Horvath Gyorgy wrote:
>>   ....
>>    My guess is that I write a core driver for the hardware itself
>>    that can be compiled in the kernel (or can be modularized).
>>    This driver allows manipulating the IP-Core for the FPGA.
>>    Functional drivers are then modularized on demand.
>
>That is probably the right model. We do something similar with dual
>function parallel/serial cards and of course on a huge scale with USB
>where a USB hub means loading many other drivers to use the devices
>attached to it.

I think I was not precise enough. Sorry.
"On demand" - not from the applications' or hot-plug device's
point of view - but the configuration of the given box as a whole.
Let say - passing the string "TTTPP" to the core driver
(as kernel parameter) tells that first three card is
for telephony, and the next two for POS. Is it OK?

>>    BTW Can I insmod other drivers from a kernel driver?
>
>Yes. request_module() and the hotplug interface let you do that in
>various kernels. Right now for example the USB layer goes back to the
>userspace /sbin/hotplug and says "I need a driver for one of these"
>and
>the hotplug layer figures out what to do.

I see... e.g. in generic_ppp.c for compression modules.

>
>> 2. Packet over SONET...
>>    Is syncppp conforming RFC1619, RFC1662, RFC2615?
>>    I can't find notes on this in syncppp.c...
>
>Syncppp is pretty basic and obsoleted by the hdlc driver stuff.

Hmmm... the hdlc.c sais the syncppp.c is used for PPP.
I'll dig it up.

>
>> 3. The telephony part is not yet clear for me.
>>    For the new application in question - there is not much to do
>>    in Linux, since the mass will be driven/sunk by the
>>    hard-disks.  But it might be useful elsewhere...
>>    Anyway - I will dig-up the Linux telephony project for advice
>>    before bothering this list.
>
>Take a look at the Zaptel stuff, thats basically the T1 version of a
>winmodem but might have some interesting ideas in it.

Thank you. I am on it.

>
>> 4. Optionally - and if I have enough time - I'd like
>>    to develop a twin-linear filesystem driver for
>>    time-stamped capture/playback for multiple channels
>>    of data - like a multi-band magnetic tape.
>>    BTW do you know an existing one?
>
>I've seen people do this in user space (just interleaving the disk in
>big chunks in the app and driving it with O_DIRECT raw access) but
>not
>in kernel file system space.

That's quick and dirty - but efficient. OK.
Whistles and bells can wait...

>====> From  Francois Romieu <romieu@fr.zoreil.com>
>
>Greetings,
>
>Horvath Gyorgy <HORVAATH@tmit.bme.hu> :
>[...]
>> 2. Packet over SONET...
>>    There were rumours about a Lucent card, and a driver for it -
>>    but I can't reach that now (a link to the void) - just
>>    for reference.
>
>NTheta Optistar (TM) ?
>
><URL:http://www.fr.zoreil.com/people/francois/misc/oclinux1_0_tar.gz>

Yes, yes, yes, yes!!!! That is it! Goooooooood stuff!
I can't beleive it!!!  Ol' PM5357 from PMC-Sierra for OC-12!
It's been years...

I almost forget that I have already developed an ATM adapter
for 622 Mbps with that chip.
I am totally stupid. THAT CAN DO POS AS WELL.
The CP622E with drivers for VxWorks is actually not in production.
Some info from the early stages of the development can be found
in http://alpha.ttt.bme.hu/~cellpick.
It was used for network monitoring - and performed well.

Let's thinking...
Little HW/FW/SW mods, and I have a POS box - for testing
the SGA155D implementation.
Errr... Actually the only piece of that card that I have is
at a student - for playing with :-)
Yep... And as I remember - that revision of the chip contains a
silicon bug in POS mode...
Life is hard.

Thank you for all again, now I can get started.

Best regards,
Gyuri

Gyorgy Horvath,        Technical University of Budapest
--------------         Dept. of Telecom. and Telematics

Tel.: +36-1-463-1865,  Fax.: +36-1-463-1865
Mail: horvaath@bme-tel.ttt.bme.hu
FTP:  ttt-pub.ttt.bme.hu  ./income