u-boot:即使内核小于最大BOOTM_LEN,也无法引导linux内核 [英] u-boot: cannot boot linux kernel despite kernel being less than maximum BOOTM_LEN

查看:336
本文介绍了u-boot:即使内核小于最大BOOTM_LEN,也无法引导linux内核的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个带有u-boot的MIPS系统(VSC7427),我正在尝试引导一个比供应商在其GPL版本中提供的内核更新的内核(该内核

I have a MIPS system (VSC7427) with u-boot and I am trying to boot a more recent kernel than the kernel provided by the vendor in their GPL release (which boots just fine).

内核FIT映像似乎是健全的,从输出来看,我认为它应该是可引导的:

The kernel FIT image appears to be sane, and judging by the output I think it should be bootable:

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 - b2:6b:53:af:2d:a0
eth0: switch@1010000
luton # dhcp
(snipped)
luton # tftp vmlinux.gz.itb
Using switch@1010000 device
TFTP from server 192.168.1.60; our IP address is 192.168.1.154
Filename 'vmlinux.gz.itb'.
Load address: 0x80100000
Loading: #################################################################
(snipped)
done
Bytes transferred = 5172244 (4eec14 hex)
luton # iminfo 0x80100000

## Checking Image at 80100000 ...
   FIT image found
   FIT description: Linux 5.11.11
    Image 0 (kernel@0)
     Description:  Linux 5.11.11
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x801000c0
     Data Size:    5167511 Bytes = 4.9 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x80100000
     Entry Point:  0x809898f4
     Hash algo:    sha1
     Hash value:   b963ed48f45e332bd5df263dd69d69c3818e6586
    Image 1 (fdt@luton_pcb091)
     Description:  MSCC Luton PCB091 Device Tree
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x805edb60
     Data Size:    2851 Bytes = 2.8 KiB
     Architecture: MIPS
     Hash algo:    sha1
     Hash value:   5283ae4322294e594a7be5e6de65e4f039ff36a5
    Default Configuration: 'conf@default'
    Configuration 0 (conf@default)
     Description:  Generic Linux kernel
     Kernel:       kernel@0
    Configuration 1 (pcb091)
     Description:  Luton Linux kernel
     Kernel:       kernel@0
     FDT:          fdt@luton_pcb091
## Checking hash(es) for FIT Image at 80100000 ...
   Hash(es) for Image 0 (kernel@0): sha1+ 
   Hash(es) for Image 1 (fdt@luton_pcb091): sha1+

但是,当我尝试引导内核时,u-boot出现以下错误:

However, when I attempt to boot the kernel, u-boot gives the following error:

luton # bootm 0x80100000
## Loading kernel from FIT Image at 80100000 ...
   Using 'conf@default' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.11
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x801000c0
     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
Error: inflate() returned -3
gzip compressed: uncompress error -1
Must RESET board to recover

内核大小远低于 CONFIG_SYS_BOOTM_LEN (16MB),所以我不认为这是此错误的根本原因.

The size of the kernel is well below the limit defined by CONFIG_SYS_BOOTM_LEN (16MB) so I don't believe that is the root cause of this error.

用于生成 itb vmlinux.bin.gz 是有效的gzip存档,并且解压缩后的大小也小于 CONFIG_SYS_BOOTM_LEN 限制:

The vmlinux.bin.gz used to generate the itb is a valid gzip archive and the decompressed size is also less than the CONFIG_SYS_BOOTM_LEN limit:

$ file vmlinux.bin.gz
vmlinux.bin.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 11494800

我尝试使用未压缩的 vmlinux.bin 创建 itb 文件(我只是编辑了 vmlinux.its 以包含 data=/incbin/("vmlinux.bin"); compression ="none"; 以及 readelf -h vmlinux 指示的入口地址)但是尝试启动时收到以下错误:

I have tried creating the itb file using the uncompressed vmlinux.bin (I simply edited vmlinux.its to have data = /incbin/("vmlinux.bin"); and compression = "none"; and the entry address indicated by readelf -h vmlinux) but I receive the following error when trying to boot:

luton # bootm ${loadaddr}
## Loading kernel from FIT Image at 80100000 ...
   Using 'conf@luton_pcb091' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.0
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x801000c0
     Data Size:    11584912 Bytes = 11 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x80100000
     Entry Point:  0x809898f4
     Hash algo:    sha1
     Hash value:   d13175476fd38269a02a3e85bef53419092c01e1
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 80100000 ...
   Using 'conf@luton_pcb091' configuration
   Trying 'fdt@luton_pcb091' fdt subimage
     Description:  img,luton_pcb091 Device Tree
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x80c0c758
     Data Size:    2303 Bytes = 2.2 KiB
     Architecture: MIPS
     Hash algo:    sha1
     Hash value:   daa8a8147bbce692d81383af7b748a763212bb24
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x80c0c758
   Loading Kernel Image
ERROR: new format image overwritten - must RESET the board to recover

查看 common/bootm.c 中的 bootm_load_os ,看来这个错误告诉我我要引导的内核之间有一些重叠...某事,我不确定是什么.

Looking at bootm_load_os in common/bootm.c it appears that this error is telling me that there is some overlap between the kernel I'm trying to boot and... something, I'm not sure of what.

这是内核5.11生成的 vmlinux.its :

Here is vmlinux.its generated by kernel 5.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";
  };
 };
};

binwalk 并不表示ITB中的 gzip 数据无效:

binwalk doesn't indicate that the gzip data in the ITB is invalid:

$ binwalk vmlinux.gz.itb 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             device tree image (dtb)
192           0xC0            gzip compressed data, maximum compression, from Unix, last modified: 1970-01-01 00:00:00 (null date)
3960903       0x3C7047        MySQL ISAM compressed data file Version 10
5167968       0x4EDB60        device tree image (dtb)

mkimage版本2020.01 由buildroot作为 host-uboot-tools-2020.01

mkimage version 2020.01 is built by buildroot as part of host-uboot-tools-2020.01

根据Tom Rini的建议,我更改了FIT映像的loadaddr,并且不再收到 uncompress 错误,但是系统仍然没有启动.我已将其移至后续问题.

As per the suggestion from Tom Rini, I changed the loadaddr of the FIT image and no longer receive the uncompress error, however the system still does not appear to boot. I've moved this to a follow up question.

推荐答案

您遇到的最后一个问题:

The final problem you run in to:

错误:新格式的图片已被覆盖-必须重置板才能恢复

ERROR: new format image overwritten - must RESET the board to recover

是因为您已将映像加载到与入口点相同的位置的内存中,但需要将其加载到其他位置的内存中,以便U-Boot可以解压缩映像并将内容放置在其加载地址中设定为.由于您有128MB的内存,因此应该可以从一开始就将其设置为+32或+ 64MB,然后一切正常.

is because you've loaded the image in to memory in the same location as the entry point but you need to load it in to memory somewhere else so that U-Boot can unpack the image and put the contents where their load address is set to. Since you have 128MB of memory you should be able to put it at +32 or +64MB from start and then things should work.

这篇关于u-boot:即使内核小于最大BOOTM_LEN,也无法引导linux内核的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆