• State TI Thinks Resolved
  • Locked Locked
  • Replies 15 replies
  • Answers 3 answers
  • Subscribers 101 subscribers
  • Views 809 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.

66AK2E05: SPI Boot Mode ROM Delay

Patrick Bonzelet
Prodigy 90 points
Part Number: 66AK2E05


We are trying to boot the part as quickly as possible.  Our initial boot comes from SPI Flash.  However, we see a delay of ~476ms after reset release before the part pulls the first piece of data from Flash.  Should we expect the Boot ROM to take that long to start pulling the code or are we doing something to cause that delay?  I understand that SPI Boot transfer is very slow and we are minimizing the stage 1 code size.  However, I am interested in the delay before the code is transferred when running in SPI Boot mode.

  • 0
    TI__Guru**** 161600 points
    Hi Patrick,

    Which software are you trying to boot? RTOS or linux?

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

    SPI boot is a general purpose boot mode in which the BootROM configures the PLL in bypass mode. The BootROM loads the image from the base of the SPI NOR flash.

    Are you working on EVM or custom board?

    In the example, the first stage stage loads the boot parameter table that forces the BootROM to configure the PLL and load the seconds stage at 100Khz.
    processors.wiki.ti.com/.../KeystoneII_Boot_Examples

  • 0
    TI__Guru** 116710 points
    Patrick,

    I believe that you are using secure boot device as your issue seems fairly similar to the issue reported here by JEramie:
    e2e.ti.com/.../2841053

    SPI and I2C boot on this device are not designed for fast boot. Our recommendation would be to use a boot mode which sets the ARM core to max
    device SPEED like NAND to speed up the boot process.

    Regard,s
    Rahul
  • 0 in reply to Yordan Kovachev
    Prodigy 90 points

    We are booting to VxWorks, but this is the stage 1 boot loader.  Just to clarify, I am looking for the initial delay before anything is pulled from Flash in SPI Boot Mode.  The operating system is much farther down the boot process than where I am looking.

  • 0 in reply to Raja
    Prodigy 90 points
    I am working on a custom board. I understand the process and that the PLL is disabled. I am just curious if I should expect a 476ms delay before anything is pulled from Flash. Do you see this behavior on your eval module?
  • 0 in reply to Rahul Prabhu
    Prodigy 90 points
    I am not using a secure device. I am using a standard device and need to boot from SPI. I know this is a slower interface but I did not expect it to take 476ms to START pulling data from Flash.
  • 0 in reply to Patrick Bonzelet
    TI__Guru** 116710 points
    Patrick,

    I am checking with the ROM author if he could indicate if the efuse scan chain, boot parameter setup and the state machine setup in the ROM could take this long when run in PLL bypass mode. Do you have an option to use any other boot mode on the HW where PLL may be configured?

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    TI__Guru** 116710 points
    PAtrick,

    HEre is the response from the ROM team:

    The number looks pretty slow. Obviously in bypass mode everything runs quite a bit slower. But on K2E I think the slowest clock supported is 50MHz, which is not horrible.The code does setup an secure entry point but that shouldn’t be the problem.

    Here is a general overview of the steps the ROM executes:

    1) Configure and verify the endian swapper registers (device level) needed for initial bootstrap
    2) Setup the stack and vector base address
    3) Configure the translation tables MMU (both in secure and non-secure state) – This is slow – it was improved in galileo, but since it is done before PLL enable I don’t think it is the problem (although it would help to know how long it takes to do an SPI access when the PLL is enabled).
    4) Initialize the boot log instance
    5) Flush the cache – this is also painfully slow when in PLL bypass mode.
    6) Clear BSS
    7) Branch to bootMain
    8) Initialize the boot Traces and status stack
    9) Check the reset type and quick branch if local
    10) Configure remaining endian swappers
    11) Setup the SES and SMS segments needed for boot (PCIe and hyperlink maps)
    12) Initialize the GIC
    13) Initialize any MPU regions to allow boot data to pass
    14) Power cycle the PLL (required due to a band gap failure on K2 PLLs)
    15) Copy RAM table entries into place
    16) Permanently power down the gem core(s) if required by e-fuse
    17) Clear boot stats
    18) Copy the boot version info from ROM to RAM and unpack into an ascii string
    19) Initialize the boot parameter tables
    20) Configure the PLLs required for the specific boot mode
    21) Power up PSCs required for the boot mode
    22) Configure the SPI peripheral
    23) Read a block of data


    My guess is that if you compare the no PLL time to first access to the PLL time to first access they will not be that different, since the PLLs were not configured until step 20.


    Could you explain how you are measuring this time are you measuring it from time you applied power to the board or are you monitoring the POR pin on the SOC. I am trying to eliminate time added by power management circuitry for the rails to stabilize and only make sure that the time is contributed by the ROM on the SOC.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 10 points
    Rahul,
    I work with Pat Bonzelet, and we are currently measuring the time from the rising edge of RESETSTAT_N to the first rising edge on the SPI Clock of our SPI Flash component that is connected to the SPI0 interface of the 66AK2E05 device. We are probing at the SPI Clock pin on the SPI Flash device.

    The time that we are measuring is ~460ms.

    This still seems like a long period of time of inactivity from the core and IOs being completely powered up to pulling data from the SPI flash. The boot mode pins that we are strapping are as follows.

    DEVSTAT[1] = 0
    DEVSTAT[2] = 1
    DEVSTAT[3] = 0
    DEVSTAT[4] = 1 = Min
    DEVSTAT[16:5] = 0

    Would modifying any of these boot mode strapping pin values assist in reducing this ~460 ms gap?

    Thanks,
    Chris
  • 0 in reply to Chris Springer
    Prodigy 90 points

    Just to expand on what Chris has posted:

    We don't release reset to the processor until all voltages and clocks are stable.  We then are looking at the reset status being returned from the processor, which indicates it is up and running.  That is the start of our measurement and we see a 460ms delay.  It is 476ms from release of reset (16ms to get the good status back from the part).  We are using an input clock of 100MHz.

    We would like to understand what the Param Idx (DEVSTAT[7:5]) and Min (DEVSTAT[4]) do to the boot flow.  Could those settings impact the delay to the fetch of the first piece of data?  Also, we are using the multi-stage boot as called out in the ARM_Bootloader (spruhj3) application note.  We update the boot table and perform a second boot.  I am curious which line items in the list provided are executed in the second boot.  We don't see the 460ms on the second boot.

    Pat

  • 0 in reply to Patrick Bonzelet
    TI__Guru** 116710 points
    Patrick,

    Sorry for the delay in getting to the post. I was tied up with some priority task so wasn`t able to get to this issue.

    the Parameter index in the DEVSTAT is provided as it allows users to specify multiple boot parameter table and pick the appropriate settings by specifying and index. Are you using anything different than default 0. This can effect the boot time as the boot parameter table is the one that configures the boot peripheral and clock to the boot core. The min pin sets every thing to default for the boot peripheral. Typically this is used to save on boot pin configuration and setting the mode and min pin is enough for boot ROM to copy the image using conservative settings pre-configured in the ROM code.

    I am setting up a platform in my office to be able to make some measurements in ROM to see how long it take in the boot ROM to get to sending the first SPI command and will report back with my findings.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 90 points

    Rahul,

    We are using the default setting for the parameter table.  We did try to change it and the part did not boot properly.

    Please let me know once you have measurements on your platform.

    Thanks,

    Pat

  • 0 in reply to Patrick Bonzelet
    TI__Guru** 116710 points
    Patrick,

    At the moment, there doesn`t appear to be a way to improve the existing boot time for this device for SPI boot. IF faster boot is required then we recommend that you switch to a higher speed interfaces where the ROM configures the PLL and SOC clocks to avoid this boot latency.

    Regards,
    Rahul
  • 0 in reply to Rahul Prabhu
    Prodigy 90 points

    Rahul,

    In your previous post the PLLs were not configured until step 20 of 23.  How will switching to a PLL enabled boot mode get rid of the latency if the first 20 steps are still executed at the slower clock rate?

    In that response you stated:

    My guess is that if you compare the no PLL time to first access to the PLL time to first access they will not be that different, since the PLLs were not configured until step 20.

     

    You had mentioned that you were trying to get a measurement on an eval card, were you able to do that?

    Thanks,

    Pat

  • 0 in reply to Patrick Bonzelet
    TI__Guru** 116710 points
    Patrick,

    The measurement that we were setting up was by cpu reset the core and set a break point at the line in ROM where the first SPI command is sent out. However, this setup doesn`t work due to some A15 privilege state violation. I have tried to consult with the ROM author and he doesn`t think the SPI boot time can be improved on this device as it was not designed for fast boot.

    I will try to see if there is any other guidance that I can provide from the design team that would clarify if the ROM code is the root cause or if the time from release of power on reset to the execution could be the root cause of this issue.

    Regards,
    Rahul