Wiki

This version (13 Feb 2024 14:45) was approved by George Mois.

ADRV9026/ADRV9029 Integrated Radio Frequency Transceiver Linux device driver

As demand for data increases globally, telecom infrastructure manufacturers are challenged by shorter time to market, increased antenna count, ever-growing cost pressure, and proliferation in variants of form factors, frequency bands, output power, and software. The ADRV9026, ADI's 4th generation wideband RF transceiver, delivers quad-channel integration with the lowest power, smallest size, common platform solution available to simplify design and reduce system power, size, weight, and costs for 3G/4G/5G applications, including multi-standard base stations, massive MIMO, and small cells.

Supported Devices

Note that the baseline device, ADRV9025, is used within this Wiki with functions/properties that are common to both devices.

Evaluation Boards

Overview

The ADRV9026 is a highly integrated, radio frequency (RF) agile transceiver offering four independently controlled transmitters, dedicated observation receiver inputs for monitoring each transmitter channel, four independently controlled receivers, integrated synthesizers, and digital signal processing functions providing a complete transceiver solution. The device provides the performance demanded by cellular infrastructure applications, such as small cell base station radios, macro 3G/4G/5G systems, and massive multiple in/multiple out (MIMO) base stations.

The ADRV9029 is a highly integrated, radio frequency (RF) agile transceiver offering four independently controlled transmitters, dedicated observation receiver inputs for monitoring each transmitter channel, four independently controlled receivers, integrated synthesizers, and digital signal processing functions providing a complete transceiver solution. The device provides the performance demanded by cellular infrastructure applications, such as small cell base station radios, macro 3G/4G/5G systems, and massive multiple in/multiple out (MIMO) base stations.

Applications

  • Macro base stations
  • Massive MIMO
  • Small cells

Markets and Technologies

  • Aerospace and Defense
  • Communications

Description

This is a Linux industrial I/O (IIO) subsystem driver, targeting RF Transceivers. The industrial I/O subsystem provides a unified framework for drivers for many different types of converters and sensors using a number of different physical interfaces (i2c, spi, etc). See IIO for more information.

Source Code

Status

Source Mainlined?
git No

Files

Interrelated Device Drivers

Receive AXI-ADC driver

Transmit AXI-DAC / DDS driver

AXI JESD204B HDL driver

AXI JESD204B GT (Gigabit Tranceiver) HDL driver (XILINX/ALTERA-INTEL)

Function File
driver drivers/iio/jesd204/axi_adxcvr.c

Device Driver Customization

Please follow the link here for detailed options and examples:

Processors

Stream Processor

A stream processor is a processor within the transceiver tasked with performing a series of configuration tasks based on some event. After a request from the user, the stream processor performs a series of predefined actions that are loaded into the stream processor during device initialization. This processor takes full advantage of the speed of the internal register buses for efficient execution of commands.

The stream processor can access and modify registers independently, avoiding the need for ARM interaction.

The stream processor executes streams, or series of tasks, for the following:

  • Tx1/Tx2/Tx3/Tx4 enable/disable
  • Rx1/Rx2/Rx3/Rx4 enable/disable
  • ORx1/ORx2/ORx3/ORx4 enable/disable

The transceiver flexibility is maintained by implementing the stream processors with similar flexibility. The stream processor image changes with configuration, similar to how the initialization structures change with the selected profiles. For example, the stream that enables the receivers differs depending on the JESD204B and JESD204C interface configuration. For this reason, it is necessary to save a stream image for each device configuration. When the user saves the configuration files (.c) using the GUI, a stream binary image is generated automatically. Use this stream file when initializing the transceiver with the profile in question.

The following are examples of how the stream files can differ:

  • The framer choices for observation receiver and receiver
  • For link sharing purposes
  • If floating point formatting is being used on receiver and observation receiver paths, the stream image can change

Eleven separate stream processors exist in the transceiver, which are each responsible for the execution of some dedicated functionality within the device. These stream processors can be divided into two broad categories, slice stream processors and the core stream processor.

The stream binary stream_image_XYZ.bin must be stored in the /lib/firmware folder, or compiled into the kernel using the CONFIG_FIRMWARE_IN_KERNEL, CONFIG_EXTRA_FIRMWARE config options. Multiple stream binaries can be added. However a unique name must be given. The stream binary loaded during driver probe can be specified using following device tree property:

stream-firmware-name = “stream_image_6E3E00EFB74FE7D465FA88A171B81B8F.bin”;

In case no stream is specified or loaded, the driver will continue to use the standard stream_image_6E3E00EFB74FE7D465FA88A171B81B8F.bin file.

ARM Processor

The transceiver is equipped with a built in ARM M4 processor. The firmware for this ARM processor is loaded during the initialization process. The firmware memory size is 224 kB, and the ARM has access to another 160 kB of data memory to utilize. The ARM is tasked with configuring the transceiver for the selected use case, performing initial calibrations of the signal paths, and maintaining device performance over time through tracking calibrations.

When the arm core is powered up, the ARM moves into its power-up/reset state. The ARM firmware image is loaded at this point. When the ARM image has been loaded, the ARM is enabled and begins its boot sequence. After the arm has been booted, it enters its ready/idle state. In this state, it can receive configuration settings or commands (instructions), such as performing the initial calibrations or enabling tracking calibrations.

DFE Processor

There is a dual core embedded ARM processor in which the DPD and CLGC algorithms reside. One of the dual core ARM processors is a control processor (ARM-C), which is the master, and the second core is a dedicated ARM core for DPD processing (ARM-D).

The firmware files for these processors must be stored in the /lib/firmware folder, or compiled into the kernel using the CONFIG_FIRMWARE_IN_KERNEL, CONFIG_EXTRA_FIRMWARE config options. The fimware loaded during driver probe are specified using following device tree property:

arm-firmware-name = “ADRV9025_FW.bin;ADRV9025_DPDCORE_FW.bin”;

Function File
ARM processor firmware firmware/ADRV9025_DPDCORE_FW.bin
DFE processor firmware firmware/ADRV9025_FW.bin

Gain Tables

The Gain tables for the RX and TX paths must also be loaded during boot/setup phase. They are also loaded using the firmware framework.

Function File
RX Gain Correction table firmware/ADRV9025_RxGainTable.csv
TX Attenuation table firmware/ADRV9025_TxAttenTable.csv

Enabling Linux driver support

Configure kernel with “make menuconfig” (alternatively use “make xconfig” or “make qconfig”).

The ADRV9025 driver depends on CONFIG_SPI

Adding Linux driver support

Configure kernel with “make menuconfig” (alternatively use “make xconfig” or “make qconfig”)

Linux Kernel Configuration
	Device Drivers  --->
	<*>     Industrial I/O support --->
	    --- Industrial I/O support
	    -*-   Enable ring buffer support within IIO
	    -*-     Industrial I/O lock free software ring
	    -*-   Enable triggered sampling support

	          *** Analog to digital converters ***
	    [--snip--]

		-*- Analog Devices High-Speed AXI ADC driver core
		< > Analog Devices AD9361, AD9364 RF Agile Transceiver driver
		< > Analog Devices AD9371 RF Transceiver driver
		< > Analog Devices ADRV9009/ADRV9008 RF Transceiver driver
		<*> Analog Devices ADRV9025/ADRV9026/ADRV9029 RF Transceiver driver
		< > Analog Devices AD6676 Wideband IF Receiver driver
		< > Analog Devices AD9467, AD9680, etc. high speed ADCs
		< > Analog Devices Motor Control (AD-FMCMOTCON) drivers

	    [--snip--]
	    

	Frequency Synthesizers DDS/PLL  --->
    		Direct Digital Synthesis  --->
	 		<*> Analog Devices CoreFPGA AXI DDS driver
		Clock Generator/Distribution  --->	
			< > Analog Devices AD9508 Clock Fanout Buffer                 
			< > Analog Devices AD9523 Low Jitter Clock Generator          
			<*> Analog Devices AD9528 Low Jitter Clock Generator          
			< > Analog Devices AD9548 Network Clock Generator/Synchronizer
			< > Analog Devices AD9517 12-Output Clock Generator  	

	<*>   JESD204 High-Speed Serial Interface Support  --->
		--- JESD204 High-Speed Serial Interface Support  
		< >   Altera Arria10 JESD204 PHY Support         
		<*>   Analog Devices AXI ADXCVR PHY Support      
		< >   Generic AXI JESD204B configuration driver  
		<*>   Analog Devices AXI JESD204B TX Support     
		<*>   Analog Devices AXI JESD204B RX Support  
			
	

Driver testing / API

Each and every IIO device, typically a hardware chip, has a device folder under /sys/bus/iio/devices/iio:deviceX. Where X is the IIO index of the device. Under every of these directory folders reside a set of files, depending on the characteristics and features of the hardware device in question. These files are consistently generalized and documented in the IIO ABI documentation. In order to determine which IIO deviceX corresponds to which hardware device, the user can read the name file /sys/bus/iio/devices/iio:deviceX/name. In case the sequence in which the iio device drivers are loaded/registered is constant, the numbering is constant and may be known in advance.

02 Mar 2011 15:16

TIP: An example program which uses the interface can be found here:


General attribute naming convention:

IIO sysfs attribute naming prefix Target
Transceiver
in_voltage0_[…] RX1
in_voltage1_[…] RX2
in_voltage2_[…] RX3
in_voltage3_[…] RX4
in_voltage4_[…] Observation RX1
in_voltage5_[…] Observation RX2
out_altvoltage0_[…] TRX LO1
out_altvoltage1_[…] TRX LO2
out_altvoltage2_[…] TRX AUX LO
out_voltage0_[…] TX1
out_voltage1_[…] TX2
out_voltage2_[…] TX3
out_voltage3_[…] TX4

This specifies any shell prompt running on the target

root@analog:~# cd /sys/bus/iio/devices/
root@analog:/sys/bus/iio/devices# ls
iio:device0  iio:device2  iio:device4
iio:device1  iio:device3  iio_sysfs_trigger

root@analog:/sys/bus/iio/devices# cd iio:device2

root@analog:/sys/bus/iio/devices/iio:device2# ls -al
total 0
drwxr-xr-x 3 root root    0 Nov 22 11:04 .
drwxr-xr-x 6 root root    0 Nov 22 11:04 ..
-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate
-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_rx_qec_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_tx_lol_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_tx_lol_ext_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 calibrate_tx_qec_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_temp0_input
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_gain_control_mode
-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_gain_control_mode_available
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_hd2_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage0_rssi
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_gain_control_mode
-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_gain_control_mode_available
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_hd2_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage1_rssi
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_gain_control_mode
-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_gain_control_mode_available
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_hd2_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage2_rssi
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_gain_control_mode
-r--r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_gain_control_mode_available
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_hd2_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage3_rssi
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage4_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage5_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 in_voltage_sampling_frequency
-rw-r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_ctrl
-r--r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_error
-r--r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_paused
--w------- 1 root root 4096 Nov 22 11:04 jesd204_fsm_resume
-r--r--r-- 1 root root 4096 Nov 22 11:04 jesd204_fsm_state
-r--r--r-- 1 root root 4096 Nov 22 11:04 name
lrwxrwxrwx 1 root root    0 Nov 22 11:04 of_node -> ../../../../../../../../firmware/devicetree/base/axi/spi@ff040000/adrv9025-phy@0
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage0_LO1_frequency
-r--r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage0_LO1_label
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage1_LO2_frequency
-r--r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage1_LO2_label
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage2_AUX_LO_frequency
-r--r--r-- 1 root root 4096 Nov 22 11:04 out_altvoltage2_AUX_LO_label
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_lo_leakage_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage0_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_lo_leakage_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage1_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_lo_leakage_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage2_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_lo_leakage_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage3_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 11:04 out_voltage_sampling_frequency
drwxr-xr-x 2 root root    0 Nov 22 11:04 power
lrwxrwxrwx 1 root root    0 Nov 22 11:04 subsystem -> ../../../../../../../../bus/iio
-rw-r--r-- 1 root root 4096 Nov 22 11:04 uevent
-r--r--r-- 1 root root 4096 Nov 22 11:04 waiting_for_supplier
root@analog:/sys/bus/iio/devices/iio:device2# 

Show device name

This specifies any shell prompt running on the target

root@analog:/sys/bus/iio/devices/iio:device2# cat name
adrv9025-phy

Show device temperature

This specifies any shell prompt running on the target

root@analog:/sys/bus/iio/devices/iio:device2# cat in_temp0_input
66000

Channel Enable/Powerdown Controls

For use cases where pin control mode is not used or required, these attributes can be used to enable/disable the Rx/Tx signal paths while in the ENSM radio_on state.

  • in_voltage0_en
  • in_voltage1_en
  • in_voltage2_en
  • in_voltage3_en
  • out_voltage0_en
  • out_voltage1_en
  • out_voltage2_en
  • out_voltage3_en

This specifies any shell prompt running on the target

root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage0_en 
1
root@analog:/sys/bus/iio/devices/iio:device2# echo 0 > in_voltage0_en
root@analog:/sys/bus/iio/devices/iio:device2# cat in_voltage0_en 
0

Local Oscillator Control (LO)

The device contains two RF PLLs. Each RF PLL uses the PLL block common to all synthesizers in the device and employ a 4 core VCO block which provides a 6dB phase noise improvement over the single core VCO. The tuneable range of the RF LO is 30-6000 MHz.It is possible to set the LO frequency independently for each port.

Attribute Port
out_altvoltage0_RX1_LO_frequency RX1
out_altvoltage1_RX2_LO_frequency RX2
out_altvoltage2_TX1_LO_frequency TX1
out_altvoltage3_TX2_LO_frequency TX2

This specifies any shell prompt running on the target

cat out_altvoltage2_AUX_LO_frequency 
3605000000
root@analog:/sys/bus/iio/devices/iio:device2# echo 3600000000 > out_altvoltage2_AUX_LO_frequency 
root@analog:/sys/bus/iio/devices/iio:device2# cat out_altvoltage2_AUX_LO_frequency 
3600000000

Some care is needed for correctly handle carrier configuration. Note that the driver exposes 4 controls giving the idea that we can, independently, control all 4 ports. That is not true because, as stated above, the device only has 2 PLLs. Hence, applications have to be careful. For an example on how this can be handled and for more details, look at this commit on the IIO Oscilloscope plugin.

Signal Path Configuration

TX Signal Path

The ADRV9026 transmitter section consists of four identical and independently controlled channels that provide all the digital processing, mixed-signal, and RF blocks necessary to implement a direct conversion system while sharing a common frequency synthesizer. The digital data from the SERDES lanes pass through a digital processing block that includes a series of programmable half-band filters, interpolation stages, and FIR filters, including a programmable FIR filter with variable interpolation rates and up to 80 taps. The output of this digital chain is connected to the digital-to-analog converter (DAC). The DAC sample rate is adjustable up to 2.5 GHz. The in-phase (I) and quadrature (Q) channels are identical in each transmitter signal chain.

After conversion to baseband analog signals, the I and Q signals are filtered to remove sampling artifacts and fed to the upconversion mixers. Each transmit chain provides a wide attenuation adjustment range with fine granularity to help designers optimize signal-to-noise ratio (SNR).

Properties

The following settings are available for each TX channel:

This specifies any shell prompt running on the target

root@analog:/sys/bus/iio/devices/iio:device2# ls -la | grep out_voltage0
-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_en
-rw-r--r-- 1 root root 4096 Nov 22 15:25 out_voltage0_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_lo_leakage_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 12:17 out_voltage0_rf_bandwidth

Primary Signal Bandwidth

To query TX Primary Signal Bandwidth:

This specifies any shell prompt running on the target

root@analog:/sys/bus/iio/devices/iio:device2# cat out_voltage0_rf_bandwidth 
450000000

Hardware Gain

To query and modify TX Hardware Gain:

This specifies any shell prompt running on the target

root@analog:/sys/bus/iio/devices/iio:device2# cat out_voltage0_hardwaregain 
-10.000000 dB
root@analog:/sys/bus/iio/devices/iio:device2# echo -12 > out_voltage0_hardwaregain
root@analog:/sys/bus/iio/devices/iio:device2# cat out_voltage0_hardwaregain 
-12.000000 dB

RX Signal Path

The ADRV9026 provides four independent receiver channels. Each channel contains all the blocks necessary to receive RF signals and convert these signals to digital data usable by a baseband processor. Each receiver can be configured as a direct conversion system that supports up to a bandwidth of 200 MHz. Each channel contains a programmable attenuator stage, followed by matched I and Q mixers that downconvert received signals to baseband for digitization.

Two gain control options are available, as follows:

  • Users can implement their own gain control algorithms using their baseband processor to manage manual gain control mode
  • Users can use the on-chip automatic gain control (AGC) system.

Performance is optimized by mapping each gain control setting to specific attenuation levels at each adjustable gain block in the receive signal path. Additionally, each channel contains independent receive signal strength indication (RSSI) measurement capability, dc offset tracking, and all the circuitry necessary for self calibration.

The receivers include analog-to-digital converters (ADCs) and adjustable sample rates that produce data streams from the received signals. The signals can be conditioned further by a series of decimation filters and a programmable FIR filter with additional decimation settings. The sample rate of each digital filter block is adjustable by changing decimation factors to produce the desired output data rate. All receiver outputs are connected to the SERDES block, where the data is formatted and serialized for transmission to the baseband processor.

Properties

The following settings are available for each RX channel:

This specifies any shell prompt running on the target

ls -la | grep in_voltage1 
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_bb_dc_offset_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_en
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_gain_control_mode
-r--r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_gain_control_mode_available
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_hardwaregain
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_hd2_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_quadrature_tracking_en
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_rf_bandwidth
-rw-r--r-- 1 root root 4096 Nov 22 12:17 in_voltage1_rssi

Advanced Debug Facilities

The ADRV9025 driver supports advanced debug controls via the kernel debugfs. These controls are mostly to debug which settings are currently configured in the device. How these device files/controls can be used is described here.

Runtime Device Driver Customization

Through these controls, the user can run and configure BIST tests. In order to identify if the IIO device in question (adrv9025-phy) you first need to identify the IIO device number. Therefore read the name attribute of each IIO device

This specifies any shell prompt running on the target

root@analog:~# grep "" /sys/bus/iio/devices/iio\:device*/name
/sys/bus/iio/devices/iio:device0/name:xilinx-ams
/sys/bus/iio/devices/iio:device1/name:ad9528-1
/sys/bus/iio/devices/iio:device2/name:adrv9025-phy
/sys/bus/iio/devices/iio:device3/name:axi-adrv9025-rx-hpc
/sys/bus/iio/devices/iio:device4/name:axi-adrv9025-tx-hpc

Change directory to /sys/kernel/debug/iio/ iio:deviceX.

This specifies any shell prompt running on the target

root@analog:~# cd /sys/kernel/debug/iio/iio\:device2
root@analog:/sys/kernel/debug/iio/iio:device2# ls -la
total 0
drwxr-xr-x 2 root root 0 Jul 10  2019 .
drwxr-xr-x 6 root root 0 Jan  1  1970 ..
-rw-r--r-- 1 root root 0 Jul 10  2019 bist_framer_0_prbs
-rw-r--r-- 1 root root 0 Jul 10  2019 bist_framer_loopback
-rw-r--r-- 1 root root 0 Jul 10  2019 bist_tone
-rw-r--r-- 1 root root 0 Jul 10  2019 direct_reg_access
root@analog:/sys/kernel/debug/iio/iio:device2#

Build-In Self-Test (BIST)

Controlling these attribute files directly take effect and therefore don’t require the initialize sequence. Test functionality exposed here is only meant to route or inject test patterns/data than can be used to validate the Digital Interface or functionality of the device.

PRBS

Pseudorandom Binary Sequence (PRBS) to Framer 0.

SYNTAX:

bist_framer_0_prbs <Data Source>

Data Source
Value Function
0 ADC data source
1 Checkerboard data source
2 Toggle 0 to 1 data source
3 PRBS31 data source
4 PRBS23 data source
5 PRBS15 data source
6 PRBS9 data source
7 PRBS7 data source
8 Ramp data
14 16-bit programmed pattern repeat source
15 16-bit programmed pattern executed once source

Example: Inject ramp PRBS

This specifies any shell prompt running on the target

root@analog:/sys/kernel/debug/iio/iio:device2# echo 8 > bist_framer_0_prbs 

BIST Loopback

Allows to digitally loopback framer data into the deframer.

SYNTAX:

bist_framer_loopback <Mode>

Value Mode
0 Disable
1 Digital framer → Digital deframer

Example: Digital TX → Digital RX

This specifies any shell prompt running on the target

root@analog:/sys/kernel/debug/iio/iio:device2# echo 1 > bist_framer_loopback 

BIST Tone

User selectable tone (with frequency and gain selection), that can be injected into the TX path. All Tx channels are selected.

SYNTAX:

bist_tone <Enable> <Tone Frequency> <Tone Gain>

Enable
Value Function
0 Disable Tx NCO
1 Enable Tx NCO on both transmitters
Tone Frequency
Signed frequency in Hz of the desired Tx tone
Tone Gain (Optional)
Value Function
0 Nco gain -18 dB
1 Nco gain -12 dB
2 Nco gain -6 dB
3 Nco gain 0 dB

Example: Inject 0 dB tone at 3 MHz into TX (all channels enabled)

This specifies any shell prompt running on the target

root@analog:/sys/kernel/debug/iio/iio:device2# echo 1 3000 > bist_tone 

Low level register access via debugfs (direct_reg_access)

Some IIO drivers feature an optional debug facility, allowing users to read or write registers directly. Special care needs to be taken when using this feature, since you can modify registers on the back of the driver.

To simplify direct register access you may want to use the libiio iio_reg command line utility.

Accessing debugfs requires root privileges.

In order to identify if the IIO device in question feature this option you first need to identify the IIO device number.

Therefore read the name attribute of each IIO device

This specifies any shell prompt running on the target

root@analog:~# grep "" /sys/bus/iio/devices/iio\:device*/name
/sys/bus/iio/devices/iio:device0/name:ad7291
/sys/bus/iio/devices/iio:device1/name:ad9361-phy
/sys/bus/iio/devices/iio:device2/name:xadc
/sys/bus/iio/devices/iio:device3/name:adf4351-udc-rx-pmod
/sys/bus/iio/devices/iio:device4/name:adf4351-udc-tx-pmod
/sys/bus/iio/devices/iio:device5/name:cf-ad9361-dds-core-lpc
/sys/bus/iio/devices/iio:device6/name:cf-ad9361-lpc
root@analog:~# 

Change directory to /sys/kernel/debug/iio/ iio:deviceX and check if the direct_reg_access file exists.

This specifies any shell prompt running on the target

root@analog:~# cd /sys/kernel/debug/iio/iio\:device1
root@analog:/sys/kernel/debug/iio/iio:device1# ls direct_reg_access 
direct_reg_access

Reading

This specifies any shell prompt running on the target

root@analog:/sys/kernel/debug/iio/iio:device1# echo 0x7 > direct_reg_access                                                                                                                                 
root@analog:/sys/kernel/debug/iio/iio:device1# cat direct_reg_access 
0x40

Writing

Write ADDRESS VALUE

This specifies any shell prompt running on the target

root@analog:/sys/kernel/debug/iio/iio:device1# echo 0x7 0x50  > direct_reg_access                                                                                                                            
root@analog:/sys/kernel/debug/iio/iio:device1# cat direct_reg_access 
0x50

Accessing HDL CORE registers

Special ADI device driver convention for devices that have both:

  • a SPI/I2C control interface
  • and some sort of HDL Core with registers (AXI)

In this case when accessing the HDL Core Registers always set BIT31.

The register map for typical ADI HDL cores can be found here: Register Map

This specifies any shell prompt running on the target

root@analog:/sys/kernel/debug/iio/iio:device6# echo 0x80000000 > direct_reg_access                                                                                                                           
root@analog:/sys/kernel/debug/iio/iio:device6# cat direct_reg_access 
0x80062

02 Mar 2011 15:16
resources/tools-software/linux-drivers/iio-transceiver/adrv9025.txt · Last modified: 13 Feb 2024 14:45 by George Mois