Linux内核初始化中未调用内置平台驱动程序__initcall

背景

我正在通过Yocto提出一些供应商提供的嵌入式硬件的Linux内核。我已将映像配置为通过具有initramfs且没有rootfs的fitImage进行引导（存在持久存储，但这完全供用户空间应用程序使用）。考虑一下PXE实时图像，您就不会遥不可及。

一切进展顺利，直到我的initramfs图片超过了〜128MB。在此之下，一切都会按预期启动，并且所有驱动程序均无问题地绑定。在此标记之上，内核仍会引导，但许多驱动程序（虽然不是全部）没有绑定。这是非常令人困惑的，因为所有驱动程序都是静态内置在内核中的（此平台上未使用任何模块）。不幸的是，这些模块之一运行平台监视程序，这会导致完全可预测的重启。

到目前为止，我已经验证了所有符号都存在于vmlinux映像中：

$ objdump -x vmlinux | grep mtk_wdt
0000000000000000 l    df *ABS*  0000000000000000 mtk_wdt.c
ffffff800880ac40 l     F .text  000000000000004c mtk_wdt_stop
ffffff800880ac90 l     F .text  0000000000000040 mtk_wdt_shutdown
ffffff80091de778 l     F .init.text     0000000000000020 mtk_wdt_driver_init
ffffff800880acd0 l     F .text  000000000000004c mtk_wdt_ping
ffffff800880ad20 l     F .text  0000000000000070 mtk_wdt_set_timeout
ffffff800880ad90 l     F .text  0000000000000074 mtk_wdt_start
ffffff800880ae08 l     F .text  0000000000000144 mtk_wdt_resume
ffffff800880af50 l     F .text  0000000000000120 mtk_wdt_suspend
ffffff800880b070 l     F .text  0000000000000080 mtk_wdt_remove
ffffff80088977a8 l     F .text  0000000000000210 mtk_wdt_isr
ffffff80091fe0a0 l     F .exit.text     000000000000001c mtk_wdt_driver_exit
ffffff800880b4f0 l     F .text  0000000000000310 mtk_wdt_probe
ffffff8008c2acd8 l     O .rodata        0000000000000028 mtk_wdt_info
ffffff8008c2ad00 l     O .rodata        0000000000000050 mtk_wdt_ops
ffffff8008c2ad98 l     O .rodata        00000000000000b8 mtk_wdt_pm_ops
ffffff8008c2ae50 l     O .rodata        0000000000000190 mtk_wdt_dt_ids
ffffff80093a3cb8 l     O .data  00000000000000b0 mtk_wdt_driver
ffffff800a199368 l     O .bss   0000000000000008 mtk_wdt1
ffffff8009285598 l     O .init.data     0000000000000008 __initcall_mtk_wdt_driver_init6

另外，我在fitImage程序集之前，fitImage程序集之后和解压缩到系统内存后（通过引导加载程序）中都有二进制内核（例如linux.bin），initramfs和设备树的sha256校验和。全部匹配。据我所知，构建的是打开包装并启动的东西。

此外，我已经启用了，initcall_debug并且在看到其他__initcall（）时，毫无疑问，缺少了非绑定驱动程序。

我知道设备存在于设备树中并已正确配置。启动后，在看门狗启动之前，我获得了大约5秒钟的控制台访问权限。只有足够的时间来执行一两个命令。在“有效”映像（initramfs <〜128MB）和失败映像（initramfs>〜128MB）上，/sys/bus/platform/devices它们的内容相同，并且可以看到我的看门狗（除其他外）：

$ ls -lha /sys/bus/platform/devices
...
lrwxrwxrwx 1 root root 0 Jan  1 00:00 10007000.watchdog -> ../../../devices/platform/10007000.watchdog

执行相同的测试，但进行比较/sys/bus/platform/devices显示未__initcall（）缺失的驱动程序。

我检查了一些集体的其他东西：

• 设备树。在工作图像和损坏图像中都使用了相同的DTB。我还如上所述验证了设备树在内存中。不使用设备树覆盖。
• 实际内存加载偏移量。一切都应该存在，并且每个区域都有足够的空间。我可以在内存中移动内核，无论位置在哪里，问题仍然存在。
• 记性不好。此故障在多个单元上相同地发生。
• 压缩不良。无论内核/ initramfs压缩如何，问题都会显现。目前，我正在测试所有未压缩的东西，以最大程度地减少破损点。
• 错误的签名。我已经禁用签名验证（毕竟适用于fitImage分区图像）；那里也没有骰子。
• 尝试将initramfs直接捆绑到内核中。没变化。现在，我将initramfs内置到fitImage中，但否则将单独加载和验证。
• 错误的内核命令行参数。我正在使用root=/dev/ram initrd=0x48000000,384M并且一直跟踪到init/initramfs.c完成拆包的位置。我能够验证传递的偏移量确实在正确的虚拟内存空间中，总和为384M。
• 根据此论坛帖子更新内核链接程序脚本。我能够.initramfs通过objdump看到vmlinux中生成的部分，但是问题仍然存在。

鉴于以上所有内容，我唯一不知道如何验证的是从vmlinux到linux.bin的跳转。这是通过Yocto通过objcopy完成的，如下所示：

[ -n "${vmlinux_path}" ] && ${OBJCOPY} -O binary -R .note -R .comment -S "${vmlinux_path}" linux.bin

问题

1. 如何验证给定的符号包含在最终的linux.bin中？
2. 哪些机制会在构建时影响给定符号的包含或排除？
3. initramfs大小会影响内核构建和运行时的哪些部分？
4. 还有其他工具/技术/部落智慧可以帮助调试这种情况吗？

编辑1：

下面是所有内存和空间利用率的基本内存映射。如上所述，在注释中，我可以将内核，DTB和initramfs重定位到（几乎）任意位置，但是问题仍然存在。

0x40000000 - 0x40001000 = Bootloader arg area (Fixed usage)
0x40080000 - 0x41EDFFFF = Kernel (~12MB / 29.5MB used)
0x41E00000 - 0x42FF5FFF = Trampoline (96 bytes / ~6MB used)
0x42FF6000 - 0x42FFFFFF = ATF BL3-1 (Fixed usage)
0x43000000 - 0x43FFFFFF = Trusted OS (~476K / 16M used)
0x44000000 - 0x44FFFFFF = DTB (~77.3K / 16M used)
0x45000000 - 0x47FFFFFF = Trusted OS memory (dynamic)
0x48000000 - 0x5FFFFFFF = Initramfs (~129MB / 384MB used)
0x60000000 - MEM END    = Free