正如前面所说,“如果把SOC比作一个人的话”,那么debug子系统就相当于医生,可以检测身体的健康状态。本小节就简单分析一下ORPSoC的debug子系统。
debug系统担任两个主要任务,除了调试以外,还负责对flash的编程。
整个debug系统可简单的分成两部分,上部分和下部分,上下两部分之间通过JTAG协议通信。
上部分包括PC部分和FTDI。
FTDI是一个4in1的芯片,其中两路是jtag接口(FPGA本身一路,ORPSoC的jtag一路),另外两路是uart,如图:
or32-debug_proxy是FTDI的驱动,可以用svn在opencores官网SVN server上download,其svn目录结构如下:
需要说明的是,trunk目录下的内容较多,可根据需要单独下载对应的子目录:
可使用svn,输入对应的checkout路径下载对应的资源:
下部分是FPGA内部的ORPSoC的模块部分,通过内部自定义协议,根据上部分的jtag指令,读取sprs(特殊功能寄存器)来获得系统状态信息,返回给上部分,最终给or32-elf-gdb(or1200平台的gdb),在终端打印出来,完成调试工作。
下部分对应的芯片引脚和模块的端口名称等信息,请参考:
http://blog.csdn.net/rill_zhen/article/details/9044791
要想让ORPSoC运行软件至少需要做两部分工作,第一,将ORPSoC的硬件逻辑烧写到FPGA,第二,将软件烧写到ORPSoC的flash里面。
1》通过FPGA的工具操作ORPSoC的altserial_flash_loader模块,这是altera的LPM,这个模块的作用是什么呢?
手册里描述如下:
Serial flash loader megafunction. The altserial_flash_loader is a bridge that allows programming data to cross from the JTAG interface via the FPGA to the active serial interface.
2》altserial_flash_loader将FPGA工具传来的数据(软件程序)保存下来,受ORPSoC的simple_spi模块的控制,传到arbiter_bytebus模块,而arbiter_bytebus模块又是arbiter_dbus的从设备(s3),arbiter_dbus的master正好是or1200_top的data接口。事先存在bootrom里面的指令可以读取spi flash的内容到sdram,然后启动系统。
关于ORPSoC的启动过程,请参考:
http://blog.csdn.net/rill_zhen/article/details/8855743
自此,我们对ORPSoC的bootloader(orpmon)启动过程比较清晰了。
1》FPGA工具将orpmon写到altserial_flash_loader。
2》bootrom里面的启动代码的硬件固化。
3》上电运行bootrom的指令
4》bootrom的指令读取altserial_flash_loader到sdram,并运行。
5》加载linux,应用程序
6》系统的大厦展现在我们面前。
7》总体的数据路径如下,
红色:事先初始化。
黄色:上电bootrom运行。
绿色:oprmon的代码读取。
蓝色:oromon的写入内存。
本小节简单介绍了ORPSoC的debug系统的结构和调试过程的数据通路。
如果在调试中遇到问题,可以分阶段的逐步的进行分析和排查,解决问题。