[J-core] Fwd: Re: Resources for figuring out how to replace boot rom in bitstream?

[Rob Landley]

This is probably of more general interest...

Rob

-------- Forwarded Message --------
Subject: Re: Resources for figuring out how to replace boot rom in bitstream?
Date: Tue, 7 Nov 2017 14:02:47 +0900
From: D. Jeff Dionne <jeff at uclibc.org>
To: Rich Felker <dalias at libc.org>, Rob Landley <rob at landley.net>

>>> On Oct 30, 2017, at 11:30, Rich Felker wrote:
>>> 
>>> Jeff,
>>> 
>>> It came up at the end of last week that it doesn't make sense for me
>>> to be taking yours and Nishii's time & attention away every time I
>>> need a bitstream with a new version number. Can you point me to the
>>> Xilinx documents I should look at to figure out how to replace the
>>> boot rom in an existing bitstream, assuming I'm not really familiar
>>> with any of the tools? If I can figure that out, it will make releases
>>> go a lot more smoothly, and it will also unblock development on the
>>> bootloader itself (since there will no longer be a 2-3 hour turnaround
>>> time for testing a new bootloader build).
>>> 
>>> Rich

>> On Mon, Oct 30, 2017 at 11:56:38AM +0900, D. Jeff Dionne wrote:
>> 
>> I think the tool data2mem is what we want:
>> https://www.xilinx.com/Attachment/Xilinx_Answer_46945_Data2Mem_Usage_and_Debugging_Guide.pdf
>> 
>> That said, it is clearly 'advanced' use of the tools, and interwebs
>> has ppl complaining it doesn't work correctly. Part of the prob is
>> surely user error, this use guide is an eye opener. Messing around
>> inside the design hierarchy is fraught with pitfalls.
>> 
>> I think it can be mechanical, but not automatic. Nothing is going to
>> write out where the rom is, so something had to walk the hierarchy
>> and find where it put the blocks. That part is a question of keeping
>> the correct files (the bitstream alone will not have that info), and
>> not hard. The main issue is knowing the path to the ROM, that is the
>> mangled name of block ram instance... the obvious thought is to give
>> the rom a unique searchable name, and then just search for that name
>> to discover the path in some file.
>> 
>> Cheers,
>> J

> On Nov 7, 2017, at 12:59, Rich Felker <dalias at libc.org> wrote:
> 
> I've been doing some more reading on this tool, and it seems like it's
> intended to do what we want, but the documentation is all awful and
> seems to be assuming (1) you're using Microblaze cpus, and (2) the
> original block ram is defined through Xilinx tools rather than
> initialized in a VHDL file. I don't think either of these assumptions
> is actually necessary or an issue, but they're major obstacles to
> making sense of the instructions.
> 
> Since data2mem is supposed to be able to dump the existing bram init
> contents, I want to see if I can get that to work first. But it seems
> to need a "bmm" file defining some sort of address mapping. I'm not
> sure what its contents should be. There's some confusing mention of
> bitgen which makes me think it might be able to produce the bmm file,
> but I'm not sure.
> 
> Any quick ideas that might help me move forward on this?
> 
> Rich

Hi Rich,

We found a tool that will give you the locations of the RAMs.  You need the Placed and Routed .ncd file (Native Circuit Description) from the build.  Then, you can convert that to text with the xdl tool, and look for the rams.  The names of the Boot ROM RAM blocks are defined in memory_fpga.vhd (a file generated by the build from the template memory_fpga.vhd.in)

jeff at VirtualSuSE:~/work/gps/soc_top/last_output> ls -l memory_fpga.vhd
-rw-r--r-- 1 jeff users 94853 2017-09-05 00:45 memory_fpga.vhd
jeff at VirtualSuSE:~/work/gps/soc_top/last_output>
jeff at VirtualSuSE:~/work/gps/soc_top/last_output>
jeff at VirtualSuSE:~/work/gps/soc_top/last_output> xdl -ncd2xdl soc2_evb2_par.ncd
jeff at VirtualSuSE:~/work/gps/soc_top/last_output>
jeff at VirtualSuSE:~/work/gps/soc_top/last_output> grep RAM[01234][HL][HL] soc2_evb2_par.xdl | grep placed
inst "soc/cpus/sram/RAM3HH" "RAMB18E1",placed BRAM_L_X32Y120 RAMB18_X2Y49  ,
inst "soc/cpus/sram/RAM3HL" "RAMB18E1",placed BRAM_R_X41Y115 RAMB18_X3Y47  ,
inst "soc/cpus/sram/RAM2HH" "RAMB18E1",placed BRAM_L_X32Y130 RAMB18_X2Y52  ,
inst "soc/cpus/sram/RAM2HL" "RAMB18E1",placed BRAM_R_X41Y120 RAMB18_X3Y48  ,
inst "soc/cpus/sram/RAM3LH" "RAMB18E1",placed BRAM_R_X41Y135 RAMB18_X3Y55  ,
inst "soc/cpus/sram/RAM3LL" "RAMB18E1",placed BRAM_L_X32Y115 RAMB18_X2Y47  ,
inst "soc/cpus/sram/RAM1HH" "RAMB18E1",placed BRAM_R_X41Y125 RAMB18_X3Y51  ,
inst "soc/cpus/sram/RAM1HL" "RAMB18E1",placed BRAM_R_X41Y115 RAMB18_X3Y46  ,
inst "soc/cpus/sram/RAM2LH" "RAMB18E1",placed BRAM_R_X41Y140 RAMB18_X3Y57  ,
inst "soc/cpus/sram/RAM2LL" "RAMB18E1",placed BRAM_L_X32Y120 RAMB18_X2Y48  ,
inst "soc/cpus/sram/RAM0HH" "RAMB18E1",placed BRAM_L_X32Y130 RAMB18_X2Y53  ,
inst "soc/cpus/sram/RAM0HL" "RAMB18E1",placed BRAM_R_X41Y125 RAMB18_X3Y50  ,
inst "soc/cpus/sram/RAM1LH" "RAMB18E1",placed BRAM_R_X41Y135 RAMB18_X3Y54  ,
inst "soc/cpus/sram/RAM1LL" "RAMB18E1",placed BRAM_L_X32Y125 RAMB18_X2Y50  ,
inst "soc/cpus/sram/RAM0LH" "RAMB18E1",placed BRAM_R_X41Y140 RAMB18_X3Y56  ,
inst "soc/cpus/sram/RAM0LL" "RAMB18E1",placed BRAM_R_X41Y120 RAMB18_X3Y49  ,
jeff at VirtualSuSE:~/work/gps/soc_top/last_output>

It should not be hard to work out the structure of the Boot ROM’s RAM blocks from the tool patchcode.pl in soc_top/tools/patchcode.pl

Cheers,
J.