phupasornsart-del
**[Bug / Support] PetaLinux 2023.2 Migration — PL→PS DMA Interrupt (GIC SPI 63) Never Reaches CPU on ANTSDR E310 Rev.C** --- ## Hardware - Board: ANTSDR E310 Rev.C - SoC: Zynq Z7020 (ARM Cortex-A9) - RF chip: AD9363 (CMOS full-port, 1R1T mode) - Bitstream: from `antsdr-fw-patch/plutosdr-fw/hdl/projects/ant/` (MODE_1R1T, ADC_INIT_DELAY=21) --- ## Background I am migrating the ANTSDR E310 from the official Buildroot firmware to PetaLinux 2023.2 with the `meta-adi-xilinx` layer, in order to use IIO Oscilloscope for RF signal capture. **Buildroot baseline (working ✅):** AD9361 initializes, IIO Oscilloscope receives RF signal normally. Kernel: `6.1.0-23073-gf3da30df6004-dirty`. **PetaLinux target:** Kernel `6.1.70adi-v2023.2`, boot succeeds, SSH/iiod working — but `iio_readdev` always times out. --- ## Problem 1: dig_tune FAILED → RESOLVED ✅ On first PetaLinux boot, the kernel reported `ad9361_dig_tune_delay: Tuning RX FAILED!`. Root cause: In ADI `2023_R2` kernel, `check_pn()` never sees `ADI_STATUS` set during the delay sweep, so all 256 combinations return as invalid. **Fix applied:** Set `adi,digital-interface-tune-skip-mode = <2>` and hard-coded the delay values read directly from the working Buildroot board: ``` adi,rx-data-clock-delay = <0>; adi,rx-data-delay = <8>; /* from reg 0x006 = 0x08 */ adi,tx-fb-clock-delay = <10>; /* from reg 0x007 = 0xa0 */ adi,tx-data-delay = <0>; ``` Result: AD9361 and cf_axi_adc probe successfully. ✅ --- ## Problem 2: DMA Interrupt Never Reaches CPU ❌ (UNRESOLVED) After resolving dig_tune, `iio_readdev` still fails: ``` $ iio_readdev -u local: -s 4096 -b 1024 cf-ad9361-lpc voltage0 voltage1 Unable to refill buffer: Connection timed out (110) ``` ### Investigation AXI ADC core registers look healthy: ``` cf-ad9361-lpc @ 0x79020000: RSTN (0x040) = 0x3 → released from reset ✅ STATUS (0x05C) = 0x5 → ADI_STATUS bit set ✅ CNTRL (0x044) = 0x4 → R1_MODE (1R1T CMOS) ✅ ``` RX DMAC (0x7c400000) registers after enabling IIO buffer: ``` CTRL (0x400) = 0x1 → DMAC enabled ✅ TRANSFER_DONE (0x428) = 0x1 → transfer COMPLETED ✅ IRQ_PENDING (0x084) = 0x3 → bits 0,1 pending ✅ IRQ_SOURCE (0x088) = 0x3 → interrupt asserted ✅ ``` DMA transfer completes at hardware level. The DMAC is asserting its interrupt. But: ``` /proc/interrupts: 31: 0 0 GIC-0 63 Level 7c400000.dma ← always 0, never increments GIC Distributor: ISENABLER1 (0xF8F01104) bit 31 = 1 → SPI 63 enabled at GIC ✅ ISPENDR1 (0xF8F01204) bit 31 = 0 → SPI 63 NOT pending ❌ ``` ### What I have verified | Item | Status | |---|---| | Bitstream MD5 (PetaLinux vs Buildroot) | Identical ✅ | | `dma-axi-dmac.c` source (both kernels) | Identical line-by-line ✅ | | SLCR INT_MASK (0xF8000620) | 0x0 — nothing masked ✅ | | GIC ISENABLER1 bit 31 (SPI 63) | 1 — enabled ✅ | | GIC ISPENDR1 bit 31 | 0 — NOT pending ❌ | | PS interrupts (UART, Ethernet, MMC) | All working normally ✅ | | DMAC TRANSFER_DONE | 1 — completes ✅ | | DMAC IRQ_SOURCE | 3 — asserted ✅ | | CPU IRQ count (/proc/interrupts) | 0 always ❌ | The interrupt signal does not cross from PL to PS, even though SLCR is not masking it and the GIC has SPI 63 enabled. --- ## Hypothesis: FSBL ps7_init Misconfigures IRQ_F2P Routing The only meaningful difference between the two environments is the **BOOT.BIN**: - **Buildroot BOOT.BIN**: FSBL generated from Vivado SDK (vendor-provided for ANTSDR E310) - **PetaLinux BOOT.BIN**: FSBL generated from PetaLinux project's XSA file My hypothesis is that the PetaLinux-generated `ps7_init.c` does not correctly enable or route the `IRQ_F2P` signals from PL to PS, causing GIC SPI 63 (IRQ_F2P[2]) to never receive the assertion from the AXI DMAC. My planned next step is to boot using Buildroot's BOOT.BIN while keeping the PetaLinux kernel and rootfs, to confirm whether the FSBL is the root cause. --- ## Questions 1. Is there a known issue with the PetaLinux XSA or `ps7_init` configuration for ANTSDR E310 Rev.C that could cause `IRQ_F2P` routing to fail? 2. Could you share the reference `ps7_init.c` or `ps7_init_gpl.c` that is used in the official Buildroot FSBL for this board? This would allow me to compare directly against the PetaLinux-generated version. 3. Are there any additional SLCR or GIC registers beyond `INT_MASK` that must be configured for `IRQ_F2P[x]` to work correctly on this board? 4. Is there an officially supported path for using ANTSDR E310 Rev.C with PetaLinux 2023.2 and IIO Oscilloscope that I might be missing? --- Thank you for your time. If you need additional register dumps, kernel logs, or DTS files, I am happy to provide them. If there are any follow-up questions or suggestions from your side, please feel free to reply in this issue thread — I will continue the discussion here.