Keystone 2 BOOTMODE ARM PLL setting

Hello Lance,

In K2H EVM, they used 122.88MHz for system clock and 125MHz for ARM clock. However the 125MHz is not listed in the ARM PLL configuration table. They might have used the value of 312.5MHz for 125MHz as well but i am not sure on this. I will check on this internally and update you.

Regards,
Senthil

Senthil,

Thanks for the quick response. I have investigated/experimented a little further and what i have found answers some questions, but raises more.

First, I found the board would boot with the ARM PLL config bits set to 111, but of course, that makes the ARM core run about 2% too fast since the ARM clock is 125MHz, not 122.88MHz (which I didn't notice until you pointed it out). The board would boot with any setting PLL config setting that didn't make the clock too fast, so the value is clearly used.

I read the ARMPLLCTL0 register and found that it was programmed with a different value after u-boot started. The value was PLLM=47 and PLLD=4. According to the data manual, with a 125MHz clock, this corresponds to an ARM frequency of 600MHz.

I believe I found the corresponding u-boot code/data that sets these values and the comment says "1200". The PLL configuration table in the data manual shows the 47:4 settings as the values to use for as 1200MHz device with a 250MHz clock.

So something doesn't add up. I'm not sure exactly how to verify the actual ARM frequency, but that might be useful to know.

Thanks,
Lance

Hi Lance,

You are correct that the 110 setting for the arm pll config boot mode pin provided by the BMC is giving the K2H incorrect information about the arm reference clock frequency. 110 defines the arm clock frequency as 312.5MHz and uses PLLM = 22, PLLD = 2 and the OD = 1. With those settings and a 125MHz reference clock, the arm subsystem is operating at about 479.16MHz during the boot process. Note that the UART frequency is based on the sys clock so the baud rate should be correct. UART boot is not a mode that was tested on the EVM so we didn't catch that error but even with the slower arm subsystem clock, the boot should operate. 

Once u-boot is loaded, it will change the clock frequencies based on a structure that is part of the u-boot code. U-boot does not look at the arm pll config or the sys pll config bits in the DEVSTAT register so the clock frequencies should be set up correctly. U-boot defines the PLLM = 47, the PLLD = 4 and the OD = 0 so the arm subsystem frequency will be set to ((125MHz * 48) / 5) / 1 = 1200MHz. 

Regards, Bill

Bill,

Thank you for the quick response. The UART boot mode does work on the EVM, probably because, as you said, the system clock is correct and the baud rate derives from that.

The frequency equation you gave doesn't quite agree with the equation in the data manual (section 7.1.4.1 of SPRS866B). It shows:

CLK = CLKIN x (PLLM+1) / (2 x (PLLD+1))

Which agrees with the values shown in table 7-28 -- in particular, it says that these values (47:4) would yield 1200MHz if the clock in was 250MHz. The system clock equation and tables shown in 7.1 also agree with the above equation. 

The command "cat /proc/cpuinfo" shows the ARM processor BogoMIPS as 400. I thought that the value would be closer to 1 BogoMIPS per MHz for an ARM core. On the other hand, I know practically nothing about BogoMIPS.

Thanks,

Lance

Hi Lance,
The data manual that you are using is not the most recent release. You can get SPRS866E on TI.com. The formula that you listed has been updated and is now in section 8.1.4.1. The formula is documented as follows.

CLK = CLKIN × ((PLLM+1) ÷ ((OUTPUT_DIVIDE+1) × (PLLD+1)))
Where OUTPUT_DIVIDE is the value of the field of SECCTL[22:19]

If you read the PLLM, PLLD and OUTPUT_DIVIDE fields from the ARM PLL registers you can calculate the frequency of the ARM clock.
Regards, Bill

Hi Lance,
I'm checking with the experts to see if I can get an definitive answer. I'll reply once I have clarification.
Bill

Hi Lance,

I am also facing exactly same problem what you have faced and discussed under this topic "Keystone 2 BOOTMODE ARM PLL setting". While searching for any inputs in forum , i got to see your and helped to get some idea.

We have developed our own custom board with K2HK14 processor. We have given core input clock as 122.88MHz ,ARM clock as 125 Mhz  and DDR input clock as 66.66Mhz . But none of them work at exact clock frequency 1.2Ghz,1.4Ghz,1333Hz respectively.

Our working frequency with above input frequency is ,

DSP cores acting at 614 Mhz

Arm core acting at 625 Mhz

and DDR acting at 400Mhz.

In the topic "Keystone 2 BOOTMODE ARM PLL setting" you have mentioned about the ARM Clock.

What was your DSP core working frequency ?
Was you able to achieve 1.4Ghz for arm after any changes ??

What was your bootstrap configuration ?

Your input can help us in finding solution to our problem.

Vidya,

I'm glad to see you found the thread useful. As you can see, there was never an expert, definitive answer to the questions posed, but we got enough to continue and the design is now successfully deployed. To answer some of your specific questions:

DDR3 clock = 100MHz

SYSCLK = 122.88MHz

ARMCLK = 122.88MHz

PASSCLK=122.88MHz

SGMIICLK=156.25MHz

We use one of two boot modes -- SPI or UART (for initial bring up). The bootmode strappings (GPIO[0..16]) are (in binary):

0.0110.0000.0000.0101 SPI

0.0100.1110.1110.1111 UART

We are using the 1.2GHz device and running the ARM core at that speed, although the latter was never re-verified. Note, however, that we do not rely on the PLL strapping for the processor speed after boot. Instead, we program the PLL registers during boot (part of u-boot).

In your posting, you said "Arm core acting at 625 Mhz" How did you measure that?

The PLL initialization still uses the 48/5 values of the EVM2KH. With a 122.88MHz ARM clock, I believe this should actually give us about 1.18GHz ARM core speed. We never verified this and the application runs fine. Still, it might be nice to know.

As you can see from the thread, most of our issues were really related to incomplete, incorrect or unclear documentation. The device itself seems to work fine and as expected, once you know what to expect.

Best Regards,

Lance

Hi ,

Thanks for your reply,

I have modified the  arm pll values to (8/2) which comes 500 with 125Mhz input. I can fine tune the frequency of arm upto 625Mhz.
Only at the frequency i am able to get the u-boot prompt. I could not see any u-boot prints when i use 48/5.

Once u-boot is up, using getclk command  i could see the frequency coinfigured,

U-Boot#
U-Boot# getclk  0
clock index [0] - frequency 491520000
U-Boot# getclk  1
clock index [1] - frequency 983040000
U-Boot# getclk  2
clock index [2] - frequency 500000000
U-Boot# getclk  3
clock index [3] - frequency 200000000
U-Boot# getclk  4
clock index [4] - frequency 100000000
U-Boot# getclk  5
clock index [5] - frequency 491520000
U-Boot# getclk  6
clock index [6] - frequency 491520000
U-Boot# getclk  7
clock index [7] - frequency 245760000
U-Boot# getclk  8
clock index [8] - frequency 163840000
U-Boot# getclk  9
clock index [9] - frequency 122880000
U-Boot# getclk  10
clock index [10] - frequency 81920000

and from your post, i tried to change the ARMPLLCTL0 in uboot prompt by setting it to 0x17000bc4. Then used getclk to see it changed to 1200Mhz.

but any change to core pll  makes u-boot hang. Core pll is fixed to work at 614 . i am not even able to fine tune it.

We took reference schemetic of K2HK evm and designed. But now nothing is achieved at accurate clock speed.

I am so much confused with this frequency change.

Any suggestion on this working.

Vidya,

I wasn't aware of the getclk command. I don't have access to one of boards right now, so I can't run it. Below are the values obtained from the EVM:

[0] 798720000 core_pll_clk,
[1] 983040000 pass_pll_clk,
[2] 1200000000 tetris_pll_clk,
[3] 400000000 ddr3a_pll_clk,
[4] 333333333 ddr3b_pll_clk,
[5] 798720000 sys_clk0_clk,
[6] 798720000 sys_clk0_1_clk,
[7] 399360000 sys_clk0_2_clk,
[8] 266240000 sys_clk0_3_clk,
[9] 199680000 sys_clk0_4_clk,
[10] 133120000 sys_clk0_6_clk,
[11] 99840000 sys_clk0_8_clk,
[12] 66560000 sys_clk0_12_clk
[13] 33280000 sys_clk0_24_clk
[14] 798720000 sys_clk1_clk,
[15] 266240000 sys_clk1_3_clk,
[16] 199680000 sys_clk1_4_clk,
[17] 133120000 sys_clk1_6_clk,
[18] 66560000 sys_clk1_12_clk
[19] 399360000 sys_clk2_clk,
[20] 159744000 sys_clk3_clk

But I believe these are all based on a combination of defines and programmed value of various registers, rather than on any actual measurements. I will have to check, but I am guessing that my custom board will report the same values since I didn't change the defines. It would be good if you could get confirmation of core frequency via some measurement -- perhaps like the benchmark I ran earlier (see thread).

I am not overly surprised that writing to the PLL register from u-boot would cause hangs. I don't recall for sure, but I think the "kicker" interlock might be used with PLL changes. In any case, I did most of my experimenting by modifying the u-boot board file. In particular tetris_pll_config in board_k2hk.c:

{ TETRIS_PLL, 48, 5, 1 }, /* 1200 */

The 4th parameter (1) is another divider (see my earlier post), which is set to divide by 1. A few lines later, you will see:

{ TETRIS_PLL, 8, 1, 2 }, /* 500 */

which I believe is used for the secondary program loader build that is directly fetched by the K2's boot ROM. The thing to notice there is the divide by 2 in the end. Booting from the UART turned out to be very handy for this since it only takes about 40 seconds.

One of the thing we did differently from the EVM design was to use a 122.88MHz ARMCLK instead of the 125MHz of the EVM. There is still an unexplained discrepancy between the EVM BSP settings and the K2 data manual. The latter suggests that 122.88MHz is the correct value to use, but the BSP values would yield 1.2GHz for 125MHz ARMCLK.

Hopefully, a TI expert will jump in here and clear all this up. For my part, it works as I need it to work, so the answers would just be for my own edification.

Best Regards,
Lance

Hi Lance,

In your post , you mentioned about running "delayTest" to check the processor speed.

How did you checked the code in u-boot or CCS  ?

Can you please share the code so that i can also check .

I changed 125MHz to 122.88 for ARM and kept dsp clock as same.

In no boot mode, i could see sysclk out as 20.4Mhz but in boot mode(NAND), sysclk out ranges 98.3 and board is in continuous reset.

Have you ever faced any such reset issue in your board ??

Vidya,

Unfortunately, I have lost that delayTest program, but it is was really very simple as you can see from the posting. It's been nearly a year and a half, but I believe I wrote it in C with optimizations disabled and used the assembly listing to count instructions. The results gave me a measured clock of about 1.12GHz, which was close enough to the predicted 1.2GHz for me. For somewhat better accuracy, you could add NO-OPs in the loop using the "asm" features of GNU C.

If I remember correctly, I actually ran this in Linux and, given the time accuracy, probably added time stamping at the start and end. Of course, with Linux, you will have some inaccuracies due to interrupts and other processes and they may have accounted for some of the 6% error.

I have not seen what you are reporting here. If I remember correctly, the SYSCLLOUT signal should be 1/6 the main PLL frequency. It is used for the C66 DSPs and for most of the peripherals, but it is not used for the ARM. Note also, that its reference can be either SYSCLK or ALTCORECLK depending on the core clock select. So, while SYSCLKOUT can tell you the DSP and main PLL frequencies, it does not tell you anything about the ARM core frequency.

The 20.4MHz SYSCLKOUT means that the main clock is running at 122.4MHz (probably 122.88), which suggests a PLL divisor ratio of 1 or, more likely, PLL bypass mode. In no boot (sleep boot) mode SYSEN can disable the system PLL. I am guessing that means bypass it, hence the output you are seeing.

In NAND boot mode, are you using the ARM (Boot Master = 0)? Anyway, the 98.3MHz translates to a system clock of 590MHz, but there is no setting in the SYS PLL table for that frequency with a 122.88MHz clock. However, this is exactly the frequency you get if the SYS PLL were set to 101(b) with a 122.88MHz clock instead of 250MHz as indicated by the table. You should be using a setting of 111(b). If you can get the system to boot, you can read the bootmode strapping in the DEVSTAT register.

As you may know, the boot sequence starts with an internal, hard coded boot loader, which looks at the various strapping options, sets up cores/peripherals as needed and then attempts to load a secondary boot loader that you supply. The document spruhj3 (KII ARM Bootloader User Guide) describes this pretty well. So the initial behavior is controlled by the bootloader, but then is quickly relinquished to the secondary bootloader, over which you have control.

To see how far it is getting, you can look at what you expect it to be doing. For example, with the NAND boot, you would expect to CS signals as it tries to read from NAND; for SPI boot, look for SPI clocks and selects; for UART boot, look for a character transmission.

If it gets as far as loading and running your secondary program loader, (first stage of u-boot), then the strapping options are probably okay. If it fails after that, you might look at what that secondary loader does.

Best Regards,
Lance

Hi Lance,

I have checked the nand chip select and its continuous. But since board is reset state , nand is not able to boot.

I will change the bootstrap with 122.88 Mhz and check whether i am to boot. Then will try to see time stamp in linux and check the processor clock speed.

Thanks for sharing this much information .