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.

PROCESSOR-SDK-DRA8X-TDA4X: MT35XU01G spi flash with u-boot issue

Part Number: PROCESSOR-SDK-DRA8X-TDA4X

Hi TI members:

Our customer board have one SPI flash MT35XU01G,

  • In Linux 07_00 version, we can directly add one new spi device in drivers/mtd/spi/spi-nor-ids.c, just follow EVM's ospi device mt35xu512aba config.

like below code:

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 2facd8de9a..59fcb388be 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -244,6 +244,13 @@ const struct flash_info spi_nor_ids[] = {
                        .change_mode = spi_nor_micron_set_octal_ddr_mode,
                        .adjust_op = spi_nor_micron_adjust_op
        },
+       {
+               INFO("mt35xu01g", 0x2c5b1b, 0, 128 * 1024, 1024, 
+                       SECT_4K | USE_FSR | SPI_NOR_OPI_DTR |
+                       SPI_NOR_4B_OPCODES)
+                       .change_mode = spi_nor_micron_set_octal_ddr_mode,
+                       .adjust_op = spi_nor_micron_adjust_op
+       },
        { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | SPI_NOR_4B_OPCODES) },

Then we can normal boot form ospi flash mt35xu01g.

  • But in Linux 07_01 version, I follow the same rule to add a new spi device, like below code:
sdc@sdc:~/opt/V3GA_07_01/psdkla/sources/u-boot-ti-staging$ git diff
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index b4066901a4..b1dd1942e6 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -3338,6 +3338,8 @@ void spi_nor_set_fixups(struct spi_nor *nor)
        if (!strcmp(nor->info->name, "mt35xu512aba"))
                nor->fixups = &mt35xu512aba_fixups;
 #endif
+       if (!strcmp(nor->info->name, "mt35xu01g"))
+               nor->fixups = &mt35xu512aba_fixups;
 }

 int spi_nor_scan(struct spi_nor *nor)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 7365fb0a56..19fc19af85 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -185,7 +185,7 @@ const struct flash_info spi_nor_ids[] = {
 #ifdef CONFIG_SPI_FLASH_MT35XU
        { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ) },
 #endif /* CONFIG_SPI_FLASH_MT35XU */
+       { INFO("mt35xu01g", 0x2c5b1b, 0,  128 * 1024,  1024, USE_FSR | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_READ | SPI_NOR_OCTAL_DTR_READ ) },
        { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | SPI_NOR_4B_OPCODES) },
 #endif

But after test, this modify will cause ospi-boot failed. The fail log as below

U-Boot SPL 2020.01-g3c9ebdb87d (Jan 18 2021 - 03:38:30 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0014 '20.8.5--v2020.08b (Terrific Lla')
Reading on-board EEPROM at 0x50 failed 1
Trying to boot from SPI
ti_sci_get_response: Message receive failed. ret = -110
Mbox send fail -110
ti_sci_get_response: Message receive failed. ret = -110
Mbox send fail -110
  • If we only add one new ospi device as below patch in 07_01, 
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 7365fb0a56..996f8d766e 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -185,7 +185,7 @@ const struct flash_info spi_nor_ids[] = {
 #ifdef CONFIG_SPI_FLASH_MT35XU
        { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_DTR_READ) },
 #endif /* CONFIG_SPI_FLASH_MT35XU */
+       { INFO("mt35xu01g", 0x2c5b1b, 0,  128 * 1024,  1024, USE_FSR | SPI_NOR_4B_OPCODES) },
        { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | SPI_NOR_4B_OPCODES) },
 #endif
 #ifdef CONFIG_SPI_FLASH_SPANSION       /* SPANSION */

then we can boot successfully to kernel, but there are some error message in u-boot log, like "WARN: PHY calibration failed: -2" 

U-Boot SPL 2020.01-g3c9ebdb87d (Jan 18 2021 - 06:24:20 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0014 '20.8.5--v2020.08b (Terrific Lla')
Reading on-board EEPROM at 0x50 failed 1
Trying to boot from SPI
WARN: PHY calibration failed: -2
Loading Environment from MMC... *** Warning - No MMC card found, using default environment

Starting ATF on ARM64 core...

NOTICE:  BL31: v2.3():07.01.00.006-dirty
NOTICE:  BL31: Built : 12:30:55, Dec 25 2020

U-Boot SPL 2020.01-g3c9ebdb87d (Jan 18 2021 - 06:25:50 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0014 '20.8.5--v2020.08b (Terrific Lla')
Reading on-board EEPROM at 0x50 failed 1
Trying to boot from SPI
WARN: PHY calibration failed: -2


U-Boot 2020.01-g3c9ebdb87d (Jan 18 2021 - 06:25:50 +0000)

SoC:   J721E SR1.0
Model: Texas Instruments K3 J721E SoC
Reading on-board EEPROM at 0x50 failed 1
Board: J721EX-PM1-SOM rev E2
DRAM:  4 GiB
not found for dev hbmc-mux
Flash: 0 Bytes
MMC:   sdhci@4f80000: 0
Loading Environment from MMC... OK
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Reading on-board EEPROM at 0x50 failed 1
Net:   Could not get PHY for ethernet@46000000: addr 0
phy_connect() failed
No ethernet found.

Hit any key to stop autoboot:  0
=>
=>
=>

and sometimes after I flash new u-boot files finish, I want to reset u-boot.

It will also meet fail message " ti_sci_get_response: Message receive failed. ret = -110, Mbox send fail -110", and can't reboot device.

Does anyone can help us to debug this situation?

BR

Sentinen Chen

  • Hi Sentinen,

    WARN: PHY calibration failed: -2

    If you check the SDK u-boot OSPI documentation: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/07_01_00_10/exports/docs/linux/Foundational_Components_U-Boot.html#ospi-qspi

    This typically means that PHY calibration pattern is not flashed and OSPI is working at lower frequency(25MHz).

    Below commands can be used to flash the PHY pattern, with the location of the pattern depending on which flash is being used:

    => sf probe
    => tftp ${loadaddr} pattern_file
    => sf update $loadaddr 0x3fe0000 $filesize

    Best Regards,
    Keerthy

  • Hi Keerthy:

    • Below commands can be used to flash the PHY pattern
      ==> I search the source code on u-boot-ti-staging folder, but I didn't find related PHY pattern files. 
             Do you know where we can get the related pattern file for MT35XU01G?
    • Is the error message "ti_sci_get_response: Message receive failed. ret = -110, Mbox send fail -110"  also caused by OSPI is working at lower frequency(25MHz)???

    BR

    Sentinen Chen

  • Hi Sentinen Chen,

    I am checking on this. I will get back to you in couple of days.

    Best Regards,
    Keerthy

  • Sentinen.Chen said:
    •        Do you know where we can get the related pattern file for MT35XU01G?

    Attaching the pattern file here: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/pattern_5F00_file

    Sentinen.Chen said:
    Is the error message "ti_sci_get_response: Message receive failed. ret = -110, Mbox send fail -110"  also caused by OSPI is working at lower frequency(25MHz)???

    I am not quite sure of the above. Do you always get that?

    - Keerthy

  • Hi Keerthy:

    • Attaching the pattern file here: pattern_file
      =
      =>  Thanks, I will try this first.
    • I am not quite sure of the above. Do you always get that?
      ==> Yes, recently I find every time after I flash rootfs into EMMC finish and try to reset u-boot,
              then I will meet this error message, and reboot function will stuck. 

    BR

    Sentinen Chen

  • Hi Keerthy:

    Update the test result to you.

    As the document describle " the PHY calibration pattern must be flashed to OSPI at the start of the last erase sector." 

    So I would flash the pattern file to our MT35XU01G last sector

    I use below steps to flash phy pattern file to ospi

    ---- U-boot on board  ----
    => sf probe
    => usb start
    => setenv dfu_alt_info_ospi 'tiboot3.bin raw 0x0 0x080000;tispl.bin raw 0x080000 0x200000;u-boot.img raw 0x280000 0x400000;u-boot-env raw 0x680000 0x020000;sysfw.itb raw 0x6c0000 0x100000;rootfs raw 0x800000 0x3800000;phypattern raw 0x7FE0000 0x20000'
    => saveenv
    => setenv dfu_alt_info ${dfu_alt_info_ospi }
    => dfu 0 sf "0:0:64000000:0"
    
    
    ---- PC side ----
    > dfu-util.exe -c 1 -i 0 -a 6 pattern_file

    I can see flash OK message 

    #DOWNLOAD ... OK
    Ctrl+C to exit ...

    But after I reboot the board, I still get the calibration failed message

    U-Boot SPL 2020.01-g3c9ebdb87d (Jan 22 2021 - 01:51:49 +0000)
    SYSFW ABI: 3.1 (firmware rev 0x0014 '20.8.5--v2020.08b (Terrific Lla')
    Reading on-board EEPROM at 0x50 failed 1
    Trying to boot from SPI
    WARN: PHY calibration failed: -2
    Loading Environment from MMC... *** Warning - No MMC card found, using default environment
    
    Starting ATF on ARM64 core...
    
    NOTICE:  BL31: v2.3():07.01.00.006-dirty
    NOTICE:  BL31: Built : 12:30:55, Dec 25 2020
    
    U-Boot SPL 2020.01-g3c9ebdb87d (Jan 22 2021 - 01:29:14 +0000)
    SYSFW ABI: 3.1 (firmware rev 0x0014 '20.8.5--v2020.08b (Terrific Lla')
    Reading on-board EEPROM at 0x50 failed 1
    Trying to boot from SPI
    WARN: PHY calibration failed: -2

    Does I miss any modify? 

    PS:
    I also try the below dfu_alt_info_ospi config "tiboot3.bin raw 0x0 0x080000;tispl.bin raw 0x080000 0x200000;u-boot.img raw 0x280000 0x400000;u-boot-env raw 0x680000 0x020000;sysfw.itb raw 0x6c0000 0x100000;rootfs raw 0x800000 0x37E0000;phypattern raw 0x3FE0000 0x4020000",
    but it also failed.

    BR

    Sentinen Chen

    :ㄆ

  • Hi Sentinen,

    diff --git a/arch/arm/dts/k3-j721e-som-p0.dtsi b/arch/arm/dts/k3-j721e-som-p0.dtsi
    index e143c7b5b4..8320d04037 100644
    --- a/arch/arm/dts/k3-j721e-som-p0.dtsi
    +++ b/arch/arm/dts/k3-j721e-som-p0.dtsi
    @@ -99,7 +99,7 @@
             partition@3fe0000 {
                 u-boot,dm-spl;
                 label = "ospi.phypattern";
    -            reg = <0x3fe0000 0x20000>;
    +            reg = <0x7fe0000 0x20000>;
             };
         };
     };

    This is a limitation with the current driver. It can only use the PHY pattern location hard coded from the device tree. So it is checking at 0x3fe0000 which is last sector for 512 Mb flash. You are flashing at 0x7fe0000 (which is correct). So need to update DT as above.
    Best Regards,
    Keerthy
  • Hi Keerthy:

    I try this patch, but the PHY calibration is still failed. 

    So I try to dump failed log, 

    I find it already failed at the first "cadence_spi_find_rx_low" function when phy calibration step start.

    So I try to dump the rx read data, like below modify

            ret = spi_mem_exec_op(spi, &op);
    -       if (ret)
    +       if (ret) {
    +               printf("%s[%d], V3GA Print\n", __func__, __LINE__);
                    goto out;
    +       }
    +
    +       printf("%s[%d], V3GA Print 0x%x\n", __func__, __LINE__, read_data);
    
            if (memcmp(read_data, phy_tuning_pattern,
                       ARRAY_SIZE(phy_tuning_pattern))) {
    +               printf("%s[%d], V3GA Print\n", __func__, __LINE__);
                    ret = -EAGAIN;
                    goto out;
    

    follow the log, it seem the read_data all can't map to phy_tuning_pattern, so the calibration still get failed result.

    The pattern should as (this define in drivers/spi/cadence_qspi.c)

       static const u8 phy_tuning_pattern[] = {
       0xFE, 0xFF, 0x01, 0x01, 0x01, 0x01, 0x01, 0x00, 0x00, 0xFE, 0xFE, 0x01, 0x01,
       0x01, 0x01, 0x00, 0x00, 0xFE, 0xFE, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00,
       0x00, 0xFE, 0xFE, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0xFE, 0xFE, 0xFF, 0x01,
       0x01, 0x01, 0x01, 0x01, 0xFE, 0x00, 0xFE, 0xFE, 0x01, 0x01, 0x01, 0x01, 0xFE,
       0x00, 0xFE, 0xFE, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFE, 0x00, 0xFE, 0xFE,
       0xFF, 0xFF, 0xFF, 0xFF, 0xFE, 0x00, 0xFE, 0xFE, 0xFF, 0x01, 0x01, 0x01, 0x01,
       0x01, 0x00, 0xFE, 0xFE, 0xFE, 0x01, 0x01, 0x01, 0x01, 0x00, 0xFE, 0xFE, 0xFE,
       0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0xFE, 0xFE, 0xFE, 0xFF, 0xFF, 0xFF,
       0xFF, 0x00, 0xFE, 0xFE, 0xFE, 0xFF, 0x01, 0x01, 0x01, 0x01, 0x01, 0xFE, 0xFE,
       0xFE, 0xFE, 0x01, 0x01, 0x01, 0x01, 0xFE, 0xFE, 0xFE, 0xFE, 0x01,
       };

    but the read data I dump is always 0x81f0xxxx

    cadence_spi_find_rx_low[138], V3GA Print
    cadence_spi_phy_check_pattern[113], V3GA Print 0x81f006c0
    cadence_spi_phy_check_pattern[117], V3GA Print
    cadence_spi_find_rx_low[138], V3GA Print
    cadence_spi_phy_check_pattern[113], V3GA Print 0x81f00740
    cadence_spi_phy_check_pattern[117], V3GA Print
    cadence_spi_find_rx_low[138], V3GA Print
    cadence_spi_phy_check_pattern[113], V3GA Print 0x81f007c0
    cadence_spi_phy_check_pattern[117], V3GA Print
    cadence_spi_find_rx_low[138], V3GA Print
    cadence_spi_phy_check_pattern[113], V3GA Print 0x81f00840
    cadence_spi_phy_check_pattern[117], V3GA Print
    cadence_spi_find_rx_low[138], V3GA Print
    cadence_spi_phy_check_pattern[113], V3GA Print 0x81f008c0
    cadence_spi_phy_check_pattern[117], V3GA Print
    cadence_spi_find_rx_low[138], V3GA Print
    cadence_spi_phy_check_pattern[113], V3GA Print 0x81f00940
    cadence_spi_phy_check_pattern[117], V3GA Print

    Do you have any idea about this situation? 

    BR

    Sentinen Chen

  • Hi,

    I will check with our expert & get back on this.

    Regards,
    Keerthy

  • Hi,

    Try verifying if the PHY pattern is actually present on the flash or not. This can be done by going to U-Boot prompt and running:

    sf probe
    sf read 0x92000000 0x7fe0000 0x100
    md.b 0x92000000 0x100


    Best Regards,

    Keerthy

  • Hi Keerthy:

    It seem the data on OSPI flash is OK. 

    Please see below compare picture

    BR

    Sentinen Chen

  • Hi Sentinen,

    The pattern file shared is 128 bytes. Here is the snapshot.

    Also OSPI boot is broken on 7.1 & internal teams are working on fixing it.
    DMA is not functional on SPL and hence you will be seeing mbox time out.

    So OSPI Boot needs to wait for fix on 7.1. 

    Release notes: https://software-dl.ti.com/jacinto7/esd/processor-sdk-linux-jacinto7/07_02_00_07/exports/docs/devices/J7/linux/Release_Specific_Release_Notes.html

    2.1.6.5. U-Boot Known Issues

    Record ID

    Summary

    Workaround

    LCPD-19636

    J7: HS: OSPI Boot broken

    This should ideally be fixed in the next release. Hope we can close this thread.

    Best Regards,
    Keerthy