AM5K2E04: Boot Up Duration from Reset to U-Boot

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,

Lennart

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

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,

Lennart

Hi Bill,

Thanks for your efforts, we're looking forward to the results of your investigations. Unfortunately we cannot switch to another boot mode without further ado.

Best regards,

Lennart

Hi Rex,

Thank you for your reply. Could you please provide some further information about the clock/speed we can expect during boot up and how to check it? As mentioned above we're actually expecting a frequency of 1400 MHz for SYSCLK1. If that is not the case, it may also affect other timings/settings.

Best regards,

Lennart

Hi Lennart,
Based on your earlier posts you have a 100MHz clock and a 1400MHz part. Let's double check that the PLL is being configured correctly.  Do you have access to the SYSCLKOUT pin?  Can you measure the length of the control signals going to the flash memory used for boot? 
Thanks, Bill

Hi Bill,

Yes, our setup consists of a 100 MHz clock and a 1400 MHz part. The SYSCLKOUT pin is available for measurements. I'll provide results as soon as I can get my hands back on the board, presumably next week.

To be sure: Does your question refer to the physical length of the signals' PCB tracks?

Best regards,

Lennart 

Hi Bill,

Measuring the SYSCLKOUT Pin during the boot sequence we observe that the processor seems to run on only 100 MHz (SYSCLKOUT = 16.7 MHz = 100 MHz / 6) for a long period of time (approx. 450 ms):

When the UBoot is copied, the frequency is ok (233 MHz = 1400 MHz / 6). As already mentioned in earlier posts the duration of this phase meets our expectations.

Now we’re still unsure about the first period of time (marked "phase (1)" in the plot), as we expect the processor to run on the higher clock of 1400 MHz as configured with the bootmode pins.

As a further explanation: the early accesses to the flash are not driven by the AM5K2, as also indicated by the EMIF_CE2# chip enable signal, which goes low (= active) when the UBoot is copied by the AM5K2.

Can you provide any hints or explanations why the processor does not seem to configure the PLL right after reset to a frequency of 1400 MHz? The bootmode pins aren’t accessible for physical measurement but we already double-checked the belonging code of the CPLD which manages the pins.

Best regards,

Lennart

Hi Rex,

thanks for your response and sorry for my late reply.
To be sure to understand your suggestion right:
1. Do you mean we should change our clock which is provided to the pins of the AM5K2 and which has a frequency of 100 MHz now to a higher value during the boot?
Or do you refer to any settings “inside” the AM5K2, maybe the corresponding DEVSTAT/BOOTMODE bits as shown in Table 8-24 in SPRS864D?

2. How is the max. value of 212 MHz derived?
3. Is any more information about the mentioned “PLL issue” available?

Thanks, best regards
Lennart

Hi, Lennart,

Sorry, it was a typo. The max frequency is 312 MHz, not 212MHz. When discussed with the ROM developer, he didn't realize that the time measurement you had. From the scope measurement, it won't make difference with higher frequency. We don't have the detail of the PLL issue. 

Rex

Hi Rex,

as we are still stuck with the problem I’d like to ask you for some more information:

1.  Although you mentioned that not all pins are available for measurement on your evaluation board we think it should be possible to determine if you can reproduce the long delay.
2. You mentioned that for „a secure device, the time is even longer“
   1. We are using an AM5K2E04XABD, X = Security Accelerator enabled / General Purpose device; do we have to expect the longer delay with this device, or does your statement only refer to devices labeled das „High Security device“?
   2. And if we are seeing the “longer delay”: what times can we expect using another device?

Thanks, best regards
Lennart

Dear Rex,

we would really love to see this issue resolved; at least to the point where we have a decent explanation of this effect along with a statement whether this delay occurs in all variants of the K2 device or not.

To give you some background:

Our Keystone2-based product is used in the field of high-performance automotive controllers. Our customers are basically all major automotive OEMs and for them, boot performance of a the device is pretty important. We've invested quite some effort to push the boot time of our device way below 2000ms. Therefore, a(seemingly) unneccessary additional boot delay of >500ms *is* significant for us. If that problem cannot be solved we'd like to have at least a plausible explanation.

Cheers,

Gerald

Given the above findings, I have additional follow up questions to understand the larger than expected boot delay with your setup.

1. Have you confirmed to check NOR flash gets powered up before the SOC tries to access the flash? 

2. Is the oscilloscope measurement from when you apply power to board or when the POR is asserted. 

3. Can you confirm that board_init function is in first stage uboot/SPL code. We are assuming this is the first function that will execute after bootROM exits. Is that true? Are you adding a GPIO toggle in that function to measure the timing on the scope?

Hello Rahul,

yes, as we wrote our external clock runs with a frequency of 100 MHz. For testing purposes we switched to 312.5 MHz and could observe that the delay shrunk from 460 ms to 147 ms (which is exactly 460 ms * 100 MHz / 312,5 MHz) and matches your findings that the PLL needs about 42E6 cycles to come up.

Now that this "mysterious phase" seems to be identified as the initialization of the PLL, a major question still persists:

Is there any chance to speed this up (apart from the higher clock)? Maybe by using another device type?

And could you please provide information about the correlation of the reset signals (RESET#, POR#, RESETFULL#) and the behavior of the PLL? In other words: if we do not release all three resets more or less at the same time (delayed by 100 µs) as we do currently, is there any possibility to start the PLL configuration at an earlier point in time and trigger the actual boot procedure separately?

Best regards

Lennart

Hi Rahul,

are there any news concerning the reset sequence?

Best regards

Lennart