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.

Should i modify source code when using different QSPI flash

Other Parts Discussed in Thread: J6EVM5777, DRA742

Hi, I am using Jacinto 6, GLSDK 7.04.03.

If we replace eMMC to "N25Q064A13E12H0F" on DRA742-EVM 577G-02-21-00 board, should i modify any code?

As i see in dra7-evm.dts file, there are description about QSPI like below

&qspi {           

status = "okay";

 spi-max-frequency = <64000000>;
 m25p80@0 {
  compatible = "s25fl256s1";
  spi-max-frequency = <64000000>;

the value of compatible is the original QSPI flash, so i think i should modify here, am i right?

besides, is there any place should i modify too?

  • Hi Pavel,

    After finish dinner, the system log stop, here is the rest log=>

    rx cmd 00390fff dc 00000000
    rx done, status 05a90002, read 00
    rx cmd 00390fff dc 00000000
    rx done, status 05aa0002, read 00
    rx cmd 00390fff dc 00000000
    rx done, status 05ab0002, read 00
    rx cmd 00390fff dc 00000000
    rx done, status 05ac0002, read 00
    rx cmd 00390fff dc 00000000
    rx done, status 05ad0002, read 00
    spi_cs_deactivate: 0x81280008
    spi_release_bus: bus:0 cs:0
    Jumping to U-Boot
    image entry point: 0x80800000
       

    Regards,

    Shawn

  • Hi Shawn,

    I see in your log you have:

    "spl: payload image: U-Bo load addr: 0x807fffc0 size: 488872"

    What is the size of your u-boot.img? Does it match with this size 488872?

    At some point (at line 8574) the QSPI module start reading only 00 from the Flash, I suspect this is the problem here. Can you make a hex dump of your QSPI u-boot.img and compare it with a hex dump of SD card u-boot.img? I suspect something in your u-boot.img in QSPI flash is not correct.

    Can you also boot in debug mode (enable debug) from QSPI flash some of the boards that are able to boot up successful (TI EVM or 1GB board). I want to compare this boot log with some boot log of a working board (in QSPI boot mode).

    Regards,
    Pavel
  • You can also run some memory test to verify the DDR3 memory is correct:

    u-boot/doc/README.memory-test
    u-boot/common/memsize.c
  • Hi Pavel,

    Pavel Botev said:
    What is the size of your u-boot.img? Does it match with this size 488872?

    My u-boot.img size is 488.9 kB, it should match the 488872.

    Pavel Botev said:
    I suspect something in your u-boot.img in QSPI flash is not correct.

    Yes, you're righ. After i dump QSPI flash content, i found everything is fine before address 0xFF8, after that, the content of address 0xFF8 is 0, and contents between 0xFF9 ~ 0xFFB is fine, but after 0xFFB, the rest contents are all 0.

    Then i try to erase flash, after that the address i mention before(0xFF8, 0xFFC~) is still with content 0. The partial log =>QSPI_content.txt   

    I try different sector(the area of MLO & u-boot.img), both the same situation, only address before 0xFF8 is fine. Could it be some config error for this QSPI flash?

    P.S. The flash in our custom board is STMicro MT25QL128(But after "sf probe", system recognize it as N25Q128 flash, maybe they share the same ID)

    Regards,

    Shawn

  • Hi Pavel,

    Update current status.
    As discuss before, i found the flash data are full of 0 at some section(after address 0xFFB).
    So, i try to read flash data inside the mtd driver. I read through "spi_flash_read_common()" function, which located at sf_ops.c
    The data are just what i wrote to flash(not 0).
    Based on this result, i think "write & erase" operation is fine, but something wrong with "read" operation. That's why QSPI boot will fail, because system read wrong data.
    Do you have any suggestion for me to try?

    P.S. Currently, i disable "CONFIG_TI_SPI_MMAP". Because without disable it, the data i read from flash will abnormal.(content will have lots of 0xCC or 0xCD).

    Regards,
    Shawn
  • shawn lin said:
    As discuss before, i found the flash data are full of 0 at some section(after address 0xFFB).

    shawn lin said:
    P.S. Currently, i disable "CONFIG_TI_SPI_MMAP". Because without disable it, the data i read from flash will abnormal.(content will have lots of 0xCC or 0xCD).

    I think you hit the below QSPI IP limitation:

    http://processors.wiki.ti.com/index.php/Linux_Core_QSPI_User's_Guide#Limitations

    QSPI IP is designed in such a way that after 4096 word transfer, chip select automatically gets de asserted. As a result of which, the entire flash cannot be read in a single chip select using (Single/Dual/Quad) bit read mode feature. While the serial flash linux framework and flash specification expects the entire read to happen with a single read command in a single chip select. This limitation is not applicable when QSPI is used in memory mapped mode for reads. The QSPI driver by default uses memory mapped reads.


    I would suggest you to switch to MMAP mode, and debug why data is abnormal.

    Another approach is to try flash the QSPI from user space (not from u-boot), thus you will not have to use "sf read" u-boot command.

    You can also test if your QSPI flash hardware design is correct. For that purpose you can boot from MMC/SD card and use mtd-utils and/or dd commands as explained in the below wiki:

    http://processors.wiki.ti.com/index.php/Linux_Core_QSPI_User's_Guide#Testing

    Regards,
    Pavel

  • Hi Pavel,

    Pavel Botev said:
    I would suggest you to switch to MMAP mode, and debug why data is abnormal.

    I already enable MMAP at our two custom board(one is use S25FL256, another is use MT25QL128). I try to erase flash with length 0x10000, then read the content. It works fine at S25FL256, but fail at MT25QL128.

    Here are the test log for S25FL256=>QSPI_S25F.txt    ,and MT25QL128=>QSPI_MT25QL128.txt   

    Pavel Botev said:
    Another approach is to try flash the QSPI from user space (not from u-boot), thus you will not have to use "sf read" u-boot command.

    I also try it, but fail too. Flash data into QSPI is fine at u-boot with "sf write" command is ok, but the problem should be "read". If i try to use QSPI BOOT, then i should try to fix "sf read" problem.

    The test result for S25FL256 & MT25QL128 is different, so is it possible the problem is because the command format exist difference?(ex. command ID, number of dummy bytes...etc.)

    Regards,

    Shawn

  • shawn lin said:

    I already enable MMAP at our two custom board(one is use S25FL256, another is use MT25QL128). I try to erase flash with length 0x10000, then read the content. It works fine at S25FL256, but fail at MT25QL128.

    Here are the test log for S25FL256=>(Please visit the site to view this file)    ,and MT25QL128=>(Please visit the site to view this file)   

    May be you have a HW issue. On your MT25QL128 custom board, can you try to replace MT25QL128 flash with S25FL256 flash and check if that board will start to work fine?

    Can you also check what will be the result (for both S25FL256 and MT25QL128) when CONFIG_TI_EDMA is disabled in u-boot?

    Also you can compare your u-boot with the latest QSPI u-boot driver to see if some new features related to Micron QSPI quad read are implemented.


    {PSDKLA 3.02}/board-support/u-boot-2016.05/drivers/spi/ti_qspi.c

    shawn lin said:
    The test result for S25FL256 & MT25QL128 is different, so is it possible the problem is because the command format exist difference?(ex. command ID, number of dummy bytes...etc.)

    Did you port MT25QL128 in linux kernel before trying the test? Can you share the test log?

    S25FL256 and MT25QL128 are non-TI parts. For full difference you should compare the datasheets. You can also check with Micron (MT25QL128 supplier) if their QSPI flash support quad read in u-boot-2014.07

    Regards,
    Pavel

  • Hi Pavel,

    After i compare the datasheet of both S25FL256 & MT25QL127, i found some setting should be modify in ti_qspi.c in order to let quad read successfully.
    Now, i can boot from qspi(MT25QL127). Thanks for your great help.

    Regards,
    Shawn
  • Hi Pavel,

    Recently, we update our BSP version from 7.04.00.03 to 3.02.00.03.
    Originally, i fix the problem of "sf read" at u-boot phase, but now, sf read fail again under new BSP version.
    I already put my solution at new BSP version, but the data read back from flash still incorrect.
    Last time i solve "sf read" problem is to modify u-boot/drivers/spi/ti-qspi.c (i modify QSPI_CMD_READ_QUAD and QSPI_SETUP0_NUM_A_BYTES define value because they are different between Spansion & STMicro)

    Is there any place i should pay attention for new BSP version with QSPI function?

    Regards,
    Shawn
  • Shawn,

    I see you have open new e2e thread regarding the new issue. The new issue will be addressed on that new e2e thread.

    e2e.ti.com/.../619953

    Regards,
    Pavel
  • Hi Pavel,

    ok, thanks

    Regards,

    Shawn