The 172 MB was simply because that's the only way I can see to get Ruby to find the boot loader ROM...by moving it from the higher address space to the lower. I left out that the boot loader ROM is 64MB, therefore I had to shrink the DRAM by 64MB. Basically, it seems Ruby supports multiple contiguous address spaces, just not discontiguous. Is there something I am missing with regards to the ROM...maybe it doesn't need to be 64MB?
-Andrew On Thu, May 24, 2012 at 4:01 PM, Ali Saidi <[email protected]> wrote: > > > On 24.05.2012 15:23, Beckmann, Brad wrote: > > > Sorry for the much > delayed response here. I've been too selective reading the gem5-dev list > lately. > > > > So if I understand correctly, the ARM FS boot loader maps > to some higher portion of the address space and you would like to model > the accesses to this boot loader ROM through Ruby. Is that correct? I'm > a bit confused with the comment that the maximum memory supported by > Ruby is 172 MB. That certainly is not true. > > This isn't true, but what > I'm not understating is why it was done in the first place. > > > So it > appears from the patch that the CPU accesses to the boot loader don't go > thru Ruby, but rather go through the pio bus. Only the dma reads and > writes from the boot loader go through Ruby. Does that analysis seem > correct to you? Without testing the patch myself, I can't say for sure, > but think that is what's happening here. If you view the boot loader > accesses as being non-performance critical, then the current simple > solution is how I would do it. However, if want *all* those accesses > going through Ruby, then Ruby will have to support multiple address > spaces. > > That is a reasonable solution, provided that it works. The boot > loader is only executed in during boot and nominally ~10 instructions > per CPU, so it shouldn't be critical. The only issue is getting > gem5/ruby/cpus/etc to start executing code out of something on the pio > bus and the transition to ruby. Brad, do you believe that this should > work? > > Supporting multiple address spaces > non-cacheable accesses and > more powerful mapping functions in the protocol files. Currently only > one protocol, MOESI_hammer, supports non-cacheable accesses and even > that hasn't been fully flushed out. Improving the mapping functions > requires better coordination between the python config files and Ruby. I > don't have a clear idea of how to do it, but I'm happy to discuss ideas. > > > > > I think most people would be happy in the above worked, although > long term that would be a good solution. > the response, > > Ali > > Brad > > -----Original Message----- From: > > Links: > ------ > [1] > mailto:[email protected] > [2] http://reviews.gem5.org/r/1191/#review2708 > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
