Open wbreiler opened 3 years ago
Card works as expected with no hiccups or issues, no kernel recompile needed
Huh?! I wasn't expecting that seeing as the serial controller only lists 2 I/O regions that are both disabled, and this is going via a PCIe to PCI bridge. I've failed to get any PCI devices working via a bridge as they almost all use the (unsupported on ARM) I/O BAR. I don't quite see how the above dump tallies with the card having any resources to actually be accessed.
Could you provide the output from lspci -k
please?
I've added this board to the site; it's currently listed as 'Maybe' working—but I would also like to know if you're able to actually get data to flow through the card.
In terms of:
Card works as expected with no hiccups or issues, no kernel recompile needed
Does that mean you were able to communicate with another device via one of the serial ports? Or just that the card appears when you list it out?
Could you provide the output from lspci -k please?
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20) 01:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04) 02:00.0 Serial controller: Systembase Co Ltd Device 4d02 (rev b0) Subsystem: Systembase Co Ltd Device 4d02
Does that mean you were able to communicate with another device via one of the serial ports? Or just that the card appears when you list it out?
Right now, just that the card appears when I list it out. I have a couple serial devices coming in on Monday morning that I will test with.
Googled a bit, and found this and currently following along. Will update with changes
That lspci output doesn't appear to be with the -k
flag as it isn't listing a kernel driver for any of the devices.
eg on my Pi4 I get
pi@raspberrypi:~ $ lspci -k
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 10)
Kernel driver in use: pcieport
01:00.0 USB controller: VIA Technologies, Inc. VL805 USB 3.0 Host Controller (rev 01)
Subsystem: VIA Technologies, Inc. VL805 USB 3.0 Host Controller
Kernel driver in use: xhci_hcd
root@cm4:~# lspci -k
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
01:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 04)
02:00.0 Serial controller: Systembase Co Ltd Device 4d02 (rev b0)
Subsystem: Systembase Co Ltd Device 4d02
Googled a bit, and found this and currently following along. Will update with changes
Update: The driver requires a kernel header that does not exist for ARM64 (asm/segment.h
). Will see Monday if card will work without a driver... Fingers crossed!
OK thanks for confirming on the lspci output. I'm surprised that it's not listing pcieport for the base PCI bridge, and memory says that the ASM1083/1085 driver is standard too. That does sort of confirm that the serial controller isn't actually configured and doing anything.
Can you point me at this driver you're trying to compile? It doesn't appear that that file exists at all for ARM
$ find -name segment.h
./arch/sh/include/asm/segment.h
./arch/m68k/include/asm/segment.h
./arch/x86/um/asm/segment.h
./arch/x86/include/asm/segment.h
./arch/arc/include/asm/segment.h
./arch/h8300/include/asm/segment.h
./arch/csky/include/asm/segment.h
./fs/nilfs2/segment.h
./fs/f2fs/segment.h
Looking at the x86 version, it is giving me flashbacks to writing x86 assembler and having to worry about the hideous addressing mode you find there with CS (code segment) and DS (data segment) pointers. Drivers shouldn't normally be needing to worry about that level of architecture specific adaptation.
Sorry to say, but I still don't have much hope that this card will work from what I've seen so far.
Can you point me at this driver you're trying to compile? It doesn't appear that that file exists at all for ARM
https://www.sysbas.com/en/downloads/pcie-serial-card-series/
Amazon link
Product Image:
Dmesg:
lspci:
Card works as expected with no hiccups or issues, no kernel recompile needed