[Zephyr] Suggestion on removing nrf7002 dts binding file QSPI on-bus label

Dear Nordic,

Currently nrf7002 dts binding file for QSPI bus has an 'QSPI' label inside for [compatible, on-bus] scheme matching, This may cause problem on non-NRF host MCU, because 'QSPI' is not really a standard name as 'SPI' among different host MCU families, which in the end may result in the failure of the binding process. 

For example, on stm32 processor, QSPI is regarded as a special 'spi' bus controller, any device node (like nrf7002) on this QSPI bus is resolved into something like 'node_name@spi'. It is obvious that Zephyr device tree binding tool will fail to match the name, and all properties under the node are missed in generated device tree file.

It is suggested to remove the 'QSPI' label in dts binding file, because the [compatible, on-bus] matching scheme only put formal constrains and does mot mean anytihing during real runtime. On the other hands, as 'SPI' is a real 'standard' name, it is actually recommended to put a 'SPI' label in 7002's dts binding file for SPI bus.

Thank you for your attention to this issue.

/Roland

Parents
  • Thanks for the suggestion! I've forwarded this to the relevant team.

    Regards,

    Elfving

  • Thank you  .

    Expecting feedback from the team soon.

    /Roland

  • Hi Elfving,

    We set the nRF7002 with website's sample, but only can successfully works on SPI mode, 

    looking for the QPSI with DMA mode to reduce the CPU loading when adding others functions.

    But it seems not explicitly setting method currently.

    GitHub - chshzh/nrf7002ek-diff-hosts: Run Zephyr Wi-Fi samples using nRF7002EK with STM32/NXP chips as host.

    Many thanks~

  • Joey Wang said:

    But it seems not explicitly setting method currently.

    Could you expand a bit on this? I am not sure if I understand what you mean here.

  • Hi Elfving,

    When configuring the QSPI using the nrf7002-qspi label in our overlay, we encounter several Kconfig dependency errors (see the attached log). The detailed configuration can be found in stm32h757i_eval_stm32h757xx_m7.overlay.

    Is there a recommended method to enable QSPI (with DMA) successfully?

     - NRF70_ON_QSPI (defined at modules/nrf_wifi/bus/Kconfig:22, modules/nrf_wifi/bus/Kconfig:22), with value y, direct dependencies NRF70_BUSLIB || (NRF70_BUSLIB && 0) (value: y), and select condition NRF70_BUSLIB (value: y)
    error: Aborting due to Kconfig warnings
    #stm32h757i_eval_stm32h757xx_m7.overlay
    #include <freq.h>
    
    / {
    	chosen {
    		zephyr,wifi = &wlan0;
    		zephyr,canbus = &fdcan1;
    		zephyr,qspi = &quadspi;
    	};
    };
    
    
    /* Disable Ethernet MAC controller */
    &mac {
    	status = "disabled";
    };
    
    /* Disable MDIO interface */
    &mdio {
    	status = "disabled";
    };
    
    &mt25ql512ab1 {
        status = "disabled";
    };
    
    &mt25ql512ab2 {
        status = "disabled";
    };
    
    &spi1 {
    	status = "disabled";
    };
    
    // for 757 FDCNA Clock Source setting 80Hz
    &pll2 {
    	div-m = <5>;
    	mul-n = <32>;
    	div-p = <1>;
    	div-q = <2>;
    	div-r = <2>;
    	clocks = <&clk_hse>;
    	status = "okay";
    };
    
    &fdcan1 {
        status = "okay";
     	compatible= "st,stm32h7-fdcan";
        /* 修改 pinctrl */
        //pinctrl-0 = <&fdcan1_rx_pd0 &fdcan1_tx_pd1>;  // for 723 boards pin setting 
    	//pinctrl-0 = <&fdcan1_rx_pb8 &fdcan1_tx_pb9>;  // for 757 boards pin setting 
    	pinctrl-0 = <&fdcan1_rx_pd0 &fdcan1_tx_pd1>;
        pinctrl-names = "default";
    
        /* 修改 clock source 或啟用 */
        clocks = <&rcc STM32_CLOCK_BUS_APB1_2 0x00000100>,
                 <&rcc STM32_SRC_PLL2_Q FDCAN_SEL(2)>;
    			bus-speed = <1000000>;
    			bus-speed-data=<8000000>;
    
        /* 修改 Nominal / Data bitrate 與時序 */
        //bus-speed = <4000000>;          // Nominal baud rate 1 Mbps
    	//bus-speed = <2982456>;          // Nominal baud rate 1 Mbps
    	//bus-speed-data=<2982456>;
        //bus-speed-data=<4000000>;
        // sjw = <1>;
        // prop-seg = <6>;
        // phase-seg1 = <13>;
        // phase-seg2 = <1>;               // STM32H7 固定 1
    
        // fd-data-bus-speed = <4000000>;  // Data phase 4 Mbps
        // fd-sjw = <1>;
        // fd-prop-seg = <1>;
        // fd-phase-seg1 = <2>;
        // fd-phase-seg2 = <1>;
    };
    
    
    /* Configure QSPI for high-speed nRF7002 communication (for h757 board) */
    &quadspi {
    	pinctrl-0 = <&quadspi_clk_pf10 &quadspi_bk1_ncs_pg6 
    	             &quadspi_bk2_io0_ph2 &quadspi_bk2_io1_ph3 
    				 &quadspi_bk2_io2_pg9 &quadspi_bk2_io3_pg14>;
    	pinctrl-names = "default";
    	status = "okay";
    
    	nrf70qspi: nrf7002-qspi@0 {
    		compatible = "nordic,nrf7002-qspi";
    		status = "okay";
    		qspi-quad-mode; /* Enable quad mode */
    		qspi-cpha;
    		qspi-frequency = <DT_FREQ_M(16)>; /* 16MHz QSPI clock */
    		reg = <0>;
    		/* Control GPIOs - using available pins that don't conflict */
    		iovdd-ctrl-gpios = <&gpioj 8 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>; 
    		bucken-gpios = <&gpioj 9 (GPIO_ACTIVE_HIGH | GPIO_PULL_DOWN)>;     
    		host-irq-gpios = <&gpioj 10 GPIO_ACTIVE_HIGH>;                     
    		
    		/* List of interfaces */
    		wlan1: wlan1 {
    			compatible = "nordic,wlan";
    
    		};
    		
    		/* Wi-Fi TX power limits */
    		wifi-max-tx-pwr-2g-dsss = <21>;
    		wifi-max-tx-pwr-2g-mcs0 = <16>;
    		wifi-max-tx-pwr-2g-mcs7 = <16>;
    		wifi-max-tx-pwr-5g-low-mcs0 = <13>;
    		wifi-max-tx-pwr-5g-low-mcs7 = <13>;
    		wifi-max-tx-pwr-5g-mid-mcs0 = <13>;
    		wifi-max-tx-pwr-5g-mid-mcs7 = <13>;
    		wifi-max-tx-pwr-5g-high-mcs0 = <12>;
    		wifi-max-tx-pwr-5g-high-mcs7 = <12>;
    	};
    };
    //C:\Users\JackLin\limb_string\zephyrproject\zephyr\boards\st\nucleo_h723zg

  • So unfortunately the nrf7002-qspi label is tied to the vendor, and doesn't work with non-nrf devices. I agree that this could've been made clearer with the naming. You would have to use spi, though what you can do is to modify the driver, or port QSPI portions of the nRF70 driver to the non-nRF MCU, one of our FAE has done it for STM32 evaluations on mimxrt1170_evk. I'll see if I can find more info on this.

    Regards,

    Elfving

  • Hi again, I got a bit more info on this one for you.

    So the issue is that there has not been any generic QSPI peripheral driver within Zephyr so far. The as of now, it looks as if they've gotten further with a "MSPI" peripheral driver. (And seems to be some development on our side of this as well now)

    Our wifi driver works on zephyr-spi (which is generic and works with any SPI peripheral driver as long as the board/target is supported with its spi HAL in the zephyr project).

    This means it does not work out of the box on any other "qspi". Another problem is the fact that other vendors do not call it qspi. NXP for example has lpspi and flexspi - both of these can work with 4 data lines basically making a QSPI.

    So what one would need to do here in order to get the NRF7 to work on other vendor MCUs, is to take our qspi driver implementation as an example and migrate this to the vendor specific peripheral for multi line SPI/QSPI.

    I have yet to find anyone internally who has tried this with STM, and I am not sure how straight forward it in fact is. What you need is the QSPI driver from STM, and the bridge to our wifi driver. You can see more on how this bridging works here. 

    It also calls the rpu_hw_if driver and qspi_if.h. Those files are all Nordic dependant. They call nrfx qspi and run Nordic special defines/macros. This is what needs to be mapped to qspi / multi line spi from STM32.

    Any update on this from your side?

    Regards,

    Elfving

Reply
  • Hi again, I got a bit more info on this one for you.

    So the issue is that there has not been any generic QSPI peripheral driver within Zephyr so far. The as of now, it looks as if they've gotten further with a "MSPI" peripheral driver. (And seems to be some development on our side of this as well now)

    Our wifi driver works on zephyr-spi (which is generic and works with any SPI peripheral driver as long as the board/target is supported with its spi HAL in the zephyr project).

    This means it does not work out of the box on any other "qspi". Another problem is the fact that other vendors do not call it qspi. NXP for example has lpspi and flexspi - both of these can work with 4 data lines basically making a QSPI.

    So what one would need to do here in order to get the NRF7 to work on other vendor MCUs, is to take our qspi driver implementation as an example and migrate this to the vendor specific peripheral for multi line SPI/QSPI.

    I have yet to find anyone internally who has tried this with STM, and I am not sure how straight forward it in fact is. What you need is the QSPI driver from STM, and the bridge to our wifi driver. You can see more on how this bridging works here. 

    It also calls the rpu_hw_if driver and qspi_if.h. Those files are all Nordic dependant. They call nrfx qspi and run Nordic special defines/macros. This is what needs to be mapped to qspi / multi line spi from STM32.

    Any update on this from your side?

    Regards,

    Elfving

Children
No Data
Related