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. 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. Supporting multiple address spaces in Ruby is something I would like to see happen, but it will be a substantial change. It requires supporting 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. Brad > -----Original Message----- > From: [email protected] [mailto:gem5-dev- > [email protected]] On Behalf Of Andrew Cebulski > Sent: Friday, May 18, 2012 2:01 PM > To: Default; Andreas Hansson; Andrew Cebulski > Subject: Re: [gem5-dev] Review Request: ARM: Enable Ruby functionality > with ARM FS > > > > > On May 18, 2012, 6:12 a.m., Andreas Hansson wrote: > > > Conceptually I would very much like to see the patch being flipped > around, i.e. not ARM FS on Ruby, but how to make Ruby work with ARM FS, > and preferably having a more flexible memory map. The main goal would be > to run the same images/kernel on different memory systems. Would this be > possible? > > > > Andreas Hansson wrote: > > To clarify, I was not referring to the name of the patch, but to the > changes made. In other words, I would propose to change Ruby to be able to > deal with the memory map...not the other way round. > > Right, I understand...I should have commented with that change too. That is > definitely the final goal, but I'm still waiting on suggestions and/or > pointers > on how this can be done. I'm new to the Ruby model (and Ruby itself), and > have not had time to ramp up on how it works and handles memory. > > My current solution is definitely a temporary "hack". Submitting it here on > the review board will hopefully get more people thinking about a permanent > solution without the current memory limitations (172MB). That and getting > Ruby working with O3CPU in ARM FS. That should work even with 172MB of > memory (it does at least with the classic system). When I get a chance, I can > run a debug trace and email the it to the list. > > > - Andrew > > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1191/#review2708 > ----------------------------------------------------------- > > > On May 18, 2012, 8:36 a.m., Andrew Cebulski wrote: > > > > ----------------------------------------------------------- > > This is an automatically generated e-mail. To reply, visit: > > http://reviews.gem5.org/r/1191/ > > ----------------------------------------------------------- > > > > (Updated May 18, 2012, 8:36 a.m.) > > > > > > Review request for Default. > > > > > > Description > > ------- > > > > These are the changes I made to get ARM FS working with Ruby. Most > notably, I had to make the memory contiguous by putting the physmem and > nvmem together, otherwise Ruby would not handle them correctly. Details > here on the mailing list: > http://permalink.gmane.org/gmane.comp.emulators.m5.users/10440 > > > > This required shrinking physmem from 256MB to 172MB, then placing > nvmem at address 172MB. Next, the boot loader has to be recreated with > the Makefile under the system directory, changing the address to > 0x0C000000. > > > > Hopefully, at the very least, this will help others start testing out ARM FS > with Ruby. > > > > > > Diffs > > ----- > > > > build_opts/ARM_MESI_CMP_directory PRE-CREATION > > build_opts/ARM_MOESI_CMP_directory PRE-CREATION > > build_opts/ARM_MOESI_CMP_token PRE-CREATION > > build_opts/ARM_MOESI_hammer PRE-CREATION > > configs/common/Benchmarks.py f681719e2e99 > > configs/common/FSConfig.py f681719e2e99 > > configs/example/ruby_fs.py f681719e2e99 > > src/dev/arm/RealView.py f681719e2e99 > > system/arm/simple_bootloader/Makefile f681719e2e99 > > > > Diff: http://reviews.gem5.org/r/1191/diff/ > > > > > > Testing > > ------- > > > > Currently, I've tested this successfully with the SPEC CPU2006 libquantum > benchmark with the Timing CPU. I'm still running tests with the ARM O3CPU. > They seem to be hanging during boot at "sched_clock: 32 bits at 24MHz, > resolution 41ns, wraps every 178956ms". Note that I have not tested this > with Android, only Ubuntu. > > > > > > Thanks, > > > > Andrew Cebulski > > > > > > _______________________________________________ > 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
