Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G274A hello expert We are investigating an unexpected dependency between QuadSPI and the PFE HIF data path on an S32G274A running QNX 7.1. If QuadSPI is not initialized, PFE0 and PFE2 complete PHY, EMAC, firmware, and HIF initialization successfully. The EMAC can receive valid frames, but the HIF DMA does not consume TX or RX descriptors, so packets are not transferred between PFE and DDR, and ARP/ping fails. After reducing the QuadSPI initialization sequence step by step, we found that a single write is sufficient to restore PFE communication: writing 0x020F000C to the QuadSPI Module Configuration Register, QuadSPI_MCR at offset 0x0000 from QuadSPI base address 0x40134000—that is, physical address 0x40134000. If this write is removed, PFE communication consistently fails. Flash identification, JEDEC transactions, the QNX F3S framework, /dev/fs0, and startup delay have all been excluded as necessary conditions. Our current interpretation is that the relevant effect may be clearing QuadSPI_MCR[MDIS] to 0, which enables the QuadSPI clocks. Could you please confirm whether clearing QuadSPI_MCR[MDIS] can activate any clock request, bridge, or interconnect state shared with the PFE HIF DMA-to-DDR/XBAR/NoC path on S32G274A? Is there any undocumented or indirect dependency between PFE HIF DDR access and the QuadSPI clock or interconnect state, or could this indicate a missing shared-clock/NoC initialization step during platform startup? Which MC_CGM, RDC, MC_ME, NoC, or PFE platform register should be configured to establish the required state independently, instead of having the PFE driver access the QuadSPI MCR? We are currently performing complementary tests to confirm whether clearing MDIS alone is both necessary and sufficient; at this stage, the confirmed trigger is the complete MCR write value 0x020F000C. Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,waitewang
Thank you for contacting us.
1. Are you using a customer board?
2.What is your PFE version?
BR
Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi Joey, Yes, we are using a custom board based on the S32G274A. PFE0 and PFE2 are connected through RGMII to KSZ9031 PHYs. The operating system is QNX 7.1. The PFE software versions are as follows: - NXP PFE QNX driver version: PFE-DRV_S32G_QNX_1.9.0 - PFE firmware version: PFE-FW_S32G_1.12.0 - PFE hardware version reported by the driver: 0x00050300 Please let me know if you need the complete startup log, clock configuration, schematic section, or register dump for comparison. Best regards, Waitewang Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi,
Thank you for your reply.
1.What is your method of S32G booting? Was there no initialization of QSPI in the early stage?
2.Try operating only the MDIS bit to see if it affects the results.
BR
Joey Re: Unexpected Dependency of PFE HIF DMA-to-DDR Communication on QuadSPI MCR Configuration on S32G27 Hi Joey, 1. We load the QNX IFS and DTB via TFTP in U-Boot and start QNX with bootm. QNX is not loaded from QSPI Flash. Before starting the PFE driver, QNX does not start devf-qspi-s32g or explicitly initialize the QuadSPI controller. 2. We tested the MDIS bit using read-modify-write operations on the QuadSPI Module Configuration Register (QuadSPI_MCR, base address 0x40134000, offset 0x0000). Test A — No QuadSPI MCR operation The QSPI driver was not started and QuadSPI_MCR was not written. PFE communication failed. Test B — Set only MDIS MCR before = 0x030F00CC MCR write = 0x030F40CC MCR after = 0x030F40CC MDIS = 1 PFE Communication successful Only MDIS, bit 14, was changed from 0 to 1. The QSPI Flash filesystem was not started, /dev/fs0 was not created, and no JEDEC access was performed. The test program exited normally after the register operation. Test C — Clear only MDIS The initial MDIS value was already 0, so the unchanged MCR value 0x030F00CC was written back. PFE communication failed. We also previously tested writing the complete value 0x020F000C to QuadSPI_MCR. PFE communication succeeded in that case. Could you please advise why setting only the QuadSPI MCR MDIS bit from 0 to 1 affects PFE0/PFE2 communication on S32G274A? Is there any required initialization sequence, known erratum, or documented dependency between QuadSPI MCR operations and the PFE HIF/DMA-to-DDR path? BR, Waitewang
記事全体を表示
