• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 894 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.

TDA4VM: "sf probe" for OSPI doesn't work at slower reference clock

Jeff Kim27
Intellectual 320 points
Part Number: TDA4VM

Hello,

I put the OSPI boot log below. The existing reference clock is 133MHz. Everything works fine with this. As the phy_mode is enabled, is the clock output to flash device same as 133MHz ref_clk?

The problem is the lower 100MHz. After I change the assigned-clock-rates to 100MHz in the below u-boot device tree, "sf probe" command at u-boot prompt doesn't recognize the flash device at SD boot.

Do I need to change other codes accordingly when the assigned-clock-rates is changed?

Thanks.

  • OSPI boot log

U-Boot SPL 2020.01-dirty (May 10 2023 - 19:36:58 -0700)
SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
Trying to boot from SPI
cadence_spi_ofdata_to_platdata: regbase=47040000 ahbbase=50000000 max-frequency=50000000 page-size=256 phy_mode=1
cadence_qspi_apb_config_baudrate_div: ref_clk 133333333Hz sclk 50000000Hz Div 0x1, actual 33333333Hz
cadence_spi_set_speed: speed=50000000
cadence_qspi_apb_chipselect : chipselect 0 decode 0
READ : Opcode : 0x9f, C.W 1, A.W 1, D.W 1

  • u-boot device tree

ospi0: spi@47040000 {
compatible = "ti,am654-ospi";
reg = <0x0 0x47040000 0x0 0x100>,
<0x5 0x00000000 0x1 0x0000000>;
interrupts = <GIC_SPI 840 IRQ_TYPE_LEVEL_HIGH>;
cdns,fifo-depth = <256>;
cdns,fifo-width = <4>;
cdns,trigger-address = <0x0>;
clocks = <&k3_clks 103 0>;
assigned-clocks = <&k3_clks 103 0>;
assigned-clock-parents = <&k3_clks 103 2>;
assigned-clock-rates = <100000000>;//<133333333>;
power-domains = <&k3_pds 103 TI_SCI_PD_EXCLUSIVE>;
#address-cells = <1>;
#size-cells = <0>;
};

  • 0
    TI__Guru**** 162770 points

    Hi Jeff,

    What is the target frequency you want to run the OSPI?

    Also please confirm the SDK version?

    Best Regards,

    Keerthy 

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    I think the OSPI is running at 133MHz currently. I'd like to change it to 100MHz. The attempt was failed as I described above.

    the SDK version is "ti-processor-sdk-linux-automotive-j7-evm-07_00_01".

    Best Regards,

    Jeff

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points

    Hi Jeff,

    I am able to see the error below when i change the OSPI frequency to 100M:

    [2023-05-19 15:12:37.894] => sf probe
    [2023-05-19 15:12:40.726] cadence_spi spi@47040000: Can't get reset: -2
    [2023-05-19 15:12:40.726] jedec_spi_nor flash@0: unrecognized JEDEC id bytes: 68, b6, 34
    [2023-05-19 15:12:40.742] Failed to initialize SPI flash at 0:0 (error -2)

    Couple of questions:

    • Why do we have to change that to 100M?
    • Do you see the same errors?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    Thank you for producing the failure. Slowing down clock frequency is one of the effective analytical methods for me if I encounter an abnormal case.

    Your error log seems similar to mine as below. I didn't enable the DEBUG option when I got the error.

    # sf probe 0:0

    unrecognized JEDEC id bytes: ce, ad, 8c

    Failed to initialize SPI flash at 0:0 (error -2)

    Best Regards,

    Jeff

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points

    Hi Jeff,

    Seems like read-delay changing is working on the j7200-EVM.

    diff --git a/arch/arm/dts/k3-j7200-som-p0.dtsi b/arch/arm/dts/k3-j7200-som-p0.dtsi
    index 8228849fd9..77e9d23a2d 100644
    --- a/arch/arm/dts/k3-j7200-som-p0.dtsi
    +++ b/arch/arm/dts/k3-j7200-som-p0.dtsi
    @@ -188,7 +188,7 @@
                    cdns,tsd2d-ns = <60>;
                    cdns,tchsh-ns = <60>;
                    cdns,tslch-ns = <60>;
    -               cdns,read-delay = <4>;
    +               cdns,read-delay = <1>;
                    cdns,phy-mode;
                    cdns,phy-tx-start = <18>;
                    #address-cells = <1>;

    Please try changing it to 1 or even 2.

    Both worked for me.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    Thank you for the idea. However, it still doesn't solve my problem. The "read-delay" was set to <0> in the code as below.

    The read-delay <4>, <1>, and <2> were tried but the error message from the "sf probe" result at 100MHz ref_clk was same as below.

    Do you see any other clues for this issue? Thanks.

    Best Regards,

    Jeff

    • k3-j7200-som-p0.dtsi

    &ospi0 {
    pinctrl-names = "default";
    pinctrl-0 = <&mcu_fss0_ospi0_pins_default>;

    flash@0{
    compatible = "jedec,spi-nor";
    reg = <0x0>;
    spi-tx-bus-width = <8>;
    spi-rx-bus-width = <8>;
    spi-max-frequency = <50000000>; // 50000000
    cdns,tshsl-ns = <60>;
    cdns,tsd2d-ns = <60>;
    cdns,tchsh-ns = <60>;
    cdns,tslch-ns = <60>;
    cdns,read-delay = <0>;
    cdns,phy-mode;
    #address-cells = <1>;
    #size-cells = <1>;
    };

    • sf probe result

    # sf probe 0:0
    cadence_spi_ofdata_to_platdata: regbase=0000000047040000 ahbbase=0000000500000000 max-frequency=50000000 page-size=256 phy_mode=1
    cadence_qspi_apb_config_baudrate_div: ref_clk 100000000Hz sclk 50000000Hz Div 0x0, actual 50000000Hz
    cadence_spi_set_speed: speed=50000000
    cadence_qspi_apb_chipselect : chipselect 0 decode 0
    READ : Opcode : 0x9f, C.W 1, A.W 1, D.W 1
    cadence_qspi_apb_read_setup:
    Mode : CQSPI_STIG_READ
    Command Read : Opcode 0x9f
    CQSPI_REG_CONFIG : 0x00003881
    CQSPI_REG_RD_INSTR : 0x0000009F
    CQSPI_REG_WR_INSTR : 0x00000002
    CQSPI_REG_SIZE : 0x00101000
    CQSPI_REG_CMDCTRL : 0x9FD00000
    CQSPI_REG_CMDADDRESS : 0x00000000
    unrecognized JEDEC id bytes: ce, ad, 8c
    Failed to initialize SPI flash at 0:0 (error -2)

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points

    Jeff,

    Is this a custom board or EVM? If this is a custom board are you using the same OSPI part?

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    It is a customized board. The same OSPI part works well at 133MHz ref_clk.

    Best Regards,

    Keerthy

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points

    Jeff,

    At this point I do not have feedback on the difference in behavior on the custom board.

    However can you share the logs when it succeeds with 133M ref_clk?

    Jeff Kim27 said:
    unrecognized JEDEC id bytes: ce, ad, 8c

    In the above failure case the bytes read are ce, ad, 8c.

    I want to check what is read in the successful case. This is to see if there is a bit shift pattern or completely random bytes are being read.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    The successful read bytes at 133MHz ref_clk is 9d, 5b, 19. It seems the wrong bytes are one bit shifted pattern.

    Best Regards,

    Jeff

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points

    Jeff,

    This hints at read delay being not compatible. I am seeing that with changed read-delay the sf probe works on the evm.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    It's strange that the read-delay <0>, <4>, <1>, and <2> all didn't make a change in my experiment. Is it possible to print out the read-delay for debug purpose like I printed the ref_clk above?

    Best Regards,

    Jeff

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points

    U-Boot repo, file: drivers/spi/cadence_qspi.c

    Function: cadence_spi_ofdata_to_platdata

    You can try adding there.

    - Keerthy

  • 0 in reply to Keerthy J
    Intellectual 320 points

    Hi Keerthy,

    Thank you for the suggestion. I tried the read_delay changes from <0> to <4> with printing the debug message. The below picture is the example of delay <3>. The delay modifications were verified from it but the OSPI device still can't be recognized with the delay changes. 

    How is the spi-max-frequency? It was fixed at 50MHz no matter with the assigned-clock-rates. Do I need to change the spi-max-frequency as well when the assigned-clock-rates are changed with the phy_mode is enabled?

    Best Regards,

    Jeff

    delay3

  • 0 in reply to Jeff Kim27
    TI__Guru**** 162770 points
    Jeff Kim27 said:
    How is the spi-max-frequency? It was fixed at 50MHz no matter with the assigned-clock-rates. Do I need to change the spi-max-frequency as well when the assigned-clock-rates are changed with the phy_mode is enabled?

    Can you try changing that as well? Let me know if that helps. I believe it works will with 133M right? So it should not really impact.

    - Keerthy