search

openrisc / orpsoc-cores

Core description files for FuseSoC
123 stars 78 forks source link

No pin assignment of JTAG_TAP for de0_nano #103

Open zavax2005 opened 8 years ago

zavax2005 commented 8 years ago

I couldn't find pin assignment of JTAG_TAP for de0_nano from orpsoc-cores/systems/de0_nano/data/pinmap.tcl. Does that mean I couldn't use OpenOCD to write program to RAM via JTAG?

This seems to explain the trouble I'm running into now:

However

Did I miss anything during those steps, or am I completely wrong? Thanks in advance.

-Xueming

olofk commented 8 years ago

The OpenRISC debug system needs to connect to a JTAG controller in the FPGA. For some SoCs, we use the jtag_tap as a JTAG controller, and in those cases we need to connect to FPGA I/O pins. For the de0 nano SoC however, the debug system is connected to an internal Altera JTAG controller in the FPGA which is called altera_virtual_jtag here. This controller is connected to the dedicated JTAG pins on the FPGA (which is the same interface that is used for example by SignalTap). Therefore we don't need any specific pin mappings for the JTAG pins, as this is hard wired in the FPGA

On the de0 nano board, the dedicated FPGA JTAG pins are then connected to a chip which translates the JTAG commands to USB, using the USB Blaster protocol. It is this way we use to connect OpenOCD to the OpenRISC.

About your problem with not getting the LED blinker running, I have a theory why it's not working. When the CPU is started, it starts to execute the program that is stored in the built-in boot ROM. The default boot ROM for the de0_nano SoC is set up to load a program from the SPI Flash to memory and execute this. In your case, there probably isn't any program in the SPI Flash, and since I have not implemented a fallback mechanism, nothing at all happens.

If my theory is correct we could get around this by using another boot ROM that just tries to execute directly from RAM instead. With this boot ROM, you can connect to the CPU with a debugger, upload your program, and when you reset the CPU, it will execute.

Try building with fusesoc build de0_nano --bootrom_file=~/.local/share/orpsoc-cores/systems/de0_nano/sw/clear_r3_and_jump_to_0x100.vh and see if that helps.

A better long term solution would probably be to improve the default boot loader to execute from RAM if nothing is found in the SPI Flash. I'll try to fix that

zavax2005 commented 8 years ago

Thanks Olofk. Finally got back to check on this, and it is working now! So you theory is correct.

I have a question here: what does --bootrom paramter actually do during the fusesoc building? Before I post the question here, I kind figured out that I needed to change the bootrom configuration from "spi_uimage_loader.vh" to "clear_r3_and_jump_to_0x100.vh". So I did manually on the file at orpsoc-cores/systems/de0_nano/rtl/verilog/orpsoc_top.v, but it didn't seem to work....but using your --bootrom_file parameter did work! Do you have any documentation regarding parameters I can pass to fusesoc for building?

The reason why I asked about JTAG_TAP pin configuration is Julius Baxter's project at https://github.com/juliusbaxter/mor1kx-dev-env. He had pin mapping for the JTAG_TAP on his configuration. And I was able to build ajd run everything following his tutorials.....

Thanks again! -Xueming

olofk commented 8 years ago

Hmm... that's strange. Changing the bootrom parameter in orpsoc_top.v should work. Maybe it was just a typo? Did you check the synthesis log (<workspace>/build/de0_nano/bld-quartus/de0_nano.map.rpt) to see if Quartus failed to find the file?

For parameters in general, you can just run fusesoc build de0_nano --help to find all options that can be used when building the de0_nano target. Similarly, you can use fusesoc sim de0_nano --help to find all options that can be used for simulation

mor1kx-dev-env is very outdated and not used anymore. I'm not sure anyone remembers the reason behind some of the decisions in there anymore :)