Introduction
In previous posts we've made minimal but enough for studying and playing basic application which is able to output debug information. It sets some PLLs and clocks except, maybe, for most of us, the most interesting one — ARM PLL, or PLL which controls the speed of ALU. And we will do such research in this part. The announce of this post is partial, this is on a purpose — it will be more interesting for you to read without knowing the complete plan of this post.
The research plan
We can't measure ALU clock directly because it has no outputs outside of SoC. So, how should we act if we want to know if it is at least changed? We need to do something that depends on ALU speed, and what we can measure. What could it be? UART? No. We configure UART to output data on a particular baud rate, but that has nothing in common with ALU speed. UART configuration affects its TX and RX pins but impulses UART makes while transceiving data are irrelevant with ALU clock. Thus, we need different «interface» with SoC which can give us possibility to measure its clock. Let's turn to theory for a little. So-called ALU «cycle» is one tick of ALU clock, but single clock tick is not equal to an instruction, instruction may take from one to thousands of cycles. (Instruction that take zero cycles are out of scope of this post). But we know that any particular instruction takes the same amount of cycles at any ALU speed. Thus, real execution time of any block of instructions will directly vary according to different ALU speeds. We just need to have some measurable points of some «reference» block of instructions. The most obvious block of instructions is empty loop which translates into branch back to itself (even leaving link register intact) until the countdown variable reaches zero. What could be the rest of our setup? The most clear way to measure something on a SoC is GPIO. Hence, in this post we will initialise IOMUX Controller, one of pads of particular GPIO bank and put GPIO toggling function among with some empty loop (generating measured impulse length) into an infinite loop. After that we'll be able to measure impulses with a scope, change ALU PLL speed, leaving reference code intact and measure impulses again.
As we've reviewed the workflow on embedded systems without any BSP, bootloader, kernel — bare-metal, in previous posts, I'll not provide such details in this and further parts. You'll see what and how is done in the code. Some code lines have comments referencing datasheet page numbers. If you'll ever need to change, for example, GPIO number you can look datasheet around page numbers that you'll see in code and make necessary changes according to appropriate sections of datasheet.
The practice
This time we need a GPIO. As we've noticed in previous posts, GPIO is one of AFs (alternative functions) of a pad or ball. AFs are configured by IOMUX Controller. Therefore, we start with IOMUXC. First, as we did in previous posts, we check the section 6.1.4.2 — «Boot block activation» (p.706) and check if IOMUXC is configured by BROM or not. And we see that we are lucky today because it is initialised by BROM. Thus, we omit initialisation and configuration of this hardware block and proceed straight to GPIO.
Now, we have to see what GPIOs are available and choose one we will use. I'm working on DEBIX Model A SBC. In (most probably fantastic) case you have the same SBC, you can use the picture below and/or the same GPIO as we will use in this post. If you have another SBC, you have to find similar picture for your SBC. What you need is called «pinout» or «header pinout» or «gpio header». This information usually is included in your SBC datasheet or user manual. But sometimes it is easier and faster to search the Internet for something like «_your_sbc_name_ gpio pinout». Let's see what pinout we have:
DEBIX Model-A GPIO header pinout
There is a handy GPIO on this board — GPIO number 11 on bank 1 (pin 29). Today we will add two new files to our project — gpio.c and gpio.h. So, we add GPIO initialisation and set its direction to barium_main() function:
/* Init GPIO and set 11th of first bank as output */
gpio_init();
gpio_set_dir(GPIO_BANK1, 11, GPIO_OUT);
After that we add our measurement code — the reference code we have mentioned earlier:
/* Generate impulses for measurements */
loop_meas:
gpio_toggle_val(GPIO_BANK1, 11);
for (lVal = 0; lVal < IMPULSE_LEN; lVal++);
goto loop_meas;
IMPULSE_LEN can have any value, but I've chosen 1 000 000 to fit the loop to comfortable scope view settings.
Build, write to SD-card, connect scope, start the board and see:
Measure at default ARM PLL settings
Here we see that period is approximately 570ms. The period width is uninformative itself. This is just how many time our SoC spends executing our reference cycle on the default ARM PLL settings. From «PLL setting by ROM» we remember that ARM PLL is set at 1GHz. Let's reconfigure it and see what measurements we'll have. ARM cores of iMX8MP are driven by so-called PLL1416x. I could not find any documentation describing it, so we will cope with SoC's datasheet (ARM PLL), see the registers we need to write values to and generate the exact values using the sheet I've managed to create from information I've gathered from around and got from my experiments. You'll see the sheet file in the repository and can play with it. The methodology is simple — you change the Main divider (the biggest number in the most left column) with step of 25 and see column «Clock (MHz)». The rest will be done by the sheet formulas. The table will display register value in hexadecimal and decimal, and two values — Pre div and Scaler. We can configure iMX8MP ARM PLL by using three values — Main div, Pre div and Scaler in formula, or just write the exact value from the most right columns.
iMX8MP ARM PLL Settings
The whole code is added to files clocks.c and clocks.h. And I utilise three values formula instead of a exact single value. That's because I used to do it this way while I was on my researches. Let's rev our SoC up to 1.8GHz — its stated maximum (p. 95). According to sheet we will use 225, 3, 0 coefficients:
raw_writel((225 << 12) | (3 << 4) | (0), CCM_ANALOG_ARM_PLL_FDIV_CTL0);
Now build, write to SD-card, start the board and see:
Measure at 1.8GHz
And what we see here? 507ms. The period has narrowed, but not as we expected — 570ms@1GHz expected to be 570/1.8 what is 316ms@1.8GHz! What is going on here? To make long story short (it still is not the most interesting part of this post) I'll tell that I've measured different speeds and all periods appeared to be non-proportional to ARM clock. The short summary is shown in following table. I've made a little calculations also:
Non-linearity of ARM ALU clock speed
We see clocks we set, periods we have measured and two rows as values should be if reference (real true value) was at the slowest or at the fastest clock. Being calculated in any direction the calculated values have linear relation with clock speed. But measured values are non-linear and look like barely related to clock speed at all. The table displays that something is really unclear or even wrong here.
What could go wrong? NXP PLL1416x is undisclosed, thus, we don't know how it exactly works — we can't be sure what speeds it really sets. Another reason could lead to such results — our reference code was modified. But we can't examine PLL and we are sure our code stays intact between builds. So let's try to find some different cause of such ARM ALU behavior. We remember that at this stage ALU works on OCRAM — the slowest one of all RAMs. Let's assume that nonlinearity of our clock speed and period measurements is caused by OCRAM — its access speed. What can we do now? We can use caches. According to specification iMX8MP has 32kB of instruction cache and the same amount of data cache. Therefore our tiny 1-2kB application will fit in SoC's cache entirely. Let's turn on both caches by adding this code to our start_64.s file:
# Load System Control Register (EL3):
mrs x3, SCTLR_EL3
# Turn on Data Cache:
orr x3, x3, #(1 << 2)
# Turn on Instruction Cache:
orr x3, x3, #(1 << 12)
# Set System Control Register (EL3):
msr SCTLR_EL3, x3
Let's check what we get on default 1GHz now:
.bmp)
ARM ALU at 1GHz with caches on
The changes appeared to be so dramatic, that I had to tune my scope to make pretty-looking picture! Now our reference code executes in 36ms at 1GHz instead of 570ms with caches turned off at the same ALU clock speed! And here is new resulting table, showing that not only is everything faster, but it is also linear in both directions:
Linearity of ARM ALU clock speed (caches on)
Now everything is in order and clear — be it calculated from the lowest value (big to small) or from the highest (small to big) — the values check with each other and correlation is absolutely linear: 200MHz * 3 (600MHZ is three times slower than 200MHz) = 180ms/3 = 60ms; 1800MHz * 9 (1800MHz is nine times faster than 200MHZ) = 1800ms/9 = 20ms and so on. The hypothesis is confirmed — OCRAM timings was messing ARM ALU speeds and now we have formula to set ARM ALU clock speed, we have measurement tool and nice and clean results.
But there is more to explore. As I mentioned earlier, we have a tool for calculating ARM PLL speeds — the spreadsheet. And maybe you noticed that picture above («iMX8MP ARM PLL Settings») shows some clock speeds far above of 1.8GHz. Yes, let's check that and here is the result we've got:
.bmp)
Linearity of ARM ALU clock speed (caches on)
The table contains columns with 1.2GHz and 1.6GHz and this is on a purpose. The thing is that NXP's documentation claims that even 1.8GHz is so-called «overdrive» of this SoC's ALU. And my Linux system (NXP's BSP) confirms that — it works on two speeds only — 1.2GHz and 1.6GHz. These speeds are marked green — as normal or standard. I've measured both standard speeds and the highest I've managed to make SoC to work on (2.2GHz) to show the difference between really used clock speed and maximum I've got out of this SoC's ALU in single core mode.
The result
Barium No-Boot V0.2 (iMX8MP)
Build: 22:00:00, Mar 12 2025
Initial PC: 0000000000920000
BootROM SP: 0000000000916ED0
Current EL: 0000000000000003
Running at: 2200MHz
In previous posts we were reading, planning, preparing, learning, today we've learned how to use GPIO on this SoC, how to configure ARM PLL speed. But today is a special day — we've some nice and exceptional result, which is a real practical result — we've significantly revved up (overclocked) iMX8MP and maybe invented the only one iMX8MP running at 2.2GHz! Disclosing undocumented features is another one benefit of bare-metal studying (or exploring).
You can clone the final repository from Barium No-Boot (iMX8MP) (see «Stage III» directory).
