OpenRisc-53-debugging the OpenRISC 1200

引言

or1200的调试，是玩OpenRISC绕不过去的话题，无论是硬件上的调试，软件程序的烧写，调试，还是仿真时的调试，都需要相关的调试系统的支持。

鉴于debug系统的重要性，Opencores官方也开发了一个调试系统-advance debug system，这个系统包含硬件和软件的所有组件，

请参考：

http://opencores.org/project,adv_debug_sys

http://opencores.org/or1k/OpenOCD

通过下载和阅读advance debug system中的文档（doc/or1k_debug_sys_manual.pdf），我们可以根据自己的具体环境搭建合适的调试系统，

但是，为了加快上手速度，之前也写过几篇关于debug的blog，但是还不够，所以本小节就再进一步解决这个问题。

其实，real-time embedded也做过相关工作： http://www.rte.se/blog/blogg-modesty-corex/index

下面就是其中一篇博文，其中详细介绍了or1200的调试系统的搭建过程。

http://www.rte.se/blog/blogg-modesty-corex/debugging-openrisc-1200/2.13

内容如下：（都是比较简单易懂的语句，所以就没有翻译）

虽然文中使用的硬件和软件环境也许和我们各自的有所区别，但还是有一定的参考价值的。

如果你没有买ORSoC USB debugger的话，请参考： http://opencores.org/forum,OpenRISC,0,4444)

Introduction

There are different ways of  performing debugging  depending on the "target" (the actual representation of the OpenRISC processor and platform.) Two main categories of target exist; physical targets such as FPGA or ASIC OpenRISC implementations, and simulated targets such as a low-level event-driven simulations of RTL models (using a simulator such as Icarus Verilog) or models with greater abstraction such as the OR1ksim architectural simulator.

We will focus on debugging with the  GNU debugger , GDB, as the primary user interface. The "targets" that GDB connects to will somehow support GDB with a "stub" or a component that can understand and translate GDB commands into the appropriate commands for the target. Here is some more  information  about using gdb for software debugging.

The four currently supported targets for debugging are:

• Physical target (FPGA or ASIC)
• Event-driven simulation
• Cycle-accurate model simulation
• Architectural simulator

Debugging a physical target

Physical implementations of OpenRISC systems can be debugged using a  set of tools made available at OpenCores.org . Whether simply poking registers in IP cores or debugging complex software executing on the processor, these tools provide a useful debugging capability. The following block diagram gives a simplistic representation of the of the components involved in debugging a physical target.

 

JTAG TAP

 

The implementation of the Test Access Port (TAP) is fully IEEE 1149.1 compliant. It includes a TAP controller, a 4-bit instruction register and three test data registers: idcode register, bypass register and boundary scan register.
 

SoC debug interface

The Debug Interface is used for development purposes (debugging). It is an interface between the CPU(s), peripheral cores and any commercial debugger/emulator. The external debugger or BS tester connects to the core via JTAG port that is fully IEEE 1149.1 compatible. For that reason JTAG TAP needs to be used together with this core.

 

The GNU debugger

The GNU debugger, GDB, is a popular tool that is capable of debugging many architectures from many platforms. The OpenRISC port of GDB (or32-elf-gdb), is used as the primary debugging tool for all OpenRISC targets. It functions as, among other things, the actual user interface when debugging.

Using the ORSoC USB to JTAG debugger

ORSoC  has developed an  USB to JTAG debugger , aimed at debugging OpenRISC based systems. One or more OpenRISC processors can be controlled over a JTAG interface. Additionally the debugger could be used to handle a serial connection for a console. Signal level on the JTAG is user configurable by use of an external voltage. The debugger is USB 1.1 compatible for easy connection to a host. A local proxy server handles the USB connection and offers a TCP connection to a software debugger. The GNU debugger with optional graphical user interface, such as DDD, is supported. It connects to the board under test with a ribbon cable. The cable has a 2×5 pin header with 0,1″ spacing using the following pinout: