U-boot ERROR: can't get kernel image!

I try to get my QSMP-1570 (STM32MP157) card booting a Yocto Dunfell compiled image but got problems with uImage.

Why do I get this Bad Data CRC and how can I troubleshoot it?
I have tested to change load address, entry point and where in memory it’s loaded from eMMC without luck.
I have also tried without extlinux.

U-Boot 2020.10-stm32mp-r1-00008-g28d5224181-dirty (Sep 23 2021 - 09:34:22 +0000)

CPU: STM32MP157CAC Rev.B
Model: STMicroelectronics custom STM32CubeMX board
Board: stm32mp1 in trusted mode (st,stm32mp157c-qsmp1570-mx)
DRAM:  512 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208 MHz
- AXI : 266.500 MHz
- PER : 0 MHz
- DDR : 533 MHz
WDT:   Started with servicing (32s timeout)
NAND:  0 MiB
MMC:   STM32 SD/MMC: 0, STM32 SD/MMC: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Net:   eth0: ethernet@5800a000
Boot over mmc1!
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:2...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
239 bytes read in 23 ms (9.8 KiB/s)
Retrieving file: /splash.bmp
Failed to load '/splash.bmp'
There is no valid bmp file at the given address
1:      OpenSTLinux
Retrieving file: /uImage
12341688 bytes read in 298 ms (39.5 MiB/s)
append: root=PARTUUID=491f6117-415d-4f53-88c9-6e0de54deac6 rootwait rw console=ttySTM0,115200
Retrieving file: /stm32mp157c-qsmp1570-mx.dtb
57638 bytes read in 25 ms (2.2 MiB/s)
## Booting kernel from Legacy Image at c2000000 ...
   Image Name:   Linux-5.10.10
   Created:      2021-01-23  15:04:06 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    12341624 Bytes = 11.8 MiB
   Load Address: c2000040
   Entry Point:  c2000040
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
SCRIPT FAILED: continuing...
57638 bytes read in 25 ms (2.2 MiB/s)

binwalk uImage

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x4C753A9D, created: 2021-01-23 15:04:06, image size: 12341624 bytes, Data Address: 0xC2000040, Entry Point: 0xC2000040, data CRC: 0xF2806D38, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-5.10.10"
64            0x40            Linux kernel ARM boot executable zImage (little-endian)
2532          0x9E4           device tree image (dtb)
29440         0x7300          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
6337766       0x60B4E6        CRC32 polynomial table, little endian

mkimage -l uImage

Image Name:   Linux-5.10.10
Created:      Sat Jan 23 16:04:06 2021
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    12341624 Bytes = 12052.37 KiB = 11.77 MiB
Load Address: c2000040
Entry Point:  c2000040

Belove is output from same board with different image. This image is clean without balena and compiled by manufacture. I have tried to use same entry point, load address and so on, but with nu success.

U-Boot 2020.10+karo+g69a0454b5b (Jul 02 2021 - 10:17:34 +0000)

CPU: STM32MP157CAC Rev.B
Model: Ka-Ro electronics GmbH QSMP-1570 solder-in module
Board: QSMP-1570 in trusted mode (karo,stm32mp157c-qsmp-1570)
DRAM:  512 MiB
Clocks:
- MPU : 650 MHz
- MCU : 208.878 MHz
- AXI : 266.500 MHz
- PER : 24 MHz
- DDR : 533 MHz
WDT:   Started without servicing (0s timeout)
MMC:   STM32 SD/MMC: 2, STM32 SD/MMC: 0
Loading Environment from MMC... OK
In:    serial@40010000
Out:   serial@40010000
Err:   serial@40010000
Net:   MAC addr from fuse: 00:0c:c6:88:4f:71
eth0: ethernet@5800a000
Hit any key to stop autoboot:  0
6432600 bytes read in 160 ms (38.3 MiB/s)
52847 bytes read in 4 ms (12.6 MiB/s)
## Booting kernel from Legacy Image at c0000000 ...
   Image Name:   Linux-5.10.23-karo+gdfbf345b63c3
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    6432536 Bytes = 6.1 MiB
   Load Address: c0008000
   Entry Point:  c0008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at c4000000
   Booting using the fdt blob at 0xc4000000
   Loading Kernel Image
   Using Device Tree in place at c4000000, end c400fe6e
Copying video timing from 'ETV570'

Starting kernel ...

I tried to cleanup and rebuild the kernel and then replace uImage in resin-boot.img.:

DEVELOPMENT_IMAGE=1 MACHINE=qsmp1570-qsbase1 bitbake -c cleansstate virtual/kernel
DEVELOPMENT_IMAGE=1 MACHINE=qsmp1570-qsbase1 bitbake virtual/kernel

The kernel boot and stop where it need root partiton. So I guess the kernel is working but it is missing some balena code. The size of uImage is smaller. When I rebuild Balena with the barys script I still get that CRC error. Now both uImage look similar but size differ alot.

barys build uImage

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x57D5F28B, created: 2021-01-23 15:04:06, image size: 12339328 bytes, Data Address: 0xC2000040, Entry Point: 0xC2000040, data CRC: 0xFCBE0A27, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-5.10.10"
64            0x40            Linux kernel ARM boot executable zImage (little-endian)
2532          0x9E4           device tree image (dtb)
29440         0x7300          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

bitbake built uImage

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0x38C47040, created: 2021-01-23 15:04:06, image size: 7919648 bytes, Data Address: 0xC2000040, Entry Point: 0xC2000040, data CRC: 0x3E919E2E, OS: Linux, CPU: ARM, image type: OS Kernel Image, compression type: none, image name: "Linux-5.10.10"
64            0x40            Linux kernel ARM boot executable zImage (little-endian)
2532          0x9E4           device tree image (dtb)
29440         0x7300          gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)

… so what differ barys script with just use bitbake? I need to know where to check to troubleshoot.

I’am getting closer…

The size difference was all about with or without initramfs.

The kernel is not generated in same directory as balena image. It is deployed into a subdirectory called kernel by meta-st-stm32mp.

kernel-image-initramfs couldn’t find it so I overrided do_install() with correct path and the balena image was created correctly.
The problem is that something happen to that uImage file before it get added to resin-boot.img as size increase and binwalk report one more row:
6337799 0x60B507 CRC32 polynomial table, little endian

I guess this is why CRC check fails. If I replace uImage in resin-boot.img with the on in the subdirectory kernel it work.

1 Like

Nice progress on this one @Ankan! I am not familiar with that CRC issue, but for testing purposes, is there a way to disable CRC checks? (Yes, ideally, it would be better to solve that properly…I am just curious if you can work around to test the rest of the process, and see if the kernel loads, then RootFS, and you get a booting system).

After some cleaning and modifications in recipes it I got it working. Sadly, I don’t know what solved it. But now it is working.