Como usar a placa serial PCI Express no Debian Jessie, no ARMv71?

Question

Eu estou executando o Debian Jessie no meu Hummingboard, um ARM SBC baseado em iMX6.

root@torpedo:~# uname -a
Linux torpedo 4.11.4-cubox #2 SMP Tue Jun 13 14:51:52 CEST 2017 armv7l GNU/Linux

Ele tem um slot mini PCI Express, que eu pretendo usar para um cartão UART de 4 portas. Tenho um cartão da Diamond Systems que usa o chip EXAR XR17V354 UART .

Sendo um otimista, liguei o cartão e inicializei, esperando pelo melhor.

Parece que o cartão é reconhecido:

root@torpedo:~# lspci -v
00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00 [Normal deco             de])
        Flags: bus master, fast devsel, latency 0
        Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: 01100000-011fffff
        [virtual] Expansion ROM at 01200000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
        Capabilities: [70] Express Root Port (Slot-), MSI 00
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [140] Virtual Channel
        Kernel driver in use: pcieport

01:00.0 Serial controller: Exar Corp. Device 0354 (rev 03) (prog-if 02 [16550])
        Flags: fast devsel, IRQ 334
        Memory at 01100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [78] Power Management version 3
        Capabilities: [80] Express Endpoint, MSI 01
        Capabilities: [100] Virtual Channel

No entanto, o dmesg não contém menções aos ttys criados no momento da inicialização, além dos GPIOs associados ao Hummingboard, que sempre estiveram lá.

O fornecedor (Diamond) fornece um driver personalizado, que eu baixei e criei a partir do código-fonte. Quando eu carrego o .ko , dmesg diz:

[  640.564446] DSMPESER4MDriver: loading out-of-tree module taints kernel.
[  640.565123] The init fun get called
[  640.565199] pci 0000:01:00.0: enabling device (0140 -> 0142)
[  640.565359] DS-MPE-SER4M driver loaded

/ var / log / messages diz:

root@torpedo:~# tail -f /var/log/messages
...
Apr 17 15:48:50 torpedo kernel: DSMPESER4MDriver: loading out-of-tree module taints kernel.
Apr 17 15:48:50 torpedo kernel: The init fun get called
Apr 17 15:48:50 torpedo kernel: pci 0000:01:00.0: enabling device (0140 -> 0142)
Apr 17 15:48:50 torpedo kernel: DS-MPE-SER4M driver loaded

Algumas perguntas:

1. Como faço para corrigir "o carregamento do módulo de manchas do módulo fora da árvore"? (não é um problema técnico - veja o comentário)
2. Como eu uso mknod para criar os arquivos / dev / tty para este driver?
3. Como configuro o módulo para carregar no momento da inicialização?

Answer 1

A documentação do EXAR estava correta. Este fórum é suportado pelos kernels Linux modernos. Este problema para mim foi que meu kernel foi configurado para suportar apenas 4 portas seriais, total.

No Hummingboard, os UARTs on-chip estavam usando os primeiros 4 UARTs. Eu reconfigurei o kernel para 16 portas seriais, max. Reconstruiu meu kernel seguindo o método específico do debian . Reiniciado.

root@torpedo:~# uname -a
Linux torpedo 4.16.2whoi-armhf #1 SMP Wed Apr 18 16:56:21 GMT 2018 armv7l GNU/Linux

Novo kernel instalado e em execução ... verifique o barramento PCI:

root@torpedo:~# lspci -vv
...
01:00.0 Serial controller: Exar Corp. Device 0354 (rev 03) (prog-if 02 [16550])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 334
        Region 0: Memory at 01100000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 0000000000000000  Data: 0000
        Capabilities: [78] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold-)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [80] Express (v2) Endpoint, MSI 01
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
                LnkCap: Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [100 v1] Virtual Channel
                Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
                Arb:    Fixed- WRR32- WRR64- WRR128-
                Ctrl:   ArbSelect=Fixed
                Status: InProgress-
                VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
                        Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
                        Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
                        Status: NegoPending- InProgress-
        Kernel driver in use: exar_serial

Parece que eu não quebrei o barramento PCI.

O kernel encontrou os UARTs?

root@torpedo:~# dmesg|grep tty
[    0.000000] Kernel command line: root=/dev/mmcblk0p1 rootfstype=ext4 rootwait console=tty1 consoleblank=0 video=mxcfb0:dev=hdmi,1920x1080m60,if=RGB24,bpp=32 rd.dm=0 rd.luks=0 rd.lvm=0 raid=noautodetect pci=nomsi vt.global_cursor_default=0 loglevel=1
[    0.001375] console [tty1] enabled
[    1.220660] 0000:01:00.0: ttyS0 at MMIO 0x1100000 (irq = 334, base_baud = 7812500) is a XR17V35X
[    1.221093] 0000:01:00.0: ttyS1 at MMIO 0x1100400 (irq = 334, base_baud = 7812500) is a XR17V35X
[    1.221498] 0000:01:00.0: ttyS2 at MMIO 0x1100800 (irq = 334, base_baud = 7812500) is a XR17V35X
[    1.221896] 0000:01:00.0: ttyS3 at MMIO 0x1100c00 (irq = 334, base_baud = 7812500) is a XR17V35X
[    1.222587] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 26, base_baud = 5000000) is a IMX
[    1.223350] 21ec000.serial: ttymxc2 at MMIO 0x21ec000 (irq = 70, base_baud = 5000000) is a IMX
[    1.224122] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 71, base_baud = 5000000) is a IMX

Legal. Obras.