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

AM5716: QSPI boot issue

Oleg Semyonov
Intellectual 360 points

Part Number: AM5716
Other Parts Discussed in Thread: AM5728

We are making a custom board using AM5716 processor. The board has QSPI NOR memory we are going to boot from.

We build a firmware including U-Boot using Yocto system with the official "meta-ti" layer. u-boot recipe uses repository "git://git.ti.com/ti-u-boot/ti-u-boot.git" and branch "ti-u-boot-2019.01". Using it, we can successfully boot the board from SD card. But there are issues booting from QSPI.

SPL is loaded by ROM code and shows a banner, but it hangs trying to load u-boot.img. Checking the data it loads from QSPI flash, we found that it loads some garbage. At the same time the U-Boot loaded from SD card can access QSPI flash memory using sf command (sf probe, sf read, sf write). The SPL was written to QSPI with it, and ROM loader boots it.

The file "/doc/SPI/README.ti_qspi_dra_test" in the u-boot repository mentions that QSPI memory is mapped at 5c000000 ("SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000"). But the code in this branch has nothing common with that example (the source does not have code to print "mapped at", and flash data structure also does not have such field). Trying to dump memory at address 5c000000 using U-Boot md command shows us the same garbage which SPL loads instead of u-boot.img payload. The assumption is that SPL tries to load data from mapped memory which, in fact, was not mapped at all. In contrary, the sf command uses driver to access SPI flash, and it works.

At the same time the U-Boot branch used in TI processor SDK is "ti-u-boot-2018.01", but it has significally changed flash code, and it includes QSPI memory mapping.

So my questions are:
1) How it is possible, that (presumably) latest u-boot branch has README which promises memory mapped QSPI, but the code does not map it?
2) Why the officially supported "meta-ti" layer in Yocto repository has non-actual u-boot code which has issues booting from QSPI?
3) What u-boot version should we actually use? What branch is the latest: 2018.01 which maps memory or 2019.01 which is in "meta-ti" layer?
4) Any reason that there are two unrelated u-boot branches which have different features?
5) Any possible reasons why SPL may be unable to load code from QSPI flash while the main U-Boot code built at the same time has no issues accessing the same flash with sf command?

PS. Answering in advance: we do not use tisdk repository because we need gcc 8.3 for our applications (some C++17 features). Attempt to update the tisdk compiler requires too many changes, while the Yocto project with meta-ti layer has no issues building gcc 8.3 for the whole system. Besides, instead of removing lots from tisdk repo, we prefer to add only required features to a minimal Yocto image. Finally, it was said that "meta-ti" layer is officially supported by TI. So why not?

  • 0
    Intellectual 360 points

    I tried to compare my U-Boot with the supplied with AM5728 IDK one running on AM5728 IDK. They have the same behavior related to SPI flash:

    => sf probe
    SF: Detected S25FL256S_64K with page size 256 Bytes, erase size 64 KiB, total 32 MiB, mapped at 5c000000
    => sf read 82000000 0 100
    device 0 offset 0x0, size 0x100
    SF: 256 bytes @ 0x0 Read: OK
    => md 82000000 10
    82000000: ffffffff ffffffff ffffffff ffffffff    ................
    82000010: ffffffff ffffffff ffffffff ffffffff    ................
    82000020: ffffffff ffffffff ffffffff ffffffff    ................
    82000030: ffffffff ffffffff ffffffff ffffffff    ................
    => md 5c000000 10
    5c000000: 4f400000 4f400000 4f400000 4f400000    ..@O..@O..@O..@O
    5c000010: 00000008 00000008 00000008 00000008    ................
    5c000020: 00000003 00000000 00000000 00000000    ................
    5c000030: 00000000 00000000 00000000 00000000    ................
    => ver

    U-Boot 2016.05-g2f757e5b2c (Oct 03 2016 - 19:16:30 -0400)
    arm-linux-gnueabihf-gcc (Linaro GCC 5.3-2016.02) 5.3.1 20160113
    GNU ld (GNU Binutils) 2.25.0 Linaro 2015_10

    It does not look like the flash is mapped at 5c000000. Should it be ffffffff read from there?

  • 0 in reply to Oleg Semyonov
    Intellectual 360 points

    I finally solved the issue with QSPI boot. I had to enable CONFIG_SPL_REGMAP and CONFIG_SPL_SYSCON in U-Boot configuration.

    But the question about read-only memory mapping of QSPI flash still valid.

  • 0 in reply to Oleg Semyonov
    TI__Mastermind 45015 points

    Hello,

    With regards to the memory mapping, I am internally checking with our experts and I will keep you posted.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    TI__Mastermind 45015 points

    Hello,

    Based on my testing, the memory mapping is correct but you cannot just use md command to read the contents of the flash device. Please use the "sf read" command to read  "x" bytes from the flash into memory.

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 360 points

    Well, can you tell me then, how to verify qspi flash memory mapping from U-Boot?

    AFAIK, if it is mapped for read-only to address 0x5c000000, I shoud read the flash content with any read access to that memory range.

    md 5c000000 does not work.

    cp 5c000000 82000000 100; md 82000000 also does not work.

    So is it mapped at all, if any access does not return flash data? How to verify it? I understand that "sf read" command always works. But what is then the "mapped at" if the data can't be read from that memory address? It is not actually a problem for me, but I wonder how to verify that it really is mapped?

  • 0 in reply to Oleg Semyonov
    TI__Mastermind 45015 points

    Hello,

    Please refer to the following thread. By default, Uboot is in config mode and it explains why md 5c000000 does not work. Here is an alternative way to verify the data written inside the flash:
    1. mw 81000000 0xdededede 0x40000
    2. sf write 81000000 0 0x40000
    3. sf read 82000000 0 0x40000
    4. cmp.b 81000000 82000000 0x40000 (Result = Total of 262144 byte(s) were the same)

    Regards,
    Krunal

  • 0 in reply to Krunal Bhargav34
    Intellectual 360 points

    Hi,

    the steps you wrote do use the "sf" commands, there is nothing wrong with it. And I have no issues using "sf" to read/write flash, and ROM loader to boot from it.

    The question was: even if U-Boot uses config mode to read/write QSPI via "sf" command, what does mean "mapped at"?

    For me, using "cp <QSPI mapped address> <SDRAM address> length" should make a copy of QSPI flash to RAM since the QSPI is mapped for reading. U-Boot's "cp" is flash-aware, so it should understand that some address is in flash, and use proper method to read/write it. It works in both directions for parallel NOR flash mapped at 08000000. But since it does not work for "cp" from QSPI, it may mean that U-Boot "thinks" that the memory is mapped, and just does memcpy(), but there is no real mapping, and thus no QSPI data is copied.

    Please, feel free to close this thread if desired. The main question of booting was resolved. But I still do not understand why mapped GPMC/NOR works (can be read/write with "cp"), but mapped QSPI can't be read with the same "cp". I think that "sf read/write" must work in any case (using config mode and QSPI commands), but "cp" should also read QSPI content if it is mapped at address space.