Making some changes in order to speed up the boot in a iMX6ULL, I was testing with the core-image-minimal recipe from OpenEmbedded.
Regarding what I found, I wanted to ask 2 questions, that I believe would be really useful to clarify towards the community and for similar posts:
It looks like the CPU is starting at 396MHz rather than its full speed of 792MHz. Checking some NXP’s community post and the reference manual, it is indeed locked at 396MHz (or 198MHz) at boot. Already in Linux, via sysfs you can check that the running frequency ( cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq ) is already 792MHz. When is this frequency changed in the boot process and how?
In image.json, you can see that U-boot is copied twice as different MTD. Why is that? Is it related to the SPL?
Dear @mlai, could you open another question for this? Hopefully one of my colleagues could look at this in detail, or even myself, as they are different SoCs!
When is this frequency changed in the boot process and how?
Early in the Linux boot process the appropriate cpu frequency driver is loaded. That driver takes care of switching the CPU clock and CPU voltage according to the currently needed workload.
U-Boot does currently not have any code to change the CPU clock and voltage, we have no plans to do implement such a feature.
In image.json, you can see that U-boot is copied twice as different MTD. Why is that? Is it related to the SPL?
There is no SPL used for the Colibri iMX6ULL.
The Colibri iMX6ULL uses raw NAND which inherently may have bit errors in its stored data. Error correction code added to the stored user data allows to get reliable data back from storage.
Since the bootrom must be stored at fixed places in the NAND it is a bit more likely that pages may fail. Thus the bootrom can fall back to a second location from which it loads the bootloader should it happen to detect an uncorrectable error at the first location.
