Linux kernel 地址ZTEXTADDR在ARM Linux引导中的应用

ZTEXTADDR在Linux内核中扮演什么角色

从，它是RAM中的一个地址，它保存着zImage的地址，如下所示

A.

uImage (DataFlash/NAND) ---load_to_RAM---> 
 uImage (@ boot_addr) ---decompress_uImage--> 
  zImage (@ ZTEXTADDR) --- decompress_zImage---> 
   uncompressed image (@ ZRELADDR).

uImage (DataFlash/NAND) ---load_to_RAM---> 
 uImage (@ boot_addr) ---decompress_uImage--> 
  uncompressed image (@ ZRELADDR)

或者只是：

B.

uImage (DataFlash/NAND) ---load_to_RAM---> 
 uImage (@ boot_addr) ---decompress_uImage--> 
  zImage (@ ZTEXTADDR) --- decompress_zImage---> 
   uncompressed image (@ ZRELADDR).

uImage (DataFlash/NAND) ---load_to_RAM---> 
 uImage (@ boot_addr) ---decompress_uImage--> 
  uncompressed image (@ ZRELADDR)

---

没有在新内核版本中使用ZTEXTADDR来引导进程？

Linux ARM解压引导加载程序在从RAM运行时能够重新定位自身。重定位部分是PC相关的，因此可以在任何地址加载。但是，如果您的主映像从FLASH/ROM启动，则无法重新定位代码；虽然在RAM中移动图像是一个简单的

memmove（）

，但对于NOR闪存来说，它要复杂得多，对于ROM来说可能是不可能的

在中，a与ZTEXTADDR一起用作解压缩代码的位置。在图中，您有一个u-boot，它将加载uImage。没有理由直接从闪存/ROM执行此操作。u-boot可以将映像复制到RAM，并且不需要ZTEXTADDR值，它应该保留为零

如果您的映像直接从Flash/ROM引导，而不使用引导加载程序，那么ZTEXTADDR非常有用

 zImage (in flash) --> decompress vmlinux.bin to RAM --> run kernel

---

zImage可能需要使用一些芯片设置进行注释，才能正常工作，并且需要ATAGS或设备树链接。由于这个原因，有许多机器的变种；这是不可维护的，不鼓励使用这些类型的文件。通常，另一个引导加载程序将映像加载到RAM中，zImage可以将自己移动到它需要的任何目的地；我认为这就是您的情况，您应该将ZTEXTADDR设置为零，然后忘记它。

谢谢您的回答。因此，如果使用ZTEXTADDR，那么我们是否需要地址ZRELADDR？通常ZRELADDR现在是自动的。看见自动代码获取PC并屏蔽高7位。ZRELADDR用作内核映像的最终物理地址（解压缩到RAM）。但是，这已在中设置，并且必须与

virt\u to\u phys（）

宏相匹配。如果可能的话，最好不要使用它。你的意思是：如果直接从ROM/Flash启动，那么ZTEXTADDR是ROM/Flash中解压器代码（zImage）的物理地址？解压器代码将把ROM/Flash中的zImage解压到RAM中的ZRELADDR，其中是解压图像的地址（vmlinux.bin）？您提到的宏是：

\uu virt\u to\u phys（TEXTADDR）=ZRELADDR

？在直接ROM/闪存解压缩到RAM的情况下

ZTEXTADDR

是ROM的物理地址，

ZRELADDR

是RAM的物理地址；我们还需要一个ZBOOT_ROM_BSS用于解压缩RAM。没有MMU或

virt_to_phys（）

；对于RAM到RAM的情况，只要代码在RAM区域内，它就会移动到它喜欢的任何地方；MMU可以重新映射东西。在RAM到RAM的情况下，代码可以检查它从何处运行（物理），并计算出虚拟内存的移动位置。