I have a PC104 embedded system and am trying to make a Diamond
Emerald-mm-opto four port serial board work in a recent kernel version
(>=2.6.17). The vendor only validates the board against 2.6.11: a
kernel nearly two years old and several serial kernel config parameters
have changed in that time period.
the board uses two 16c2850 uarts and has four ports. It supports
interrupt sharing through an ISR bitmask.
since the recent 2.6.x kernels now break down the non-standard uart
support into specific hardware groups I cannot figure out how to get the
blasted thing to register/recognize with setserial. the MULTIPORT
option no longer exists in the kernel code so I had to explicitly
compile in "fourport" support just so ttyS4 through ttyS7 would be
accessible...and yes, you can assume that I've increased the available
ports using 8250.nr_uarts=16
At least now, with fourport compiled into the kernel, I can use
setserial to see the uarts and correctly identify them...but the shared
interrupt vector doesn't seem to work. I haven't even attempted yet to
try stty or echoing data our to an o-scope.
Here is the setserial dialog
# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i;
done
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x01a0, IRQ: 2, Flags: Fourport
/dev/ttyS5, UART: unknown, Port: 0x01a8, IRQ: 2, Flags: Fourport
/dev/ttyS6, UART: unknown, Port: 0x01b0, IRQ: 2, Flags: Fourport
/dev/ttyS7, UART: unknown, Port: 0x01b8, IRQ: 2, Flags: Fourport
# sh /root/setserial
+ SS=/bin/setserial
++ /bin/setserial /dev/ttyS4 port 0x120 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS5 port 0x128 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS6 port 0x130 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS7 port 0x138 irq 12 autoconfig '^fourport'
++ /bin/setserial /dev/ttyS4 set_multiport port1 0x244 mask1 0x0f match1 0
Cannot get multiport config: Invalid argument
# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; done
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16850, Port: 0x0120, IRQ: 12
/dev/ttyS5, UART: 16850, Port: 0x0128, IRQ: 12
/dev/ttyS6, UART: 16850, Port: 0x0130, IRQ: 12
/dev/ttyS7, UART: 16850, Port: 0x0138, IRQ: 12
-bash-3.1#
and the isadump shows that the ports are visible
# # dump uart registers
# isadump -f -y 0x120 32
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: 00 10 01 00 00 60 00 00 00 10 01 00 00 60 00 00
10: 00 10 01 00 00 60 00 00 00 10 01 00 00 60 00 80
# # dump ISR at 0x244
# isadump -f -y 0x240 16
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: ff ff ff ff 00 ff ff ff ff ff ff ff ff ff ff ff
-bash-3.1#
I would so much appreciate if someone intimately familiar with the
serial drivers could enlighten me as to what is going on here.
I'm not registered on the kernel list so CC to my email address would be
appreciated.
Thanks,
Rob Prowel
Kuchera Defense Systems
On Fri, Feb 23, 2007 at 12:05:48PM -0500, Rob Prowel wrote:
> At least now, with fourport compiled into the kernel,
You don't even need to do that. Just configure SERIAL_8250_NR_UARTS
and SERIAL_8250_RUNTIME_UARTS appropriately for your system. There's
absolutely no need to build any of the additional modules.
> I can use
> setserial to see the uarts and correctly identify them...but the shared
> interrupt vector doesn't seem to work. I haven't even attempted yet to
> try stty or echoing data our to an o-scope.
I dropped support for the shared interrupt vector - having multiple
different ISRs depending on the way the wind was blowing was extremely
complex, and in this day and age of GHz CPUs rather silly.
The serial driver can still share interrupts just fine. Just omit
configuring the multiport address and masks.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Thanks so much for your followup.
Russell King wrote:
> On Fri, Feb 23, 2007 at 12:05:48PM -0500, Rob Prowel wrote:
>
>> At least now, with fourport compiled into the kernel,
>>
>
> You don't even need to do that. Just configure SERIAL_8250_NR_UARTS
> and SERIAL_8250_RUNTIME_UARTS appropriately for your system. There's
> absolutely no need to build any of the additional modules.
>
>
Unfortunately what I'm seeing in 2.6.20.1 seems to differ from this. If
I use the options below:
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=16
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
# CONFIG_SERIAL_8250_FOURPORT is not set
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
# CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# Non-8250 serial port support
Then I can only access ttyS0 through ttyS3 sith setserial. Only after I add
CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do anything with the
additional ports. I would otherwise get the evil setserial: invalid
parameter error.
If you'd like I can offline you my complete .config file. lemme know.
>> I can use
>> setserial to see the uarts and correctly identify them...but the shared
>> interrupt vector doesn't seem to work. I haven't even attempted yet to
>> try stty or echoing data our to an o-scope.
>>
>
> I dropped support for the shared interrupt vector - having multiple
> different ISRs depending on the way the wind was blowing was extremely
> complex, and in this day and age of GHz CPUs rather silly.
>
> The serial driver can still share interrupts just fine. Just omit
> configuring the multiport address and masks.
>
>
OK. Fair enough. My question then becomes, how does the driver deal
with this now? scan all applicable uarts when any relevant interrupt is
detected (as identified in setserial)?
Thanks.
From: On Behalf Of Rob Prowel
> Russell King wrote:
> > You don't even need to do that. Just configure SERIAL_8250_NR_UARTS
> > and SERIAL_8250_RUNTIME_UARTS appropriately for your
> system. There's
> > absolutely no need to build any of the additional modules.
> >
> Unfortunately what I'm seeing in 2.6.20.1 seems to differ
> from this. If
PC104 is really an ISA bus. The ISA ports are stored in a table in the
8250 driver (instead of allocated dynamically like PCI ports); the
config option _NR_UARTS just tells the driver how large to make the
table.
> I use the options below:
>
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_8250_PCI=y
> CONFIG_SERIAL_8250_NR_UARTS=32
This makes the internal table be 32 ports big. The first four ports
end up configured for legacy/standard com ports, the rest are
unconfigured. You should be able to see them as unknowns with
setserial.
> CONFIG_SERIAL_8250_RUNTIME_UARTS=16
> CONFIG_SERIAL_8250_EXTENDED=y
> CONFIG_SERIAL_8250_MANY_PORTS=y
> # CONFIG_SERIAL_8250_FOURPORT is not set
All _FOURPORT does is specifically config ports 4-7 in the table to
have specific address/irqs for the FourPort board. What you do with
setserial is then change that config info to match your board.
You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it
looks like you don't. As long as _NR_UARTS is big enough, thus making
the internal table big enough, you should be able to configure, with
setserial, any of the ports in the table, including the first four.
> Then I can only access ttyS0 through ttyS3 sith setserial.
> Only after I add
> CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do
> anything with the
> additional ports. I would otherwise get the evil setserial: invalid
> parameter error.
Very odd. You get this error when doing "setserial /dev/ttySxx", no
configuration? If so, that would imply that the table wasn't made big
enough, and the unconfigured ports haven't been registered with the
serial core.
> OK. Fair enough. My question then becomes, how does the driver deal
> with this now? scan all applicable uarts when any relevant
> interrupt is
> detected (as identified in setserial)?
With our boards, the multiport is just a status register; it shows
which port has produced the interrupt, so the driver doesn't have to
loop through all the ports on the board looking for the correct one.
It doesn't actually enable/disable the sharing of the interrupt. The
setting of "irq 12" on multiple ports (from your original post) is
what enables the sharing, from the driver-side view. Maybe your
hardware is unusual and requires this ISR port to be set properly to
enable sharing; more likely is that the board itself has one or more
jumpers to set which interrupt it's using, and that's what enables the
sharing from the hardware-side view.
If I get some time tomorrow, I'll set up 2.6.20.1 and see what the
current options are doing.
If you can't get your board working, we have similar boards that do.
..Stu
--
We make multiport serial products.
http://www.connecttech.com/
(800) 426-8979
Stuart MacDonald wrote:
>> I use the options below:
>>
>> CONFIG_SERIAL_8250=y
>> CONFIG_SERIAL_8250_CONSOLE=y
>> CONFIG_SERIAL_8250_PCI=y
>> CONFIG_SERIAL_8250_NR_UARTS=32
>>
>
> This makes the internal table be 32 ports big. The first four ports
> end up configured for legacy/standard com ports, the rest are
> unconfigured. You should be able to see them as unknowns with
> setserial.
>
>
I can see them as unknowns with setserial but cannot set any parameters
for them until a subsequent driver is loaded, like (fourport).
> All _FOURPORT does is specifically config ports 4-7 in the table to
> have specific address/irqs for the FourPort board. What you do with
> setserial is then change that config info to match your board.
>
> You shouldn't need to do this, and I quickly reviewed 2.6.20.1 and it
> looks like you don't.
>
But I DO HAVE TO to make any configuration changes without getting
(invalid parameter) errors from setserial.
>> Then I can only access ttyS0 through ttyS3 sith setserial.
>> Only after I add
>> CONFIG_SERIAL_8250_FOURPORT=y am I actually able to do
>> anything with the
>> additional ports. I would otherwise get the evil setserial: invalid
>> parameter error.
>>
>
> Very odd. You get this error when doing "setserial /dev/ttySxx", no
> configuration? If so, that would imply that the table wasn't made big
> enough, and the unconfigured ports haven't been registered with the
> serial core.
>
>
I can read the ports as unknown/unconfigured. I just cannot modify them
until the fourport driver has been loaded.
> If you can't get your board working, we have similar boards that do.
>
>
your website address didn't work when I tried it...
See below for a (script) dump of that demonstrates the behavior I
describe. Additional ports are not configurable until a driver such as
fourport is loaded. This is in 2.6.20.1 and 2.6.17 (those versions I
have tested).
# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; done
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x03e8, IRQ: 4
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS5, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS6, UART: unknown, Port: 0x0000, IRQ: 0
/dev/ttyS7, UART: unknown, Port: 0x0000, IRQ: 0
# cat /etc/rc.local
#! /bin/sh
SS=/bin/setserial
IRQ="irq 12"
AC="autoconfig ^fourport"
`$SS /dev/ttyS4 port 0x120 $IRQ $AC`
`$SS /dev/ttyS5 port 0x128 $IRQ $AC`
`$SS /dev/ttyS6 port 0x130 $IRQ $AC`
`$SS /dev/ttyS7 port 0x138 $IRQ $AC`
# sh /etc/rc.local
Cannot set serial info: Invalid argument
Cannot set serial info: Invalid argument
Cannot set serial info: Invalid argument
Cannot set serial info: Invalid argument
# modprobe 8250_fourport
# for i in 0 1 2 3 4 5 6 7; do setserial /dev/ttyS$i; done
/dev/ttyS0, UART: 16550A, Port: 0x03f8, IRQ: 4
/dev/ttyS1, UART: 16550A, Port: 0x02f8, IRQ: 3
/dev/ttyS2, UART: unknown, Port: 0x02b8, IRQ: 5, Flags: Fourport
/dev/ttyS3, UART: unknown, Port: 0x02e8, IRQ: 3
/dev/ttyS4, UART: 16850, Port: 0x0120, IRQ: 12
/dev/ttyS5, UART: 16850, Port: 0x0128, IRQ: 12
/dev/ttyS6, UART: 16850, Port: 0x0130, IRQ: 12
/dev/ttyS7, UART: 16850, Port: 0x0138, IRQ: 12
# grep 8250 .config
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_NR_UARTS=8
CONFIG_SERIAL_8250_RUNTIME_UARTS=8
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_FOURPORT=m
# CONFIG_SERIAL_8250_ACCENT is not set
# CONFIG_SERIAL_8250_BOCA is not set
# CONFIG_SERIAL_8250_EXAR_ST16C554 is not set
# CONFIG_SERIAL_8250_HUB6 is not set
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
# CONFIG_SERIAL_8250_RSA is not set
# Non-8250 serial port support
On Mon, Feb 26, 2007 at 12:02:57PM -0500, Rob Prowel wrote:
> See below for a (script) dump of that demonstrates the behavior I
> describe. Additional ports are not configurable until a driver such as
> fourport is loaded. This is in 2.6.20.1 and 2.6.17 (those versions I
> have tested).
Check what /proc/tty/driver/serial contains, rather than relying on
setserial. setserial distributed by distros hasn't kept up with the
changes in the serial layer.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
Russell King wrote:
> On Mon, Feb 26, 2007 at 12:02:57PM -0500, Rob Prowel wrote:
>
>> See below for a (script) dump of that demonstrates the behavior I
>> describe. Additional ports are not configurable until a driver such as
>> fourport is loaded. This is in 2.6.20.1 and 2.6.17 (those versions I
>> have tested).
>>
>
> Check what /proc/tty/driver/serial contains, rather than relying on
> setserial. setserial distributed by distros hasn't kept up with the
> changes in the serial layer.
>
>
The setserial being used is the latest one from sourceforge. Its
relevant output matches the /proc entries. The problem still remains
though. Entries for ttyS4 and up seem to be read-only until I add a
supplemental driver such as fourport.
On Tue, Feb 27, 2007 at 09:24:32AM -0500, Rob Prowel wrote:
> Russell King wrote:
> >On Mon, Feb 26, 2007 at 12:02:57PM -0500, Rob Prowel wrote:
> >
> >>See below for a (script) dump of that demonstrates the behavior I
> >>describe. Additional ports are not configurable until a driver such as
> >>fourport is loaded. This is in 2.6.20.1 and 2.6.17 (those versions I
> >>have tested).
> >>
> >
> >Check what /proc/tty/driver/serial contains, rather than relying on
> >setserial. setserial distributed by distros hasn't kept up with the
> >changes in the serial layer.
> >
> >
> The setserial being used is the latest one from sourceforge. Its
> relevant output matches the /proc entries. The problem still remains
> though. Entries for ttyS4 and up seem to be read-only until I add a
> supplemental driver such as fourport.
After experimenting here, it turns out the reason is you're trying to
configure a port with a zero base baud. Unfortunately, it starts off
as zero.
However, when you try to change a port without specifying the base baud,
it is possible for the port to become "usable" and unless we enforce
the "must not have zero base baud" rule we have the possibility to oops
the kernel via a divide by zero.
So, the answer is to specify the base baud when using setserial to
configure new ports.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
From: Russell King [mailto:[email protected]]
> After experimenting here, it turns out the reason is you're trying to
> configure a port with a zero base baud. Unfortunately, it starts off
> as zero.
That explains why adding the fourport module fixed Rob's issue, as the
fourport code sets a uartclk value for its ports.
> However, when you try to change a port without specifying the
> base baud,
> it is possible for the port to become "usable" and unless we enforce
> the "must not have zero base baud" rule we have the
> possibility to oops
> the kernel via a divide by zero.
>
> So, the answer is to specify the base baud when using setserial to
> configure new ports.
Would it be more intuitive to give ports the default uartclk of
1843200 at init time? That would avoid this issue, but would make the
baud rates come out wrong on hardware with a non-standard clock, if a
base baud wasn't specified.
From: Rob Prowel [mailto:[email protected]]
> your website address didn't work when I tried it...
The website may have been down on the weekend for maintenance. Please
try again.
..Stu
--
We make multiport serial products.
http://www.connecttech.com/
(800) 426-8979
Stuart MacDonald wrote:
> Would it be more intuitive to give ports the default uartclk of
> 1843200 at init time? That would avoid this issue, but would make the
> baud rates come out wrong on hardware with a non-standard clock, if a
> base baud wasn't specified.
>
>
I prefer the option to specify the base baud rate in setserial from a
startup script. Having the additional ports at BAUD 0 (unusable) until
some explicit action is taken strikes me as a safer option, provided
this gets properly documented in the kernel Documentation directory and
in Linux HOWTO docs.
-Rob Prowel