Limesdr xtrx not found

[sergey]

I think it is correct that it is detected as a Xilinx audio controller. Is something aligned with the information in other threads here. And I don’t think it is that uncommon for smaller teams of developers to re-use all those PCIe or USB identifiers, as registering your own is not that easy or cheap. But, again, that is my understanding

I use CM4 IO Board, which, I think, is the official one. And for the adapter I got some generic adapter typically used for WiFi module. I think this one is exactly what I’ve got.

To show some outputs on the CM4 board, just in case of interest:

pi@cm4-dev ~ % lspci
00:00.0 PCI bridge: Broadcom Inc. and subsidiaries BCM2711 PCIe Bridge (rev 20)
01:00.0 Multimedia audio controller: Xilinx Corporation Device 7023 (rev 01)

pi@cm4-dev ~ % dmesg | grep litepcie
[    3.042825] litepcie: loading out-of-tree module taints kernel.
[    3.043437] litepcie 0000:01:00.0: [Probing device]
[    3.043562] litepcie 0000:01:00.0: enabling device (0000 -> 0002)
[    3.043614] litepcie 0000:01:00.0: BAR0 address=0x000000003ae617b1
[    3.066267] litepcie 0000:01:00.0: Version
[    3.066430] litepcie 0000:01:00.0: 1 MSI IRQs allocated.
[    3.083998] litepcie 0000:01:00.0: [device info] LimeXTRX FW:1 HW:0 PROTOCOL:1 S/N:0x0000000000000000
[    3.084021] litepcie 0000:01:00.0: DMA channels: 1, buffer size: 8192, buffers count: 256
[    3.084034] litepcie 0000:01:00.0: Creating /dev/LimeXTRX0_trx0
[    3.086968] litepcie 0000:01:00.0: Creating /dev/LimeXTRX0_control

pi@cm4-dev build (develop) % ./bin/limeDevice
Found 1 device(s) :
0: LimeXTRX0, media=PCIe, addr=/dev/LimeXTRX0_control, serial=0000000000000000


pi@cm4-dev build (develop) % ./bin/examples/basicRX
Devices found :
0: LimeXTRX0, media=PCIe, addr=/dev/LimeXTRX0_control, serial=0000000000000000

Configuring device ...
SetFrequencySXR, (1900.000 MHz)INT 142, FRAC 161312, DIV_LOCH 1, EN_DIV2_DIVPROG 1
SetFrequencySXT, (1899.000 MHz)INT 142, FRAC 80672, DIV_LOCH 1, EN_DIV2_DIVPROG 1
RxLPF modifying G_PGA_RBB 18 -> 12
RxLPF bypassed
TxLPF bypassed
RxLPF modifying G_PGA_RBB 18 -> 12
RxLPF bypassed
TxLPF bypassed
Sampling rate set(10.000 MHz): CGEN:80.000 MHz, Decim: 2^1, Interp: 2^1
SDR configured in 1574ms
Stream started ...
Samples received: 8159232, Peak amplitude: -51.71dBFS @ 1905.000
Samples received: 16089088, Peak amplitude: -83.70dBFS @ 1905.000
Samples received: 24281088, Peak amplitude: -80.23dBFS @ 1905.000
Samples received: 32440320, Peak amplitude: -82.32dBFS @ 1905.000
Samples received: 40599552, Peak amplitude: -81.12dBFS @ 1905.000
Samples received: 48775168, Peak amplitude: -84.83dBFS @ 1905.000
Samples received: 56950784, Peak amplitude: -83.16dBFS @ 1905.000
Samples received: 65077248, Peak amplitude: -83.93dBFS @ 1905.000
Samples received: 73220096, Peak amplitude: -81.57dBFS @ 1905.000

For the test I didn’t have any antenna plugged, which would explain the low signal level.
I didn’t have time yet to dig deeper than getting the core things running and seeing some command line prints which show things are OK. Next steps would definitely be seeing some FFT or waterfall in LineSuite, or some SDR software integration.

One thing I am missing (or failing to see) is a self-test app. The LimeSuite used to have it (LimeQuickTest, AFAIR) and it was handy have for quick self-tests. Not sure if it exists in the LimeSuiteNG.

P.S. I’ve got another PCIe adapter for the RPi5 coming, will see how that goes. Maybe it is some wiring on the specific adapter is not to spec or something. Will see.

P.P.S. I’ve also have CM4-IO-BASE-B from Waveshare. It is a bit inconvenient to plug all the adapters to it, but if there is an interest I can give it a try!

[masefi]

Cool, Thanks for the info. this helps for sure. I will get a CM4 board and give that a shot as well to see how it works. currently my dmesg | grep litepcie does not detect the limeXTRX which could be a problem with the adapter as you mentioned. I have ordered couple of other ones to see if that changes things. I am also waiting for the one that Andrew had mentioned in another thread which is supposed to be available for order in a week or so.
Will add updates here if anything changes

[sergey]

May I ask if you’re referring to this adapter discussion LimeSDR XTRX PCIe Adapter Board - #9 by andrewback ?

[masefi]

Yes, had an error in the name though, haha!

[sergey]

I’ve tested few other adapters woth RPi5.

So far the best results I had was with the M.2 HAT+ for Raspberry Pi 5. I did reboot a lot of time, and occasionally the LimeSDR would not be detected, but that was maybe a couple of times for like 30 reboots. Unfortunately, I could not get past the issue of litepcie_mmap I’ve mentioned above. It seems there is still some work needs to be done in the driver to fully support RPi5. I didn’t have time to give it a crack myself yet.

I’ve also tried GeeekPi N04 M.2 M-Key NVMe SSD Shield and GeeekPi P02 PCIe slot for Raspberry Pi 5 and they had exactly the same issue as the original tests with the GeeekPi PCIe Express to Mini PCIe HAT M02 for Raspberry Pi 5: it takes a lot of reboots for the LimeSDR to appear in the listing of lspci.

I really wonder whether it is a signal integrity issue in the adapter. For example, in the P02 PCIe slot there is this bent ribbon cable, with all the tracks running in parallel, without an attempt to length-match the traces. I’d try to get some high speed NVME or mini-PCIe device to compare stability, to see if the issue is limited to the XTRX.

Also, I am running on the gateware/firmware with which the XTRX was shipped from Crowdsupply. Not sure if there are updates to it which could improve stability with all those weird and wonderful adapters.

[sergey]

I had some time this evening, so poked DKMS a little bit. There is a bit of annoyance with integrating it with CMake, but it is not too bad. I’ve committed the current progress to GitHub - sergeyvfx/LimeSuiteNG at dkms_experiment Will let @ricardas to guide further how we can proceed with this.

[masefi]

Thanks for the updates and the work. I also just got the pineboards hat and will give it a shot soon to see what happens.

[ricardas]

Thanks for the efforts. I don’t want to add DKMS for the current version of the driver, as it is planned to be replaced with a refactored/renamed version, and DKMS would prevent the old version from disappearing, and as it is now only a single driver can be binded to the device at same time.

I’m upgrading the driver, and it will use DKMS.

@sergey

What worked for me to get past the litepcie 0000:01:00.0: arch assigned 64-bit MSI address 0xffffffe000 but device only supports 32 bits error is adding this to the config.txt:
dtoverlay=pciex1-compat-pi5,no-mip.From its documentation: Revert to the MSI target in the RC, instead of the MSI-MIP peripheral. Use if a) more than 8 interrupt vectors are required or b) the EP requires DMA and MSI addresses to be 32bit. The latter sounds related.

Thanks this is usefull information, I haven’t looked into RPi5 specifically yet. Trying to get 64bit DMA to work on the CM4. I’ve generated the gateware to use 64bit adressing, and set the driver to use 64bit dma masks, the system doesn’t throw any errors, but the transferred data is not as expected, the data is correct only if dtoverlay=pcie-32bit-dma is still used.

[sergey]

Thanks for the updates and explanation. Makes perfect sense, and is really great to hear it is all part of roadmap! Let me know if I can somehow help you!