Wie verwende ich eine serielle PCI-Express-Karte unter Debian Jessie auf ARMv71?

694
Matt

Ich verwende Debian Jessie auf meinem Hummingboard, einem auf iMX6 basierenden ARM-SBC. 

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

Es verfügt über einen Mini-PCI-Express-Steckplatz, den ich für eine 4-Port-UART-Karte verwenden möchte. Ich habe eine Karte von Diamond Systems, die den EXAR XR17V354 UART-Chip verwendet .

Als Optimist steckte ich die Karte ein und bootete, und hoffte auf das Beste.

Sieht aus wie die Karte erkannt wird:

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

In dmesg werden jedoch keine während der Bootzeit erstellten ttys erwähnt, mit Ausnahme der GPIO-Typen, die mit dem Hummingboard verbunden sind und immer vorhanden waren.

Der Hersteller (Diamond) stellt einen benutzerdefinierten Treiber zur Verfügung, den ich heruntergeladen und aus dem Quellcode erstellt habe. Als ich den Laden .ko, dmesg sagt:

[ 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

Und / var / log / messages sagt:

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

Ein paar Fragen:

  1. Wie behebe ich das "Laden des Out-of-Tree-Modul-Taints-Kernels"? (kein technisches Problem - siehe Kommentar)
  2. Wie verwende ich mknod, um die / dev / tty- Dateien für diesen Treiber zu erstellen ?
  3. Wie konfiguriere ich das Modul so, dass es beim Booten geladen wird?
0
Wenn der Kernel beschädigt ist, bedeutet dies, dass er sich in einem Zustand befindet, der nicht von der Community unterstützt wird. Die meisten Kernel-Entwickler ignorieren Fehlerberichte, die fehlerhafte Kernel betreffen, und Community-Mitglieder bitten Sie möglicherweise, den Verfälschungszustand zu korrigieren, bevor Sie mit der Diagnose von Problemen im Zusammenhang mit dem Kernel fortfahren können. Außerdem können einige Debugging-Funktionen und API-Aufrufe deaktiviert werden, wenn der Kernel beschädigt ist. Matt vor 6 Jahren 0
Update: Die EXAR-Site hat einen besseren Treiber und doc. Ihr Dokument besagt, dass dieser Chipsatz im Kernel unterstützt wird. Nach der Untersuchung sieht es so aus, als würden moderne Kernel eine feste Anzahl von seriellen Geräten unterstützen: 4 standardmäßig. Erneue meinen Kernel mit einer höheren Nummer, um alle meine UARTs zu unterstützen. Matt vor 6 Jahren 0

1 Antwort auf die Frage

0
Matt

Die EXAR-Dokumentation war korrekt. Dieses Board wird von modernen Linux-Kerneln unterstützt. Dieses Problem bestand für mich darin, dass mein Kernel so konfiguriert wurde, dass er insgesamt nur 4 serielle Ports unterstützt.

Auf dem Hummingboard verbrauchen die On-Chip-UARTs die ersten 4 UARTs. Ich habe den Kernel für 16 serielle Ports, max. Erneue meinen Kernel nach der Debian-spezifischen Methode . Neustart

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

Neuer Kernel installiert und ausgeführt ... Überprüfen Sie den PCI-Bus:

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

Sieht aus, als hätte ich den PCI-Bus nicht gebrochen.

Hat der Kernel die UARTs gefunden?

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

Cool. Arbeitet.

Verwandte Probleme