XTRX not found

[ricardas]

Hi, thank you.

@tszn

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.

Yes, it applies to all host systems.

@tszn

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?

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.

@tszn

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.

Correct.

@tszn

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.

DKMS is not part of the driver itself. It’s a system that automatically rebuilds registered driver modules, when the system kernel version changes.

@tszn

Can you confirm the driver will run on the RPi5 without DKMS

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.

@tszn

“loading out-of-tree module taints kernel”

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.

@tszn

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?

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.

@tszn

With all these steps, one should be able to see the device with limeDevice or lspci in an deterministic manner.

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.

@tszn

3/ Memory Mapping
There is a 32 vs 64 bit memory mapping issue of the XTRX Shipped Firmware in communications with the RPi5.

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.