u-boot hangs at “Uncompressing/Loading Kernel Image”

Question

This is a follow up to a previous question ( u-boot: cannot boot linux kernel despite kernel being less than maximum BOOTM_LEN ) on the same platform (MIPS VSC7427).

I am trying to boot Linux 5.11 and u-boot hangs at "Uncompressing Kernel Image" (gzip compression):

U-Boot 2019.10 (Mar 28 2021 - 20:41:55 +0000)

MSCC VCore-III MIPS 24Kec
Model: Cisco Meraki MS220-8P
DRAM:  128 MiB
Loading Environment from SPI Flash... SF: Detected mx25l12805d with page size 256 Bytes, erase size 64 KiB, total 16 MiB
OK
In:    serial@10100000
Out:   serial@10100000
Err:   serial@10100000
Net:   
Warning: switch@1010000 (eth0) using random MAC address - f6:22:ff:96:01:2d
eth0: switch@1010000
luton # setenv loadaddr 0x83000000
luton # dhcp
luton # tftp ${loadaddr} vmlinux.gz.itb
Using switch@1010000 device
TFTP from server 192.168.1.60; our IP address is 192.168.1.164
Filename 'vmlinux.gz.itb'.
Load address: 0x83000000
Loading: #################################################################
(snipped)
done
Bytes transferred = 5172240 (4eec10 hex)
luton # bootm 0x83000000
## Loading kernel from FIT Image at 83000000 ...
   Using 'conf@default' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.11
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x830000c0
     Data Size:    5167511 Bytes = 4.9 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x80100000
     Entry Point:  0x809898f4
     Hash algo:    sha1
     Hash value:   b963ed48f45e332bd5df263dd69d69c3818e6586
   Verifying Hash Integrity ... sha1+ OK
   Uncompressing Kernel Image

Trying to boot an uncompressed vmlinux results in u-boot hanging at "Loading Kernel Image":

luton # setenv loadaddr 0x83000000
luton # setenv fdtaddr 0x85000000
luton # dhcp
luton # tftp ${loadaddr} vmlinux.bin
luton # tftp ${fdtaddr} ms220.dtb
luton # bootm ${loadaddr} - ${fdtaddr}
## Booting kernel from Legacy Image at 83000000 ...
   Image Name:   Linux 5.11.11
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    11531664 Bytes = 11 MiB
   Load Address: 80100000
   Entry Point:  809898f4
   Verifying Checksum ... OK
## Flattened Device Tree blob at 85000000
   Booting using the fdt blob at 0x85000000
   Loading Kernel Image

I have looked at other questions regarding u-boot hanging at "Loading Kernel Image" and I don't believe the suggestions there (reading from addresses not in DRAM) apply to my situation.

The Kernel Load Address of 0x80100000 corresponds to CONFIG_SYS_SDRAM_BASE + CONFIG_SYS_LOAD_ADDR defined in u-boot , so I'm fairly certain I am loading from an address in RAM.

---

Using the same version of u-boot ( 2019.10 ) I am able to boot the 3.18.123 kernel built from the vendor's GPL source:

luton # tftpboot vmlinuz
Using switch@1010000 device
TFTP from server 192.168.1.60; our IP address is 192.168.1.157
Filename 'vmlinuz'.
Load address: 0x81000000
Loading: #################################################################
(snipped)
done
Bytes transferred = 1578176 (1814c0 hex)
luton # bootm ${load_addr}
## Booting kernel from Legacy Image at 81000000 ...
   Image Name:   Linux 3.18.123
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    1578112 Bytes = 1.5 MiB
   Load Address: 81000000
   Entry Point:  81000000
   Verifying Checksum ... OK
   Loading Kernel Image
[    0.000000] Linux version 3.18.123-meraki-elemental (hmartin@alp) (gcc version 5.4.0 (GCC) ) #36 Tue Apr 14 20:11:18 UTC 2020

(I seem to recall needing to change the Kernel Load Address from 0x80100000 to 0x81000000 for in-kernel decompression to work, but otherwise it boots just fine)

---

The its file used to generate the FIT image for kernel 5.11.11:

/* SPDX-License-Identifier: GPL-2.0 */
/dts-v1/;
/ {
 description = "Linux 5.11.11";
 #address-cells = <1>;
 images {
  kernel@0 {
   description = "Linux 5.11.11";
   data = /incbin/("vmlinux.bin.gz");
   type = "kernel";
   arch = "mips";
   os = "linux";
   compression = "gzip";
   load = /bits/ 32 <0xffffffff80100000>;
   entry = /bits/ 32 <0xffffffff809898f4>;
   hash@0 {
    algo = "sha1";
   };
  };
 };
 configurations {
  default = "conf@default";
  conf@default {
   description = "Generic Linux kernel";
   kernel = "kernel@0";
  };
 };
};
/* SPDX-License-Identifier: (GPL-2.0 OR MIT) */
/ {
 images {
  fdt@luton_pcb091 {
   description = "MSCC Luton PCB091 Device Tree";
   data = /incbin/("boot/dts/mscc/luton_pcb091.dtb");
   type = "flat_dt";
   arch = "mips";
   compression = "none";
   hash@0 {
    algo = "sha1";
   };
  };
 };
 configurations {
  pcb091 {
   description = "Luton Linux kernel";
   kernel = "kernel@0";
   fdt = "fdt@luton_pcb091";
  };
 };
};

---

Trying either of the following earlycon boot arguments has zero effect:

luton # setenv bootargs console=ttyS0,115200 earlycon=uart,mmio,0x10100000 mem=134152192
luton # setenv bootargs console=ttyS0,115200 earlycon=uart,mmio,0x70100000 mem=134152192

( 0x10100000 is the uart offset in the ahb section of the kernel dts and in u-boot , 0x70100000 is the UART base address used in the vendor kernel )

---

The mkimage command used to generate the uncompressed 5.11 kernel image:

mkimage -A mips -O linux -T kernel -C none -a 0x80100000 -e $(readelf -h vmlinux | grep "Entry point address" | awk '{print $4}') -n "Linux 5.11.11" -d arch/mips/boot/vmlinux.bin /var/lib/tftpboot/vmlinux.bin

mkimage version 2020.01

Answer 1

I have limited experience in using FIT, so my observation below could be wrong. Anyhow, it looks to me like the first image of your ftb is being used, which in turn has a configuration which does not include a device tree. You are basically loading a kernel without any information about the hardware (such as where and how to access the uart for the serial console), right? More specifically, I think the kernel needs the "chosen" node (eg stdout-path) as described here https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt

I'm in a similar situation (developing a board based on a similar "luton" SoC from Vitesse->Microsemi->Microchip, VSC7425). I'm not having any problems booting linux 5.9 with u-boot 2021.07. Then again, it's not exactly the same hardware nor software.

You could try to move your device tree sub-image into the first image, and replace the first configuration with what is found in the second one.