• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1342 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 QSPI boot issue

Gunter Schmer
Genius 14382 points

Hi,

a customer is using the following QSPI partitioning

[    1.945132] 0x000000000000-0x000000080000 : "QSPI.U-BOOT"

[    1.951440] 0x000000080000-0x000000100000 : "QSPI.U-BOOT-backup"

[    1.958278] 0x000000100000-0x000000110000 : "QSPI.U-BOOT-env"

[    1.964784] 0x000000110000-0x000000120000 : "QSPI.FDT"

[    1.970577] 0x000000120000-0x000000920000 : "QSPI.KERNEL-zImage"

[    1.977324] 0x000000920000-0x000004000000 : "QSPI.FILESYSTEM"

 

actual u-boot.bin is approx. 0x50000 bytes so well within the 0x80000 range.

The issue we are running into is that if the u-boot.bin at 0x0 to 0x80000 is erased and the backup u-boot.bin is loaded at 0x80000, the Bootrom somehow hangs and does not move to the next boot source (here eMMC). However if the backup u-boot.bin at 0x80000 is erased (assuming the first u-boot.bin at 0x0 is already erased), the Bootrom correctly moves to the next boot source and boots from eMMC.

Is there a detail in the Bootrom QSPI mode that does not allow anything to be at 0x80000?

Are there any other restrictions with Bootrom QSPI boot mode with regard to other locations?

And a general question would be whether the Bootrom QSPI mode can support something like a fall back u-boot.bin, in case the first u-boot.bin at 0x0 does not boot.

Thanks,

--Gunter

  • 0
    TI__Guru**** 393215 points
    Hi,

    Have you checked processors.wiki.ti.com/.../Linux_Core_U-Boot_User's_Guide There is a section there dedicated to QSPI. Unfortunately the wiki is not online at the moment, so I cannot give you more details.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 14382 points

    Biser,

    yes we have looked at that document, but the issue is a particular behavior of the Bootrom that is observed, and we would need someone to comment on that:

    "The issue we are running into is that if the u-boot.bin at 0x0 to 0x80000 is erased and the backup u-boot.bin is loaded at 0x80000, the Bootrom somehow hangs and does not move to the next boot source (here eMMC). However if the backup u-boot.bin at 0x80000 is erased (assuming the first u-boot.bin at 0x0 is already erased), the Bootrom correctly moves to the next boot source and boots from eMMC"

    Regards,

    --Gunter

  • 0 in reply to Gunter Schmer
    TI__Guru**** 393215 points
    I have asked the factory team to help on this. They will respond here.
  • 0 in reply to Biser Gatchev-XID
    TI__Genius 15510 points

    I think I might know what is happening, but have not tested my theory. I looked at the latest Processor SDK 03.01.00.06 at u-boot. in the configs/am43xx_evm_qspiboot_defconfig you'll find this line

    CONFIG_ISW_ENTRY_ADDR=0x30000000

    So u-boot.bin is built to execute from that address. My theory is that if you flashed that same image to 0x30080000 and erase the image at 0x30000000, the boot ROM will not detect u-boot at 0x30000000 and jump to the image at 0x30080000, which is built to run from 0x30000000. Can you modify that line so that you build u-boot to start at 0x30080000

    CONFIG_ISW_ENTRY_ADDR=0x30080000

    Flash that image to 0x30080000, and erase the image at 0x30000000 and see what happens.

    Steve K.