search

openrisc / orpsoc-cores

Core description files for FuseSoC
124 stars 79 forks source link

Atlys ROM addressing issue found, with patch #79

Closed brunosmmm closed 9 years ago

brunosmmm commented 9 years ago

Hello, I have successfuly synthesized the design with fusesoc for atlys. However, when I proceeded to modify the rom code with a booloader for copying data from the board's SPI memory, I faced strange behavior and ultimately I found that code in the rom was not running properly.

Upon much inspection and simulation of a modified version, I discovered that there is an error in the wb_interconnect description file for this board. As it is, ROM cannot be accessed beyond the 16th instruction, because the mask provides for 64 addresses which is consistent with default ROM size, but instruction addresses are word-aligned. This ultimately gives a wishbone bus error that makes the PC jump to a weird place.

diff: http://pastebin.com/uyArMp8Y

bandvig commented 9 years ago

Ops! :+1:
Some times ago I tried to propose the very similar solution: https://github.com/openrisc/orpsoc-cores/pull/70 However it was rejected as far as I understood due to the reasons listed by @olofk : https://github.com/openrisc/orpsoc-cores/pull/70#issuecomment-48904492

brunosmmm commented 9 years ago

Got it, too bad that it seems that out of the box support for atlys is still far away.

skristiansson commented 9 years ago

On Tue, Nov 11, 2014 at 7:33 PM, Bruno Morais notifications@github.com wrote:

Got it, too bad that it seems that out of the box support for atlys is still far away.

I don't oppose adding a ROM that accesses the SPI as an intermediate solution until some more fancy mechanism is in place. That said, your patch only updated the generated verilog, not the .conf file that it is generated from. If you provide a new patch that has that change as well, then we can apply that.

Stefan

brunosmmm commented 9 years ago

Yes, I did not realize that a more generic patch was necessary so this is why I closed the issue. I am working on or1k on atlys for a project, so if I have time to make a more thorough modification I will surely submit it here. Thanks!

brunosmmm commented 9 years ago

Here goes modification of both files necessary for a temporary solution. http://pastebin.com/6M9p48qg

olofk commented 9 years ago

Yep. That looks good to me. I realize that there really isn't any need to be overly conservative with the address space allocated for the boot rom here. A smaller memory space only makes the wb_mux more complicated. We could as well allocate a few kilobytes here so that people don't run into this problem with larger boot loaders

brunosmmm commented 9 years ago

I agree that the hardcoded rom is ugly and I am currently looking into a block ram implementation where contents can be loaded from a .mem file. This is particularly good because you could compile your assembly bootrom with or1k-gcc and then simply use or1k-objcopy with "verilog" output to generate the content file, but I am not sure on how to integrate this new process with the system as a whole

olofk commented 9 years ago

Yes, the hardcoded ROM is ugly, but after experimenting quite a bit, I found that it was very difficult to do a generic RAM component that could use $memreadh, have separate write enable signals for all four bytes and map efficiently to on-chip RAM at the same time.

So, I think that just increasing the allocated memory space for the boot loader is good enough for now. One problem here that struck me is that it's not very good to have the base address at 0xf0000100, as this means that we can only use the addresses from 0xf0000100 to 0xf00001ff. We need to move the boot ROM to base address 0xf0000000 instead, to allow for larger bootloader than 256 bytes.

It would be great if you could apply the following changes to wb_intercon.conf [slave rom0] -offset=0xf0000100 -size=64 +offset=0xf0000000 +size=1024

, regenerate wb_intercon.v and change OPTION_RESET_PC to 32'hf0000000 in orpsoc_top.v and see if it still works. I don't have an Atlys board myself anymore, and there isn't any test bench for this system either, so I don't want to blindly apply changes

brunosmmm commented 9 years ago

I'll do that if I can, but right now I am still having issues with the board booting correctly from bootrom and retrieving contents via SPI. This is a pain to debug because every time synthesis & mapping for the board takes a very very long time.