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.

  • TI Thinks Resolved

AM5K2E04: Boot Up Duration from Reset to U-Boot

Prodigy 160 points

Replies: 35

Views: 1189

Part Number: AM5K2E04



Analyzing the boot procedure of a TI AM5K2E04 we tumbled over an unexpectedly long period of time between the end of the reset sequence and the entrance of U-Boot.

BOOTCOMPLETE pin is used to indicate the beginning of U-Boot function board_init_f(), where we set the BOOTCOMPLETE register at address 0x0262013C to 0xFFFFFFFF to generate a rising edge of BOOTCOMPLETE pin (pin AF31).

Between the end of the reset (rising edge of RESETSTAT#, pin AH29) and the entrance of board_init_f() a duration as long as 560 ms elapses (measured with oscilloscope). We can't explain this timespan to ourselves, as we for example expect a duration of about 60 ms to copy the U-Boot (about 150 kB in size); we are using EMIF Boot mode.

Is it plausible that almost 600 ms elapse from the end of reset to the entrance of board_init_f()? What’s going on during this time?


Thanks, best regards


  • Hi,

    I have the same questions as the ones I asked on the other thread you've opened:

    Do you observe this on K2E EVM or a custom board? Which Processor SDK Linux version are you using?

    Do you see the same behavior when your board is connected to CCS via JTAG and board initialization is done by GEL files?

    Best Regards,


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Dear Yordan,

    Gerald here; I'm a colleague of Lennart from our department which is in charge of the embedded software.
    To answer your question:

    1. We're using our own board
    2. We do not use the Processor SDK Linux

    We're analyzing the Keystone Reset procedure because boot performance is critical to our product.

    To provide some more details:
    Our Keystone2 is connected via EMIF16 to a NOR Flash and the boot process is controlled by an external logic (namely a CPLD which manages the boot sequence). The NOR Flash holds UBoot as a standard boot loader; we use UBoot 2016-05 as a base with slight modifications in the later boot stages. The effect described by Lennart is observed in the very early boot stages.

    The BOOTMODE[15:0] pins (DEVSTAT[16:1])are set to 00011-1000110011, which means:

    DEVSTAT[4:1] = 0011 ==> Use EMIF16 as boot device
    DEVSTAT[7:5] = 011 ==> Sys PLL for 100Mhz input clock
    DEVSTAT[8] = 0 ==> ARM Boot Master
    DEVSTAT[10:9] = 10 ==> Use EMIF16 ChipSelect4 (CE2)
    DEVSTAT[11] = -
    DEVSTAT[12] = 1 ==> Use 16-bit accesses on EMIf16
    DEVSTAT[13] = 1 ==> Extended Wait Enabled
    DEVSTAT[15:14] = 00 ==> Use 0x0 as base address
    DEVSTAT[16] = 0 ==> Use EMIF16 as boot device

    The boot sequence created by our CPLD looks like this:
    t_0 = 0 s: \POR pin is released (low -> high)
    t_1 = 100 µs: \RESETFULL pin is released (low -> high); Boot mode pins -> high Z
    t_2 = 200 µs: \RESET pin is released (low -> high)

    Using a scope, we measure the time from t_0 and the time when the DDR controller is reset by SW which is more or less immediately after board_init_f() is called in UBoot.

    Of course, the very first steps of UBoot take a few microseconds. And of course, the Keystone ROM bootloader needs some time to copy UBoot from EMIF16/Flash to internal SRAM. But 560ms is *way* above anything we'd expect. So we're wondering if this is some software effect inside the ROM bootloader or a possible HW effect which takes place even before the ROM bootloader starts.

  • In reply to Gerald Ruescher:

    Hi, Gerald,

    I am not sure what would cause the long elapse time. Let me see what I get from our EVM.



  • In reply to Rex Chang:

    Hi, Gerald,

    I just disucssed this with our HW engineer. Could you measure the time to see how long it takes to read from EMIF NOR, from the first chip select to the last block read?

    After RESETSTAT# goes high, the EMIF PLL is configured to the default max values. We did a calculation based on K2E at 25MHz, The EMIF NOR read will take about 3.5us. For 158KB, it takes about 553 ms.

    If it is the case, you may want to load a very small ROM code to configure the NOR to higher speed than using the default values. Then, load the rest of the u-boot code which may improve the load time.



  • In reply to Rex Chang:

    Hi Rex,

    thanks for your answer.
    Our HW guys will measure the EMIF16 access time by monotoring the CS signal and we'll post the results as soon as they are available.

    HoweverI have my doubts that the EMIF16 transfer time is the reason here. Currently our UBoot is indeed around 160KB large and we see this delay of roughly 600ms. To check the influence of the UBoot size I've simply doubled it in size to ~320KB by adding some random data. When we use the double-size UBoot, the boot time increases from ~600ms to ~700ms (Lennart has the exact numbers).

    So according to this, the UBoot only accounts for about 100ms, leavin ~500ms a mystery :-D

    Anyway let's wait for the HW measurment results :-)

  • In reply to Gerald Ruescher:

    Hi Rex,


    we did the measurement and found the following:

    yellow: RESET#

    orange: RESETSTAT#

    white: BOOTCOMPLETE, set in function board_init_f() as described above

    light blue: flash's ChipSelect# 

    The following three plots show the same boot sequence using a 152kB sized U-Boot (only the cursors differ). The plot starts with the rising edge of RESET#. We expect the blue block of the ChipSelect# signal occuring after about 460 ms and taking up about 81 ms to be the phase in which the U-Boot is copied. About 21 ms later board_init_f() is reached.


    With an enlarged U-Boot of about 218 kB this block takes up 117 ms as shown in the following plot:



    But the mysterious phase of 460 ms remains while copying the U-Boot does not seem to be the reason. Any ideas?


    Best regards,


  • In reply to Lennart Siekmann:

    Hi, Lennart,

    I am not seeing the plots. Could you try to insert them as attachments? The cut and paste won't work.



  • In reply to Rex Chang:

    Sorry, I updated my post
  • In reply to Lennart Siekmann:

    Hi Lennart,

    The current reset sequencing doesn't match the power up sequencing shown in the K2E data manual. The RESETz signal should be at a steady high state when PORz and RESETFULLz are released and should remain high until after the device has booted. I don't know if this is causing your long delays but it should be corrected before we attempt any further debug.

    Regards, Bill

    If you need more help, please reply back. If your question is answered, please click  Verify Answer 

  • In reply to Bill Taboada:

    Hi Bill,

    Thanks for your answer. We fixed our reset sequencing and also double checked the timings of the BOOTMODE pins, but the delay still remains.

    Our sequence now:

    t_0 = 0: RESET# low -> high

    t_1 = 100 µs: POR# low -> high

    t_2 = 200 µs: RESETFULL# low -> high

    BOOTMODE pins are held stable for another 400 ns after the rising edge of RESETFULL# (taken "12 transitions of the SYSCLK1 after the rising edge of RESETFULL#" and "maximum clock period is 33.33 nsec", although we expect SYSCLK1 to have a frequency of 1400 MHz).

    Best regards,


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.