NanoPi K2 (Amlogic S905) 解决自行编译内核无法启动问题
NanoPi K2 (Amlogic S905) 解决自行编译内核无法启动问题
前言
第一次拿到NanoPi K2开发板是几个月之前了，当时就出现了使用store固件正常，下载的内核源码不做任何修改，编译后下载进去Android系统无法启动。当时还记录了文档NanoPi K2 (Amlogic S905) 自行编译内核启动不起来，并邮件咨询厂家，他们一直觉得是我个人的问题，出于不想当新产品的小白鼠的想法，当时这个问题就搁置在这了。最近不得硬着头皮再拾起来研究。
分析
由于我没有做任何改动，只是编译一下就启动不起来，这着实让人费解，怀疑过交叉工具链的问题，系统环境的问题等等，甚至想过是不是必须和Android系统一样新编译才可以。这些一个一个都排除了，还是没有找到问题。当时记录的文档NanoPi K2 (Amlogic S905) 自行编译内核启动不起来里有整个内核启动Log，这次也使用logcat查看了Android的Log，截取到了关键Log信息：
I/DEBUG ( 1797): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG ( 1797): Build fingerprint: 'Android/nanopi_k2/nanopi-k2:5.1.1/LMY48G/tony12261955:userdebug/dev-keys'
I/DEBUG ( 1797): Revision: '0'
I/DEBUG ( 1797): ABI: 'arm'
I/DEBUG ( 1797): pid: 2878, tid: 2878, name: surfaceflinger >>> /system/bin/surfaceflinger <<<
I/DEBUG ( 1797): signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
I/DEBUG ( 1797): Abort message: 'no suitable EGLConfig found, giving up'
I/DEBUG ( 1797): r0 00000000 r1 00000b3e r2 00000006 r3 00000000
I/DEBUG ( 1797): r4 f74b7e38 r5 00000006 r6 00000002 r7 0000010c
I/DEBUG ( 1797): r8 ab6de550 r9 00000000 sl 00000000 fp 00000001
I/DEBUG ( 1797): ip 00000b3e sp ffcbda30 lr f742514d pc f744a938 cpsr 600f0010
I/DEBUG ( 1797):
I/DEBUG ( 1797): backtrace:
I/DEBUG ( 1797): #00 pc 0003c938 /system/lib/libc.so (tgkill+12)
I/DEBUG ( 1797): #01 pc 00017149 /system/lib/libc.so (pthread_kill+52)
I/DEBUG ( 1797): #02 pc 00017d67 /system/lib/libc.so (raise+10)
I/DEBUG ( 1797): #03 pc 000144f5 /system/lib/libc.so (__libc_android_abort+36)
I/DEBUG ( 1797): #04 pc 000129f0 /system/lib/libc.so (abort+4)
I/DEBUG ( 1797): #05 pc 00007c55 /system/lib/libcutils.so (__android_log_assert+88)
I/DEBUG ( 1797): #06 pc 00028ad9 /system/lib/libsurfaceflinger.so
I/DEBUG ( 1797): #07 pc 000286d5 /system/lib/libsurfaceflinger.so
I/DEBUG ( 1797): #08 pc 00018a39 /system/lib/libsurfaceflinger.so (android::SurfaceFlinger::init()+148)
I/DEBUG ( 1797): #09 pc 00000af1 /system/bin/surfaceflinger
I/DEBUG ( 1797): #10 pc 000123a1 /system/lib/libc.so (__libc_init+44)
I/DEBUG ( 1797): #11 pc 00000c08 /system/bin/surfaceflinger
I/DEBUG ( 1797):
I/DEBUG ( 1797): Tombstone written to: /data/tombstones/tombstone_02由Log可以看到是surfaceflinger没有启动起来，这个是显示相关的。再结合之前了解到的自行编译的内核，系统中预置的内核模块加载不进去。其中和显示相关的是mali.ko这个是GPU的内核模块，位置是/boot/mali.ko。手动加载一下：
shell@nanopi-k2:/system # insmod /boot/mali.ko
[ 813.219045@0] module mali: unsupported RELA relocation: 275
insmod: init_module '/boot/mali.ko' failed (Exec format error)
shell@nanopi-k2:/system # 这个错误信息unsupported RELA relocation: 275成为了破案的关键。开始以为这是mali.ko模块里打印出来的呢，最后在内核里搜索了一下才知道其是内核中打印的。具体的位置在：arch/arm64/kernel/module.c的382行
int apply_relocate_add(Elf64_Shdr *sechdrs,
const char *strtab,
unsigned int symindex,
unsigned int relsec,
struct module *me)
{
/* Perform the static relocation. */
switch (ELF64_R_TYPE(rel[i].r_info)) {
/* Null relocations. */
case R_ARM_NONE:
case R_AARCH64_NONE:
ovf = 0;
break;
/* Data relocations. */
...
case R_AARCH64_CALL26:
break;
default:
pr_err("module %s: unsupported RELA relocation: %llu\n",
me->name, ELF64_R_TYPE(rel[i].r_info));
return -ENOEXEC;
}
...
return -ENOEXEC;
}这是一个switch语句，能进入default里，说明275应该是一个常量，搜索到在arch/arm64/include/asm/elf.h里
...
#define R_AARCH64_ADR_PREL_PG_HI21 275
...其在这个switch语句被CONFIG_ARM64_ERRATUM_843419宏给条件编译了，如下：
#ifndef CONFIG_ARM64_ERRATUM_843419
...
case R_AARCH64_ADR_PREL_PG_HI21:
ovf = reloc_insn_imm(RELOC_OP_PAGE, loc, val, 12, 21,
AARCH64_INSN_IMM_ADR);
break;
#endif
case R_AARCH64_ADD_ABS_LO12_NC:而这个CONFIG_ARM64_ERRATUM_843419正是y。经查这个配置的位置在：
Kernel Features --->
ARM errata workarounds via the alternatives framework --->
[ ] Cortex-A53: 843419: A load or store might access an incorrect address
将其去掉选中，重新编译内核后，按照wiki上的方法更新内核：
adb shell mount -t ext4 /dev/block/mmcblk0p1 /storage/sdcard1/
adb push arch/arm64/boot/Image /storage/sdcard1/
adb push arch/arm64/boot/dts/amlogic/nanopi-k2.dtb /storage/sdcard1/
adb reboot可以正常启动了，如下截图：
小结：
就这一行代码困扰好长时间，以后会遇到网上查不到的问题，不能心急，硬着头皮解决了也不错。厂家release源码的时候应该好好的验证，这样自家的板子才能有更多的人使用。