之前遇到过过年期间整理一下。主要涉及到的内容就是VMlinuxuimagezimage。镜像格式本质属性是否压缩是否带头部信息主要应用场景vmlinux纯静态链接的 ELF 可执行文件❌ 否❌ 纯 ELF 结构有 ELF Header符号表调试、GDB 源码级调试、汇编分析zImage自解压的二进制压缩内核压缩 (通常 gzip/lz4)❌ 包含简易的自解压头Decompressor stub传统的 ARM 32位架构引导、直接由 Bootloader 跳转启动uImage带特定头部信息的zImage压缩带 64 字节的U-Boot 专用头部U-Boot 引导程序、老牌嵌入式 Linux 板卡1 VMlinux就是linux内核编译生成文件virtual memory linux。这居然打包成一个exe还是elf格式的。看了下资料可以通过启动gdb对VMlinux也就是linux内核进行调试。特点如下未压缩包含了完整的符号表Symbol Table、调试信息、段表Text、Data、BSS 等。体积巨大因为它没有被压缩且包含了调试符号。无法直接在裸机上运行硬件的 Bootloader 通常无法直接解析复杂的 ELF 格式并将其加载到指定物理地址运行它需要纯二进制机器码。2 zimage为了适应嵌入式设备较小的 Flash 存储空间和更快的加载速度开发者将 vmlinux 通过 objcopy 转成纯二进制vmlinux.bin再用 gzip 等算法进行压缩并在前面加上一段极简的自解压引导汇编代码最终打包成 zImage。就是对VMlinux打包的产物看介绍是使用的gzip。运行时会把image解压到内存中。自解压能力zImage内部集成了“解压代码”。当 Bootloader 将它加载到 RAM 并跳转执行时它会先将自己解压到内存的高地址或指定解压区然后把控制权交给解压后的内核。体系结构关联这个名字最常出现在ARM 32位ARMv7 及以前架构中例如经典的arch/arm/boot/zImage。zimage死死绑定了32位 ARM 架构。现在基本上被淘汰了。3 uimage在早期的 U-Boot 引导时代U-Boot 无法直接识别标准的 zImage因为它不认识 zImage 的头部结构于是 U-Boot 官方设计了一个专用工具 mkimage。所以在zimage的基础上增加了一个头。有比如校验信息内核入口参数等。主要起到简化配置的作用。使用mkimage命令生成。在每个平台上可能会定制不同的信息。64 字节头部uImagezImage64 字节的 U-Boot 专属头部Header。头部信息包含镜像名称、生成时间戳、数据大小、加载地址Load Address、入口地址Entry Point、CRC32 校验和以及压缩类型。U-Boot 在加载时会先读取这 64 字节的头部校验 CRC32 是否正确然后根据里面的“加载地址”把后面的内核数据搬运到正确的 RAM 位置最后跳过去执行。不过现在uimage也差不多要淘汰了原因如下现代的 U-Boot 已经变得极其强大原生直接支持识别未压缩的纯二进制镜像如 ARM64 的Image、直接支持 Gzip 压缩包如Image.gz甚至支持更现代的FIT 镜像.itb。冗余的 64 字节头uImage强行加的那 64 字节头部在现代 Bootloader 眼中已经成了多余的“累赘”。4 Image在现代的 64 位架构如 ARM64 / AArch64或现代 Linux 内核发展中uImage 已经逐渐退出了历史舞台。ARM64 统一使用更标准的 Image纯内核二进制或 Image.gzGzip 压缩内核并通过 FIT 图像格式Flattened Image Tree, .itb 或 UEFI 规范来进行多组件内核、设备树 DTB、根文件系统的统一打包与引导。Image是将vmlinux 去除掉所有的 ELF 头、调试符号和未用段之后使用 objcopy 转换出来的纯二进制机器码Raw Binary。ARM6464位在 ARM64 架构下内核编译出来的核心产物就是Image。ARM64 的Image头部有一个 64 字节的标准 Header包含了魔数ARM\x64、内核加载偏移量等Bootloader如现代 U-Boot读取这个 Header 就能直接将其加载到物理内存的对应地址运行。未压缩它本身是不压缩的。如果需要节省存储通常会使用gzip手动压缩生成Image.gz。现代 64 位 ARM 架构如高通、联发科、全志、树莓派 4/5 等的主流内核镜像。最后三者关系如下Linux Kernel-VMlinux-zimage-uimage参考linux之vmlinux、vmlinuz、System.map和/proc/kallsyms简介-CSDN博客