I just got my new XTRX and have spend the last couple days attempting to get it set up, to no avail.
My original setup was a Rpi5 8gb, with a 52pi mini pcie hat. I have tried raspios and Ubuntu 24.04. I’m able to compile and successfully get limesuiteng compiled, but was unable to locate the XTRX with lspci. Upon that failing I tried to do a usb connection on the pi, and still can’t find it under lsusb. I have Status leds on the XTRX in both scenarios so I am getting power. I have the 52pi recommended pci configuration applied to my pi as well. I did see an earlier thread referencing an updated gateware that may help, but without establishing a link to my device I’m not sure how I’ll be able to apply that.
Hi,
Very similar topic has been discussed in Limesdr xtrx not found
There are quite few related aspects discussed there, mainly:
- To fully support RPi5, including 64bit DMA both driver and gateware needs to be updated Limesdr xtrx not found - #37 by ricardas
- Some hats do not seem to work reliably. I think this the Pineboards mPCIe hat gives the most reliable results: Limesdr xtrx not found - #35 by masefi I don’t have it myself, so can not confirm if it is 100% reliable, or if it sometimes requires reboots for XTRX to be detected by
lspci.
What I am not sure is whether and update of gatware is required for lspci to detect the XTRX if 32bit DMA is used. If you feel comfortable updating the gateware, it probably will eliminate some variables for troubleshooting, and will make it simpler to configure the config.txt.
P.S. If you’ll be updating the gateware, then double-check everything: that firmware file looks correct, commands, etc. It’s easy t flash a wrong thing using limeFLASH , and after that you’d need JTAG to recover. It is not too complicated or expensive to setup JTAG, but without PCIe Adapter Board (LimeSDR XTRX PCIe Adapter Board - #17 by aardric) physically connecting JTAG programmer could be the most challenging part.
as long as the XTRX has a functioning gateware any version, lspci should always be able to show it. It doesn’t depend on DMA adressing bits capabilities, or LimeSuiteNG.
Thanks for confirming it.
Do you know if there is a way for us to troubleshoot why exactly sometimes on RPi5 and some adapters it might take few reboots before lspci “sees” the XTRX?
I’ve suspected some signal integrity in the adapters, but all the other PCIe devices i’ve tested (including NVMe drives, via NVMe->mPCIe adapters) worked reliably.
I don’t have RPi5 myself, so I can’t test it directly, but in any case that sounds like hardware level problem. I have looked over kernel logs produced by RPi5 when the device is detected, and when not. It doesn’t show any usefull information about what could be the problem.
RPi5 XTRX not found:
[ 0.387319] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.811650] brcm-pcie 1000110000.pcie: link down
RPi5 XTRX found:
[ 0.389754] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
[ 0.495717] brcm-pcie 1000110000.pcie: link up, 5.0 GT/s PCIe x1 (!SSC)
So this requires hardware debugging tools to figure out if it is timing/power/clocking/signal integrity problem or something else is happening. That is beyond my expertise.
The RPi CM4 seems to work reliably with XTRX, the only difference in the logs compared to RPi5 is the indication of PCIe SSC usage. I don’t know if that is relevant.
[ 1.353255] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
A little update, I have switched to the Pineboard hat and am having dramatically more success, I actually get results back from lspci. I’ve been really crunched for time so I haven’t had too much time to troubleshoot the 52pi issues, but I’m making progress with the new hardware. Now im having issues with litepcie, when I modprobe I get:
“FATAL : Module litepcie not found in directory /lib/modules/6.5.0-1008-raspi”
couple of days ago, there was an update to the pcie driver. now it’s name is “limepcie”, and the install procedure was made to remove the old “litepcie”, as the device can be binded to only one driver at a time. Also if DKMS is installed on the system, than it will be used by default to manage the new driver, it’s optional and can be disabled with cmake option ‘USE_DKMS=off’
hi there, I’m using the same set up as user @Jfleg : RPi5 8Gb Limesdr xtrx, ubuntu 24.04. Originally I tried to use the 52pi mpcie hat to no success so I’ve also switched to using the pineboards version. When I first connected everything it was recognised by lspci, subsequent reboots have not (despite not changing anything). I then loaded it up again today (again changing nothing) and it has appeared in lspci again. Any suggestions for how i should try to trouble shoot?
HI,
Ricardas was mentioning earlier (XTRX not found - #5 by ricardas) it might be related to SSC (Spread Spectrum Clocking), or could be hardware related.
I didn’t find a way to possibly control whether SSC is enabled or not, but maybe you can have a better luck in that.
It could also be hardware related, and it’s something I wanted to check if I can see anything obvious by comparing actual signals between CM4 and RPi5. I didn’t get around doing such a comparison (and not sure if I’m equipped to do proper measurements as I’m not sure what are the exact frequencies on the data/clock lanes).
Was also thinking of checking if, maybe, other mpcie devices work reliably, and whether there is some difference in the AC coupling capacitors compared to XTRX.
There might also be some low-level logging we can enable in Linux to have more insights of what’s going on on the protocol level?
I’ll take a look at the SSC and some low level logging, I’ve captured the full dmesg logs for a boot which recognizes the Xilinx device and a boot which doesn’t.
When it recognises it I have the problem you solved in another thread (arch assigned 64-bit msi address 0xffffffe000 but device only supports 32 bits) but hopefully your solution will work for me too.
I’ll check if I have other mpcie devices lying around to test
Hi, it’s not the SSC fault. And the ‘dmesg’ logs won’t show anything, the most it can sometimes show is that the pcie link training has failed.
We might have identified a timing issue of when the link training is being started, and working on verifying a fix.
Unfortunately it appears that some of the LimeSDR XTRX boards were assembled without R114 resistor fitted, which connects the PCIe PERST# signal. PERST is responsible for indicating when the host power and clocks have stabilized, and resetting the device. Soldering a 0 Ohm resistor (0201 package) or just shorting that resistor which is shown in the attached image, proved to fix the enumeration instability issue.
1 Like
That’s a great find! I can confirm with my unit and and adapter that used to give problems: with the solder bridge in place the device is detected on every reboot now.
Thanks everyone involved in the investigation!
2 Likes
Hello All,
first I want to thank ricardes being so active here from official side.
Then further a big thanks to sergey, as his posts (esp. in the other related thread [Limesdr xtrx not found - #38 by ricardas])
helped me understand my Problem at hand with getting the XTRX running on the RPi5 + Pineboard’s miniPCIe Hat.
Being busy with this for weeks now, I indeed have XTRXs here which all have the R114 not fitted,
and have great hopes on getting it finally running.
Before I warm up my soldering iron and skills I however would like to ask for some clarifications,
as the issues (this and other thread) are a bit convoluted in my perception by now.
Could you please comment on my understanding of the current steps to perform to get the XTRX running on an RPi5.
A/ Hardware:
1/ Solder 0R for in place for missing R114 (for v 1.2, for v 1.1 it is R112). I.e. short the R114 0201 pins.
- That is necessary to communicate “when the host power and clocks have stabilized, and resetting the device”
- Does this apply for all Hosts, not only the RPi5, or at least those hosts which follow a similar PCIe power/clock protocol?
- I.e., there wont be any consequences if I short those pins now, and use it in the future hopefully with your eval board.
Please also note that R114 is still marked NF in the v 1.2 Schematic export and in the corresponding BOM.
B/ Software / LimeSuiteNG:
1/ Installation Guide & git branch
Your git head points to the develop branch. One will automatically clone the develop branch and nowadays find LimePCI instead of LitePCI.
This is not inline with the official documentations, and has been mentioned by ricardes already, however, from which branch do you want me to pull: develop or stable?
2/ LitePCIe vs. LimePCIe
Related to the above (A.1), I assume the correct way would be to build from source using your latest DMA powered implementation from the develop branch,
thus building LimePCIe kernel module, which will run on the RPi5.
LimePCIe implements DMA and the driver automatically utilizes DKMS if installed.
If DKMS is not installed (or not enabled explicitly during building LimeSuiteNG using cmake option “USE_DKMS=off”), DKMS wont be used in the driver.
Can you confirm the driver will run on the RPi5 without DKMS, as sergey had success by using DKMS.
I ask because the “loading out-of-tree module taints kernel” litepci dmesg I used to get.
2.1/ Kernel Headers
If one builds for/on the RPi5 dont use the “install_dependencies.sh” script, but install all dependencies yourself,
and make sure you get the right kernel headers:
sudo apt-get install "linux-headers-$(uname -r)"
Can you confirm this is needed for both LimePCIe and/or LitePCIe solutions?
Can you confirm cmake/make are configured to include those headers during build and not use potential generic ones available concurrently?
With all these steps, one should be able to see the device with limeDevice or lspci in an deterministic manner.
3/ Memory Mapping
There is a 32 vs 64 bit memory mapping issue of the XTRX Shipped Firmware in communications with the RPi5.
Thus, once one is able to see the XTRX (see above),
the new gateware (allowing to address the 16KB of the RPi5 using 64 bit) from ricardes (thanks!) available as binary here,
must be flashed on the XTRX using
limeFLASH combined_flash_programming.bin (Note the remarks from ricardes on this [Limesdr xtrx not found - #38 by ricardas]).
Otherwise TX/RX errors will occur during use of the XTRX due to wrong DMA addressing.
This update also makes the workaround of putting “dtoverlay=pcie-32bit-dma” (ricardes) or “dtoverlay=pciex1-compat-pi5,no-mip” (sergey) obsolete, correct?
Excuses for the long message but I needed to confirm this before losing more time with getting this to work.
Thanks in advance for your time looking into my clarifications and your help.
Once you come back to me, I will setup a clean OS and RPi5+Pineboard-miniPCIe-HAT+XTRX, and implement the steps.
Upon Success, I am volunteering to share a manual and lessons learned here.
Cheers
1 Like
The issue is that it should be connected, but when it is not this may not always be a problem. I’m guessing it’s a question of how quickly PCIe power and clock stabilises at host power-on vs. how quickly the PCIe peripheral gets power.
There shouldn’t be AFAIK.
Thanks. @Zack, can we get this updated, please.
Stable AFAIK.
Tagging @ricardas to confirm and for comment on the other software questions.
Hi, thank you.
Yes, it applies to all host systems.
I just updated the stable branch to the latest version. I suggest using ‘develop’ branch, we’re currently still in rapid development, so there is no “stable” v1 release yet. Currently the “stable” branch is placeholder for deployment automation.
Correct.
DKMS is not part of the driver itself. It’s a system that automatically rebuilds registered driver modules, when the system kernel version changes.
Yes, it can run without DKMS. Just notice, that if you update your kernel version, the driver will have to be manually rebuilt and installed again for the new kernel version.
The driver is not digitally signed, so this is just a security notice, that the module is not “trusted”. It does not have effect for driver functionality. Only systems that have enabled “Secure boot” would refuse to use unsigned driver.
Using DKMS to build the driver signs it.
Yes, linux kernel headers are required for building the pcie drivers.
Headers usage is dictated by the KBuild system used to build the driver/kernel module. It will use headers of the kernel version that is being used to build the module, if the headers are not installed or an exact version of the headers is not available, build will fail.
Yes. lspci should always display the device. limeDevice depends on limepcie driver, so if it is not loaded, or LimeSuiteNG was built without PCIe support, then it woudn’t show it.
Yes, XTRX shipped with gateware version <1.13 had only 32bit dma adressing capabilities, unfortunatelly RaspberryPi requires at least 35bits (to circumvent that, dtoverlays need to be used to allow 32bit support).
Updating XTRX to latest gateware will support 64bit addressing and will not require dtoverlays.
Thank @andrewback for your swift reply, and thanks @ricardas for the complete answer including the refresher on DKMS - really appreciated. I’ll give it a go these days, and come back to you all.
Here’s what I will do ,including my understanding and expectations:
1. Solder R114 pins short:
This will allow the host to communicate with the XTRX gateware in an deterministic manner (i.e., XTRX will then be shown as PCI device when calling “lspci” - most likely as the Xilinix Audio device initially).
NOTE: As per @ricardas & @andrewback replies this is required to have deterministic/reliable communications for any host - so if your board doesn’t have this 0R connection one most likely runs into problems.
2. Build LimeSuiteNG including LimePCI:
As limePCI has now been merged in the stable branch, the latest PCI driver -LimePCI- will be build if pulling from stable branch. Thus any notion or use of LitePCI driver is generally considered depreciated.
However, as suggested by @ricardas , I’ll build from the develop branch.reflecting the latest rapid developments.
If the correct kernel headers "linux-headers-$(uname -r)" are not available the build process will fail.
After this build, LimeSuiteNG should be able to do basic communications with the XTRX on the RPi5 - including the use of limeFLASH. However due to DMA addressing mismatch on the RPi5 (using 64 bit) and the stock gateware (version < 1.13, using 32 bit) TRX data communication (I reckon such as LMS_Recv/Sen_Stream) will run into issues.
3. Update gateware to enable 64 bit DMA Addressing:
Once we can see the device with LimeSuiteNG, I’ll use limeFLASH to flash the gateware update provided.
Thanks again, and I’ll come back if I succeeded in following this procedure.
Cheers
Dear All,
I come with good news, for the ones, who want to use the XTRX on the RPi5,
and share with you this post as sort of Manual and Lessons Learnt,
of how I was able to get my unit(s) to work.
Note that I use the pineboards (former pineberrypi) HatMPCIe (my version is 2024/V1), as miniPCIe interface. I got a multitude of other adapter combinations first to PCIx1 and then to mPCIe,
however I’ve been using the pineboards products from the beginning and would recommend all their products - esp. since this is a native RPi5 PCIe x1 FPC to miniPCIe adapter board.
So far even the PCI provided power through the FPC cable seems sufficient for first limeTRX applications.
General Info:
The RPi5, has next to the external FPC PCIe connection also its ethernet controller connected to the PCI domains.
If something is not right with the XTRXs/RPi5’s PCI connection you will only see this ethernet device and its bridge controller on the PCI system.
You can check this using
lspci -vvv -nn
and/or
dmesg | grep pci
Your XTRX should show up as something like this using lspci
0000:01:00.0 Multimedia audio controller [0401]: Xilinx Corporation Device [10ee:7023] (rev 01)
with corresponding dmesg entries under
pci 0000:01:00.0: [10ee:7023] type 00 class 0x040100
pci 0000:01:00.0: ...
Note that if the XTRX is not detected by the RPi5, the ethernet controller occupies this 0000:01 (domain:bus) identifier, and if both are active, the ethernet device/bridge is listed under the next domain (0001:01).
1. Hardware Issue (for LimeSDR XTRX v 1.2): Check R114
If lspci doesnt list your XTRX, check first if R114 (0 Ohm) is soldered in place.
If R114 is not fitted, you have to solder it in place (or short it) as per the official recommendation above.
This is required to connect the XTRXs’ PRST line to the foreseen miniPCIe Pin 22, as designed, and thus allow a deterministic PCI protocol behavior.
As its a 0201 package, this is not trivial to do for the inexperienced user, and requires some prior soldering experience and/or proper equipment.
If you succeeded you should then be able to “see” the XTRX as
0000:01:00.0 Multimedia audio controller [0401]: Xilinx Corporation Device [10ee:7023] (rev 01)
using lspci.
Then you can continue with the next step.
Alternatively: Also the LEDs (at least my gateware version 1.11, shipped in July '24) may indicate proper PCI communication, settling with continuous behavior after their initial boot sequence.
| R114 | LED 1 | LED 2 |
|---|---|---|
| NF | Green 1 Hz | off |
| 0 Ohm (short) | Green 1 Hz | Green 3 Hz |
However, this LED behavior may only be indicative, as being undocumented, and may also appear in other (failure) scenarios.
2. Build LimeSuiteNG
Note: For this exercise I used the latest clean OS from the Raspberry Pi Imager:
Debian GNU/Linux 12 (bookworm)
Linux 6.6.31+rpt-rpi-2712 Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux
2.1 Install dependencies for LimeSuitNG
I installed the dependencies extracting the information from the documentation and the install_dependencies.sh, adapting for the RPi OS and Kernel.
For clarity, I list them step by step below.
Install dependencies:
sudo apt-get install build-essential
sudo apt-get install cmake
sudo apt-get install libusb-1.0-0-dev
sudo apt-get install libwxgtk3.2-dev
sudo apt-get install libsoapysdr-dev
sudo apt-get install "linux-headers-$(uname -r)"
Note that for me, the kernel headers were already installed. Even though they are not inline with the one from the install_dependencies.sh script the build config will account for them correctly.
Following the discussion above, I opted to install and use DKMS as well, as it seemed more sophisticated to me.
(optional/recommended) Install DKMS:
sudo apt-get install dkms
2.2. Build LimeSuiteNG
As per the discussion above I pulled from the (default) develop branch, to account for the latest continuous developments.
Clone from git:
git clone https://github.com/myriadrf/LimeSuiteNG
or explicitly pulling from develop branch (in case head is moved to stable at one point)
git clone https://github.com/myriadrf/LimeSuiteNG --branch develop
From now on also the stable branch is updated to use LimePCI instead of the LitePCI driver.
Note that any documentation referring to LitePCI can be considered deprecated.
Configure the built with:
$ cmake -B build
Even though its output may report missing required kernel headers (I reckon because the make config scripts report only for information and still parse for the kernel versions inline with the install_dependencies.sh), we can continue. The build would fail in the next stage if those headers are really missing.
So, we can ignore this as long as it also outputs you something like this:
...
-- ######################################################
-- ## LimeSuiteNG enabled features
-- ######################################################
--
* HEADERS, The limesuiteng headers
* LIBRARY, The limesuiteng library
* USB_FTDI, USB support for FTDI
* USB_FX3, USB support for Cypress FX3
* LIMEPCIE, PCIe support
* LIMEPCIE_KERNEL_MODULE, Build Linux LimePCIe kernel module
* DKMS, DKMS support for lime PCIe kernel module
* EXAMPLES, LimeSuite library API examples
* CLI, LimeSuite command line interface tools
* GUI, GUI Application for LimeSuite
* AMARISOFT_PLUGIN, LimeSuite Amarisoft integration plugin
* DESKTOP, LimeSuiteNG freedesktop integration
* SOAPYSDR, SoapySDR bindings for LimeSuiteNG
* UDEV_RULES, Install Linux udev rules
…
-- Configuring done
-- Generating done
-- Build files have been written to: /<removed, where ever you pulled from git>/LimeSuiteNG/build
Then we can compile from the build directory.
cd build && make -j4
Which should output an extended version of:
[ 1%] Building Linux kernel module in dir: /<removed, where ever you pulled from git>/LimeSuiteNG/build/src/comms/PCIe/linux-kernel-module
...
[100%] Linking CXX executable ../bin/limeGUI
[100%] Built target limeGUI
Next we need to deploy the installation to the system
sudo make install
sudo ldconfig
and from here on you should be able to verify already that lspci recognizes the limepci kernel module:
0000:01:00.0 Multimedia audio controller [0401]: Xilinx Corporation Device [10ee:7023] (rev 01)
Subsystem: Xilinx Corporation Device [10ee:0007]
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-
Region 0: Memory at 1b00000000 (32-bit, non-prefetchable) [virtual] [size=1M]
Capabilities: <access denied>
Kernel modules: limepcie
The limeDevice command wont find the XTRX yet, and after reboot dmesg will give a hint whats the reason. See next step.
Update: The latest limesuiteNG/limepci will account for this and step 2.3 may not be necessary anymore (c.f., post below).
2.3 Force RPi5 to use 32 bit Addressing (temporarily):
Update: The latest limesuiteNG/limepci will account for this and step 2.3 may not be necessary anymore (c.f., post below).
As the shipped gateware still uses the 32 bit addressing scheme,
dmesg will indicate such issue:
…
[ 2.680344] limepcie 0000:01:00.0: try_set_dma_bitmask(32): dma_map_single error @ va:0000000090196e28 pa:107804000 bus:ffffffffffffffff
[ 2.680350] limepcie 0000:01:00.0: Failed to set DMA mask 32bit.
[ 2.680354] limepcie 0000:01:00.0: try_set_dma_bitmask(64): test buffer va:0000000090196e28 pa:107804000 bus:1107804000
[ 2.680359] limepcie 0000:01:00.0: using 64bit dma
[ 2.690287] limepcie 0000:01:00.0: arch assigned 64-bit MSI address 0xffffffe000 but device only supports 32 bits
[ 2.696613] limepcie 0000:01:00.0: Failed to enable MSI
[ 2.696623] limepcie 0000:01:00.0: Probe fail:
[ 2.696629] limepcie: probe of 0000:01:00.0 failed with error -1
...
Following @ricardas (see post below), this applies to all gateware versions < 1.13 being bound to this 32 bit addressing.
To resolve this, I recalled that @sergey was already early reporting progress in solving such error, with using the following dtoverlay:
dtoverlay=pciex1-compat-pi5,no-mip
So add the above dtoverlay line to your RPi’s /boot/firmware/config.txt,
reboot, and the device should be created this time:
...
[ 2.658822] limepcie 0000:01:00.0: try_set_dma_bitmask(32): dma_map_single error @ va:00000000d2114dee pa:1006a4000 bus:ffffffffffffffff
[ 2.658838] limepcie 0000:01:00.0: Failed to set DMA mask 32bit.
[ 2.658843] limepcie 0000:01:00.0: try_set_dma_bitmask(64): test buffer va:00000000d2114dee pa:1006a4000 bus:11006a4000
[ 2.658848] limepcie 0000:01:00.0: using 64bit dma
[ 2.663273] limepcie 0000:01:00.0: 1 MSI IRQs allocated.
[ 2.663295] limepcie 0000:01:00.0: DMA channels: 1
[ 2.664357] limepcie 0000:01:00.0: Creating /dev/limepcie0/trx0
[ 2.671991] limepcie 0000:01:00.0: Creating /dev/limepcie0/control0
Now also shown limeDevice --full
Found 1 device(s) :
0: LimeSDR XTRX, media=PCIe, addr=/dev/limepcie0, serial=000000008f6ac878
Current XTRX gateware does not support 64bit DMA addressing. RF data streaming might not work. Please update gateware.
Expansion name : UNSUPPORTED
Firmware version : 4
Gateware version : 1
Gateware revision : 11
Gateware target board : LimeSDR XTRX
Hardware version : 2
Protocol version : 1
Serial number : <removed>
SPI slave devices :
FPGA
LMS7002M
Memory devices :
FPGA/FLASH
GPS Lock:
GPS - Undefined
Glonass - Undefined
Galileo - Undefined
Beidou - Undefined
But note that there is still some addressing errors to be expected and in dmesg reported.
You’ll also come across a nice hint from @ricardas in the lime-tools that we still have to update the gateware to be able to switch (back) to and use RPi5’s 64 bit addressing, in order to achieve proper function.
However at this point we can make use of the most basic lime-tools.
Most importantly limeFLASH is usable and required in the next step.
So the dtoverlay is just a temporary workaround to enable the next step,
and we will have to remove the dtoverlay after switching to 64 bit addressing.
2.4 Upgrade Gateware and use RPi5’s 64 bit addressing
Depending on which gateware version you run, you have to flash either the combined or the user image following the instructions here and/or here.
Following instructions of @ricardas, I flashed this image [LimeSDR-XTRX_GW/bitstream/combined_flash_programming_file.bin at master · myriadrf/LimeSDR-XTRX_GW · GitHub] in its August 2024 commit.
However, please check what is applicable in the future when you read this as yours may be different - I do not take any responsibility on what you flash.
For my gateware (1.11) being <1.13, I needed to flash the combined image, using:
limeFLASH combined_flash_programming_file.bin
The flashing will take a short while, but shows you the live progress resulting in:
Current XTRX gateware does not support 64bit DMA addressing. RF data streaming might not work. Please update gateware.
File size : 3889296 bytes.
[100] bytes written 3889296/3889296
[100] bytes written 3889296/3889296
Programming completed.
I cannot stress enough that you should triple check what you downloaded and be 100% sure on what you are going to flash to which target.
It is your responsibility to verify your downloaded gateware is not corrupted and applicable for your target.
If you flash something wrong or corrupted you’ll need to fallback to a JTAG programming interface to recover your device functionality, just like I have to do now with one of my XTRXs, because I was rushing…but thats another story.
The new gateware will be used after powercycling the XTRX.
Important not to forget:
Remove or comment the dtoverlay line of step 2.3, as we want the RPi5 to use its native 64 bit addressing again, and reboot to effect.
After reboot, for me all works well so far.
limeDevice --full
Found 1 device(s) :
0: LimeSDR XTRX, media=PCIe, addr=/dev/limepcie0, serial=000000008f6ac878
Expansion name : UNSUPPORTED
Firmware version : 4
Gateware version : 1
Gateware revision : 17
Gateware target board : LimeSDR XTRX
Hardware version : 2
Protocol version : 1
Serial number : <removed>
SPI slave devices :
FPGA
LMS7002M
Memory devices :
FPGA/FLASH
FPGA/gold-image
FPGA/user-image
GPS Lock:
GPS - Undefined
Glonass - Undefined
Galileo - Undefined
Beidou - Undefined
Success - and dont rush!
A first feedback on the new LimeSuiteNG capabilities:
@ricardas , I appreciate the limeConfig/limeTRX combo of commands, which are a real added value compared to the old limeSuite - thanks!
Also the limeGUI surprises with little tabs and settings - but I reckon XTRX will still be able to be configured like used to in the signal processings heaven of old LimeSuite.
Lets see if I can utilize limeConfig/limeTRX or their source code to the extend I need, instead of adapting my existing code to the changed API.
1 Like
Thanks @tszn , great work.
only XTRX gateware versions <1.13 were limited to 32bit addressing.
I’ve updated limepcie driver, it will allow to control the device and update gateware, even if DMA is not working, now step 2.3 should not be necessary. limepcie: Allow to enumerate devices without DMA channels · myriadrf/LimeSuiteNG@79831e7 · GitHub
Perfect. Thanks for the feedback and action taken. I edited my post accordingly.