Tuesday, January 19, 2016

Running HelenOS/sparc64 in gem5

On Sunday I created a simple shell script to install and configure the gem5 simulator for use with HelenOS (and other operating systems). The script closely follows, streamlines and automates most of the steps described in this blog written by Gedare Bloom. In particular, it takes care of:
  • cloning the gem5 repository;
  • building the gem5.fast binary for SPARC;
  • downloading and extracting the firmware blobs from the OpenSPARC tarball; 
  • creating symbolic links to the .bin files so that gem5 can find them under the name it expects;
  • copying out the gem5 configuration files and patching example/fs.py to propagate the --disk-image script option to the actual configuration (this should really be the default, IMO).
When the script runs to completion without an error, one can start the simulation by running the following command line from the directory in which the script was executed:
M5_PATH=`pwd` \
gem5/build/SPARC/gem5.fast configs/example/fs.py \
--disk-image=/path/to/image.iso
After doing this, gem5 should output a couple of lines similar to these:
gem5 Simulator System. http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.
gem5 compiled Jan 17 2016 23:03:08gem5 started Jan 19 2016 11:25:35
gem5 executing on gorgo, pid 11963
command line: gem5/build/SPARC/gem5.fast configs/example/fs.py --disk-image=/home/jermar/software/HelenOS.mainline/image.iso
Global frequency set at 1000000000000 ticks per second
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (64 Mbytes)
warn: DRAM device capacity (8192 Mbytes) does not match the address range assigned (256 Mbytes)
info: No kernel set for full system simulation. Assuming you know what you're doing
Listening for t1000 connection on port 3456
Listening for t1000 connection on port 3457
0: system.remote_gdb.listener: listening for remote gdb on port 7000
**** REAL SIMULATION ****
info: Entering event queue @ 0. Starting simulation...
info: Ignoring write to SPARC ERROR regsiter
info: Ignoring write to SPARC ERROR regsiter
warn: Don't know what interrupt to clear for console.
From another terminal one can connect to the serial console either via:
telnet localhost 3457
or:
gem5/util/term/m5term 3457
After a short while, the simulated machine should output this to the serial console:
==== m5 slave terminal: Terminal 0 ==== cpu Probing I/O buses

Sun Fire T2000, No KeyboardCopyright 2005 Sun Microsystems, Inc.  All rights reserved.OpenBoot 4.20.0, 256 MB memory available, Serial #1122867.[mo23723 obp4.20.0 #0]Ethernet address 0:80:3:de:ad:3, Host ID: 80112233.


ok 
I am planning to integrate the gem5 support into the tools/ew.py script in order to further automate the process of starting the simulation of HelenOS/sparc64/sun4v. I will also try to figure out how to get rid of the nuisance of having to type boot into the ok prompt at the beginning of each simulation. Theoretically, it should be possible to do:
ok setenv auto-boot? true
and then somehow save the contents of the NVRAM into the nvram1 binary as installed by the script.

Unfortunately, gem5 is not yet quite ready for running mainline HelenOS because it has problems with the TICK and TICK_COMPARE registers. There has been an incomplete attempt to fix this, but for the time being HelenOS needs to be patched to use STICK and STICK_COMPARE for better simulation experience.

Even after working around the TICK_COMPARE issue, HelenOS experience in gem5 will not be smooth enough because of two unresolved issues. The first issue is that for some reason the VFS server crashes when the TSB support is enabled. The TSB can be thought of as a large shared software-controlled TLB and is not essential for running HelenOS, so configuring HelenOS not to use TSB will help the simulation a lot. The remaining second issue is that sometimes the STICK register will get ahead of the STICK_COMPARE without generating the timer interrupt, which will effectively render HelenOS wedged.

I am looking into these issues as time permits and will report in the comments section or in a new blog post when there is some progress to report.