Author Topic: any *good* multi uart miniPCI card for a router?  (Read 105 times)

0 Members and 1 Guest are viewing this topic.

Online legacy

  • Super Contributor
  • ***
  • Posts: 4213
  • Country: ch
any *good* multi uart miniPCI card for a router?
« on: October 08, 2019, 01:15:51 pm »


I need 8 UART-ports able to run at {115200 .. 1M } bps. I am experimenting with some weird problems with a couple of miniPCI modules, each able to manage up to 4 ports.

One thing I do find irritating: this stuff does not respect the PCI spec concerning how to report resources to BAR, in fact the Linux kernel has to handle the card in the pic via "quirks"  :palm:

The miniPCI card in the pic comes with fixed addresses (not reprogrammable => this violate the "plug and play" mechanism), hence it needs quirks and tricks to avoid collisions.

This is not perfect, and kernel 4.9.* to kernel 4.11.* are *ALL* bugged.

Does anyone happen to know a *good* multi serial miniPCI module? which fully do respect the PCI spec?
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 5532
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: any *good* multi uart miniPCI card for a router?
« Reply #1 on: October 09, 2019, 01:51:08 am »
Find one to go from miniPCI to USB, then add some USB to serial converters.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4213
  • Country: ch
Re: any *good* multi uart miniPCI card for a router?
« Reply #2 on: October 09, 2019, 06:11:14 am »
Find one to go from miniPCI to USB, then add some USB to serial converters.

do you happen to know where can I find one? EHCI? NEC chip?  :D
 

Online legacy

  • Super Contributor
  • ***
  • Posts: 4213
  • Country: ch
Re: any *good* multi uart miniPCI card for a router?
« Reply #3 on: October 09, 2019, 06:19:12 am »
with an ugly ( too embarating, so I will never show a pic) hardware and software hack,  it seems you can  partially work-around the problem

Code: [Select]
PCI: Enabling device 0000:00:05.0 (0000 -> 0003)
0000:00:05.0: ttyS1 at I/O 0x18800800 (irq = 140, base_baud = 460800) is a 16C950/954
0000:00:05.0: ttyS2 at I/O 0x18800808 (irq = 140, base_baud = 460800) is a 16C950/954
0000:00:05.0: ttyS3 at I/O 0x18800810 (irq = 140, base_baud = 460800) is a 16C950/954
0000:00:05.0: ttyS4 at I/O 0x18800818 (irq = 140, base_baud = 460800) is a 16C950/954
PCI: Enabling device 0000:00:0a.0 (0000 -> 0003)
0000:00:0a.0: ttyS5 at I/O 0x18800840 (irq = 140, base_baud = 460800) is a 16C950/954
0000:00:0a.0: ttyS6 at I/O 0x18800848 (irq = 140, base_baud = 460800) is a 16C950/954
0000:00:0a.0: ttyS7 at I/O 0x18800850 (irq = 140, base_baud = 460800) is a 16C950/954
0000:00:0a.0: ttyS8 at I/O 0x18800858 (irq = 140, base_baud = 460800) is a 16C950/954

by forcing the two module to avoid address collisions, thank to a secondary SoC supporting chip, that only adds an offset of { 0x00, 0x40 } depending on how you set a GPIO pin. This is really ugly, but it works. Well, ... it works ... actually, it allows the two cards to avoid collision, but, I cannot solve the shared irq problem, hence this stuff comes with extremely ugly interrupt handler in kernel space  :palm:

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf