• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 1257 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.

AM57xx sysboot

Michi Yama
Guru 10030 points

Hi,

I would like to know regarding the sysboot of AM572x.


The below is the TRM of AM57xx.

***********

33.2.4.3 QSPI Redundant SBL Images Offset

Four options are available to set the offset between the redundant SBL images as described in Table 33-

7. If not using the redundant SBL feature, there is no change required to sysboot pins as only the primary

image is used and the sector offset is a don't care.

*********

In the above,  it is written "there is no change required". In this case, how do I set the state of the data bus when sysbooting?

Also I can't find the description regarding "redundant SBL feature" in TRM.  Is there any registers for confirmation whether this feature is used?

Please advise me.


I appreciate your quick reply.

 

Best regards,

Michi

 

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the AM57X team for clarification.
  • 0
    TI__Guru**** 161600 points
    Hi Michi,

    AM572x devices support redundant SBL SD(RAW mode)/SATA NAND & QSPI boot. It is NOT supported for XIP boot.
    QSPI sector size is configured by sysboot 7:6.

    QSPI boot is configured by setting the sysboot as described in Table 33-8. Booting Devices Order in AM572x TRM.

    The following docs may shed some light on MLO copies:
    processors.wiki.ti.com/.../RBL_UBL_and_host_program
    www.ti.com/.../spruhj3.pdf

    This is all the publicly available information that I know of.

    Hope this helps.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Guru 10030 points
    Dear Yordan-san,

    Thank you for your reply.

    I have two questions.
    1) If it is not used the redundant SBL feature, sysboot setting doesn't matter? pull-up/pull-down/floating , everything OK?
    2) Are there any registers to confirm redundant SBL feature setting in AM57xx?

    Please advise me.

    I appreciate your quick reply.

    Best regards,
    Michi
  • 0 in reply to Michi Yama
    TI__Guru**** 161600 points

    Hi Michi,

    Michi Yama said:
    1) If it is not used the redundant SBL feature, sysboot setting doesn't matter? pull-up/pull-down/floating , everything OK?

     

    Correct the value of the sysboots, if redundant SBL feature is not used, is DON'T CARE. They can be either on or off. However, note that you MUST NOT leave the sysboot pins floating.  

    Michi Yama said:
    2) Are there any registers to confirm redundant SBL feature setting in AM57xx?

     

    No, there aren't hw registers to confirm the use of redundant SBL image. This information should be in the boot image itself, my guess is its configuration header. Have a look at the ti_armv7_common.h, ti_omap5_common.h & boards.cfg in u-boot source. 

    Best Regards, 
    Yordan

  • 0 in reply to Yordan Kovachev
    TI__Guru**** 161600 points
    BTW, I've contacted the rom code designer to correct/confirm my understanding. Feedback will be posted here.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    TI__Guru**** 161600 points

    Hi Michi,

    Have a look at the following statement in TRM Section 33.3.7.1 Overview:

    "A booting image is considered to be present on a GP device, when the first 4 bytes word of the sector is not equal to 0000 0000h or FFFF FFFFh.

    During the first read sector (512 bytes) call, sectors are copied to a temporary device on-chip SRAM buffer. Once the image is found and the destination address is known, the content of the temporary buffer is moved to the target device on-chip SRAM location so it is required to reread the first image sector. For a GP device, the GP header is not copied into target buffer location; therefore, only executable code is in device on-chip RAM, with the first executable instruction at the destination address.
    SATA, eMMC, SD cards, SPI/QSPI and NAND devices can hold up to four copies of the booting image. Therefore, the ROM code searches for one valid image out of the four copies, if present, by walking over the first blocks of mass storage space. Other XIP devices (NOR) use only one copy of the booting image."

    Best Regards, 
    Yordan