AM625: QSPI not working.

Looks like you already posted the same question before, twice:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1206334/am625-ospi-flash-memory-of-the-evk-proc114e3-as-a-qspi-not-working/4563734#4563734

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1205448/am625-qspi-nand-flash-not-working-with-am6254/4567381#4567381

Both threads have "proposed answers", but then the discussion wasn't continued. One of the things flagged was the missing CS signals. The schematic extract you show above still doesn't show that connected. It won't work like this.

Once you have confirmed/rectified the CS issue you may want to connect a logic analyzer to all the traces and compare the communication with what is expected as per TRM and Flash device datasheet.

Regards, Andreas

hello Andreas,

as i mention i remove from ground and I connected pin (H21) OSPI0_CSn2 for cs.
but my cs pin is keep high. so please guide.

Thank you,
Chintan

Hi!

thanks for confirming the CS signal connection.

Since you are using CS2 you'll need to update the DTS file to reflect this as follows. From this...

&ospi0 {
    flash@0 {
        compatible = "winbond,W25N01GV","spi-nand";
        reg = <0x0>;
        spi-tx-bus-width = <1>;
        spi-rx-bus-width = <4>;

...to this...

&ospi0 {
    flash@2 {
        compatible = "winbond,W25N01GV","spi-nand";
        reg = <0x2>;
        spi-tx-bus-width = <1>;
        spi-rx-bus-width = <4>;

See DTS bindings description for the SPI controller for more info & an example: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/Documentation/devicetree/bindings/spi/spi-controller.yaml?h=ti-linux-5.10.y#n89

Regards, Andreas

Hi Andreas,

&ospi0 {
        status = "okay";
        flash@2 {
                compatible = "winbond,W25N01GV","spi-nand";
                reg = <0x2>;
                spi-tx-bus-width = <1>;
                spi-rx-bus-width = <4>;
                spi-max-frequency = <25000000>;
                cdns,tshsl-ns = <60>;
                cdns,tsd2d-ns = <60>;
                cdns,tchsh-ns = <60>;
                cdns,tslch-ns = <60>;
                cdns,read-delay = <4>;
                cdns,phy-mode;

                partitions {
                        compatible = "fixed-partitions";
                        #address-cells = <1>;
                        #size-cells = <1>;
                        partition@0 {
                                label = "qspi.tiboot3";
                                reg = <0x0 0x80000>;
                        };

                        partition@80000 {
                                label = "qspi.tispl";
                                reg = <0x80000 0x200000>;
                        };

    };
};

After changing dts as per your suggestion I got error.

[    1.392855] cadence-qspi fc00000.bus:spi@fc40000: invalid resource
[    1.399051] cadence-qspi fc00000.bus:spi@fc40000: Cannot remap controller address.
[    1.406639] cadence-qspi: probe of fc00000.bus:spi@fc40000 failed with error -22

From the scope shots that were provided separately it looks like the CS signal was never toggling.

So I had a closer look at this, and it looks like the spi-cadence-quadspi driver in our ti-linux-5.10.y Kernel (which is what SDK v8.x are based off) only has incomplete support for CS signals greater than 0. The support in the driver itself is there, however it is missing to correctly propagate the max number of supported CS signals to the SPI driver framework.

Can you double-check your boot log if you see something like this?

[    1.256882] cadence-qspi fc40000.spi: cs2 >= max 1

If so, this would be a symptom of the concern just discussed.

To fix this, you should cherry-pick the below commit on top of your ti-linux-5.10.y Kernel tree, and re-build/re-deploy your Kernel image.

spi: cadence-quadspi: Add multi-chipselect support for Intel LGM SoC
https://github.com/torvalds/linux/commit/b436fb7d29bfa48ff5e00cbf413609c7a6d4d81e

You won't need to set the "num-cs" property explicitly in your DTS, the default (16) will work for your case.

Also note that our upcoming TI SDK series 9.x will be based on the ti-linux-6.1.y Kernel which has the above patch already integrated.

Regards, Andreas

hi Andreas,

When we expect new TI SDK release ?

Hi Meet,

new SDK releases for AM62x (called SDK v9.0) should be available within a week or so. Our SW teams are just wrapping up the release testing.

But I'm curious, did you try the previously suggested patch? Does this improve things?

Regards, Andreas

Hi Andreas,

We are able to detect QSPI in 8.6 version only thank you for your support.

But If we set frq for QSPI port to 25MHz but if we measure using CRO it is 20MHz only, Can you suggest is there anything we are missing ?

Hi Andreas,

We are able to detect QSPI in 8.6 version only thank you for your support.

But If we set frq for QSPI port to 25MHz but if we measure using CRO it is 20MHz only, Can you suggest is there anything we are missing ?

Meet Modia said:

We are able to detect QSPI in 8.6 version only thank you for your support.

Glad to hear that this is (finally) working!!

Meet Modia said:

But If we set frq for QSPI port to 25MHz but if we measure using CRO it is 20MHz only

This is Linux I suppose?

Can you re-confirm you used the spi-max-frequency DTS property for this, in the correct SPI node?

Then, can you please try reducing the frequency to like 10,000,000Hz to see if the actual SPI bus frequency changes to 10MHz as well (I'd like to confirm that the DTS property is indeed applied to the HW registers/peripherals at least in some scenarios).

Regards, Andreas

When we set 10MHz we are getting 9.2Mhz, On EVM also when we set 25MHz we are getting 20Mhz only.

Hi!

thanks for confirming that the spi-max-frequency property is indeed able to control the frequency. From what you report it sounds like that the OSPI0 module input frequency is limiting your choices as to your observable SPI clock frequency (only an integer divider can be used to derive the output clock I think). Can you provide a dump of the available OSPI0 module parent clock frequencies by executing the following command (75 is the device ID for the OSPI0 module on AM62, see https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am62x/devices.html):

root@am62xx-evm:/# k3conf dump clock 75

Regards, Andreas

Hello Andreas,

Here is the attached requested result.

Thanks for the OSPI0 module clock dump. We can see the input clock to the module (clock ID 7) used for SPI bus clock generation is 166.66MHz, which is the SDK default. From this clock frequency you can only derive certain SPI bus clock frequencies by way of integer dividers, which is the reason you can't exactly get to 25MHz. If you want to get 25MHz on the SPI bus you'll need to modify one of the clock parents accordingly. I'm currently out of the office so access to HW is limited but I can experiment with this next week when I'm back.

Regards, Andreas

Hi Andreas,

Thank you for this suggestion. Hope you are back from your vacation.

Did you test this at your end by modifying any of the clock parent? Can you share us the steps to follow?

Regards, Ankit N

Hi Ankit,

this is next in line for me to look at (tomorrow). Will report back soon. Thanks for your patience!

Andreas

Hi Ankit,

can you please try the below DTS modification to set the default clock parent frequency for the OSPI module reference clock to 200MHz:

a0797059@dasso:~/git/linux (ti-linux-6.1.y)
$ git diff
diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index 74e34b84419a..ab3a33bd2e1e 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -680,7 +680,7 @@ ospi0: spi@fc40000 {
                        clocks = <&k3_clks 75 7>;
                        assigned-clocks = <&k3_clks 75 7>;
                        assigned-clock-parents = <&k3_clks 75 8>;
-                       assigned-clock-rates = <166666666>;
+                       assigned-clock-rates = <200000000>;
                        power-domains = <&k3_pds 75 TI_SCI_PD_EXCLUSIVE>;
                        #address-cells = <1>;
                        #size-cells = <0>;

With this, the k3conf tool should now return an updated RCLK frequency as follows:

root@am62xx-evm:~# k3conf dump clock 75
|------------------------------------------------------------------------------|
| VERSION INFO                                                                 |
|------------------------------------------------------------------------------|
| K3CONF | (version v0.1-90-g1dd468d built Thu Jul 13 05:45:57 PM UTC 2023)    |
| SoC    | AM62X SR1.0                                                         |
| SYSFW  | ABI: 3.1 (firmware version 0x0009 '9.0.5--v09.00.05 (Kool Koala))') |
|------------------------------------------------------------------------------|

|-------------------------------------------------------------------------------------------------------------------------------------|
| Device ID | Clock ID | Clock Name                                                               | Status          | Clock Frequency |
|-------------------------------------------------------------------------------------------------------------------------------------|
|    75     |     0    | DEV_FSS0_OSPI_0_OSPI_DQS_CLK                                             | CLK_STATE_READY | 0               |
|    75     |     1    | DEV_FSS0_OSPI_0_OSPI_HCLK_CLK                                            | CLK_STATE_READY | 500000000       |
|    75     |     2    | DEV_FSS0_OSPI_0_OSPI_ICLK_CLK                                            | CLK_STATE_READY | 0               |
|    75     |     3    | DEV_FSS0_OSPI_0_OSPI_ICLK_CLK_PARENT_BOARD_0_OSPI0_DQS_OUT               | CLK_STATE_READY | 0               |
|    75     |     4    | DEV_FSS0_OSPI_0_OSPI_ICLK_CLK_PARENT_BOARD_0_OSPI0_LBCLKO_OUT            | CLK_STATE_READY | 0               |
|    75     |     5    | DEV_FSS0_OSPI_0_OSPI_OCLK_CLK                                            | CLK_STATE_READY | 0               |
|    75     |     6    | DEV_FSS0_OSPI_0_OSPI_PCLK_CLK                                            | CLK_STATE_READY | 500000000       |
|    75     |     7    | DEV_FSS0_OSPI_0_OSPI_RCLK_CLK                                            | CLK_STATE_READY | 200000000       |<-+
|    75     |     8    | DEV_FSS0_OSPI_0_OSPI_RCLK_CLK_PARENT_HSDIV4_16FFT_MAIN_0_HSDIVOUT1_CLK   | CLK_STATE_READY | 200000000       |--+ This is now 200MHz and selected for RCLK
|    75     |     9    | DEV_FSS0_OSPI_0_OSPI_RCLK_CLK_PARENT_POSTDIV1_16FFT_MAIN_1_HSDIVOUT5_CLK | CLK_STATE_READY | 160000000       |
|-------------------------------------------------------------------------------------------------------------------------------------|

This _should_ allow for a OSPI output frequency of 25MHz if configured via spi-max-frequency using a clean integer divider. Can you please give this a try and report back (I don't have access to HW at the moment so I can't measure the actual frequency myself).

Regards, Andreas

Hi Andreas,

Thanks for the update. Our SW team has started working on it. Once the steps are validated they will get back to you.

Regards,

Ankit N

Hi Andreas,

After these changes we are able to get exact 25MHz of frequency. Thank you for the support.

So my another query is as per SoC datasheet(below screenshot) OSPI0_CLK can provide max 166MHz of frequency;

So we are currently using OSPI interface as a QSPI interface. So can we get the same frequency(166MHz) on OSPI0_CLK  for QSPI or will get same only if used as OSPI interface?

If we can get 166MHz as a QSPI, then please suggest required DTS changes for implementation.

Regards

Ankit N

Ankit Nikumbh said:

So we are currently using OSPI interface as a QSPI interface. So can we get the same frequency(166MHz) on OSPI0_CLK  for QSPI or will get same only if used as OSPI interface?

166MHz frequency on OSPI0_CLK implies that the "PHY Mode" is used, which is currently only supported for OSPI devices in DDR mode by our U-Boot and Linux SW. While the AM62x OSPI peripheral module hardware should be capable of supporting external QSPI devices beyond 50MHz in SDR mode or 25MHz in DDR mode, such operation implies the "PHY Mode" to be used, which again is currently not supported/validated by any of our software.

If you need a faster interface to external memory I suggest using an OSPI device instead for best-possible performance.

Regards, Andreas

Hi Andreas,

That means currently we are getting 25MHz in DDR mode default, right?

So is there any possibility to change it in SDR mode to get 50MHz at least? if so, can you please share the DTS change as per this if it is validated by your team?

Regards

Ankit N

Ankit Nikumbh said:

That means currently we are getting 25MHz in DDR mode default, right?

The default in QSPI mode is SDR mode. Looking at the current Kernel code (v6.1) it looks like DDR mode is generally only supported for OSPI NOR/NAND type devices at this time. It is enabled on applicable devices by the SPI core drivers, if both host controller (AM6x Candance QSPI driver == yes) and external Flash support it (as per that Flash chip's driver), see drivers/mtd/spi-nor/core.c and drivers/mtd/nand/spi/core.c in the Kernel sources.

Ankit Nikumbh said:

So is there any possibility to change it in SDR mode to get 50MHz at least? if so, can you please share the DTS change as per this if it is validated by your team?

We don't test/validate such specific combination, it's something you'd need to try out yourself.

I'd start with the same assigned-clock-rates = <200000000>; setting we established earlier, while bumping the SPI max. frequency to 50MHz via  spi-max-frequency = <50000000>;  Note that such data rates will likely require a custom board w/ good layout best-practices followed etc. (not a blue wire setup), I suppose you already have that.

Regards, Andreas