Tips for NewCS, Linux and custom baud rates

**gw1** · 11-02-09, 01:40 AM

Several things can go wrong with serial configuration that make NewCS particularly troublesome on certain hardware. A bunch of people have been having grief so it's time for another brain dump.

As you know smartcards are designed for particular frequency that corresponds to 9600 baud ATR; for most that's 3.58MHz except for Irdeto which use 6MHz. Any other frequency nearly always means use of a non-standard baud rate. For communication to work the PC's serial port needs to be accurately configured to the matching rate. The 8250 family of UARTs used by PCs (including 16450, 16550, 16550a, etc) are completely compatible when it comes to programming for standard baud rates. But for non-standard rates the register programming varies from one serial device to another depending on exactly what UART chip is being used and what reference frequency its baud generator is being supplied with. Most modern motherboards have settled on UART hardware and standard reference frequency that is well known to standard (generic) serial driver on both Windows and Linux, which means when your applications ask for custom baud rates they usually work fine when using motherboard serial ports. When using other plug-in cards it becomes critical that the serial driver's assumptions about the UART chip type and its reference frequency are correct; if incorrect it'll work fine with standard frequencies until an application tries to configure a custom frequency, at which point the wheels can come off.

One of NewCS's dirty secrets is that it makes custom baud rate API calls even when you are using standard card clock and 9600 baud rate. Why? Because it tries to autodetect card type by a series of card resets, listening for ATR at different speeds each time to see what the card is using. That's all very nice if you're on a properly configured device, but if the UART type isn't exactly right the custom baud rate write operation may trash UART registers leaving it crippled and unable to communicate properly until it's powered down. So if your serial card locks up occasionally until you switch off and on again check your driver configuration.

On Windows it's usually sufficient to install the correct driver for your adapter hardware: the manufacturer knows exactly what UART chip is being used and what its reference frequency is. If you have problems go into the control panel options and make sure that any advanced features are turned off. Especially you want hardware handshake, xon/xoff, RS485 and DMA turned off because all of them can cause havoc with Phoenix. (Eg RS485 is a multi-master system that typically uses RTS to control bus mastering, and if enabled it will cause unexpected card reset).

On Linux the same applies: if the manufacturer supplies a driver (binary or source) then use it. If they don't it's usually because they're compatible with one of the standard UART types, which means you can use Linux's standard serial driver. But it will ONLY work properly with non-standard baud rates if you correctly configure the uart_type and baud_base parameters. This is done using setserial command, which is the tool you use to configure the parameters of the kernel's standard serial driver. I give an example later.

Here are a bunch of tips for manual configuration of serial port settings on Linux. (Some of it also applies to Windows but for best reliability with NewCS I recommend Linux.)

Use 'setserial -g /dev/ttyS*' as root to see what serial devices are currently configured. If setserial isn't available you'll need to install its package. Note that this doesn't read anything from the UART devices themselves, it simply echos back to you the last configuration values that were given to the device driver.
/dev/ttyS0 is nearly always available on motherboard of course. If having problems you should test using that port first as it gives fewest problems. The reason for that is most motherboards stick to well-known UART types and reference frequencies which the standard device drive is familiar with and usually autodetects fine.
/dev/ttyS1 corresponds to COM2 or COMB where available on some motherboards. If not a second DB9 connector on the back, it's usually a 10-pin IDC header. There are two pinouts for that connector: the most common is "AT Everest" which wires pin 1 to pin 1, pin 2 to pin 2 etc; the other is "DTK" pinout (aka crossover) which has pins 1-5 on one row and 6-9 on the other. So if making a cable for the motherboard COM port check the manual first. Most Gigabyte and all Asus boards use AT Everest.
The same applies to IDC10 headers on PCI and PCI Express serial cards. Most (including Red Chief and ST-Labs cards I mention later) use AT Everest pinout.
When configuring with setserial you need to specify the I/O Address and IRQ line. These are allocated by Plug & Play subsystem. Use 'lspci -v' as root to see what's allocated. For each of your serial ports write down the I/O Address, IRQ using the chip manufacturer or model number mentioned in the Plug & Play descriptors to identify them. Double-check your work because it's critical you get it right.
Don't panic if you see large IRQ numbers, such as 200. Due to ACPI this is normal.
Identify the exact UART type applicable for each serial port (eg 8250, 16450, 16550 etc). Do this based on manufacturer documentation, or visual inspection of chips on the adapter card, or whatever. You need to know this: if you're incorrect the card won't be able to communicate properly with the smartcards.
16550 and 16550A are different!
Don't assume all ports on your multi-port adapter card use the same chip: some products use a combination of different chips on the same adapter card. Eg Sunix 4056A four-port serial uses a SUN1889 chip for two of its ports but a SUN1699 for the other two, and they require different baud_base values!
Search your adapter documentation to determine the baud_base value for each of your ports. baud_base is the UART reference clock frequency divided by 16. Typically it's 115200 but it could be 921600 or something else again. The fancier and faster the card the more likely it is to use an unusual baud_base.
Use 'setserial -g -G /dev/ttyS*' as root to look closely at the parameters that the standard serial driver is using.
When you know all the necessary parameters, call setserial without the -G or -g to write the configuration. See examples below. Don't skip any of the parameters! The setserial call doesn't require you to specify all the parameters but if you don't set them all the previous values will be retained, which may not be correct.
Linux has always supported device nodes for the ttyS0-3 and tried to autodetect UARTs at the standard addresses and IRQs for those PC ports. In modern times it seems to do a pretty good job at picking up extra serial devices detected on other addresses by Plug & Play, creating enough extra device nodes to cover them. If you're using a multi-port adapter card and find you don't have enough device nodes you can create extra ones by editing /boot/grub/menu.lst, adding kernel parameter '8250.nr_uarts=16', then rebooting. Its only the more recent kernels that support this though I think. You may not need to do it at all. Some third-party serial cards eg Sunix come with tools that create device nodes for you.
The mechanism used to save serial configuration settings across reboots has changed over the years and it varies depending on what distribution you're using. You may need to do some reading to get it to retain and apply your new settings properly.
Some distributions (eg those that use upstart) seem to call setserial automatically for each serial device midway through their start up process. The values it uses are usually what has been saved previously: they're NOT necessarily correct, so don't assume they're correct. Autodetected values tend to be correct for motherboards but are sometimes wrong for other products, eg some Sunix chips among others.
You should only call setserial for products that use standard UART types, because that's all the standard serial driver knows about. More complex serial cards with proprietary chipsets tend to require proprietary drivers. The ONLY time you can use them safely with the standard serial driver is if they've told you which standard UART type they're compatible with and what the baud_base should be. (Look for it in their documentation.)
If your PC gets random blue screens / kernel panics then check your device drivers are properly configured. eg wrong I/O address, wrong IRQ, wrong UART type.
If your PC randomly becomes very slow, eg pausing for ten seconds before continuing, check your device driver configuration. This may indicate wrong IRQ, leaving driver waiting until timeout after ten seconds or so, at which point it falls back to polling mode and starts working again.
Make sure your serial cable is fully wired (9 wires plus shield). Thin mouse cables may only have 4 wires and they are unsuitable for Phoenix. Null modem cables in conjunction with gender changers are also unsuitable.
Attach serial cable at both ends before applying power to your phoenix interface, to avoid risk of damage when using switchmode plug packs.

One crude but effective way to ensure the serial device settings are as you expect is to specify them manually just before you start newcs.

I put the following in /etc/rc.local (check its permissions are correct).
The I/O addresses and IRQ numbers will vary from system to system so don't copy it directly!
----------------------------------------------------------------------
#!/bin/sh -e
# rc.local
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
# In order to enable or disable this script, change the execution bits.

# install Red Chief CH352 PCI dual serial card's binary driver for ttyS2 & ttyS3
/usr/bin/install_ss_80x86

# Set uart_type and baud_base for each device to make sure
# custom baud rates work properly. In this case all devices happen
# to use the same values, but that's just coincidence. Plenty of other
# products use different values.

# motherboard port
setserial /dev/ttyS0 uart 16550A port 0x03f8 irq 4 baud_base 115200 spd_normal autoconfigure

# Red Chief CH352 PCI dual serial card
setserial /dev/ttyS2 uart 16550A port 0xc800 irq 217 baud_base 115200 spd_normal autoconfigure
setserial /dev/ttyS3 uart 16550A port 0xcc00 irq 217 baud_base 115200 spd_normal autoconfigure

# ST-Labs I-180 PCI six serial card
setserial /dev/ttyS4 uart 16550A port 0xb000 irq 209 baud_base 115200 spd_normal autoconfigure
setserial /dev/ttyS5 uart 16550A port 0xb400 irq 209 baud_base 115200 spd_normal autoconfigure
setserial /dev/ttyS6 uart 16550A port 0xb800 irq 209 baud_base 115200 spd_normal autoconfigure
setserial /dev/ttyS7 uart 16550A port 0xbc00 irq 209 baud_base 115200 spd_normal autoconfigure
setserial /dev/ttyS8 uart 16550A port 0xc000 irq 209 baud_base 115200 spd_normal autoconfigure
setserial /dev/ttyS9 uart 16550A port 0xc400 irq 209 baud_base 115200 spd_normal autoconfigure

# start NewCS
/usr/bin/newcs -c /home/admin/newcs.xml 2:>/dev/null &
exit 0
----------------------------------------------------------------------

**fandtm666** · 11-02-09, 06:45 AM

As always GW great break down and explanation

**weirdo** · 11-02-09, 08:25 AM

Way over my head but you have amazing knowledge gw1.
Thanks for sharing.

**best4less** · 11-02-09, 09:36 AM

Thanks gw1 that will be a great reference post that i will come back to all the time

Already found it useful

If your PC randomly becomes very slow, eg pausing for ten seconds before continuing, check your device driver configuration. This may indicate wrong IRQ, leaving driver waiting until timeout after ten seconds or so, at which point it falls back to polling mode and starts working again.

**vinayr** · 11-02-09, 08:19 PM

gw1 awesome as always ( thankyou for your time and sharing )

**gado** · 11-02-09, 09:06 PM

Nice work GW1.
I think I have travelled over all the ground the hard way. Your post should help alot of people getting off the ground with newcs.

Q1. Where did you get the
ST-Labs I-180 PCI six serial card ?

Q2. I have noticed some PCI serial card come up with unknown on the chipset with the lspci -v command. How do you configure those cards ?

Gado

**z80** · 11-02-09, 09:24 PM

If you just want a solution that works,

use a main board with the latest core 2 duo chipset.

**gw1** · 11-02-09, 11:36 PM

Originally Posted by gado

Where did you get the
ST-Labs I-180 PCI six serial card?

The one I played with came from .

You can find other cards by typing "PCI serial" into .

I have noticed some PCI serial card come up with unknown on the chipset with the lspci -v command. How do you configure those cards?

Check manufacturer website to see if they offer a driver.
Check manufacturer docs to see if they tell you what UART type it uses, ie which standard UART it is compatible with.
Inspect card to see what chips they use. Then check the chip manufacturer's website to see if you can find
- documentation about chip's UART type, or
- technical datasheet (electronic design and programming information) which should indicate any compatibility with standard UART types
Search to see if you can find any discussion of the chip in Linux forums; chances are you're not the first person to look for information on how to use it on Linux.
Ask on Linux forums for help. In your post be sure to include full model number of serial adapter, part numbers of controller chip(s) it uses, and detailed extract from lspci. From memory there's a -vv or -vvv option which spits out heaps of information (you probably need to be root).

There are certainly some products out there which are incompatible with all standard UART types. If their manufacturers don't provide a Linux driver, and you can't find anything about it on Linux forums, then you're SOL.

Email the manufacturer to let them know you use Linux and cannot recommend their product to others until they offer Linux support (who knows, you might even get a reply from them!)
Return it under warranty if you can (not suitable for intended purpose), otherwise flog it on ebay and put the money towards something else
Post your experience out on the forums as a warning to others

By the way, you may notice that the Linux kernel spits out a warning (under dmesg from memory) when applications use the custom baud API, saying the API is deprecated. I used to think that was a warning in the device driver that they didn't support custom baud rates, but the warning comes from Linux itself - giving you advance notice that Linux may cease supporting custom baud rates at some point, at which point that particular application may no longer work. The decision to deprecate the API is understandable because it's a fair bit of grief for a feature that only a tiny percentage of users require. Don't panic though: if and when it gets pulled it just means you'll need to stick with older kernels. Plenty of embedded systems do that, for a variety of reasons, and there's lots of long-term-support options to choose from. It's no different to keeping a Win98 partition for legacy hardware or tools that require it.

good luck

**statesmanjeff** · 12-02-09, 01:47 PM

Wow.

Well done GW1

**limit** · 10-06-09, 02:21 AM

thx for this use full info......i have same issue regarding this maybe you can give me a idea what canbe pls.....

root@testpc-desktop:lspci -v

01:01.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06)
Subsystem: AFAVLAB Technology Inc Device 2182
Flags: medium devsel, IRQ 22
I/O ports at b400 [size=32]
Memory at ff0fd000 (32-bit, non-prefetchable) [size=4K]
I/O ports at b000 [size=32]
Memory at ff0fc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 1
Kernel driver in use: serial

01:01.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)
Subsystem: AFAVLAB Technology Inc Device 2182
Flags: medium devsel, IRQ 23
I/O ports at bc00 [size=32]
Memory at ff0ff000 (32-bit, non-prefetchable) [size=4K]
I/O ports at b800 [size=32]
Memory at ff0fe000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 1
Kernel driver in use: serial

01:03.0 Serial controller: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 0 (Uart) (prog-if 06)
Subsystem: AFAVLAB Technology Inc Device 2182
Flags: medium devsel, IRQ 20
I/O ports at a400 [size=32]
Memory at ff0f9000 (32-bit, non-prefetchable) [size=4K]
I/O ports at a000 [size=32]
Memory at ff0f8000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 1
Kernel driver in use: serial

01:03.1 Bridge: Oxford Semiconductor Ltd OX16PCI954 (Quad 16950 UART) function 1 (8bit bus)
Subsystem: AFAVLAB Technology Inc Device 2182
Flags: medium devsel, IRQ 21
I/O ports at ac00 [size=32]
Memory at ff0fb000 (32-bit, non-prefetchable) [size=4K]
I/O ports at a800 [size=32]
Memory at ff0fa000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [40] Power Management version 1
Kernel driver in use: serial

=========================================
setserial -g -a /dev/ttyS*
/dev/ttyS1, Line 1, UART: 16950/954, Port: 0xac00, IRQ: 20
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_cust skip_test
/dev/ttyS2, Line 2, UART: 16950/954, Port: 0xac08, IRQ: 20
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

/dev/ttyS3, Line 3, UART: 16950/954, Port: 0xac10, IRQ: 20
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

/dev/ttyS4, Line 4, UART: 16950/954, Port: 0xb400, IRQ: 22
Baud_base: 115200, close_delay: 50, divisor: 20
closing_wait: 3000
Flags: spd_cust skip_test

/dev/ttyS5, Line 5, UART: 16950/954, Port: 0xb408, IRQ: 22
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

/dev/ttyS6, Line 6, UART: 16950/954, Port: 0xb410, IRQ: 22
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

/dev/ttyS7, Line 7, UART: 16950/954, Port: 0xb418, IRQ: 22
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_cust skip_test

/dev/ttyS8, Line 8, UART: 16950/954, Port: 0xbc00, IRQ: 23
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test

=================================================

but when i start newcs..... i got this log

This is NewCS 1.62 - the New CardServer by the Butter-team..
Compiled on Aug 27 2008 at 16:40:27
Reading Config file from /etc/newcs/newcs.xml
TCP-log password is enabled, set to: test
TCP-log set to simple mode
level: normal
type: init
output: console,all
logger config: level 1 type 3 output 255
Console log options: level 1 type 3
log file: /etc/Newcs-Log/test.txt
File log options: level 1 type 19
logger: no udp host defined, udp log disabled
TCP log options: level 1 type 3
[ 17

46 ] [ Box detect ] Box type 1 (General Boxtype - PC compatible)
[ 17

46 ] [ Config ] Option <blockc0> for device 0 (Viaccess) not present, defaulting to NO
[ 17

46 ] [ Config ] Pincode for device 0 (Viaccess): 0000
[ 17

46 ] [ Config ] /dev/ttyS4 ECM priority: round
[ 17

46 ] [ Config ] Option <cache> not present, defaulting EMM: 20, ECM: Dynamic
[ 17

46 ] [ EMM Cache ] Initialising dynamic Cache
[ 17

46 ] [ ECM Cache ] Initialising dynamic Cache
[ NewCS ] Process ID is: 14774
[ 17

46 ] [ Loader ] Starting Telnet on port 1200
[ 17

46 ] [ Loader ] Reader type 2 on node /dev/ttyS4
[ 17

46 ] [ Phoenix ] Opening device /dev/ttyS4
[ 17

46 ] [ Phoenix ] Setting Parity to: NONE
[ 17

46 ] [ Phoenix ] Setting 2 Stop bits on node /dev/ttyS4
[ 17

46 ] [ Phoenix ] Setting Baud to standard 9600
[ 17

46 ] [ Phoenix ] Normal RESET on node /dev/ttyS4
[ 17

48 ] [ Loader ] Unknown card
[ 17

48 ] [ Loader ] Trying Irdeto (T=14)
[ 17

48 ] [ Loader ] Reader type 2 on node /dev/ttyS4
[ 17

48 ] [ Phoenix ] Opening device /dev/ttyS4
[ 17

48 ] [ Phoenix ] Setting Parity to: NONE
[ 17

48 ] [ Phoenix ] Setting 2 Stop bits on node /dev/ttyS4
[ 17

48 ] [ Phoenix ] Setting Baud to custom 5713
[ 17

48 ] [ Phoenix ] Normal RESET on node /dev/ttyS4
[ 17

50 ] [ Loader ] Unknown card
[ 17

50 ] [ NewCS ] Ready to GO!

===============================================

newcs cant detect the card .........?????????? also i try <carddetect>no</carddetect> <carddetect>yes</carddetect>

===============================================

anyhow if i connect the phoenix reader to usb ( useing usb-serial cable)

with the same xml+reader+card

newcs can start normal and detect the viaccess card.......

Do i missing same setting in kernel for this 8port pci card??????

thx for your help.......

**gw1** · 10-06-09, 02:56 PM

Googling for "OX16PCI954 linux baud_base" gives a for AVLab's "PCI 8S Octet with 16950 UART" () which uses the OX16PCI954. Looking at your configuration I suspect that's the product you're using.

The Linux configuration section of that manual indicates that the Oxford chip is register-compatible with 16950 but needs a baud_base 10x higher than the usual 115200, perhaps because it's designed to offer high transfer speeds. So I would start by trying:

setserial /dev/ttyS1 port 0xac00 irq 20 uart 16950 baud_base 1152000
setserial /dev/ttyS2 port 0xac08 irq 20 uart 16950 baud_base 1152000
setserial /dev/ttyS3 port 0xac10 irq 20 uart 16950 baud_base 1152000
setserial /dev/ttyS4 port 0xb400 irq 22 uart 16950 baud_base 1152000
setserial /dev/ttyS5 port 0xb408 irq 22 uart 16950 baud_base 1152000
setserial /dev/ttyS6 port 0xb410 irq 22 uart 16950 baud_base 1152000
setserial /dev/ttyS7 port 0xb418 irq 22 uart 16950 baud_base 1152000
setserial /dev/ttyS8 port 0xbc00 irq 23 uart 16950 baud_base 1152000

Note that I've adjusted the ports and IRQs to match the ones reported by lspci in your system. Those settings are assigned by Plug & Play, and if you add or remove PCI devices to your PC at some stage in future the settings may change, in which case you may need to run 'lspci -v' again and update the ports and IRQs in your configuration script.

You might like to experiment with just one of the lines and get it going before retyping for all of them.

Also I suggest when troubleshooting serial ports in NewCS to concentrate on one at a time, disabling all the others. Only enable them all once you know their correct settings. It's easier that way.

If that doesn't do the trick then spend some time studying the manual and installing their Linux driver if they provide one. Search the manufacturer website in case they offer further information, and try emailing them for help if problems persist.

good luck. if you get it to work then let us know what the problem was.

**limit** · 10-06-09, 11:29 PM

bloody hell.....i was so busy making kernel config's /// patches ///// i change 4 times ubuntu and i try other version fedora bla bla bla......
i was doing loopback cables and change cristals on the reader ........

i also have that user manual.pdf i spend many hours on kernel and other config files........i just had a quick look on that user manual...any how i just put it in my mind baud_base 115200... cos of that it cost me 36 hours digging on wiki.linux documentations for nothing.not even there engineer point out this baud base issue....cos like me we was thinking problem some where else in the kernel......

thanks man you point out the problem.. when i was typing on ssh terminal after many hours i guess i miss the "0" for 115200...........

i'm glad this forum has guys like you.and really thanks share your great knowledge with us...

i install one more 8port pci cart......now i have 16 port serial and they working like a charm ...

thanks again help me out @gw1 ......

**gw1** · 11-06-09, 02:14 AM

bloody hell... i spend many hours...
it cost me 36 hours digging on wiki.linux documentations for nothing.
Not even their engineer point out this baud base issue...

Don't feel too bad. I had several days of frustration and hair-pulling before I was able to put all the pieces together and understand how it worked.

The support guy can be forgiven too for not knowing about baud_base, it's so esoteric. The only time baud_base ever matters is if an application utilises custom baud rates, and of all the applications written for IBM PC hardware over the years barely a handful do that. Even among smartcard applications the number that actually use custom baud rates is a small minority because most smartcards systems are designed to use 9600 baud.

It's a shame that NewCS uses the tricky custom baud API feature without warning about it and mentioning uart types and baud_base in their documentation. It's a Linux application after all. It's like they've sent their users down a road knowing there's a landmine but not telling them. The majority who only use onboard motherboard serial ports never hit it, fortunately.

**tuupje** · 11-08-09, 08:03 AM

PLEASSSSSSS HELP

Hi,

I have 2 Microclients (MiniITX with VIA Chipset) with Linux running.

1x has Featherlinux 0.7.5 with a VSCOM400H Pci 4 port serial card

1x has Debain Lenny with a Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01) with a 4 port serial card

I'm trying for almost 3 weeks for getting the card to work without succes.

On both systems I changed the Grub boot parameter so the tty devices are being recognised.

I'll give an example from what I've done till now with the Debian system, still without succes so far !!!

lspci -nn

00:0e.0 Serial controller [0700]: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) [1409:7168] (rev 01)

cat /proc/ioports

dc00-dc1f : 0000:00:0e.0
dc00-dc07 : serial
dc08-dc0f : serial
e000-e00f : 0000:00:0e.0
e000-e007 : serial
e008-e00f : serial

lspci -vv -s 00:0e

lspci -vv -s 00:0e
00:0e.0 Serial controller: Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01) (prog-if 02 [16550])
Subsystem: Timedia Technology Co Ltd Device 4056
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 15
Region 0: I/O ports at dc00 [size=32]
Region 1: I/O ports at e000 [size=16]
Kernel driver in use: serial

cat /proc/tty/driver/serial

serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:47 rx:241 fe:9 brk:7
1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:16550A port:0000DC00 irq:15 tx:180 rx:0
5: uart:16550A port:0000DC08 irq:15 tx:0 rx:0
6: uart:16550A port:0000E000 irq:15 tx:0 rx:0
7: uart:16550A port:0000E008 irq:15 tx:0 rx:0
8: uart:unknown port:00000000 irq:0
9: uart:unknown port:00000000 irq:0

Linux version 2.6.26-2-486 (Debian 2.6.26-17lenny1)

According to the Manual the settings should be

setserial /dev/ttyS2 port 0xbc00 UART 16550A irq 3 Baud_base 115200

or

setserial /dev/ttyS2 port 0xbc00 UART 16550A irq 3 Baud_base 921600

Also read this article

But still my newcs keeps resetting, usage of newcs with phoenix reader is not possible

**gw1** · 11-08-09, 05:05 PM

Google will tell you that Timedia serial port installation problems are frequently unanswered. There's a reason for that. There are a dozen different PCI serial products under various brands that are all detected as "Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01)". They have different chip arrangements so it's not possible to advise on correct configuration without knowing exactly which model you have. This is a limitation of Plug & Play: even Windows with its massive multi-gigabyte driver database can't always determine what driver to use automatically.

To know for certain what your product is we really need to know what identifying marks are written on its circuit board and chips. But from details in your post I would hazard a guess that it's a rebadged Sunix 4056A, in which case I recommend you try:
# setserial /dev/ttyS4 uart 16550A port 0xDC00 irq 15 baud_base 921600
# setserial /dev/ttyS5 uart 16550A port 0xDC08 irq 15 baud_base 921600
# setserial /dev/ttyS6 uart 16550A port 0xE000 irq 15 baud_base 115200
# setserial /dev/ttyS7 uart 16550A port 0xE008 irq 15 baud_base 115200

These may not be correct depending on what product you have. To help you troubleshoot further, and to assist others who find this via Google, I'll explain my reasoning below.

* * * * *

Products with "Timedia Technology" in the device description may be using controller chips, since Timedia and Sunix use the same Plug & Play ID codes:
Vendor ID = 1409
Device ID = 7168
A clue to the model is found in the Subdevice ID. In your case it's "4056" which indicates that it may be Sunix 4056A, 4056D, 4056U or one of numerous compatibles. Sunix website photos suggest those three models use different chip combinations, yet all of them are likely to be reported by Plug & Play as "Timedia PCI2S550"!

Let's suppose your product is Sunix 4056A. That has a mix of SUN1889 and SUN1699 controller chips:

The two chip types require different baud_base values, which presumably is why your manual mentioned two different values.

The 4056A theory is consistent with your "lspci -vv" extract which noted:
Region 0: I/O ports at dc00 [size=32]
Region 1: I/O ports at e000 [size=16]

When you see different region sizes that's a clue that there may be different devices being used. What's happening is the card's Plug & Play configuration data (stored in its onboard EEPROM) is requesting a 32-byte port range for the SUN1889, which is large because that chip supports a bunch of configurations and hence occupies more I/O. The second port range is smaller, only 16 bytes, because that's sufficient to address both SUN1699 chips.

Looking at your output of /proc/tty/driver/serial we can make several observations:
0: uart:16550A port:000003F8 irq:4 tx:47 rx:241 fe:9 brk:7
1: uart:16550A port:000002F8 irq:3 tx:0 rx:0
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:16550A port:0000DC00 irq:15 tx:180 rx:0
5: uart:16550A port:0000DC08 irq:15 tx:0 rx:0
6: uart:16550A port:0000E000 irq:15 tx:0 rx:0
7: uart:16550A port:0000E008 irq:15 tx:0 rx:0
8: uart:unknown port:00000000 irq:0
9: uart:unknown port:00000000 irq:0

The standard serial driver has allocated plenty of serial devices (ten of them), which is good.
It's recognised from Plug & Play that there are four serial devices, which is good.
It's figured out that the UART base addresses in your particular system are 0xDC00, 0xDC08, 0xE000, 0xE008 - which is good because they match the address ranges reported by lspci. (Each serial port occupies .)
All serial devices have been allocated a common IRQ (#15 in this case), which is good because it's normal on a Sunix PCI card for all serial devices to share a single IRQ.
It's autodetected the UARTs as 16550A, which is good because that's the type used by most Sunix PCI serial cards AFAIK.

How do we know to use baud_base 921600 for the SUN1889's serial devices? Well, Sunix's old 2003 [48K PDF] indicates that models 4025A and 4036A, which use SUN1889 chip, need baud_base 921600. And other websites that special baud_base too.

What about the SUN1699 chips? How do we know they require baud_base 115200? I think Sunix website used to mention it, though I can't it on their site at the moment. But it's recorded in several places such as and and I think they've copied old Sunix documentation.

If you're on the ball you might have noticed that Sunix's for 4056A says the SUN1889 is "16C650 UART compatible". Why then are we using 16550A? I believe the Sunix website and flyers are wrong. Blurb like that is often collated by marketing types who don't understand that 16C650, 16550 and 16550A are quite different. Who knows where they got 16C650 from. Their 2003 Linux Installation Guide clearly indicated that many Sunix PCI serial cards including model 4056A use UART type 16550A.

Now it's possible you may find two serial devices work but two don't. If experimenting with the baud_base value doesn't help then it's possible . Sunix many years ago just gave instructions on how to configure the Linux standard serial driver, but nowadays they offer a . Custom drivers sometimes exist to offer higher performance or access to special features, but it's also possible that maybe there's a compatibility issue. The standard serial driver is only suitable if the product is fully compatible with one of the standard UART types. If you're unable to get the standard serial driver to work your options are

Use the Sunix serial driver. If you have trouble getting it to compile on Lenny then ask about it in the Debian user forums, someone there may be able to assist. Sunix's code hasn't been updated for twelve months, though their release notes say it tested OK with Ubuntu 8.04.
Use a different serial card that's fully compatible with one of the standard UART types.
Use an earlier version of Linux that Sunix's serial driver was tested against (not recommended, it can be tricky obtaining support packages if you go back too far).
Use Windows with Sunix binary (not recommended, newcs works much better on Linux than Windows).

It's usually quicker and cheaper to change hardware than to change distribution.

Once you establish exactly what model PCI card you're using, someone here may be able to confirm whether it works with the standard serial driver or requires the Sunix one.

good luck

**tuupje** · 12-08-09, 12:12 AM

Hi,

First off all thanks for your ultra speedy reply !!!

)

I checked the board and it is like you mentioned.

Model 4056A with 2 different chips on board.

I used the setserial command to adjust te baud_base speed to the mentioned one in your post.

But still no luck. When using newcs, same reset problem with newcs, tested every seperate port with bauth both speeds.

Then I downloaded the driver from the link you posted. I wanted to install the serial driver but....

In the readme file it says unpack golden_Vx.x.x.x.tar.gz.

But there is no golden_Vx.x.x.x.tar.gz file inside the zip archive.

Also if I wanted to load the snx_golden driver, it's not in the zip file.

Load driver module, do command:

# modprobe snx_golden

So I need the correct driver package to continue. Where can it be found?

I've put the DLINK SER4 Timedia Technology Co Ltd PCI2S550 aside, not in the trash yet.

I'm now re-installing the system with the VSCOM 400H PCI.

I found some guidelines on their site about the linux installing:

I keep you updated...to be continued....

And I already bought a replacement card for the DIGITUS SER4 on ebay

COMTROL RS232 PCI-4j 4Port Adapter

I also ran into this article:

(It is not the text NewCS sends to the card hexa text..."#### you all"... as I thought at first...it is send, by this is not the problem.)

When linux initializes serial port throug open() and uses standard serial.c driver, there exists very short pulse on RTS signal. Its length depends on speed of computer, old PII 120 MHz is about 10us, AMD K6 400 MHz is about 3-5 us, fast computer gives several hundreds nanosecond.
If the pulse is very short Merlin card is ok. Just in between app. 1us to 20us card goes to "third" state.
So my descripted problem comes only when:
1. Older slower computer.
2. Serial.c driver used (drivers for 8xCOM PCI cards has no such mistake and usaully patch all serial drivers).
3. Initialization of serial port with open().

Solution:
Insert RC element in reset signal of phoenix. There is 100R protecting rezistor in reset, so for me it works with 10uF capacitor at reset pin of the card. This kills pulses shorter than 10us...and all problems are solved.

Could that also be the problem?

**gw1** · 12-08-09, 04:03 AM

Originally Posted by tuupje

In the readme file it says unpack golden_Vx.x.x.x.tar.gz.

But there is no golden_Vx.x.x.x.tar.gz file inside the zip archive.

The readme file is old and needs updating, it contains some errors.

Their driver is now distributed as .zip rather than .tar.gz.

Also if I wanted to load the snx_golden driver, it's not in the zip file.

Load driver module, do command:
# modprobe snx_golden

So I need the correct driver package to continue. Where can it be found?

It's not supplied - you have to make it yourself to suit your system, because the system libraries the driver uses aren't compatible at binary level from one kernel version to another.

Just as windows binary drivers often aren't portable between kernel versions (Win95/ME/2K/Vista), Linux binary drivers aren't either. Usual practice in the Linux world is to distribute drivers in source form and build them during the installation process. Makefiles are scripts used to automate part of that process.

In principle you just extract the zip driver, change directory to the top Makefile (in same directory as the README.linux file) and then as root run 'make clean; make install' as outlined in the readme. When successful it creates a bunch of binaries for your system, including the snx_golden driver and the snxdriver diagnostic tool.

In practice there are often hurdles to overcome when installing on systems that the manufacturer hasn't tested with (such as Debian Lenny). For non-programmers and newbies these hurdles can be daunting - thank god for FAQs, forums and google.

What sort of hurdles?

Your system may not have all the necessary packages installed.
System library changes between kernel versions may mean minor changes to the driver code are needed.
If you're running a kernel that's newer than the driver the driver code may not recognise the new kernel name properly (Windows applications sometimes have this problem too), necessitating minor changes to the driver code.

In the Windows world the work of updating and testing drivers has to be done by the driver manufacturer or by Microsoft themselves, and until they do users have to wait. In the Linux world manufacturers and/or distribution teams update the driver source code for new kernel versions, or impatient users with coding experience can fix the driver for themselves. Unfortunately serial cards don't get much priority nowadays since relatively few people still use them, so much so that Linux may even drop support for some serial driver features eventually.

If you need help compiling the Sunix driver on your system then it's probably best to start a new thread as it may be a prolonged discussion.

When linux initializes serial port throug open() and uses standard serial.c driver, there exists very short pulse on RTS signal. Its length depends on speed of computer, old PII 120 MHz is about 10us, AMD K6 400 MHz is about 3-5 us, fast computer gives several hundreds nanosecond.
If the pulse is very short Merlin card is ok. Just in between app. 1us to 20us card goes to "third" state.
So my descripted problem comes only when:
1. Older slower computer.
2. Serial.c driver used (drivers for 8xCOM PCI cards has no such mistake and usaully patch all serial drivers).
3. Initialization of serial port with open().

Solution:
Insert RC element in reset signal of phoenix. There is 100R protecting rezistor in reset, so for me it works with 10uF capacitor at reset pin of the card. This kills pulses shorter than 10us...and all problems are solved.

Could that also be the problem?

I wasn't aware of that issue, thanks for pointing it out. I'd call it a NewCS bug because NewCS should not be reinitialising the port that way unless it intends to reset the card.

That could potentially be a problem in your case. It's difficult to say. I never noticed it myself during my experiments with NewCS, though I typically used modern fast processors. There certainly were some reset failures recorded in the log that I never fully understood, but who can say whether they're caused by glitches. That's the problem with NewCS being closed source and poorly documented - it's hard to recognise bugs when you aren't sure what constitutes normal behaviour.

An RC element would certainly suppress spurious card resets, but it's a crude approach with a bunch of problems!

There's no documentation of how NewCS works (apart from what its logs reveal) so determining correct filter delays can only be done by trial and error, not with certainty.
If filter time constant is too high it could inadvertently suppress desired resets, particularly if software is poorly structured and doesn't always generate the same reset pulse length. ISO7816 defines reset sequencing parameters that ought to be taken into account but there's no guarantee that NewCS respects the specification - I doubt it does. Equipment such as satellite receivers that use smartcard controller ICs like TDA8004 have the reset sequencing regulated by hardware, but not so with Phoenix: it leaves everything up to software.
Accurate control of the reset pulse width is impossible using Phoenix interfaces with Linux or Windows, because they're not realtime operating systems. So there's a degree of luck as to whether the pulses your system generates happen to meet the requirements of your particular smartcard. Needless to say this isn't how rockets and life support equipment are engineered!
The protection resistor is vital if applying a large capacitor like 10uF, since without it the transient current would stress and perhaps damage the gate driving the capacitor.
The large capacitor compromises the transient current protection provided by the resistor, since cards could be damaged during insertion/removal by rapid discharge of the 10uF capacitor into the RST pin unless card VCC and GND both make contact first.
The RC time constant means reset signal slew rate is poor. ISO7816 is strict about signal conditioning and some cards may not like the long rise and fall times. Again it's a matter of trial and error: what works for some card brands may fail for others.
A safer way to add an RC filter would be to take the RST output from the MAX232 IC and feed it via say 10K/0.1uF filter into the input of a schmitt trigger buffer, such as a pair of 74HC14 or 74HC132 gates. Then feed the gate output via the 100R protection resistor to the card RST. That gives you your delay without undue loading, with nice clean signal edge at the card, while preserving transient protection for card insertion/removal.

Where this spurious reset issue exists it will also manifest on Windows, for applicable versions of NewCS, regardless of serial port card or driver. If you'd like to discuss that issue further then it's probably appropriate to start a new thread.

Good luck, I hope you find success. Plenty of people have had good results with NewCS using various Linux distros, usually on reasonably modern systems though and most commonly using motherboard serial ports ttyS0 & ttyS1. I would not be at all surprised to see timing problems manifest when trying to run applications like NewCS on ancient Pentiums and K6s - its crypto operations are a time consuming distraction, not to mention the running of a busy network stack and the churn of memory management. ISO7816 protocol involves time limits so if the software is tardy due to antiquated hardware you shouldn't be surprised if wheels come off occasionally. Enjoy the hobby, just don't expect it to be bullet-proof.

**tuupje** · 12-08-09, 07:40 AM

Problem solved.

I installed Debian onto an older PII compaq with the same Timedia Technology Co Ltd PCI2S550 (Dual 16550 UART) (rev 01) that didn't work on the Microclient and now it works!

At least for ttyS4 and ttyS5 with a 16550A UART setting.
deskpro:~# dmesg | grep ttyS*
[ 0.004000] console [tty0] enabled
[ 4.711396] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 4.711912] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
[ 4.718353] 00

ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 4.719357] 00

ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
[ 4.722168] 0000:00:0e.0: ttyS4 at I/O 0x20c0 (irq = 11) is a 16550A
[ 4.723041] 0000:00:0e.0: ttyS5 at I/O 0x20c8 (irq = 11) is a 16550A
[ 4.723910] 0000:00:0e.0: ttyS6 at I/O 0x20b0 (irq = 11) is a 16550A
[ 4.724839] 0000:00:0e.0: ttyS7 at I/O 0x20b8 (irq = 11) is a 16550A
[ 1942.009793] newcs-1.65_cd.i sets custom speed on ttyS6. This is deprecated.
[ 2060.574484] newcs-1.65_cd.i sets custom speed on ttyS7. This is deprecated.

/dev/ttyS4, UART: 16550A, Port: 0x20c0, IRQ: 11

For ttyS6 and ttyS7 I had to use setserial command:

setserial /dev/ttyS7 uart 16550A port 0x20b8 irq 11 baud_base 115200

I read somewhere that slow pcs (which the microclient is, a VIA with 533 Mhz) can have problems with serial devices under linux.

I'm glad that I did this last test but dissapointed that it doesn't work on my Microclient.

I also tested an ATEN USB to Serial adapter on the microclient that works on windows and was recognised correctly on Debian as /dev/ttyUSB0 with newcs. But the same problems as with the 4 port serial card, only resets!
In Debian on the Deskpro it doesn't reset but it only adds 1 key and than it fails !

[ 23:16:20 ] [ Loader ] Reader type 2 on node /dev/ttyUSB0
[ 23:16:20 ] [ Phoenix ] Opening device /dev/ttyUSB0
[ 23:16:20 ] [ Phoenix ] Setting Parity to: NONE
[ 23:16:20 ] [ Phoenix ] Setting 2 Stop bits on node /dev/ttyUSB0
[ 23:16:20 ] [ Phoenix ] Setting Baud to standard 9600
[ 23:16:20 ] [ Phoenix ] Normal RESET on node /dev/ttyUSB0
[ 23:16:22 ] [ ATR ] T=0 1etu=104.17us Guardtime:204etu WWT:144000etu
[ 23:16:22 ] [ ATR ] Historical bytes: p p 7 [0E] l [B6] [D6]
[ 23:16:22 ] [ Loader ] Init Seca card
[ 23:16:22 ] [ Phoenix ] Setting Parity to: EVEN
[ 23:16:22 ] [ Phoenix ] Setting 2 Stop bits on node /dev/ttyUSB0
[ 23:16:22 ] [ Phoenix ] Setting Baud to standard 9600
[ 23:16:22 ] [ KeymaN ] Adding key xxxxxxxxxxx type 0 on Provider 000000 for caid 0100 ID=0
[ 23

08 ] [ Loader ] Card 0100 on port /dev/ttyUSB0 failed
[ 23

09 ] [ Loader ] Starting Newcamd Server on port 10001
[ 23

09 ] [ Newcamd ] Newcamd thread Server started on port 10001

Is there another possible way to get those pci cards running on he microclient under linux (eSeSIX-WLV102 / Northec Jr)

Otherwise I will have to switch to smargo USB readers I read on the Dutch Sat forum that they do work with a microclient pc.

**gw1** · 12-08-09, 04:43 PM

Congratulations tuupje, glad your perseverence paid off.

For the record can you confirm that what you ended up using on your Compaq Pentium II/Timedia 4056A system? It sounds like it was
setserial /dev/ttyS4 uart 16550A port 0x20C0 irq 11 baud_base 921600
setserial /dev/ttyS5 uart 16550A port 0x20C8 irq 11 baud_base 921600
setserial /dev/ttyS6 uart 16550A port 0x20B0 irq 11 baud_base 115200
setserial /dev/ttyS7 uart 16550A port 0x20B8 irq 11 baud_base 115200

As for your Microclient, a Smargo USB reader sounds like a good idea if others have reported it to work well.

I haven't used Smargo USB readers before but most likely their firmware emulates Phoenix mode rather than simply gating FTDI handshaking lines straight through to the card. That would mean it observes proper ISO7816 reset sequencing and be less susceptible to glitches like the one you posted about.

With don't be surprised if you encounter flakey behaviour occasionally. Running only the bare minimum of daemons, turning off logging etc, may all help on slow systems. They may be fine for small networks of 2 or 3 clients but if buying just for NewCS then a cheap DM500 clone may be more cost effective.

For best NewCS reliability with larger loads I recommend a slow cool Core 2 Duo, a high quality PSU, reputable motheboard & RAM, fanless video, big copper Zalman cooler, quiet Antec Solo or Sonata case with big slow fan and good dust filtering, all behind a reputable firewall with a business grade internet plan from a reputable ISP like Internode. (Oh, and no torrents on the connection!) For really big loads a Cisco 831/857/877 is a smart investment (you sometimes see second-hand ones on ebay).

**tuupje** · 14-08-09, 08:29 AM

This is the outpout for:

deskpro:~# setserial -g /dev/ttyS[01234567]
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: undefined, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16550A, Port: 0x20c0, IRQ: 11
/dev/ttyS5, UART: 16550A, Port: 0x20c8, IRQ: 11
/dev/ttyS6, UART: 16550A, Port: 0x20b0, IRQ: 11, Flags: spd_cust
/dev/ttyS7, UART: 16550A, Port: 0x20b8, IRQ: 11, Flags: spd_cust

This is actually my microclient:

And a Dutch forum user answered me that this PCI card: Sweex PU006V2 (MOSCHIP MCS9865CV) works in his microclient.

I don't know what you mean by exactly large, but on this microclient (256MB RAM ONLY) newcs runs well with lots of accounts and several cards with Feather Linux 0.7.5