Limesdr xtrx not found

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 :slight_smile:

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!

1 Like

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 :slight_smile:

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

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

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.

1 Like

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.

1 Like

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.

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.

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.

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!

I was going to order this one, just noticed that it has fewer pins than the xtrx has 8 pins on the side, but the M.2 HAT+ for pi5 has 4 pins on that side! does it fit without loosing functionality?

LimeSDR XTRX is Mini PCIe and not M.2. The two are not the same.

1 Like

Yes, my response was to the comment and was wondering if it was an error or there was a way to connect the two!

Sorry, I should have clarified a bit more: I used an extra adapters to go from XTRX to the Hat. In this case it was XTRX → mPCIe-to-PCIe → PCIe-to-NVME → The M.2 Hat. To my surprise it worked more reliably than the mPCIe hat from GeeekPi.

I’ve also tried XTRX → mPCIe-to-NVME adapter from Ali → The M.2 Hat. And that lead to somewhat better results than the GeeekPi hat, but was more flackey than the mPCIe-to-PCIe → PCIe-to-NVME chain.

I’ve also tested NVME drives in a lot of hats, and had no issues with them. So somehow for me it is only XTRX which is not detected by RPi5 at reboot every now and then. Not sure why though. For now I’m using CM4 IO board for development, which seems to work just fine.

Also, keep in mind, while I did manage to get semi-reliable low-level connectivity between Rpi5 and XTRX using that adapter, I couldn’t get past the driver issue. For that we’d need Ricardas to do his magic :slight_smile:

With the Pineboards mPCIe hat the XTRX is detected more reliably and limeDevice returns a valid device. However running the basicRX example fails with the following error:

Devices found :
0: LimeXTRX0, media=PCIe, addr=/dev/LimeXTRX0_control, serial=000000008f59d892

terminate called after throwing an instance of 'std::runtime_error'
    what():  : failed to MMAP Rx DMA buffer

Any ideas on how to get around this?

That’s an interesting hat, I didn’t stumble upon it before. Thanks for sharing!

The error sounds very similar to the issue I’m getting with Rpi5.
From my understanding it is that 32 vas 64 bit issue mentioned above. Ricardas earlier mentioned he is working on it. Hopefully once that works on CM4 it also works on RPi5.

1 Like

The memory mapping error on Rpi5 was caused by unusual memory PAGE_SIZE, usually on linux it’s 4KB, but on RPi5 it’s 16KB, the driver didn’t account for that. The XTRX gateware was updated to support 64 bit DMA addressing and is now working on Rpi.
I just need to double check the gateware update procedure, as now gateware consists of two images. I’ll post the instructions tomorrow.


XTRX gateware can be updated with:
limeFLASH combined_flash_programming.bin
And then power cycle device.

This combined image needs to be used once for the initial transition to dual boot gateware.

New gateware consists of two parts “gold” and “user” images. In normal operation the “user” image is used, if it becomes corrupted or wrong gateware is flashed into the device, FPGA will fallback to load “gold” image, so that device could be recovered without needing JTAG.
Following gateware updates can be done using:
limeFLASH -t FPGA/user-image user_flash_programming_file.bin

That’s great! Upgrade worked without any issues. Did both combined image, and then verified the user image also works. Didn’t test butchering the user image yet to verify the gold image allows to recover. Might do it later though! :slight_smile:

Removed all the 32bit DMA overlays from CM4, worked entire evening and had zero issues.

Still have the issue with some of the RPi5 adapters for which the XTRX doesn’t show up in lspci. Still not sure what’s up with that, but something unrelated to the addressing. Once its detected the new driver and gatewere worked fine as well.

Thanks for the updates! Much appreciated!

1 Like

Awesome, thanks for the fix! I am now able to run the basicTX and basicRX examples without issue.