F S B L (First Stage Boot Loader)加载 (一)

fsbl是elf文件,是运行的第一个用户应用程序,基本工作是将逻辑从flash复制到RAM中。用户对所有所有的可编程元素的定义可以借助Bootgen工具组装成一个可引导的映像。fsbl就是来打开这个单一的映像的。

1、上电  Power Applied

一旦电源连接到设备,内部的电源管理电路会确保系统各个电源轨(例如供电给CPU、内存、I/O接口等的电压轨)保持稳定。电源轨的稳定性对于保证设备正常工作至关重要,尤其是在启动过程中,设备必须确保各种电压满足硬件组件的要求。

2、引导与管理  PMU ROM Code Executes

在启动过程中,PMU(Platform Management Unit,平台管理单元)检查引导模式引脚的状态。引导模式引脚(如 Boot Mode Pins)是硬件级的输入引脚,用于决定系统启动时应该从哪个介质(如闪存、SD卡、外部存储等)加载操作系统或固件镜像。这一过程对于启动顺序非常关键,决定了系统如何加载操作系统或引导加载程序。对应读取引脚的是FPGA上的拨码开关;不同的FPGA的拨码设置不同

例如:

在加载 FSBL 之前,PMU 会执行一些电源管理、硬件初始化、管理存储器选择等任务,确保设备能够按照预期方式启动。在完成这些初始化任务后,PMU会释放复位信号到 “配置和安全单元”。从而进入下一个阶段的系统启动过程,这种机制确保了设备在启动时的电源稳定性、安全性,并为后续的引导和操作系统加载做好准备。

3、捕获与加载 CSU ROM Code Executes

与PMU类似,CSUConfiguration and Security Unit,配置和安全单元)是负责硬件配置、启动过程管理和安全性的模块。它通常会控制启动的顺序,保护敏感信息,并确保在启动过程中没有受到恶意篡改。

①捕获 :根据拨码开关设置的启动模式,CSU会在对应的模式下捕获引导映像的标头(Header),CSU根据引导头中的信息,找到FSBL的位置并将其复制到OCM RAM (On-Chip Memory,处理器的快速内存)中,以便FSBL快速执行。如果需要,CSU还会加载PMU固件到PMU的RAM中。

②加载:CSU根据引导头指示,将控制转移到指定的处理器(Processor),处理器在OCM中开始执行FSBL代码

4、执行FSBL Either Processor or Mux

如果系统包含多个处理器,复用器决定哪一个处理器负责执行引导加载程序。处理器读取FSBL代码并开始执行。

FSBL 是系统启动时的第一阶段引导加载程序,在OCM RAM中执行,通常完成一些基本的硬件初始化后(如设置时钟、初始化内存控制器、加载初步的引导映像等),将一个应用程序加载到一个处理器。

当为多个处理器加载多个应用程序时会由SBL 负责进一步的引导工作,在DDR中执行,通常包括将操作系统的内核加载到主内存中( DDR 或其他大容量内存中)、驱动程序或其他系统固件,并将控制权交给操作系统或其它启动程序。

当操作系统加载后,应用程序加载开始运行,整个系统进入正常工作状态。

总结:

  1. FSBL加载:FSBL通常是引导映像的第一个块,负责对硬件进行初始化(如时钟、内存、外设等),并为后续的操作做好准备。
  2. SBL加载:在FSBL完成基础初始化后,第二阶段引导加载程序(SBL)会接管,通常它会加载操作系统内核、设备树等。
  3. 操作系统加载:引导映像中可能包含操作系统内核,SBL将其加载到大内存(DDR)中并启动系统。
  4. 应用程序加载:在引导映像中加载其他应用程序或固件模块,供处理器或硬件使用。

<think>嗯,用户问的是为什么BOOT加载的PL位流没有更改。首先,我需要理解这里的术语。BOOT应该是指系统的启动引导程序,而PL可能指的是FPGA中的可编程逻辑(Programmable Logic)部分。位流(bitstream)是FPGA的配置文件,用来定义硬件逻辑。 用户的问题核心在于,当系统启动时,通过BOOT流程加载PL的位流,但实际运行后发现PL的配置没有变化。这可能涉及多个方面,比如启动流程的配置、位流文件是否正确、硬件问题等。 首先,应该检查位流文件是否正确。如果文件损坏或者版本不对,加载后自然不会有变化。其次,启动流程是否正确配置了加载位流的步骤。例如,在Zynq芯片中,FSBLFirst Stage Boot Loader)负责初始化硬件并加载PL位流。如果FSBL的配置没有包含加载位流的指令,或者路径错误,位流就不会被加载。 另外,硬件问题也不能排除,比如FPGA的配置引脚是否正确连接,供电是否稳定,或者FLASH存储器中的位流数据是否正确烧写。还有可能是在加载过程中出现了错误,但系统没有正确报告,导致用户以为加载成功但实际上失败了。 还需要考虑是否有多余的配置覆盖了原有的位流。例如,某些系统可能在启动后由操作系统再次加载位流,如果两次加载的位流相同,用户可能察觉不到变化,但如果第二次加载失败或被跳过,实际运行的还是旧的配置。 可能的解决步骤包括:验证位流文件的完整性,检查启动脚本或配置文件中是否正确指定了位流路径,确认硬件连接正常,查看启动日志是否有错误信息,以及确保没有后续的配置覆盖。 另外,用户可能是在开发过程中遇到了这个问题,可能涉及到嵌入式系统或FPGA开发,需要具体的平台信息(如Xilinx Zynq或Altera SoC)来更准确地判断。但根据问题描述,用户可能希望了解般性的原因,而不是特定平台的细节。 总结下,可能的原因有:位流文件错误、启动配置不正确、硬件问题、加载过程错误未处理、后续配置覆盖等。需要逐排查这些可能性,找到导致PL位流未更改的具体原因。</think>在基于FPGA的嵌入式系统(如Xilinx Zynq平台)中,BOOT加载PL位流未生效的常见原因及排查路径如下: **1. 启动流程验证** $$ FSBL \rightarrow Bitstream \rightarrow U-Boot \rightarrow OS $$ - 检查FSBLFirst Stage Boot Loader)是否包含PL配置指令 - 确认`fsbl_*.elf`的生成参数中启用了`-hw`或`-hwp`选项 **2. 位流文件检查** $$ \text{有效性} = \begin{cases} 1 & \text{文件头校验通过} \\ 0 & \text{文件损坏/版本不匹配} \end{cases} $$ - 使用`bootgen`工具验证`.bit`文件完整性 - 确认生成时`-process_bitstream`选项已启用(适用于Zynq加密场景) **3. BOOT.BIN打包验证** $$ \text{镜像结构} = [FSBL] \oplus [Bitstream] \oplus [App] $$ - 使用`vivado -nolog -nojournal -mode batch -source build.tcl`检查打包脚本 - 验证分区偏移量是否满足地址对齐要求(通常4KB对齐) **4. 硬件初始化时序** $$ t_{PL\_init} = t_{PS\_POR} + t_{CLK\_stable} $$ - 检查PS_POR_B复位信号时序(典型保持时间>300ms) - 测量PL配置时钟(DCLK)的稳定性(Zynq7000要求<100MHz) **5. 运行时覆盖检测** - 使用`devmem 0xF8007100`读取PCAP状态寄存器(Xilinx平台) - 监控`/sys/kernel/debug/zynq_fpga/status`节点(Linux系统) - 防止uboot或OS中的自动重配置操作覆盖初始位流 **6. 信号完整性验证** $$ V_{CCINT} \geq 0.95V \pm 3\% $$ - 使用示波器检查配置相关信号: - PROG_B(脉冲宽度>300ns) - INIT_B(低电平时间>200μs) - DONE(上升沿后至少500ms再启动PS) **解决方案建议:** 1. 使用`bootgen -arch zynq -image boot.bif -w -o BOOT.BIN -log trace`生成详细日志 2. 在FSBL源码中添加`PS7_Init()``后的寄存器打印: ```c xil_printf("SLCR_PCAP_RDY: 0x%08X\r\n", Xil_In32(0xF8000004)); ``` 3. 通过JTAG执行边界扫描测试(BSD)验证PL物理连接 注:具体寄存器地址需参考对应芯片的Technical Reference Manual(TRM)。建议结合Vivado Hardware Manager实时监控配置过程。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值