/initrd.image: incomplete write (-28 != 32769317)

[dhk112]

Hello everyone,

I get an error when booting Linux + initramfs

The versions of the main components are:

Component	Version
tf-a-stm32mp	v2.6-stm32mp-r2.2
optee-os-stm32mp	v3.16.0-stm32mp-r2.2
u-boot-stm32mp	v2021.10-stm32mp-r2.2
linux-stm32mp	v5.15.145-stm32mp-r2.2

bootcmd:

setenv boot_device mmc;
setenv boot_instance 0;
setenv boot_partition 5;
setenv fit_addr C2000000;
mmc partactive ${boot_instance};
mmc partconf ${boot_device} 1 1 0;
load ${boot_device} ${boot_instance}:${boot_partition} ${fit_addr} fitImage-foo-image-initramfs;
setenv bootargs console=ttySTM0,115200 FIT_IMAGE_PART=${boot_partition} debug loglevel=8;
bootm ${fit_addr};

error:

[    2.588644] rootfs image is not initramfs (write error); looks like an initrd
[    2.588766] /initrd.image: incomplete write (-28 != 32769317)
[    2.753422] Freeing initrd memory: 32004K

From my research I found that:

-28: ENOSPCwhich means No space left on device.

If I add: 

setenv initrd_high 0xFFFFFFFF

The error does not occur anymore. This is probably because the ramdisk is loaded directly from flash memory and not copied to RAM beforehand (see https://docs.u-boot.org/en/v2022.10/usage/environment.html)

The fitImage loading information states the following:

## Loading kernel from FIT Image at c2000000 ...
   Using 'conf-stm32mp151c-foo.dtb' configuration
   Trying 'kernel-1' kernel subimage
     Description:  Linux kernel
     Created:      2023-12-23   9:42:00 UTC
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0xc2000120
     Data Size:    7437600 Bytes = 7.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0xc0800000
     Entry Point:  0xc0800000
     Hash algo:    sha256
     Hash value:   bf3e491301d2dc9fe63bf119ce4704a147f3dce0ca1168110ba7dd5b29e4cf63
   Verifying Hash Integrity ... sha256+ OK
## Loading ramdisk from FIT Image at c2000000 ...
   Using 'conf-stm32mp151c-foo.dtb' configuration
   Trying 'ramdisk-1' ramdisk subimage
     Description:  foo-image-initramfs
     Created:      2023-12-23   9:42:00 UTC
     Type:         RAMDisk Image
     Compression:  uncompressed
     Data Start:   0xc2724e88
     Data Size:    32769317 Bytes = 31.3 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: unavailable
     Entry Point:  unavailable
     Hash algo:    sha256
     Hash value:   47c1724633530ff00903486d1bf7d334fa46c55ff7afedcb96b403c74c8c629f
   Verifying Hash Integrity ... sha256+ OK
## Loading fdt from FIT Image at c2000000 ...
Bootstage space exhasuted
Bootstage space exhasuted
   Using 'conf-stm32mp151c-foo.dtb' configuration
   Trying 'fdt-stm32mp151c-foo.dtb' fdt subimage
     Description:  Flattened Device Tree blob
     Created:      2023-12-23   9:42:00 UTC
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0xc2717f54
     Data Size:    52840 Bytes = 51.6 KiB
     Architecture: ARM
     Hash algo:    sha256
     Hash value:   1744a9700ebbe4faa2f35112ff30749cab8d769a205d082a970c65e72303f243
   Verifying Hash Integrity ... sha256+ OK
Bootstage space exhasuted
Bootstage space exhasuted
Bootstage space exhasuted
Bootstage space exhasuted
Bootstage space exhasuted
   Booting using the fdt blob at 0xc2717f54
   Loading Kernel Image
Bootstage space exhasuted
Bootstage space exhasuted
   Loading Ramdisk to c9fbb000, end cbefb525 ... OK
   Loading Device Tree to c9fab000, end c9fbae67 ... OK
Bootstage space exhasuted
Bootstage space exhasuted

Starting kernel ...

The ramdisk is successfully loaded into memory. But later on it can't be loaded into memory by the kernel?

The position c9fbb000 - cbefb525 is exactly the size of the initramfs 1F40525 = 32769317 bytes.

Compression of the initramfs

Has it something to do with the compression? Because the initramfs is in the format "cpio.gz" which means it is compressed with gzip. In the .its file (which is generated by yocto kernel-fitimage class) the compression is set to "none". If u-boot only allocates memory for the compressed initramfs and the kernel later on decompresses it and tries to load it into the same memory position it does not fit anymore maybe?

Any information on what is actually happening while this fitImage is booting would be appreciated.