Increase number of addressed instructions for ROM

[bandvig]

Number of addressed ROM instruction is increased from 16 to 64.
Otherwise there is no enough room for a BOOTROM_SPI_FLASH-like boot.

Note 1.
Actually, I implemented small program on ASM to switch on board (Atlys) LEDs periodically using GPIO. Let's say it was my 1st exercise with OpenRISC. As I'm not very familiar with simulation tools yet I spend about 2 days to found that address mask for ROM just blocks instructions, so my program couldn't be executed completely. The extension of the mask fixes the problem. Perhaps, it makes sense to expand the mask for other boards.

Note 2.
I haven't included the LEDs switching code into updated rom.v because the increased size of ROM leads to that ISE couldn't route default Atlys configuration. So I have to exclude the VGA0, AC97 and PS_x modules from SoC temporary. If somebody is interested in the code, the following is listing for rom.v (other parts under case(adr) must be commented):

/* LEDs round switching
0 : wb_dat_o <= 32'h18000000; // l.movhi r0, 0 // r0 is zero
1 : wb_dat_o <= 32'h18209100; // l.movhi r1, hi(0x9100) // store gpio base address(0x91000000) in R1
2 : wb_dat_o <= 32'ha88000ff; // l.ori r4, r0, 0xFF // configure GPIO pins...
3 : wb_dat_o <= 32'hd8012001; // l.sb 1(r1), r4 // ... as outputs
4 : wb_dat_o <= 32'ha8800001; // l.ori r4, r0, 0x01 // light on LD0...
5 : wb_dat_o <= 32'hd8012000; // l.sb 0(r1), r4 // ... at startup
6 : wb_dat_o <= 32'h184002fa; // l.movhi r2, hi(0x02fa) // R2 - threshold for ~1sec interval counter (2faf080 = 50e6 = IN_CLK)
7 : wb_dat_o <= 32'ha842f080; // l.ori r2, r2, lo(0xf080) // the threshold is 16 times lower than period defined by IN_CLK
8 : wb_dat_o <= 32'hb8420044; // l.srli r2, r2, 4 // 4 instructions per loop and dependacy delays
9 : wb_dat_o <= 32'ha8600000; // sec_cnt_init: l.ori r3, r0, 0 // ~1sec interval counter reset
10 : wb_dat_o <= 32'h9c630001; // sec_cnt_loop: l.addi r3, r3, 1 // counter increment
11 : wb_dat_o <= 32'he4031000; // l.sfeq r3, r2 // check if we have achived 1sec threshold
12 : wb_dat_o <= 32'h0ffffffe; // l.bnf sec_cnt_loop // if not yet - continue update counter
13 : wb_dat_o <= 32'h15000000; // l.nop
14 : wb_dat_o <= 32'hb8840001; // l.slli r4, r4, 1 // light on for next led
15 : wb_dat_o <= 32'hb8640048; // l.srli r3, r4, 8 // cycle on byte owerflow
16 : wb_dat_o <= 32'ha4630001; // l.andi r3, r3, 0x1 // ...
17 : wb_dat_o <= 32'he0841804; // l.or r4, r4, r3 // ...
18 : wb_dat_o <= 32'ha48400ff; // l.andi r4, r4, 0xFF // ...
19 : wb_dat_o <= 32'hd8012000; // l.sb 0(r1), r4 // put to gpio data register
20 : wb_dat_o <= 32'h03fffff5; // l.j sec_cnt_init // count till next second
21 : wb_dat_o <= 32'h15000000; // l.nop
22 : wb_dat_o <= 32'h15000000; // l.nop
*/

[bluecmd]

Hi!

Is there a specific reason why you need this to be upstream? To me it looks like a local modification that doesn't really belong in orpsoc-cores.

[bandvig]

Let me clarify. I don't propose to include the LED switching code - it is just an example. Nothing more.

The useful modification is the only proposed extension of number of addressed ROM instructions from 16 to 64. Mostly to be able to run BOOTROM_SPI_FLASH. The spi flash loader source code isn't listed here (!!), because it could be easily compiled from ORPSoC v2 (http://opencores.org/or1k/ORPSoCv2) source tree (it is exactly that I did).

I use BOOTROM_SPI_FLASH to run u-boot (http://opencores.org/or1k/U-Boot, http://www.rte.se/blog/blogg-modesty-corex/installing-u-boot-universal-bootloader/2.9). In next turn the u-boot is used load and run linux+BusyBox port (git://openrisc.net/jonas/linux, http://www.rte.se/blog/blogg-modesty-corex/installing-linux/2.11).

I think, the BOOTROM_SPI_FLASH support is valuable feature for upstream.
However, if nobody interested in BOOTROM_SPI_FLASH actually, then the proposal could be refused.

[olofk]

Hi!

I don't mind increasing the default size of the ROM, but wb_intercon.v is an autogenerated file (generated by wb_intercon_gen), so I would like to see the corresponding change in data/wb_intercon.conf as well

I also think that the hardcoded ROM should be deprecated and replaced with wb_ram instead so we can change the boot loader code more easily, but we can do that later.

[bandvig]

@olofk, could you explain what you mean talking "wb_ram"? I'm not sure that understand you clearly. I imagine that "ram" is device that loses it content on power off. While a SoC should include a power independent storage like ROM or FLASH to perform initial boot. (Of course, for personal usage somebody can build a SoC without any ROM/FLASH support, load a program directly to RAM and execute it through debug system.)

By the way, my own idea was that it would be better for FPGA prototyping to generate ROM from FPGA's build-in RAM cell (or several cells).

And finally. Would it be better If I will close the request, update data/wb_intercon.conf, check the functionality and open another request?

[olofk]

wb_ram is a component that does exactly what I think you want to do. It implements a RAM with a wishbone interface from on-chip memories such as block ram or distram. It also supports preloading the memory from a verilog mem file, which makes it useful as a boot loader. If you don't want to be able to write to it (to have a true ROM), you can just disable the wb_we signal to only allow reading. I have a port for a new board that uses wb_ram as a boot loader, but I haven't pushed it upstream yet

You can find the component here https://github.com/openrisc/orpsoc-cores/tree/master/cores/wb_ram

[olofk]

And to answer your last question, I'm not very good at these pull request mechanisms, so I'll leave it to an expert to answer that. Anyone?

[bluecmd]

It's fine for him to commit these changes to the branch he opened the pull request for. Any new changes will show up in this request.

[skristiansson]

On Tue, Jul 15, 2014 at 12:33 AM, Christian Svensson <
notifications@github.com> wrote:

It's fine for him to commit these changes to the branch he opened the pull
request for. Any new changes will show up in this request.

Yes, but you don't want to include incremental changes to the pull-request
(e.g. first adding a couple of lines in one commit and then removing them
in a later).

Stefan

[bandvig]

Well. I think that so called wb-ram is better solution. So, I just close the request without a further action and continue use hijack on my local PC.