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
