我正在处理android boot.img，它是压缩内核、ramdisk和dtb的组合。我从uboot的串行控制台日志中看到了引导过程，下面是引发我好奇的
CPU: Freescale i.MX6Q rev1.2 at 792 MHz
CPU: Temperature 27 C
Reset cause: POR
Board: MX6-SabreSD
I2C: ready
DRAM: 1 GiB
PMIC: PFUZE100 ID=0x10
MMC: FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In: serial
Out: serial
Err: serial
check_and_clean: reg 0, flag_set 0
Fastboot: Normal
flash target is MMC:1
Net: FEC [PRIME]
Normal Boot
Hit any key to stop autoboot: 3 2 1 0
boota mmc1
kernel @ 14008000 (7272352)
ramdisk @ 15000000 (869937)
fdt @ 14f00000 (44072)
## Booting Android Image at 0x12000000 ...
Kernel load addr 0x14008000 size 7102 KiB
Kernel command line: console=ttymxc0,115200 init=/init video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32 video=mxcfb1:off video=mxcfb:off video=mxcfb3:off vmalloc=256M androidboot.console=ttymxc0 consolebalank=0 androidboot.hardware=freescale cma=384M
## Flattened Device Tree blob at 14f00000
Booting using the fdt blob at 0x14f00000
Loading Kernel Image ... OK
Using Device Tree in place at 14f00000, end 14f0dc27
switch to ldo_bypass mode!
Starting kernel ...
内核的地址是14008000，ramdisk 15000000，fdt 14f00000。我发现这些值保存在boot.img头中，当我手动处理这些值时，即使实际内容没有修改，图像也不会启动。
为什么这个地址如此关键？为什么必须是这些价值观？为什么没有其他价值观呢？
我自己的一个猜测是：这些加载地址值是在内核中硬编码的，所以如果我在boot.img头中更改它，就会产生副作用。为了详细阐述我自己的理论，将内核加载到"修改的"加载地址不会有问题。但是，当实际执行这些行时，它会导致严重的问题，因为这些代码被修复为使用正确的"加载地址"。
我的理论错了吗？如果是的话，如果你能纠正我，我将不胜感激。
U引导完成后，它需要将进一步的执行移交给内核，以便内核负责所有进一步的进程。此外，内核有一些例程，这是初始化板必不可少的。
这组例程有一个入口点start_kernel（）。在此之前，还调用一些其他例程来执行start_kernel。可以通过这个链接器脚本和这个init来识别。S.
为了在这个过程中保持执行，内核需要从一个特定的地址开始，此外，它的数据段和其他存储器也与之相连，以便以适当的方式加载和运行所有这些，需要提供准确的存储器位置。
有了这个内核，需要设备树blob来探测连接到它的设备，需要rootfs来打开用户空间，在这里加载设备树和rootfs需要精确的偏移量，这样任何数据都不会丢失或损坏。每一个字节对所有这些执行都很重要。
因此，为了安全地引导，所有这些值都存储在引导加载程序的配置中。