Zynq 7015 linux跑起来之导入之BOOT.bin生成详解
在 SDK 中点击 Xilinx Tools-》Creat Boot Image
指定 bif 路径，其实就是刚才创建的那个 BOOT 文件夹。
三个文件依次是 1FSBL.elf，ARM_CORE_wrapper.bit，u-boot.elf BOOT.bin 是可以放入到 SD 卡或者 emmc 里面的，如果是 BOOT.mcs 那 是放入 SPI flash 里面的。 output.bif 文件里面的内容 the_ROM_image： { ［bootloader］/home/gavin/work/ZYNQ/PICO_ZED/BOOT/1FSBL.elf /home/gavin/work/ZYNQ/PICO_ZED/BOOT/ARM_CORE_wrapper.bit /home/gavin/work/ZYNQ/PICO_ZED/BOOT/u-boot.elf }
master/arch/arm/boot/zImage 。/
sudo
cp
/home/gavin/work/ZYNQ/kernel/linux-Digilent-Dev-
master/arch/arm/boot/dts/devicetree.dtb 。/
cp
/home/gavin/work/ZYNQ/PICO_ZED/PICO_ZED/PICO_ZED.runs/impl_1/ARM_
CORE_wrapper.bit 。/
sudo
cp
/home/gavin/work/ZYNQ/PICO_ZED/PICO_ZED/PICO_ZED.sdk/1FSBL/Debug/
1FSBL.elf 。/
我们在生成 BOOT.bin 文件的时候，主要要用到 1FSBL.elf，
ARM_CORE_wrapper.bit，u-boot.elf 这三个文件现在都已准备好了。
至此，BOOT.bin 和 BOOT.mcs 文件生成！
sudo mv u-boot u-boot.elf
cp
/home/gavin/work/ZYNQ/kernel/linux-Digilent-Dev-
master/arch/arm/boot/uImage 。/
cp
/home/gavin/work/ZYNQ/kernel/linux-Digilent-Dev-
Zynq 7015 linux 跑起来之导入之 BOOT.bin 生成详 解
新建一个 BOOT 文件夹
sudo mkdir BOOT
cd BOOT
பைடு நூலகம்
sudo cp /home/gavin/work/ZYNQ/uboot/u-boot-xlnx-master/u-boot 。/
Zynq 7015 linux跑起来之构建ARM核
首先，这里跑 linux 主要是 PS 部分的，这里暂时不用 PL 部分。 打开 vivado 新建一个 project. 项目名和保存路径 RTL project next next next 选 Board,如果选器件，是一样的，只是需要去根据实际情况设置一些东 西。
然后在 ARM_CORM 上右键 Generate Output Products Generate 然后在 ARM_CORM 上右键 Create HDL wraper，然后全部保存，因为这 个软件是流程式作业，会从头执行到尾，所以我这里设置好 bit stream 相关的 设置 然后点 Generate bitstream lic 不出问题，正常等待一会儿就会 OK. 以上是我没有保存才有的提示，如果都保存了，就不会提示了。 至此，文件都已生成，我们不做其他操作，直接选 view Reports 就 OK 了。下一节介绍如何导入到 SDK 然后新建一个应用工程，生成 FSBL.
然后 Next 完成。 Create Block Design 这里我们需要构建 PS 核 所以我把 Design name 改成 ARM_CORE,当然，是根据实际情况来，你想 怎幺命令都是可以的。然后在右则点添加 IP,然后选 zynq 7000 如下图所示。 点 Run Block Auto...会自动根据所选的板子，自动配置 OK 然后双击进去，进行配置，最好能和自己的板子实际情况对应起来，这里 对 PL 部分都不做配置，配置完后保存。 这是配好后的，这样看起来线比较难看，不要慌，右键选 regenerate layout
Linux BOOTLOADER全程详解
Linux BOOTLOADER全程详解(Arm S3C2410)网上关于Linux的BOOTLOADER文章不少了,但是大都是vivi,blob等比较庞大的程序,读起来不太方便,编译出的文件也比较大,而且更多的是面向开发用的引导代码,做成产品时还要裁减,这一定程度影响了开发速度,对初学者学习开销也比较大,在此分析一种简单的BOOTLOADER,是在三星公司提供的2410 BOOTLOADER上稍微修改后的结果,编译出来的文件大小不超过4k,希望对大家有所帮助.1.几个重要的概念COMPRESSED KERNEL and DECOMPRESSED KERNEL压缩后的KERNEL,按照文档资料,现在不提倡使用DECOMPRESSED KERNEL,而要使用COMPRESSED KERNEL,它包括了解压器.因此要在ram分配时给压缩和解压的KERNEL提供足够空间,这样它们不会相互覆盖.当执行指令跳转到COMPRESSED KERNEL后,解压器就开始工作,如果解压器探测到解压的代码会覆盖掉COMPRESSED KERNEL,那它会直接跳到COMPRESSED KERNEL后存放数据,并且重新定位KERNEL,所以如果没有足够空间,就会出错.Jffs2 File System可以使armlinux应用中产生的数据保存在FLASH上,我的板子还没用到这个.RAMDISK使用RAMDISK可以使ROOT FILE SYSTEM在没有其他设备的情况下启动.一般有两种加载方式,我就介绍最常用的吧,把COMPRESSED RAMDISK IMAGE放到指定地址,然后由BOOTLOADER把这个地址通过启动参数的方式ATAG_INITRD2传递给KERNEL.具体看代码分析.启动参数(摘自IBM developer)在调用内核之前，应该作一步准备工作，即：设置Linux 内核的启动参数。
Linux 2.4.x 以后的内核都期望以标记列表(tagged list)的形式来传递启动参数。
ZYNQFLASH+EMMC手动移植LINUX启动
ZYNQFLASH+EMMC⼿动移植LINUX启动前⾔虽可使⽤Petalinux进⾏移植，简单⽅便，但为了更清楚明⽩的了解整个流程，还是尝试了⼀波⼿动移植。
参考资料流程对于⼿动移植，所需的⽂件为：BOOT.bin(FSBL+fpga_bit⽂件+u_boot.elf)、uImage、devicetree.dtb、uEnv.txt、⽂件系统⽂件放置位置说明：FLASH：BOOT.bin(FSBL+fpga_bit⽂件+u_boot.elf)EMMC：第⼀个分区放置：uImage、devicetree.dtb、uEnv.txt第⼆个分区放置：⽂件系统启动流程为：板⼦设置为QSPI启动模式，FSBL执⾏调u-boot执⾏，u-boot根据uEnv.txt调EMMC分区1中的内核执⾏，内核最后跳到分区⼆中的⽂件系统。
FSBL、bit⽂件、uImage、⽂件系统都可复⽤SD卡移植模式下的内容：参考参考资料第⼀个链接。
本⽂章主要讲述的重点在于：u-boot、设备树、uEnv.txt的更改部分板⼦主要信息说明：板⼦芯⽚：ZYNQ7035，板⼦的调试打印串⼝为PS0，板⼦上有SD卡(SD0)、EMMC(SD1)，板⼦上有FLASH。
其他外设不赘述。
u-boot移植说明：NOTE：u-boot xilinx-v2018.3版本的zynq-common.h跟xilinx-v2018.1版本的不⼀样，这⾥检出v2018.1版本使⽤。
主要是CONFIG_EXTRA_ENV_SETTINGS环境变量不⼀致。
默认的如下所⽰：/* Default environment */#ifndef CONFIG_EXTRA_ENV_SETTINGS#define CONFIG_EXTRA_ENV_SETTINGS \"ethaddr=00:0a:35:00:01:22\0" \"kernel_image=uImage\0" \"kernel_load_address=0x2080000\0" \"ramdisk_image=uramdisk.image.gz\0" \"ramdisk_load_address=0x4000000\0" \"devicetree_image=devicetree.dtb\0" \"devicetree_load_address=0x2000000\0" \"bitstream_image=system.bit.bin\0" \"boot_image=BOOT.bin\0" \"loadbit_addr=0x100000\0" \"loadbootenv_addr=0x2000000\0" \"kernel_size=0x500000\0" \"devicetree_size=0x20000\0" \"ramdisk_size=0x5E0000\0" \"boot_size=0xF00000\0" \"fdt_high=0x20000000\0" \"initrd_high=0x20000000\0" \"bootenv=uEnv.txt\0" \"loadbootenv=load mmc 0 ${loadbootenv_addr} ${bootenv}\0" \"importbootenv=echo Importing environment from SD ...; " \"env import -t ${loadbootenv_addr} $filesize\0" \"sd_uEnvtxt_existence_test=test -e mmc 0 /uEnv.txt\0" \"preboot=if test $modeboot = sdboot && env run sd_uEnvtxt_existence_test; " \"then if env run loadbootenv; " \"then env run importbootenv; " \"fi; " \"fi; \0" \"mmc_loadbit=echo Loading bitstream from SD/MMC/eMMC to RAM.. && " \"mmcinfo && " \"load mmc 0 ${loadbit_addr} ${bitstream_image} && " \"fpga load 0 ${loadbit_addr} ${filesize}\0" \"norboot=echo Copying Linux from NOR flash to RAM... && " \"cp.b 0xE2100000 ${kernel_load_address} ${kernel_size} && " \"cp.b 0xE2600000 ${devicetree_load_address} ${devicetree_size} && " \"echo Copying ramdisk... && " \"cp.b 0xE2620000 ${ramdisk_load_address} ${ramdisk_size} && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"qspiboot=echo Copying Linux from QSPI flash to RAM... && " \"sf probe 0 0 0 && " \"sf read ${kernel_load_address} 0x100000 ${kernel_size} && " \"sf read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \"echo Copying ramdisk... && " \"sf read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"uenvboot=" \"if run loadbootenv; then " \"echo Loaded environment from ${bootenv}; " \"run importbootenv; " \"fi; " \"if test -n $uenvcmd; then " \"echo Running uenvcmd ...; " \"run uenvcmd; " \"fi\0" \"sdboot=if mmcinfo; then " \"run uenvboot; " \"echo Copying Linux from SD to RAM... && " \"load mmc 0 ${kernel_load_address} ${kernel_image} && " \"load mmc 0 ${devicetree_load_address} ${devicetree_image} && " \"load mmc 0 ${ramdisk_load_address} ${ramdisk_image} && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \"fi\0" \"usbboot=if usb start; then " \"run uenvboot; " \"echo Copying Linux from USB to RAM... && " \"load usb 0 ${kernel_load_address} ${kernel_image} && " \"load usb 0 ${devicetree_load_address} ${devicetree_image} && " \"load usb 0 ${ramdisk_load_address} ${ramdisk_image} && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}; " \"fi\0" \"nandboot=echo Copying Linux from NAND flash to RAM... && " \"nand read ${kernel_load_address} 0x100000 ${kernel_size} && " \"nand read ${devicetree_load_address} 0x600000 ${devicetree_size} && " \"echo Copying ramdisk... && " \"nand read ${ramdisk_load_address} 0x620000 ${ramdisk_size} && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"jtagboot=echo TFTPing Linux to RAM... && " \"tftpboot ${kernel_load_address} ${kernel_image} && " \"tftpboot ${devicetree_load_address} ${devicetree_image} && " \"tftpboot ${ramdisk_load_address} ${ramdisk_image} && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"rsa_norboot=echo Copying Image from NOR flash to RAM... && " \"cp.b 0xE2100000 0x100000 ${boot_size} && " \"zynqrsa 0x100000 && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"rsa_nandboot=echo Copying Image from NAND flash to RAM... && " \"nand read 0x100000 0x0 ${boot_size} && " \"zynqrsa 0x100000 && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"rsa_qspiboot=echo Copying Image from QSPI flash to RAM... && " \"sf probe 0 0 0 && " \"sf read 0x100000 0x0 ${boot_size} && " \"zynqrsa 0x100000 && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"rsa_sdboot=echo Copying Image from SD to RAM... && " \"load mmc 0 0x100000 ${boot_image} && " \"zynqrsa 0x100000 && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \"rsa_jtagboot=echo TFTPing Image to RAM... && " \"tftpboot 0x100000 ${boot_image} && " \"zynqrsa 0x100000 && " \"bootm ${kernel_load_address} ${ramdisk_load_address} ${devicetree_load_address}\0" \DFU_ALT_INFO \BOOTENV#endif可以看到其上定义了⼀堆的东西及不同的启动指令。
(完整版)zynq启动流程分析
(完整版)zynq启动流程分析1.纯PL开发,这个和一般的xilinx的FPGA没有很大的区别。
2.纯PS开发,典型的就是helloworld工程，这个看到了网友的有两种方式。
注：这两个方式后面都有相应的实验。
一种是传统的arm的方式，这个可以参考懒兔子博客.还一种就是xilinx方法，这个是生成一个elf文件,这个elf文件包括了硬件配置信息(xmp），和裸跑程序（c文件）。
3。
PS+PL(不跑操作系统）开发，这个可以参考懒兔子博客二，三笔记，生成的elf文件包括了硬件配置信息（xmp），还有裸跑程序（c文件)，另外还有一个。
bit文件可以看出和纯PS开发的区别了。
4.PS+PL（跑操作系统)开发，这个就需要BOOT.BIN,设备树,linux内核镜像,文件系统了。
其中BOOT。
BIN是由3部分组成的(boot。
elf,。
bit，.fsbl。
elf），boot.elf这个是由交叉编译环境产生的，相当于ssbl吧，。
bit文件是PL使用产生，fsbl.elf这个就是fsbl吧。
Zynq启动过程简介1。
在器件上电运行后,处理器自动开始Stage-0 Boot，也就是执行片内BootROM中的代码2.BootROM会初始化CPU和一些外设,以便读取下一个启动阶段所需的程序代码，FSBL（First Stage Bootloader）.不过这又有一个问题了-—-—之前说到,Zynq支持多种启动设备,BootROM怎么知道从哪个启动设备里去加载FSBL?这就得靠几个特殊的MIO引脚来选择了：BootROM会去读取MIO[2。
8]，从而确定启动设备,将选定设备的头192Kbyte内容,也就是FSBL，复制到OCM(On Chip Memory)中，并将控制器交给FSBL。
3，FSBL启动时可以使用整块256Kb的OCM，当FSBL开始运行后，器件就正式由咱自己控制了.Xilinx提供了一份FSBL代码，如果没什么特殊要求，可以直接使用。
基于ZYNQ芯片的外设驱动技术方案
一、BootLoader的移植制作 (2)1、生成uboot.elf文件 (3)2、system.bit生成 (5)3、创建fsbl (8)4、生成BOOT.BIN (9)二、配置并编译linux内核 (10)1、修改设备树内容 (10)2、配置编译linux内核 (12)三、Linux设备驱动移植 (14)1、Linux设备驱动模型 (14)2、Linux设备驱动移植 (15)在嵌入式操作系统中，BootLoader是在操作系统内核运行之前运行。
可以初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境带到一个合适状态，以便为最终调用操作系统内核准备好正确的环境。
在嵌入式系统中，通常并没有像BIOS那样的固件程序（注，有的嵌入式CPU也会内嵌一段短小的启动程序），因此整个系统的加载启动任务就完全由BootLoader来完成。
在一个基于zynq的嵌入式Linux系统中，系统在上电或复位时通常都从地址0x00000000处开始执行，而在这个地址处安排的通常就是系统的BootLoader程序。
想要在zynq芯片上顺利启动Linux并且驱动相关模块正常工作，首先需要正确移植BootLoader。
作为初始化硬件平台的一段Bare Metal代码，Bootloader的移植也并入了我们的工作。
所以综合起来说，我们的工作主要分为了三个部分：Bootloader的移植以及Linux内核和设备驱动的移植。
在进行移植工作之前，首先要做的是要在宿主机上面搭建好我们目标板的开发平台，以及下载好uboot源代码，Linux内核源代码以及相关驱动源代码。
（有的模块的驱动源代码在Linux内核源代码中已经包含进去了，那么就不用单独下载。
需要下载的驱动源代码只是针对标准Linux内核中不支持的部件而言。
）一、BootLoader的移植制作每一种操作系统都需要有自己的引导程序，最为人们所知的就是Windows 的BIOS。
分析uboot生成bin文件完整过程
files you need. In your board directory, you will need at least
/*
#date:2012-11-13
#从 make XXX_config --> make -->生成 u-boot.bin文件
#逐步展开分析
#我们以smdk2410为例展开分析.
#~^~要真正掌握u-boot的移植,我们有2件事需要去做.
#(1)分析makefile、链接脚本等相关的文件,以达到了解u-boot的架构,掌握u-boot的实现过程
"Makefile" and to the "MAKEALL" script, using the existing
entries as examples. Note that here and at many other places
For the Cogent platform, you need to specify the cpu type as well;
e.g. "make cogent_mpc8xx_config". And also configure the cogent
directory according to the instructions in cogent/README.
config.mk lib_i386 nios2_config.mk
COPYING lib_m68k nios_config.mk
cpu lib_microblaze post
ZYNQ：使用PetaLinux打包BOOT.BIN、image.ub
ZYNQ：使用PetaLinux打包BOOT.BIN、image.ub说明个人还是比较喜欢灵活去管理各个部分的源码。
有关文章：ZYNQ：PetaLinux提取Linux和UBoot配置、源码编译Linux取得Linux源代码和配置后，可以在其中执行make，编译Linux。
注意，编译前请导入PetaLinux环境变量：•设置和导出ARCH为arm或者arm64；•设置和导出CROSS_COMPILE，比如aarch64-linux-gnu-。
编译（通过，但是diff 有差异）：make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- xilinx_peta_defconfig# xilinx_peta_defconfig 是我们前文拷贝 .config 得来的。
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j 2编译后得到vmlinux打包 image.ub将kernel、dtb、rootfs.img打包成image.ub。
•kernel：一般就是linux生成的elf文件。
•dtb：设备树，与驱动有关。
•rootfs.img：编译完成的文件系统。
所以，image.ub 没有那么神秘，就是一个包。
使用以下命令：#!/bin/shCROSS_COMPILE=arm-linux-gnueabihf-${CROSS_COMPILE}-objcopy -O binary -R .note -R .comment -S vmlinux linux.bingzip -9 linux.binmv -f linux.bin.gz linux.bin#需要修改 .itsmkimage -f fit-image-petalinux-user-image.its image.ub编译 UBoot取得UBoot源代码和配置后，需要有工具链的环境，编译：make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- cleanmake ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- xilinx_peta_defconfigmake ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- -j 2得到u-boot（实际上就是u-boot.elf）打包 BOOT.BIN1、需要4个文件：u-boot.elf、zynq_fsbl.elf、bootgen.bif、system.bit。
详细解读Zynq的三种启动方式(JTAG,SD,QSPI)
详细解读Zynq的三种启动方式(JTAG,SD,QSPI)本文介绍zynq上三种方式启动文件的生成和注意事项，包括只用片上RAM （OCM）和使用DDR3两种情况。
JTAG方式JTAG方式是调试中最常用的方式，在SDK中在Project Explorer窗口工程上右键-Debug As-Debug ConfiguraTIons可以看到以下窗口首次打开左边窗口中Xilinx C/C++ applicaTIon(GDB)下没有子项，这时双击Xilinx C/C++ applicaTIon(GDB)即可新建一个调试；这时右边窗口会自动填充如上图，若没有则手动填入；在右边ApplicaTIon窗口指定要下载调试的.elf文件；在右边STDIO Connection可以指定标准输入输出串口，即printf打印串口，若这里选择开发板上uart的com口，则调试时printf的信息打印到调试时Console窗口，同时也可从Console窗口输入数据，以此将数据通过串口发送到开发板上以上设置完成后点击Debug即可开始调试；若以上在Project Explorer窗口工程上右键-Run As-Run Configurations；配置与此类似，最后点击run即可开始运行，只是不是调试而是直接上板运行。
只用OCM只用OCM指不使用DDR3的方式，与使用DDR3的方式略有不同。
这里不用FSBL来加载PL部分的.bit文件和第二阶段启动程序（裸机程序），而直接用BootROM加载裸机程序到OCM，即将裸机程序当做FSBL来运行，当然还要以下处理才可以：包含进头文件：#include ps7_init.h在裸机程序main函数开始处调用：ps7_init()从design_1_wrapper_hw_platform_1目录复制ps7_init.c和ps7_init.h文件到裸机程序所在的src目录中注意：这里样调用ps7_init()只适用于只用OCM的情况，经测试打开DDR3后再这样调用会在ps7_init()中初始化失败，调试发现在初始化PLL时失败（原因未知）。
Xilinxzynq-7000系列FPGA移植Linux操作系统详细教程
Xilinxzynq-7000系列FPGA移植Linux操作系统详细教程Xilinx zynq-7000系列FPGA移植Linux操作系统详细教程⼀：前⾔最近⼿上压了⼀块⽶联客的Miz7035，⼀块xilinx zynq-7000系列的开发板，想着正好学习⼀下linux在ARM9上的移植，⽹上基本都是ZC702、zed的教程，这对于买了⾮标准板的⼈来说就不太友好，很多⽂件都不知道是怎么⽣成的。
本着学习加分享的⼼态，把这两天移植linux的过程写下来，尽可能详细。
驱动和系统移植不是我的专长，很多地⽅我也是知其然不知其所以然，写得不对的地⽅欢迎指正。
⼆：前期准备1、⼀台安装好linux系统的主机，我安装的是centos7.2.2、⼀块zynq-7000系列的FPGA开发板，我⼿上的是⽶联客miz7035，其他zynq系列⼀样通⽤。
3、vivado开发环境，我安装的2018.2版本三：操作步骤1.设置交叉编译环境因为最终运⾏在arm9上，所以uboot、内核，⽂件系统编译都需要⽤arm-linux交叉编译⼯具，zynq2000使⽤的是arm-linux-gnueabihf，交叉编译⼯具可以从⽹上单独下载，也可直接使⽤vivado⾃带的交叉编译⼯具。
使⽤⽅法也很简单source /opt/Xilinx/SDK/2018.2/settings64.sh或者gedit /opt/Xilinx/SDK/2018.2/.settings64-SDK_Core_Tools.sh将该⽂件中的内容全部复制到bashrc，更新环境变量，这样在新的终端中打开，环境变量也不会消失。
2.u-boot编译进⼊u-boot⽂件夹，make distclean //清除配置⽂件和编译中间结果make CROSS_COMPILE=arm-linux-gnueabihf- zynq_mz7x_defconfig //重新配置，⽣成makefile，具体板⼦不⼀样，在U-Boot/configs⽂件夹下make CROSS_COMPILE=arm-linux-gnueabihf- tools //编译开发所需要的⼯具make CROSS_COMPILE=arm-linux-gnueabihf- //编译，完成后⽣成⼀个elf⽂件u-boot，uboot.bin,u-boot.srec等⽂件最后把编译⽣成的u-boot后缀改成.elf,连同u-boot.img和spl/boot.bin,⼀共三个⽂件拷贝出来。
基于Zynq-7000的嵌入式Linux移植
基于Zynq-7000的嵌入式Linux移植张朝元;邵高平;汪洋【摘要】针对Zynq-7000平台在无操作系统情况下,开发应用程序需对处理器硬件结构有一定的了解,存在开发难度大的问题.从全可编程器件的角度提出了一种Vivado+ SDK+ Linux的嵌入式系统移植方法.构建了基于Zynq-7000的Linux系统移植环境,生成Linux镜像并进行系统启动.结果表明,该方法提升了系统灵活性,降低了应用开发难度.【期刊名称】《电子科技》【年(卷),期】2018(031)001【总页数】3页(P9-11)【关键词】Zyq-7000;嵌入式Linux;U-boot;全可编程SoC【作者】张朝元;邵高平;汪洋【作者单位】信息工程大学信息系统工程学院,河南郑州450000;信息工程大学信息系统工程学院,河南郑州450000;信息工程大学信息系统工程学院,河南郑州450000【正文语种】中文【中图分类】TP316.81随着全可编程SoC容量和性能的不断提高，全可编程技术在通信、汽车电子、机器学习等领域得到了广泛的应用[1]。
Zynq-7000全可编程SoC以FPGA为基础，将双核的ARM Cortex-A9处理器(Processing System，PS)和可编程逻辑(Programmable Logic，PL)集成在单个芯片中，使得嵌入式系统的设计结构更加灵活，体积显著缩小，系统整体性能明显提高[2-4]。
同时，设计的复杂度也不断提高。
传统的嵌入式Linux系统移植主要是针对SoC产品[5]，已经不能够迁移到全可编程SoC上。
本文提出一种基于Zynq-7000的嵌入式Linux系统的移植方法，针对不同的应用，进行灵活的硬件配置和Linux内核裁剪，定制嵌入式系统，提升系统灵活性。
降低在PS部分开发应用的难度。
硬件平台环境如图1所示，平台核心处理器采用Zynq-702全可编程SoC，PS部分的每个Cortex-A9处理器都有一个高性能、低功耗的内核，支持虚拟内存，Linux系统的移植主要围绕这部分展开；内部总线AXI[6]为PS与PL的数据交互提供高速的链路接口；PL部分是Xilinx的7系列FPGA，提供硬件加速和灵活的可扩展的能力[7-8]；板卡外围配置DDR3高速缓存、SD卡、Flash存储及串口、JTAG等接口，提升系统整体性能，同时为系统的启动和调试提供硬件接口。