下载掌阅APP，畅读海量书库
立即打开
在完成对U-Boot的修改移植和编译后，剩余的工作就是将代码烧写到Flash存储器中，做到上电可以运行。在目标板烧写程序是通过VisualDSP++开发环境和仿真器配合完成的，VisualDSP++是ADI推出的集成开发环境，配合仿真器可以实现对程序的单步、断点调试，可以烧写Flash程序等工作。VisualDSP++环境的安装这里不再讨论，下面仅描述利用VisualDSP++的Flash Programmer程序烧写映像的过程。
（1）目标板断电，连接目标板和仿真器的JTAG插座，注意14脚的JTAG插座的方向，不能插反。
（2）目标板上电，运行VisualDSP++软件，单击“Session”，选择BF536处理器对应的Session，建立VisualDSP++与目标板的连接。
（3）单击“Tools”->“Flash Programmer”，如图4.15所示。
（4）Flash Programmer界面如图4.16所示，单击“Driver”页面，加载Flash烧写驱动程序。选择目标板Flash驱动程序，然后单击“Load Driver”。如果驱动程序加载成功，则在Flash information栏目下出现Flash存储器的具体信息，包括制造厂家代码、芯片代码、芯片型号和厂家名称。Driver information栏目显示驱动程序的版本信息。
图4.15 运行Flash Programmer程序
图4.16 加载Flash驱动程序
（5）单击“Commands”页面，选择“Erase All”擦除Flash存储器中的内容。
（6） 单击“Programming”页面，如图4.17所示。在“Data”栏中选择要烧写的文件。本书4.2节已经讨论过U-Boot的编译，编译生成的文件包括u-boot.bin和u-boot.hex，这是两种不同格式的映像，烧写时对应的选项也不一样。如果要烧写u-boot.hex文件，则在“File format”栏中选中“Intel Hex”格式，然后单击“Program”开始烧写映像。如果要烧写u-boot.bin文件，则在“File format”栏中选中“Binary”格式，“Offset”设为0，然后单击“Program”开始烧写映像。映像烧写完成后最好单击“Compare”校验是否烧写正确。如果校验无误，断开VisualDSP++与目标板的连接，烧写工作完成。
图4.17 烧写Flash映像
注意烧写过程中用到的Flash驱动程序是根据目标板配置的Flash存储器自己开发完成的，不同的目标板配备的Flash存储器型号不同，需要的驱动程序也有所不同。VisualDSP++提供了驱动程序的模板，读者可以在其模板的基础上参考本书4.3.4节中的内容进行移植，开发自己的驱动程序。
U-Boot映像烧写到Flash存储器中，是可以掉电保存的。烧写完成后，使用RS-232电缆连接PC的串口和目标板的串口，打开PC端的超级终端，并设置串口通信参数与U-Boot的串口参数保持一致。目标板重新上电，正常情况下在超级终端应该看到U-Boot的启动信息，如图4.18所示。
图4.18 U-Boot启动信息
事实上很多工程师特别是刚刚接触Blackfin的新手们都没有这么幸运，通常遇到的情况是目标板上电，但是串口没有任何输出。除去U-Boot本身的原因外，大都和Blackfin处理器的启动模式有关。Blackfin处理器的启动是很复杂的问题，也很容易令人混淆，下面具体讨论BF536启动模式的问题。
BF536处理器支持7种启动模式，由BMODE[2:0]三个外部引脚的电平状态决定，如表4.11所示。
表4.11 BF536处理器的启动模式
7种启动模式可以分为两类：使用片内boot Rom程序和跳过boot Rom程序，其中最为常用的两种模式是模式1和模式2。Blackfin处理器内部有一段引导程序，起始地址在0xEF000000，如果BMODE[2:0]!=000，则上电后Blackfin自动跳转到0xEF000000处开始执行引导程序，然后在引导程序的控制下完成应用程序的加载工作。引导程序根据BMODE[2:0]的设置从不同的接口接收启动码流并处理该码流，启动码流的格式是特殊的，是ADI定义的一种格式，称之为LDR文件。U-Boot编译生成的hex或者bin文件是不能被引导程序解析的。LDR文件由多个连续的块组成，每个块包括10字节的头信息和块数据，头信息的格式如下所示：
32位地址：本块的目标地址，引导程序把这个块放到对应的目标地址处。
32位长度：本块的数据长度。
16位标志位为
•bit0：ZEROFILL，0——不填充，1——用0填充本块。
•bit1：RESVECT，一直为1。
•bit3：INIT，0——非初始化块，1——初始化块。
•bit4：IGNORE，0——不忽略本块，1——忽略本块。
•bit[8:5]：PFLAG，定义用于握手的GPIO引脚。
•bit[10:9]：PPORT，00——禁止握手信号；01——握手信号在PORTF；10——握
手信号在PORTG；11——握手信号在PORTH。
•bit15：FINAL，0——非最后块，1——最后一个块。
引导程序根据每块的标志位进行处理，一直到最后一个块，处理结束后处理器跳转到复位向量地址0xFFA00000处执行应用程序。
具有INIT标志的块是需要特殊注意的，很多上电不能启动的情况都和INIT块有关。µClinux内核和U-Boot程序大部分在SDRAM空间运行，其他非Linux的程序也会用到很多SDRAM空间，但是处理器在上电的时候是没有对SDRAM控制器进行初始化的，也就是说上电开始时SDRAM存储空间是不能被访问的。为了解决后面程序使用SDRAM的问题必须在上电开始后尽早完成对SDRAM控制器的初始化，INIT块就是完成初始化工作的。用户首先要自己编写SDRAM初始化程序，然后在生成LDR文件时把初始化代码放到INIT块中，片内引导程序加载时发现标志为INIT的块就会对该块入口函数进行调用，INIT块的函数执行完毕后再返回到引导程序，因此INIT块的函数必须要有返回，否则会脱离引导程序的控制。所以INIT块对SDRAM控制器的正确初始化是程序能够正常启动的关键，千万不能忽略这个问题。
如果BMODE[2:0]被设置为000，则处理器上电后会跳过片内引导程序，直接从Flash地址0x20000000开始执行。同样的道理，SDRAM控制器初始化程序也需要尽早地被执行，然后把其他代码复制到SDRAM空间，最后跳转到SDRAM空间继续执行，在前面U-Boot的启动分析中已经很清楚地看到这一点。