Драйвер для 6 UART на PCI шине, как быстрее поднять? Опции

[Hoodwin]

Имеется плата PCI, где на ПЛИС сделаны 6 UART с драйверами RS-232. Написана PCI функция, которая управляет шестью UART 16550A, тоже самописными. Все это более менее проверялось раньше по отдельности, но теперь вот есть желание запустить порты из-под линукс. Особенность платы в том, что она позволяет делать резервирование RS-232, то есть кроме самого UART 16550 каждый порт имеет логику, которая управляет выключением микросхемы соответствующего драйвера RS-232. Эта логика имеет определенные настройки, которые определяют правила отключения драйвера в зависимости от состояния внешних сигналов.

Все UART представляют собой стандартные 8 регистров, которые расширены нулями до 32-битных слов и размещены в одном BAR по смежным адресам.

Собственно интересует наиболее простой путь подружить линукс со всеми 6 портами. Пока представляются следующие способы:
1) Писать с нуля PCI драйвер ос своими PID, VID.
2) Подсмотреть готовые конфигурации UART в исходниках драйверов линукс, и изменить PID, VID своего устройства в соответствии с подходящим профилем из поддержаных.
3) Написать свой минидрайвер, который будет находить устройство на шине PCI и регистрировать его UART'ы как serial8250 platfrom_device. После чего его и линукс сам подхватит.

Если делать свой драйвер (модуль), то можно в нем зарегистрировать атрибуты портов, чтобы можно было настраивать правила его резервирования. Не уверен, можно ли это сделать, если пытаться подстроиться под существующий драйвер для шины PCI.

[Hoodwin]

---
Да, вот попробовал написать в комстроку ядра 8250.nr_uarts=8. Даже сработало. Получился такой лог:

Код

ACPI: PCI Interrupt 0000:01:0b.0[A] -> GSI 23 (level, low) -> IRQ 22
0000:01:0b.0: Probing COMB6U PCI driver for 6 ports...
0000:01:0b.0: setup port df80, irq 22, type 0
0000:01:0b.0: ttyS4 at I/O 0xdf80 (irq = 22) is a 16550A
0000:01:0b.0: setup port df88, irq 22, type 0
0000:01:0b.0: ttyS5 at I/O 0xdf88 (irq = 22) is a 16550A
0000:01:0b.0: setup port df90, irq 22, type 0
0000:01:0b.0: ttyS6 at I/O 0xdf90 (irq = 22) is a 16550A
0000:01:0b.0: setup port df98, irq 22, type 0
0000:01:0b.0: ttyS7 at I/O 0xdf98 (irq = 22) is a 16550A
0000:01:0b.0: setup port dfa0, irq 22, type 0
0000:01:0b.0: ttyS2 at I/O 0xdfa0 (irq = 22) is a 16550A
0000:01:0b.0: setup port dfa8, irq 22, type 0
0000:01:0b.0: ttyS3 at I/O 0xdfa8 (irq = 22) is a 16550A

Видно, что все 6 UART-ов поднялись. Однако есть проблема с их порядком. Пока поднимались только первые два, то ttyS2 приходился на порт df80, а ttS3 - на порт df88. Теперь порядок другой, скажем прямо, не порядок. Вопрос: почему так? Регистрировал то я все это одним циклом тупо по порядку.


И еще вопрос. Существует ли в природе какой-нибудь тест для стандартного UART 16550 (для linux 2.6)? Интересен тест, который бы позволил по возможности наиболее полно протестировать UART. Можно даже с неким внешним loopback'ом для 9-контактного разъема D-Sub.

Есть один непонятный момент.
echo 123 > /dev/ttyS2
не выводит ничего, можно хоть 100 раз подряд такое выполнить.
echo 1234567890 > /dev/ttyS2
выводит все правильно.
cat Makefile > /dev/ttyS2
выводит все правильно и без потерь.
запуск bash </dev/ttyS2 >/dev/ttyS2 2>/dev/ttyS2 &
дает совершенно нормальную консоль, эхо идет на каждый введенный символ.

прямой вывод в обход драйвера - outb 0xdf80 0x21 - работает, как часы.
Однако
echo 123 > /dev/ttyS0 (порт на системной плате) все же работает.
В общем, хочется понять в чем тут дело.

[sasamy]

Видно, что все 6 UART-ов поднялись. Однако есть проблема с их порядком.

Можно указать через setserial какой угодно
http://linux.die.net/man/8/setserial

И еще вопрос. Существует ли в природе какой-нибудь тест для стандартного UART 16550 ... Можно даже с неким внешним loopback'ом для 9-контактного разъема D-Sub.

А что там тестировать ?
http://linux.die.net/man/1/minicom