Hello,

I have arrived at the point where I consider myself being lost. Maybe someone has an idea where my mistake originates.

I am trying to adapt ORPSOCv2 to the board ML507 using ML501 as base. I want the CPU to start executing instructions from a/the boot ROM (@0xe0000000 same as in the default ML501 setup) which tells it to copy the orpmon boot loader from the SPI-flash to RAM (@0x0). My headache is that I have no access to Modelsim (the only plausible simulator). The only thing I have managed to conclude is that the SPI-flash is not accessed post configuration.

In short this is what I have done:
* Changed definitions to that the correct FPGA device

* Generated new MIG and applied JB's modifications

* Adapted UCF-file with correct locations and SPI-signals (others the same as ML501 except for changed locations)

* At the end of or1200_defines.v I have changed the Boot Address Selection to
`define OR1200_BOOT_PCREG_DEFAULT 30'h37ffffff
`define OR1200_BOOT_ADR 32'he0000000

(I did not understand why the reset vector (0x100) was used in the default setup since as far as I understand my ROM starts at 0 and goes on till 49)

*The top of orpsoc-defines.v has the following definitions

`define XILINX
`define XILINX_PLL
`define FPGA_BOARD_XILINX_ML507
`define IOCONFIG_XILINX_ML507
`define BOARD_CLOCK_PERIOD 5000
// 200MHz (pS accuracy for Xilinx sims.)
`define JTAG_DEBUG
// `define RAM_WB
// `define XILINX_SSRAM
`define CFI_FLASH
`define XILINX_DDR2
`define UART0
`define GPIO0
`define SPI0
`define I2C0
`define I2C1
`define ETH0
`define ETH0_PHY_RST


* My "sw/board/include/board.h" looks like the following

//
// ROM bootloader
//
// Uncomment the appropriate bootloader define. This will effect the bootrom.S
// file, which is compiled and converted into Verilog for inclusion at
// synthesis time. See bootloader/bootloader.S for details on each option.
#ifndef PRELOAD_RAM
#define BOOTROM_SPI_FLASH
#define BOOTROM_GOTO_RESET
//#define BOOTROM_LOOP_AT_ZERO
//#define BOOTROM_LOOP_IN_ROM
#else
#define BOOTROM_GOTO_RESET
#endif
// Address bootloader should start from in FLASH
// Last 256KB of4MB flash - offset 0x3c0000 (4MB-256KB)
#define BOOTROM_ADDR_BYTE2 0x3c
#define BOOTROM_ADDR_BYTE1 0x00
#define BOOTROM_ADDR_BYTE0 0x00
// Causes SPI bootloader to loop if SPI didn't give correct size of image
#define SPI_RETRY_IF_INSANE_SIZEWORD
//
// Defines for each core (memory map base, OR1200 interrupt line number, etc.)
//
#define SDRAM_BASE 0x0
#define GPIO_0_BASE 0x91000000
#define UART0_BASE 0x90000000
#define UART0_IRQ 2
#define UART0_BAUD_RATE 115200
#define SPI0_BASE 0xb0000000
#define SPI0_IRQ 6

...this gives me a 50 line bootrom.v

* I "maked" the orpmon-bootloader and then ran ../utils/bin2binsizeword orpmon.or32.bin orpmon-sizeword.bin. I synthesized, placed, routed and created the SPI-prepared image using the command: make orpsoc_spi.mcs BOOTLOADER_BIN=/path/to/my/orpmon/bin/orpmon-sizeword.bin

#### Generating .bit file for SPI load #### Release 13.3 - Bitgen O.76xd (lin) Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved.
Loading device for application Rf_Device from file '5vfx70t.nph' in environment /opt/XilinxDS/13.3/ISE_DS/ISE/.
"orpsoc_top" is an NCD, version 3.2, device xc5vfx70t, package ff1136, speed -1 Opened constraints file orpsoc.pcf. Fri Dec 30 21:02:06 2011
Running DRC. ...
Creating bit map...
Saving bit stream in "orpsoc_spiboot.bit".
Bitstream generation is complete.
#### Generating .mcs file with bootloader for SPI load ####
Release 13.3 - Promgen O.76xd (lin) Copyright (c) 1995-2011 Xilinx, Inc. All rights reserved. 0x338c00 (3378176) bytes loaded up from 0x0 0x1cc34 (117812) bytes loaded up from 0x3c0000 Using user-specified prom size of 4096K
Writing file "orpsoc_spi.mcs".
Writing file "orpsoc_spi.prm".
Writing file "orpsoc_spi.cfi".

* I then proceed to load the .mcs-file to the SPI-flash. After configuration the SPI-flash is not accessed (as opposed to my intention to load the orpmon loader from the small bootrom)

I hope it is possible to understand what I want to do and what I did. :)

This post is my first here so I would like to take the opportunity to say thanks for all the excellent community work. Thanks and happy new year!

Best Regards
Christer Eriksson

This is not the behaviour since I've added support for larger CFI flash part on the board.

The boot process should now be that it goes to 0xf0000000 at reset to execute out of the CFI flash. The SPI flash is no longer accessible once the FPGA is configured, unfortunately. This is due to some pinout issues which I can't exactly recall, but I'm quite sure you can't access both the CFI and SPI flashes with a user design.

I notice, however, that the way things currently are in the ml501 build in the SVN repo, the OR1200 will start up out of the bootrom (OR1200's reset address is set to 0xe0000100) which will then just go immediately to the reset vector in the main memory (0x100), due to the way the ml501/sw/board/include/board.h is configured, which I think is most useful for simulation, but isn't how I intend it to be for synthesis.


I would leave the 0xe0000100 as it was, I think I make some assumptions about us being there, although I could be wrong. That bootrom thing was one big hack that appeared to work OK so far, but there might be oddities with it if you're planning on putting a lot of code in there.


You shouldn't have those two defined. I think the GOTO_RESET one will take precedence (look at the orpsocv2/sw/bootrom.S file) and so your design is actually just going straight to 0x100 in the RAM at reset.



Yeah, I would say your best bet is to do it with the CFI flash. It's quicker, you get a bigger NV memory, and you can update the software bootloader (please use our u-boot port instead of orpmon, http://opencores.org/or1k/U-Boot ) without having to change the FPGA image in the SPI flash.

As well, I would look at tracking down some Modelsim to use. You really can't expect things to work unless you've at least simulated them because no matter how much you look over something and expect it to be right there will most likely be an incorrect assumption about something which is the cause of the thing not working.

To be honest I'm surprised the design places and routes, because I couldn't get it working with both SPI flash and CFI flash on the ML501. Perhaps the pinout is subtly different on your board.

Anyway, let us know how you go.

Cheers,

Julius

Thanks! This is just a little update, no conclusions yet.



I managed to do some simulation, but due to license limitations and me being new with the setup I have not been able to find the problem. When I run a pre-synthesis simulation I can see that the core is executing instructions from the bootrom in the logfile, however there is no activity on the SPI-signals.

The SPI-flash should be accessible through the VIRTEX5-STARTUP-block, but I have never used that before so I am following your example. I am ok with messing with the addresses for now if I get to see some sign of "life" from the board. :)

When I run a post-synthesis simulation, just for the sake, I only see the cpu running through the bootrom (pc just keeps incrementing) not executing any instructions. id_simm, which should hold the current op-code, is constant 0x0 during the whole simulation.

I will focus on the pre-synthesis simulation for now. Is there something obvious I am missing while trying to interface the SPI-flash?




I really like the hack. It is a very educational example of a bootrom. However 0x?????100 keep bothering me. Why 0x100? Or is it just "luck" that the rom repeats? :)



That label should never be executed since I have the SPI-load prior and it should jump to reset before it even reaches that label. I do not see it making any difference and I also see your point. It should not be there, but for now it makes no difference.



CFI is by far a faster development approach and the "way to go"... but I started to mess with the SPI and would like to get it working before I continue for CFI.

What it boils down to now is that the SPI interface seems dead. I would like to see the SoC sending at least the read command. That is my goal for now.

Best Regards
Christer Eriksson

Could it be as easy as an inverted reset somewhere?

--
Olof Kindgren
______________________________________________
ORSoC
Website: www.orsoc.se
Email: olof.kindgren@orsoc.se
______________________________________________
FPGA, ASIC, DSP - embedded SoC design

Even worse... :)

"Solved!"

The pre-synthesis simulation was working fine. When I run "make rtl-tests TESTS=uart-simple" the test completes successfully. (I set the bootrom to load from 0x00000 ((which will be the flash.in-file that is the UART-test-program)). It loads the program from the simulated SPI-flash ((flash.in that is)). ) The test basically takes care of all that I want for now.

However, in the post-syhthesis simulation the CPU was not executing any instructions. PC just ran through the ROM. The opcode was constantly 0x0.

I switched from Xilinx DS 13.3 32-bit to 64-bit and now it is working perfectly. What exactly did I miss? If this was obvious should not the synthesis fail? Even better a descriptive error message. I find it quite humorous that I get a half-arsed synthesis result that "almost" works.

Thanks for all the help! Hopefully I will contribute with "better" problems in the future ;)

Best Regards
Christer Eriksson