• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1815 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM572x QSPI in Mode0 Linux configuration

Tim Dylla
Expert 1070 points
Other Parts Discussed in Thread: AM5726

Hi,

  I'm trying to configure the qspi interface on a am5726 for mode0 write. Since we only have to write a bitstream into a slave the wiring is very simple:

am572x (Master)        FPGA (Slave)

qspi1_d0      ->       MOSI 

qspi1_sclk    ->       SCK FPGA

Since we have only one slave attached to the master even CS is not wired.

 

The device tree regarding qspi looks as follows:

&dra7_pmx_core {
  qspi1_pins_default: qspi1_pins_default {
      pinctrl-single,pins = <
        DRA7XX_CORE_IOPAD(0x3470, (PIN_OUTPUT               | MUX_MODE14)) /* gpmc_a12.gpio2_2  prog B */
        DRA7XX_CORE_IOPAD(0x3474, (PIN_INPUT_PULLUP         | MUX_MODE14)) /* gpmc_a13.gpio2_3  done   */
        DRA7XX_CORE_IOPAD(0x3480, (PIN_OUTPUT | MANUAL_MODE | MUX_MODE1))  /* gpmc_a16.qspi1_d0        */
        DRA7XX_CORE_IOPAD(0x3488, (PIN_OUTPUT | MANUAL_MODE | MUX_MODE1))  /* gpmc_a18.qspi1_sclk      */      
    >;
  };
};
 
&dra7_iodelay_core {
  qspi1_iodelay_default: qspi1_iodelay_default {
    pinctrl-single,pins = <
      0x168 (A_DELAY(2528) | G_DELAY(1007)) /* CFG_GPMC_A16_IN */
      0x170 (A_DELAY(0)    | G_DELAY(0))    /* CFG_GPMC_A16_OUT */
      0x188 (A_DELAY(590)  | G_DELAY(0))    /* CFG_GPMC_A18_OUT */
    >;
  };
};

&qspi {
  compatible = "ti,dra7xxx-qspi";
  reg = <0x4b300000 0x100>,
        <0x5c000000 0x4000000>;
  reg-names = "qspi_base", "qspi_mmap";
  syscon-chipselects = <&scm_conf 0x558>;
  #address-cells = <1>;
  #size-cells = <0>;
  ti,hwmods = "qspi";
  clocks = <&qspi_gfclk_div>;
  clock-names = "fck";
  num-cs = <4>;
  interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
  pinctrl-names = "default";
  pinctrl-0 = <&qspi1_pins_default &qspi1_iodelay_default>;
  status = "okay";
  spi-max-frequency = <76800000>;
 
  spi@0 {
    compatible = "rohm,dh2228fv";
    reg = <0x0>;
    spi-max-frequency = <76800000>;
    status = "okay";
  };
};


The IO-delays and mode select configs are according to sprs953A Table 7-46.
The Kernel is configured with spi user driver support, the ti-qspi driver is initialized and a spidev-compatible device node '/dev/spidev32766.0' is added. Dmesg shows debug output if I try to write data to the device node. But if I have a look at  the qspi1_sclk pin via oscilloscope, I can't see any clock output on the wire. What is wrong with my config? Do I have to add some information to the qspi dts data regarding mode 0? Are there any other steps in terms of initialization I have missed?
 
Thanks a lot in advance,
 
                Tim 


  • 0
    TI__Guru**** 393215 points
    The software team have been notified. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    Expert 1070 points

    Thank you Biser,

    I should have added the qspi-related dmesg output:

    Init:

    [ 1.569555] ti-qspi 4b300000.qspi: registered master spi32766 (dynamic)
    [ 1.569654] ti-qspi 4b300000.qspi: hz: 76800000, clock divider 0
    [ 1.569690] spi spi32766.0: setup mode 0, 8 bits/w, 76800000 Hz max --> 0
    [ 1.570052] ti-qspi 4b300000.qspi: registered child spi32766.0

    echo "hello" > /dev/spidev32766.0:

    [ 1089.767552] ti-qspi 4b300000.qspi: tx cmd 003a0005 dc 00000000 data 68
    [ 1089.767569] ti-qspi 4b300000.qspi: tx cmd 003a0005 dc 00000000 data 65
    [ 1089.767581] ti-qspi 4b300000.qspi: tx cmd 003a0005 dc 00000000 data 6c
    [ 1089.767592] ti-qspi 4b300000.qspi: tx cmd 003a0005 dc 00000000 data 6c
    [ 1089.767602] ti-qspi 4b300000.qspi: tx cmd 003a0005 dc 00000000 data 6f
    [ 1089.767612] ti-qspi 4b300000.qspi: tx cmd 003a0005 dc 00000000 data 0a

  • 0 in reply to Tim Dylla
    Expert 1070 points

    Addendum

    I didn't mention: working on processor sdk linux-rt am57xx evm 3.1.0.6

    when I'm trying to transmit data I see:

    • the qspi clock gate opening  - CM_L4PER2_CLKSTCTRL bit[12]
    • the module mode transition to 'explicitly enabled'  and 'fully functional' - CM_L4PER2_QSPI_CLKCTRL bit[1:0] and [17:16]

    But the clock and data0 pins remain quiet.

    Anyone?

               tim

  • 0
    TI__Guru**** 161600 points
    Hi Tim,

    Do I have to add some information to the qspi dts data regarding mode 0?


    No, in fact the default mode for qspi is MODE0, so I'd suggest you REMOVE the manual io timings:
    &dra7_iodelay_core {
    qspi1_iodelay_default: qspi1_iodelay_default {
    pinctrl-single,pins = <
    0x168 (A_DELAY(2528) | G_DELAY(1007)) /* CFG_GPMC_A16_IN */
    0x170 (A_DELAY(0) | G_DELAY(0)) /* CFG_GPMC_A16_OUT */
    0x188 (A_DELAY(590) | G_DELAY(0)) /* CFG_GPMC_A18_OUT */
    >;
    };

    And try again. It is possible that something goes wrong, when you explicitly redefine the io delay.
    Also try setting a lower clock frequency just for the test, to see if the behavior would change.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Expert 1070 points

    Hi Yordan,

      thank you for looking into it - I'm out of ideas.

    Unfortunately, removing the iodelay config and lowering the frequency doesn't help. However I see the changes are in effect from dmesg output:

    [ 1.560473] ti-qspi 4b300000.qspi: registered master spi32766 (dynamic)
    [ 1.560571] ti-qspi 4b300000.qspi: hz: 25000000, clock divider 3
    [ 1.560608] spi spi32766.0: setup mode 0, 8 bits/w, 25000000 Hz max --> 0
    [ 1.560959] ti-qspi 4b300000.qspi: registered child spi32766.0

    When I read out pinmux,iodelay and clock config MMRs I see this:

    pinmux:
    gpmc_a16.qspi1_d0    CTRL_CORE_PAD_GPMC_A16 0x4A003480 -> 0x00010101 (PIN_OUT, DELAY_MODE0, MUX_MODE1)
    gpmc_a18.qspi1_sclk  CTRL_CORE_PAD_GPMC_A18 0x4A003488 -> 0x00010101 (PIN_OUT, DELAY_MODE0, MUX_MODE1)
    iodelay:
    gpmc_a16.qspi1_d0    CFG_GPMC_A16_IN  0x4844A168 -> 0x0000000 ???
    gpmc_a16.qspi1_d0    CFG_GPMC_A16_OUT 0x4844A170 -> 0x0000000 ???
    gpmc_a18.qspi1_sclk  CFG_GPMC_A18_OUT 0x4844A188 -> 0x0000000 ???
    clock:
    CM_L4PER2_QSPI_CLKCTRL 0x4A009838 -> 0x01030000 (CLK_DIV:1, PER_QSPI_CLK from DPLL_PER, IDLEST changes sending data)
    CM_L4PER2_CLKSTCTRL    0x4A0098FC -> 0x00016102 (QSPI CLK is gated - changes on sending data)

     

    With my original dts config the infos are as following (changes highlighted):

    [ 1.559933] ti-qspi 4b300000.qspi: registered master spi32766 (dynamic)
    [ 1.560032] ti-qspi 4b300000.qspi: hz: 76800000, clock divider 0
    [ 1.560067] spi spi32766.0: setup mode 0, 8 bits/w, 76800000 Hz max --> 0
    [ 1.560425] ti-qspi 4b300000.qspi: registered child spi32766.0

    pinmux:
    gpmc_a16.qspi1_d0    CTRL_CORE_PAD_GPMC_A16 0x4A003480 -> 0x00010101 (PIN_OUT, DELAY_MODE0, MUX_MODE1)
    gpmc_a18.qspi1_sclk  CTRL_CORE_PAD_GPMC_A18 0x4A003488 -> 0x00010101 (PIN_OUT, DELAY_MODE0, MUX_MODE1)
    iodelay:
    gpmc_a16.qspi1_d0    CFG_GPMC_A16_IN  0x4844A168 -> 0x00000C9 according to sprs953A Table 7-46
    gpmc_a16.qspi1_d0    CFG_GPMC_A16_OUT 0x4844A170 -> 0x0000000
    gpmc_a18.qspi1_sclk  CFG_GPMC_A18_OUT 0x4844A188 -> 0x0000024
    clock:
    CM_L4PER2_QSPI_CLKCTRL 0x4A009838 -> 0x01030000 (CLK_DIV:1, PER_QSPI_CLK from DPLL_PER, IDLEST changes if data is send)
    CM_L4PER2_CLKSTCTRL    0x4A0098FC -> 0x00016102 (QSPI CLK is gated - changes on sending data)     

    When I follow your advice I'm confused about the missing iodelay configuration since the data manual explicitly states in sprs953A Table 7-46 the iodelays have to be set for qspi in order to work reliably in mode0.

    Also the clock divider which I supposed to find in CM_L4PER2_QSPI_CLKCTRL [26:25] seems not to be set, even when lowering the frequency makes the qspi driver stating that clock divider is 3.

    Nevertheless if you could say the config is fine I maybe better be asking our hardware guys if it' could be something in their realm...

    Best

             Tim

  • 0 in reply to Tim Dylla
    TI__Guru**** 161600 points

    Hi Tim,

    When I follow your advice I'm confused about the missing iodelay configuration since the data manual explicitly states in sprs953A Table 7-46 the iodelays have to be set for qspi in order to work reliably in mode0.

    I am referring to the kernel documentation (Documenatation/devicetree/bindings/spi/ti_qspi.txt), which explicitly says:

       "NOTE: TI QSPI controller requires different pinmux and IODelay paramaters for Mode-0 and Mode-3 operations, which needs to be set up by

    the bootloader (U-Boot). Default configuration only supports Mode-0 operation. Hence, "spi-cpol" and "spi-cpha" DT properties cannot be specified in the slave nodes of TI QSPI controller without appropriate modification to bootloader." 

    Can you  try the following configuration: 
     

    1. Refer to u-boot: arch/arm/dts/dra7-evm.dts and add similar entry to am57xx-beagle-x15.dts: 
      

    qspi1_pins: pinmux_qspi1_pins {
      pinctrl-single,pins = <
          0x4c (PIN_INPUT | MUX_MODE1) /* gpmc_a3.qspi1_cs2 */
          0x50 (PIN_INPUT | MUX_MODE1) /* gpmc_a4.qspi1_cs3 */
          0x74 (PIN_INPUT | MUX_MODE1) /* gpmc_a13.qspi1_rtclk */
          0x78 (PIN_INPUT | MUX_MODE1) /* gpmc_a14.qspi1_d3 */
          0x7c (PIN_INPUT | MUX_MODE1) /* gpmc_a15.qspi1_d2 */
          0x80 (PIN_INPUT | MUX_MODE1) /* gpmc_a16.qspi1_d1 */
          0x84 (PIN_INPUT | MUX_MODE1) /* gpmc_a17.qspi1_d0 */
          0x88 (PIN_INPUT | MUX_MODE1) /* qpmc_a18.qspi1_sclk */
          0xb8 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs2.qspi1_cs0 */
          0xbc (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_cs3.qspi1_cs1 */
       >;
    };

    &qspi {
         status = "okay";
         pinctrl-names = "default";
         pinctrl-0 = <&qspi1_pins>;

         spi-max-frequency = <64000000>;     

         spidev@0 {
             compatible = "rohm,dh2228fv";
             reg = <0x0>;
             spi-max-frequency = <76800000>;
             status = "okay";
          };
    }; 
    in dra7.dtsi, you should have the full qspi configuration: 
     

    qspi: qspi@4b300000 {
      compatible = "ti,dra7xxx-qspi";
      reg = <0x4b300000 0x100>,
                <0x5c000000 0x4000000>,
                <0x4a002558 0x4>;
      reg-names = "qspi_base", "qspi_mmap",
                           "qspi_ctrlmod";
      #address-cells = <1>;
      #size-cells = <0>;
      ti,hwmods = "qspi";
      clocks = <&qspi_gfclk_div>;
      clock-names = "fck";
      num-cs = <4>;
      interrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
      status = "disabled";
    };

    2. Add also the kernel configuration in arch/arm/boot/dts/am57xx-evm.dts (again refer to dra7xx-evm.dts):

    &qspi {
         status = "okay";

         spi-max-frequency = <76800000>;     

         spidev@0 {
              compatible = "rohm,dh2228fv";
              reg = <0x0>;
              spi-max-frequency = <76800000>;
              status = "okay";
          };
    };

    The other part of the qspi configuration, should be included in dra7.dtsi: 
       

    qspi: qspi@4b300000 {
        compatible = "ti,dra7xxx-qspi";
        reg = <0x4b300000 0x100>,
                 <0x5c000000 0x4000000>;
        reg-names = "qspi_base", "qspi_mmap";
        syscon-chipselects = <&scm_conf 0x558>;
        #address-cells = <1>;
        #size-cells = <0>;
        ti,hwmods = "qspi";
        clocks = <&qspi_gfclk_div>;
        clock-names = "fck";
        num-cs = <4>;
        nterrupts = <GIC_SPI 343 IRQ_TYPE_LEVEL_HIGH>;
        status = "disabled";
    }; 

    Hope this helps.  

    I've also asked the design team to elaborate on anything I've missed. 

    Best Regards, 
    Yordan

  • 0 in reply to Yordan Kovachev
    Expert 1070 points

    Hi Yordan,

      I had a look at the evm- and also the idk dts files of u-boot and I couldn't find any io delay config for the qspi pins. Is it even configured in mode0 there? The rest of the config seems quite the same to what I already have - except the pinmuxing of wires I do not intend to use. Anyway I tried to configure iodelay and pinmuxing of all pins in uboot but to no avail. I will ask the guys from our hw dept. if they have any idea.

    But now I wonder: do I have to do the io-delay configuration of qspi pins in the u-boot device tree? I don't need the qspi at boot time since I only want to use it to boot a fpga when linux is already up. It would be way more convenient to do the config in the linux device tree.

    Thanks for your efforts,

             Tim