Hardware: Custom carrier with Zynq-7000 XC7Z100-2FFG900I + AD9361 on FMC-HPC0
Software stack: PetaLinux 2019.1, ADI Linux fork (adi-4.19.0), HDL hdl_2019_r1
PCORE_VERSION: 10.01.b
Sample rate: 61.44 MHz (LVDS DDR)
Symptom (Linux):
ad9361 spi0.0: ad9361_probe : AD936x Rev 2 successfully initialized
cf_axi_dds 79400000.cf-ad9361-dds-core-lpc: Analog Devices CF_AXI_DDS_DDS MASTER (10.01.b) ... probed DDS AD9361
SAMPL CLK: 61440000 tuning: RX
0: # # # # # # # # # # # # # # # #
1: # # # # # # # # # # # # # # # #
ad9361 spi0.0: ad9361_dig_tune_delay: Tuning RX FAILED!
cf_axi_adc: probe of 79400000.cf-ad9361-lpc failed with error -5
Confirmed:
- SAME hardware works with No-OS bare-metal (init succeeds, RF measurable)
- Linux: SPI to AD9361 works (chip ID/Rev 2 read OK, registers writable)
- Linux: AXI PCORE version readable (reports 10.01.b)
- Linux: cf_axi_dds binds successfully
- Linux: TX RSSI = 0 dB independent of DDS state (suggests TX LVDS also broken)
- All 256 (delay, clock) combinations produce data-mismatch '#' in tune matrix
(no single valid IDELAY value found)
Questions:
1. Could FSBL differences (SDK vs PetaLinux) cause this? Working No-OS uses
SDK-built FSBL; our Linux uses PetaLinux-built FSBL.
2. With ALL hash in the tune matrix (no good cells at any delay), what does
this typically indicate? Signal integrity or configuration?
3. Is there a sanctioned approach to skip the tune (digital-interface-tune-skip)
and apply known-good delays from the working No-OS init?
4. Are there DT properties for LVDS configuration that, if missing, would
manifest as full-hash matrix on a custom carrier vs FMCOMMS3 reference?
Happy to share dmesg, DTSI excerpt, or HDL constraints as needed.