> 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
