• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 99 subscribers
  • Views 2440 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.

AM437x Starter Kit no warm reboot from QSPI

Ivan Chen
Prodigy 40 points

Hi everyone,

I'm using AM437x SK board with QSPI boot and trying to do warm reboot in the file system.

However, the SK board cannot boot up with QSPI, and the U-boot shows nothing after I warm reboot it

Is there anything I need to notice or I miss?

Thank you.

Ivan

  • 0
    TI__Guru**** 393215 points
    Hi,

    Please post Linux version and what command you use for rebooting.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 40 points
    Hi Biser,

    I use
    SDK: 02.00.02.11,
    Kernel: 4.1.18
    File system: arago-tisdk-base
    Command: reboot

    Thank you.
  • 0 in reply to Ivan Chen
    TI__Guru**** 393215 points
    I suppose that the QSPI is left by the kernel driver in a state that the ROM code cannot drive. I will ask the software team to check this.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 15510 points

    We're looking into this and will post here when we find something.

    Steve K.

  • 0 in reply to Steve Kipisz
    TI__Genius 14222 points
    Steve,

    we are having the same issue. On the AM437x SK we are finding that when running "reset" from u-boot commandline, then the QSPI boot works and u-boot from QSPI is coming up. (After 27 seconds).
    However when doing a kernel commandline "reboot" somehow the QSPI u-boot does not come up anymore. I was thinking "reset" and "reboot" should be the same type of reset, but I could be wrong.

    Regards,
    --Gunter
  • 0 in reply to Gunter Schmer
    TI__Guru* 86820 points
    Gunter, we checked this out on the SK and it looks like the kernel is leaving the QSPI in a bad state which doesn't allow the ROM to properly communicate with it after a warm reset. A workaround for now would be to comment out the following lines in the device tree to preclude the kernel from performing partitioning in the QSPI. I will follow up with our s/w team to get a more permanent fix.

    /* MTD partition table.
    * The ROM checks the first 512KiB
    * for a valid file to boot(XIP).
    */
    partition@0 {
    label = "QSPI.U_BOOT";
    reg = <0x00000000 0x000080000>;
    };
    partition@1 {
    label = "QSPI.U_BOOT.backup";
    reg = <0x00080000 0x00080000>;
    };
    partition@2 {
    label = "QSPI.U-BOOT-SPL_OS";
    reg = <0x00100000 0x00010000>;
    };
    partition@3 {
    label = "QSPI.U_BOOT_ENV";
    reg = <0x00110000 0x00010000>;
    };
    partition@4 {
    label = "QSPI.U-BOOT-ENV.backup";
    reg = <0x00120000 0x00010000>;
    };
    partition@5 {
    label = "QSPI.KERNEL";
    reg = <0x00130000 0x0800000>;
    };
    partition@6 {
    label = "QSPI.FILESYSTEM";
    reg = <0x00930000 0x36D0000>;
    };

    Regards,
    James
  • 0 in reply to JJD
    TI__Guru* 86820 points

    The issue has been found to be that the kernel sets the QSPI up in 4-byte address mode to be able to access larger QSPI devices, however, the ROM only communicates with the QSPI in 3-byte addressing mode.  A patch is in the works to have the kernel set the addressing mode back to 3-byte when it is finished using the QSPI.

    Regards,

    James

  • 0 in reply to JJD
    TI__Genius 14222 points

    James,

    thanks for the feedback and root cause analysis!

    In the meantime, the customer has tied the QSPI reset to the SOC reset and this works around the problem.

    Regards,

    --Gunter