Yocto Kernel Build Fails: No Rule to Make Target 'Image.zst

hello i am working on optimizing boot time and i heard that using zstd or lz4 algorithms are faster in de compression and save time
in local.conf i added the following :
KERNEL_IMAGETYPE:forcevariable = “Image.zst”
but when i try to build the whole image i get the following error:

| make[1]: *** No rule to make target 'arch/arm64/boot/Image.zst'.  Stop.
| make: *** [/home/rania/pixii_os/pixii_os/build/tmp/work-shared/apalis-imx8/kernel-source/arch/arm64/Makefile:158: Image.zst] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.

I checked menuconfig, but CONFIG_KERNEL_ZSTD is missing—only CONFIG_CRYPTO_ZSTD=y is present

there is no CONFIG_KERNEL at all all the compression methods are present in cryptoapi

How can I either enable Image.zst support or configure Yocto to use a different image format

please tell me if you have any other methods to optimize boot time or any helpful documentation

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello,

To address the issue you’re facing with enabling zstd compression for your kernel image in Yocto, here are some steps you can follow:

  1. Verify Kernel Configuration: First, ensure that your kernel configuration supports zstd compression. You can do this by running make menuconfig in the kernel source directory. Look for CONFIG_KERNEL_ZSTD. If it’s not available, your current kernel version might not support zstd compression for the kernel image.

  2. Update Kernel or Apply Patches: If CONFIG_KERNEL_ZSTD is missing, consider updating your kernel to a version that includes zstd support or applying patches that add this feature. Check the kernel’s documentation or changelogs for information on zstd support in newer versions.

  3. Consider Alternative Compression Methods: If updating the kernel is not an option, you might want to use other supported compression methods like gzip or lz4. These might already be supported by your current kernel configuration. You can set this in your local.conf by changing KERNEL_IMAGETYPE to a supported format, such as Image.gz or Image.lz4.

  4. Rebuild the Kernel: After making the necessary changes, rebuild the kernel and the entire image to apply the new configuration.

By following these steps, you should be able to either enable zstd compression or choose an alternative method that aligns with your boot time optimization goals.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

https://community.nxp.com/t5/i-MX-Processors/Question-about-MX-Processors-Knowledge-Base/td-p/2046089

Can't revert to Toradex referency image after installing custom yocto build.

Hi @rania !

I would like to split my answer in two parts: on the first one, I try to directly answer your questions, and on the second one I bring up some discussions about what you are expecting to accomplish.

So, first one:

I have never done it, but seems like this is not the right path to have your kernel ZSTD-compressed. As we can see from the error you got, by forcing KERNEL_IMAGETYPE, you are telling the build system to make that target, which doesn’t exist (Image.zst). Did you see this in Yocto documentation somewhere? Or you were just trying it out?

By “missing” you mean that it is not enabled, correct?

We do not have a specific documentation about it, but looking around in the kernel, I understood that to enable ZSTD compression for the kernel, you need to tweak the “Kernel compression mode” choice, where you can select ZSTD.

https://git.toradex.com/cgit/linux-toradex.git/tree/init/Kconfig?h=toradex_6.6-2.2.x-imx#n266

But looking around (inside the kernel), I am not sure that the ZSTD/LZ4 are supported by arm64 for kernel images.

Now, second one:

Which level of boot time optimization you need to reach? (what is the maximum boot time requirement?)

And at which time mark are you currently?

I am asking this because just by changing the kernel compression mode, it is possible that you won’t get much result out of it.

Here is a list of references about boot time optimization (please note some of the references are old and some are for Torizon, but they might be helpful nevertheless):

i’ll give you an update of what i did till now i figure out that the u-boot is responsible for compressing the kernel so i add lz4 and zstd compression support to apalis-imx8_defconfig :

+CONFIG_ZSTD=y
+CONFIG_LZ4=y
+CONFIG_LZO=y
+CONFIG_LZO=y
+CONFIG_LZ4_DECOMPRESS=y
+CONFIG_ZSTD_DECOMPRESS=y
+CONFIG_LZO_DECOMPRESS=y

now i got my image built and my kernel successfully compressed as image.lz4
but now it’s not booting i got this error

Bad Linux ARM64 Image magic! Booting from mmc failed!

i think u-boot is not recognizing the new kernel image type
do you have any idea about it ?

my boot time is currently about 13 i am willing to reduce it as much as i can

bitbake -e tdx-reference-multimedia-image | grep ^"KERNEL_IMAGETYPE"
KERNEL_IMAGETYPE="Image.lz4"
KERNEL_IMAGETYPE:aarch64="Image.gz"
KERNEL_IMAGETYPE:forcevariable="Image.lz4"
KERNEL_IMAGETYPES="Image.lz4"

as you see the problem is KERNEL_IMAGETYPE:aarch64 is still expecting an Image.gz i added this to local.conf

KERNEL_IMAGETYPE:aarch64="Image.gz"

but it did not change it persists as Image.gz

Hi @rania !

This is not something I have experience with.

But have you checked Yocto’s manual?

E.g. checking 12 Variables Glossary — The Yocto Project ® 5.1.999 documentation, seems like KERNEL_IMAGETYPES is important here.

Also, from what I can see, the machine defines the KERNEL_IMAGETYPE. Have you tried to modify it at machine level? We have an example that does something similar here: Custom meta layers, recipes and images in Yocto Project (hello-world examples) | Toradex Developer Center

Best regards,

i did changed the KERNEL_IMAGETYPE :aarch64 = “Image.lz4” in apalis-imx8.conf
and i am pretty sure that it was successfully change but the u-boot is still unable to decompress it
there’s something missing in u-boot configuration

Hello @rania,
You mentioned your boot time is 13 seconds, is this counting from the module completely off?
How much time does the kernel take to boot?
How are you measuring the boot time?
How do you consider the boot done? Do you have a GUI that should show up?
How much time should a good boot time take in your application?
This question is actually critical because the further you go trying to optimize boot time, the harder it gets, and the gains get smaller. You’ll need to balance the amount of effort you put in versus the result you’ll get.

The other questions are important because there could be some things that would be worthwhile to do before trying to change the kernel compression type. It’s correct that you could have some gains with this change, but they might not be as big as you would expect, and there’s also a tradeoff between the speed of the compression algorithm and the side of the final image. For instance, if the image gets bigger, it will take more time to read it from eMMC and some of the gains you get decompressing it faster could be lost by that.

Regards,
Rafael