ARM: Enable Ruby functionality with ARM FS

Information
Submitter:	Andrew Cebulski
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

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.

Testing Done

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.

Issue Summary

Description	From	Last Updated	Status
I would prefer if we can just make amends to the existing function for classic memory system to support Ruby ...	Nilay Vaish	May 17, 2012, 11:09 p.m.	Open
elsif?	Nilay Vaish	May 17, 2012, 11:09 p.m.	Open
Why do we need these new functions? Can't we make changes to the existing ones?	Nilay Vaish	May 17, 2012, 11:09 p.m.	Open

configs/common/FSConfig.py (Diff revision 1)

I would prefer if we can just make amends to the existing function for classic memory system to support Ruby as well, instead of this entire new function.

Show all issues

Andrew Cebulski May 18, 2012, 1:35 a.m. (May 18, 2012, 1:35 a.m.)

So pretty much mimic how Ruby is setup with X86 instead of Alpha?

Nilay Vaish May 18, 2012, 1:40 a.m. (May 18, 2012, 1:40 a.m.)

Yes, that is much more preferable. Else, any changes to the rest of the system will
have to be made in two different places.

configs/example/ruby_fs.py (Diff revision 1)

elsif?

Show all issues

src/dev/arm/RealView.py (Diff revision 1)

Why do we need these new functions? Can't we make changes to the existing ones?

Show all issues

Andrew Cebulski May 18, 2012, 1:35 a.m. (May 18, 2012, 1:35 a.m.)

Yes, just need to pass in an unattached bridge to the attachOnChipIO function when using Ruby.  Same can be said with the attachIORuby function...adding the dma_ports array.

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 May 18, 2012, 2:51 a.m. (May 18, 2012, 2:51 a.m.)

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.

Andrew Cebulski May 18, 2012, 7 a.m. (May 18, 2012, 7 a.m.)

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.

Summary:

-	ARM: Enable ARM FS functionality with Ruby
+	ARM: Enable Ruby functionality with ARM FS

You have a pending review.

Review Board 2.0.15

Screenshots

Files

Issue Summary

Summary: