linux解压arm,如何在解压缩失败时找到ARM Linux入口点？

sawdust..

7

我们似乎成功移植了Das U-Boot.

有证据表明这是一个错误的假设.

在调用内核之前,指针theKernel是10008000而不是10800000.

您使用的是哪个版本的U-Boot？

在2012.10和2013.04版本的U-Boot中,该变量theKernel仅由AVR32和MIPS等拱门的代码声明和使用.

没有应该使用的ARM代码theKernel.

u-boot-2012.10$ find . -print | xargs grep theKernel

./arch/avr32/lib/bootm.c: void (*theKernel)(int magic, void *tagtable);

./arch/avr32/lib/bootm.c: theKernel = (void *)images->ep;

./arch/avr32/lib/bootm.c: theKernel, params_start);

./arch/avr32/lib/bootm.c: theKernel(ATAG_MAGIC, params_start);

./arch/microblaze/lib/bootm.c: void (*theKernel) (char *, ulong, ulong);

./arch/microblaze/lib/bootm.c: theKernel = (void (*)(char *, ulong, ulong))images->ep;

./arch/microblaze/lib/bootm.c: (ulong) theKernel, rd_data_start, (ulong) of_flat_tree);

./arch/microblaze/lib/bootm.c: theKernel (commandline, rd_data_start, (ulong) of_flat_tree);

./arch/mips/lib/bootm.c: void (*theKernel) (int, char **, char **, int *);

./arch/mips/lib/bootm.c: theKernel = (void (*)(int, char **, char **, int *))images->ep;

./arch/mips/lib/bootm.c: (ulong) theKernel);

./arch/mips/lib/bootm.c: theKernel(linux_argc, linux_argv, linux_env, 0);

./arch/mips/lib/bootm_qemu_mips.c: void (*theKernel) (int, char **, char **, int *);

./arch/mips/lib/bootm_qemu_mips.c: theKernel = (void (*)(int, char **, char **, int *))images->ep;

./arch/mips/lib/bootm_qemu_mips.c: (ulong) theKernel);

./arch/mips/lib/bootm_qemu_mips.c: theKernel(0, NULL, NULL, 0);

./arch/nds32/lib/bootm.c: void (*theKernel)(int zero, int arch, uint params);

./arch/nds32/lib/bootm.c: theKernel = (void (*)(int, int, uint))images->ep;

./arch/nds32/lib/bootm.c: (ulong)theKernel);

./arch/nds32/lib/bootm.c: theKernel(0, machid, bd->bi_boot_params);

u-boot-2012.10$

请解释如何跟踪不应在ARM处理器上定义或分配的变量.

U-Boot打印"Starting kernel ..."后的下一个输出应该是"Uncompressing Linux ...".

对于飞思卡尔拱门,此文本输出取决于machine type number(arch_id通过)U-Boot到内核的正确传递.

您需要验证是否machine type number在U-Boot中正确定义了这一点.

U-Boot的配置文件是什么样的？

我尝试添加一些寄存器操作代码来发送压缩/ head.S中的GPIO信号,但没有响应.

您是否理智检查此代码以确保其按预期工作？

您是否从U-Boot命令行尝试了GPIO操作？

我的问题是,我怎样才能确保U-Boot正在调用正确的入口点？

对于ARM arch,它是跳转到bootm命令中指定的地址.

由于uImage加载地址和bootm指定相同的0x10800000地址,因此应该是好的(假设U-Boot已正确配置并为ARM构建).

在调用内核之前,指针theKernel是10008000而不是10800000.这是否意味着U-boot在错误的位置跳转？

是.

如果检查源代码(对于AVR32或MIPS),您会发现它theKernel是从映像头分配的,特别是入口点值.然后U-Boot会跳转到这个位置.

但真正的问题是你的ARM Cortex A9不应该使用这个代码或这个变量.

似乎没有为正确的拱门配置U-Boot和/或可能无法正确定义机器类型.

更正:

正如OP指出的那样,旧版本的U-Boot确实使用了变量,theKernel即使对于ARM拱形也是如此.

U-Boot输出行:

Loading Kernel Image ... OK

表示U-Boot已经(成功)将内核映像(没有映像信息头)从bootm0x10800000 的地址(加上报头长度的偏移量0x40 )复制到加载地址0x10008000.此存储器移动操作由程序执行bootm_load_os()在公共/ cmd_bootm.c.

因此,您报告的0x10008000的值是正确的theKernel.

没有迹象表明U-Boot跳到了错误的位置.

如前所述,您应该验证是否正确定义了机器类型.该值将__arch_decomp_setup()在arch/arm/plat-mxc/include/mach/uncompress.h中使用, 以便在内核引导之前的解压缩期间输出文本.