ZynqMP嵌入式Linux手工移植：弃用Petalinux，直通U-Boot与Kernel

简介针对ZynqMP平台的U-Boot与Kernel移植教程采用非Petalinux开发方式面向嵌入式驱动开发与底层系统工程师。其核心价值在于拆解了从交叉编译器aarch64-linux-gnu的设置到SDK内FSBL与PMU固件生成再到ATF可信固件编译、设备树文件修改、U-Boot定制与启动的完整链路。所有操作基于Xilinx官方GitHub源码并在自定义板卡上亲测可用特别包含了EMMC复位引脚改用GPIO模拟等实际工程经验。资料为单个PDF文档大小约5.89MB内容以图文步骤呈现环境变量配置、SDK工程建立、编译命令等均有截图说明便于快速落地。目前已有3335人学习下载对于希望摆脱Petalinux束缚、手动掌控ZynqMP启动流程的开发者是一份难得的实战参考。 手边这块ZynqMP板卡到手的时候我第一反应是装个Petalinux图省事结果被那套庞大的依赖体系和动辄几个小时的构建时间劝退了。后来换成纯手工方式做U-Boot和Kernel移植反而把整个启动链路看得清清楚楚。这篇东西就是我当时踩完坑之后的完整记录给同样不想被Petalinux绑住手脚的人一条更直接的路。1. 为什么放弃Petalinux选择纯手工移植Petalinux本质上是Xilinx对Yocto项目的一层封装它做的事情是帮你把U-Boot、内核、根文件系统、设备树生成一整条链路串起来。但这个封装带来了两个现实问题一是它对宿主机系统的要求非常苛刻2022.2版本只支持Ubuntu 20.04想在别的发行版上跑还得折腾容器二是它生成的代码对开发者隐藏了太多细节一旦板卡有非标准的定制需求你在它的配置体系里找问题会非常痛苦。非Petalinux方式说白了就是回到嵌入式Linux开发的本源交叉编译三样东西FSBL或者直接用U-Boot SPL、U-Boot、Kernel。这样做的核心优势有两个。第一是构建速度快增量编译一次内核只要几分钟而Petalinux每次打包动辄半小时起步。第二是可定制性强所有配置都是明文的defconfig和设备树源文件出了问题能直接定位到具体行。这种方式要求你对手头的硬件有足够了解至少要知道DDR型号、启动模式拨码、外设时钟频率这些基本信息。但说实话这些信息做任何移植工作都是必须掌握的基础Petalinux只是帮你把问问题的过程省掉了而不是把问题消掉了。2. 移植前的启动流程梳理从BootROM到U-BootZynqMP的启动流程和传统ARM SoC不太一样它不是BootROM直接加载U-Boot而是分阶段走的。搞清楚这条链路的每个环节后面的移植才不会盲目。2.1 ZynqMP的分级启动架构ZynqMP的启动分四个阶段。BootROM是芯片出厂固化的它根据Mode引脚的电平状态决定从哪启动QSPI、SD卡、JTAG都有可能。BootROM加载的是FSBL或U-Boot SPL这一级负责最基础的初始化包括DDR控制器、时钟PLL、MIO引脚复用。对于非Petalinux方案这里可以用Xilinx提供的FSBL但我个人建议直接用U-Boot SPL因为少一层固件就少一份维护负担。再往上就是ATFARM可信固件的BL31它运行在EL3特权级负责准备PSCI接口供内核调用CPU电源管理。最上层才是U-Boot本身运行在EL2它负责加载内核和设备树到DDR然后跳转过去。2.2 非Petalinux方式下ATF和PMU固件的来源这块是手工移植最容易卡住的地方。Petalinux会帮你把PMU固件、ATF、U-Boot打包成一个BOOT.BIN但手工方式下这些组件要自己搞定。PMU固件PMUFW在Xilinx的GitHub仓库里有预编译版本也可以从Xilinx SDK里提取。ATF需要从trustedfirmware-a仓库拉代码然后针对ZynqMP平台交叉编译。我当时用了一个更简洁的方案U-Boot SPL直接作为BL33之前的加载器跳过独立的FSBL把ATF编进启动链。具体在U-Boot配置里开启CONFIG_SPL_ATF然后在设备树里指定BL31的加载地址。这样整个启动链就压缩成BootROM加载SPLSPL初始化DDR后加载ATF和U-BootATF跑起来后跳到U-BootU-Boot再接管后续工作。2.3 地址分配和内存布局规划地址分配是手工移植必须自己拍板的事情ZynqMP的DDR通常从0x0开始编址但实际使用要留出固定区域给ATF和U-Boot。常见的内存布局方案是DDR起始地址0x0留出256KB给ATFBL31U-Boot放在0x80000或者更靠后的位置内核加载地址用0x8000。设备树文件.dtb加载到U-Boot之后的空档。这里有个经验值如果你的板子是4GB内存建议把内核加载地址放到0x30000000以上的地址空间避免和U-Boot自身运行时有重叠风险。板子不同这个地址要自己算方法就是看U-Boot编译时的链接地址和实际加载地址的差值。3. U-Boot移植详解配置、编译与Boot ScrīptU-Boot是整个启动链里最需要耐心打磨的部分因为它直接面对硬件差异。3.1 defconfig选型和修改思路Xilinx在U-Boot主线里维护了一套zynqmp相关的配置其中xilinx_zynqmp_virt_defconfig是最常用的起点。Virt的意思是多功能虚拟平台配置它能把ZynqMP的大部分外设驱动都编译进去方便后续调整。但直接用这个配置大概率有问题因为你的板卡I/O配置、DDR参数、启动设备都跟Xilinx官方评估板不同。我的做法是先编译一遍默认配置让它跑起来然后逐步裁剪。核心要改的地方集中在以下几个方面DDR配置在U-Boot里通常通过defconfig里的DDR_MB设置总容量比如1GB就设CONFIG_NR_DRAM_BANKS1和DDR_MB1024。这个参数不对的话U-Boot启动时会直接花屏或者卡在内存检测的地方连日志都来不及打。启动介质也有讲究如果你的板子从SD卡启动需要在defconfig里开启CONFIG_MMC_SDHCI_ZYNQ和CONFIG_MMC_SDHCI同时设置CONFIG_SYS_MMC_ENV_DEV为0。从QSPI启动则需要开启CONFIG_SPI_FLASH_SFDP_SUPPORT来让Flash驱动自己读取JEDEC ID省去手动指定Flash型号的麻烦。以太网这块最容易漏ZynqMP有的板载PHY是GMII接口有的用SGMII有的用RGMII这三种在U-Boot里的驱动配置完全不一样。先看原理图确定PHY芯片的连接方式再去改设备树里gem节点的phy-mode属性。我当时用的板子PHY挂在gem0上RGMII接口光是这里就比默认配置多调了小半天。3.2 设备树中U-Boot节点的修改U-Boot在ZynqMP平台上其实是用设备树来感知硬件的即使你还没有正式的内核设备树也没关系U-Boot自带一份arch/arm/dts/zynqmp.dtsi基础文件板级差异写在具体的dts文件里。修改dts最关键的是serial节点。ZynqMP一共有两路UART但板卡可能只引出了一路。先确认你用的是UART0还是UART1然后在dts里把对应的serial节点status改为okay把另外一路disabled。时钟这块ZynqMP的UART驱动依赖ps-clk-frequency属性指定输入时钟频率这个值和实际晶振频率不一致的话会出现乱码我调试时碰到过一次后来直接把频率参数改成原理图上晶振的值就好了。DDR的地址和大小在U-Boot的dts里也要写对默认评估板的DDR是4GB你自己板子如果是2GB要去dts中对应的ddrc节点下修改reg属性。这个不写对的话即使defconfig里DDR_MB设了2GBU-Boot能识别的内存上限还是会错乱。3.3 SPL与ATF集成编译前面提到非Petalinux方案可以用SPL直接加载ATF具体实现方式是在顶层Makefile里指定BL31的路径make xilinx_zynqmp_virt_defconfig export BL31/path/to/arm-trusted-firmware/build/zynqmp/release/bl31.bin make -j$(nproc)这里的要点是BL31不是由U-Boot的make系统自动去找的必须通过环境变量或者Kconfig里的BL31路径参数指定。如果缺少BL31SPL编译出来会报错说没有ATF支持。ATF那边编译时需要指定平台参数make CROSS_COMPILEaarch64-linux-gnu- PLATzynqmp RESET_TO_BL311RESET_TO_BL311这个选项的含义是让BL31直接作为复位入口省掉BL2这一级适合SPL已经完成DDR初始化的场景。SPL通过CONFIG_SPL_ATF和CONFIG_SPL_ATF_BL31_BASE配置BL31的加载地址我用的是0x10000000这个地址要跟ATF编译时的链接地址一致。3.4 生成BOOT.BIN并验证启动Xilinx的启动格式要求把PMUFW、ATF、U-Boot打包成一个BOOT.BIN文件。手工方式下用Xilinx提供的bootgen工具完成命令非常简单bootgen -image boot.bif -o i BOOT.BIN -w on关键在boot.bif文件的内容编排the_ROM_image: { [bootloader] ./fsbl.elf [pmufw_image] ./pmufw.elf [destination_cpua53-0, exception_levelel-3, trustzone] ./bl31.elf [destination_cpua53-0, exception_levelel-2] ./u-boot.elf }注意eception_level必须设置正确bl31跑在EL3U-Boot跑在EL2这两个级别写反了启动会直接崩。另外PMU固件这个组件不能省即使你不用它的高级电源管理功能它也要在BOOT.BIN里占位否则BootROM会拒绝启动整个镜像。4. Kernel移植配置、设备树与启动对接Kernel移植相对U-Boot来说反而轻松一些因为Linux内核里的驱动子系统足够成熟主要精力花在配置裁剪和设备树上。4.1 内核defconfig和基础配置Xilinx为ZynqMP维护了一份基础配置xilinx_zynqmp_defconfig在arch/arm64/configs目录下。直接用这份配置编译是可以启动的但会带进去大量你用不到的驱动模块镜像体积大而且启动时加载一堆无用初始化。建议的裁剪路径是保留CONFIG_ARCH_ZYNQMP为y然后根据实际外设逐项关闭不需要的驱动。以太网这块如果U-Boot里已经验证了RGMII PHY工作正常内核里要开启CONFIG_MACBCadence MACB驱动大部分ZynqMP板载网口都走这个控制器。SD卡需要CONFIG_MMC_SDHCI和CONFIG_MMC_SDHCI_OF_ARASAN第二个是ZynqMP专用驱动。如果你用了USB别忘了开启CONFIG_USB_DWC3这是Xilinx自带USB控制器驱动。编译命令相比U-Boot更常规一些export ARCHarm64 export CROSS_COMPILEaarch64-linux-gnu- make xilinx_zynqmp_defconfig make -j$(nproc) Image dtbs输出Image和dtb文件U-Boot会加载这两个文件完成引导。4.2 设备树文件的组织与修改ZynqMP内核源码里的设备树分三层zynqmp.dtsi是SoC内部所有IP核的描述这是Xilinx维护的zynqmp-clk-ccf.dtsi是时钟框架相关一般不用动剩下以具体板卡命名的dts文件比如zynqmp-zcu102-rev1.0.dts才是你改的主战场。第一件事是确认你的板卡在arch/arm64/boot/dts/xilinx/目录下有没有现成文件没有的话从最接近的评估板dts复制一份再改。改的时候按外设逐个来uart0 { status okay; pinctrl-0 pinctrl_uart0_default; pinctrl-names default; }; gem0 { phy-handle phy0; phy-mode rgmii-id; phy0: phy5 { reg 5; device_type ethernet-phy; }; };pinctrl配置是这里的重头戏ZynqMP的引脚复用非常灵活同一个UART引脚可能被复用成GPIO。打开原理图找到对应外设的引脚定义去dts里管脚配置节点中写清楚MIO编号和功能。4.3 内核DTS合并策略与U-Boot的配合手工开发方式下推荐的做法是在U-Boot里使用一份精简的设备树只包含启动必须的serial、mmc、i2c用于读eeprom或PMBus、ethernet这些节点。内核使用的完整设备树由U-Boot加载两者通过U-Boot的boot script解耦。配置文件在环境变量中设置可以在U-Boot命令行用distro bootcmd自动加载重点变量如下setenv fdt_addr 0x1000000 setenv kernel_addr 0x8000000 setenv loadkernel fatload mmc 0:1 ${kernel_addr} Image setenv loaddtb fatload mmc 0:1 ${fdt_addr} system.dtb setenv bootcmd run loadkernel; run loaddtb; booti ${kernel_addr} - ${fdt_addr}注意加载地址要和你的DDR布局匹配不要和U-Boot自身、ATF的运行地址冲突。booti命令是aarch64的引导入口它和bootm的区别是bootm会先解析内核镜像头部的格式信息而booti直接按固定偏移加载。4.4 多合一镜像与分区域加载策略实际使用中我强烈建议把设备树和内核分开存放而不是打成一个镜像。原因是开发调试阶段内核和设备树改动频率不同今天可能就改了dts里一个GPIO定义没必要重新打包整个Image重新烧写。SD卡分区方案可以这样设计第一个分区FAT32放Image、system.dtb、boot.scr第二个分区ext4挂根文件系统。这样的话你每次更新设备树只需要在宿主机上编译出新的dtb文件然后拷贝到SD卡第一个分区覆盖同名文件重启就生效。整个过程不到十秒钟极大提升调试效率。如果用NFS挂根文件系统连SD卡都可以不用从U-Boot里设置网络加载参数即可这对内核模块开发非常友好因为模块编译完直接拷到NFS目录就能在板子上通过insmod加载。5. 实操中的坑与验证方法移植工作做得再多调试笔记不如一次真实的失败排查来得印象深刻。我在这个项目里踩过三个比较有代表性的坑都列出来供你避雷。5.1 U-Boot启动卡死在Starting kernel ...U-Boot打印完这句话就再也没动静了多半问题出在设备树和内核不匹配上。我当时遇到的情况是U-Boot里加载的FDT地址写错了内核启动时实际设备树已经被什么东西覆盖了。解决方法是在U-Boot命令行手动执行fdt addr ${fdt_addr}然后fdt print /看看能不能正确解析设备树。如果报错说明地址不对。另外也要检查你用的内核Image是否开启了CONFIG_ARM64_4K_PAGES选项。ZynqMP的MMU页表配置如果和U-Boot传给它的DDR大小不一致内核会在非常早期的阶段直接静默退出像极了死机。5.2 DDR容量识别少了一半这个坑很隐蔽。ZynqMP的DDR控制器有两种地址映射模式交错和非交错。如果你的板子上贴了两颗DDR颗粒但地址映射是交错模式那么DDR的物理地址会从0x0开始连续编址到满容量。如果主控那边只读到一颗就需要检查psu_ddr节点的地址属性是否有误也可能是U-Boot的DDR_MB和dts不匹配。大多数评估板在U-Boot里设DDR_MB4096如果你的板子只有2GB没改这个参数的话U-Boot会访问不存在的地址区域轻则报错重则总线异常。5.3 以太网驱动在U-Boot里正常、内核里却不通U-Boot和内核用的是完全不同的两套驱动框架。U-Boot的MACB驱动比较简单对PHY的配置要求不严格内核的驱动会对PHY进行完整的init序列。这种情况下检查内核dts里gem节点的phy-mode是否和U-Boot一致rgmii-id和rgmii的差别在于是否包含内部延时补偿选错的话大概率不通。如果dts没问题再检查内核配置里是否开启了CONFIG_REALTEK_PHY很多板载PHY是Realtek的这个驱动如果没编进去PHY ID读不出来内核会认为PHY不存在。5.4 验证启动链路的标准流程移植完成后不要急着烧flash建议先用SD卡验证。把BOOT.BIN放SD卡FAT分区上电后进入U-Boot命令行先跑一遍内存测试mw.l和md.l命令配合确认DDR读写正常再用ping命令验证网口最后挂载SD卡读取内核镜像。每一步验证通过再进行下一步这样能把出问题的范围缩到最小。我个人的习惯是每次改完设备树或配置文件后先编译U-Boot并在RAM里跑一遍确认无异常后再固化到启动介质避免焊死QSPI之后发现问题还得重新走一遍烧录流程。6. 非Petalinux方式的维护成本与优化建议手工移植方式最大的优势是透明可控最大的劣势是升级链路要自己维护。Xilinx的U-Boot分支更新比较频繁你不太可能每次都同步主线所以要建立自己的版本基线。建议的做法是在你的Git仓库里维护三个分支vendor分支跟踪上游U-Boot和内核的更新bsp分支保存你的板级改动defconfig、dtsrelease分支用于生成可发布的构建产物。每次上游有安全修复或新驱动时把vendor分支合并到bsp分支再重新编译验证设备树整个过程半小时内能完成。这比Petalinux的方式灵活得多Petalinux里一旦你手动改了设备树后续的meta-layer更新就可能冲突而且冲突解决起来非常痛苦。对于根文件系统除非有特殊需求建议直接混用Debian/Ubuntu的rootfs用debootstrap生成一套arm64的rootfs目录再chroot进去安装必要软件包。这样你能在板子上直接用apt安装开发工具链省去自己交叉编译一大堆用户态依赖的精力。注意编译内核模块时要用板子同版本的内核源码编译装上去才能insmod成功。ZynqMP这款芯片本身性能很强跑个完整桌面环境都没什么问题所以把用户态交给发行版管理是完全可行的策略你只需要维护好内核和启动引导这一层。这也是我觉得非Petalinux方式在长期可维护性上更占优的地方——它把你需要理解的系统边界划清楚了而Petalinux把边界隐藏在你控制不到的抽象层里。/本文还有配套的精品资源点击获取