Python is also used to control the simulation, taking and restoring
snapshots as well as all the command line processing.
+We use a VExpress\_EMM based system to run Barrelfish. The number of
+cores can be passed as an argument to the gem5 script. Cores are
+clocked at 1 GHz and main memory is 64 MB starting at 2 GB.
+
\subsection{Compilation}
% Source: Get from Samuel's README file
-\pravin{FIXME: Add details of simulated board architecture}
-% TODO:
In addition to the steps described in Section~\ref{sec:armcompile} you
will need a supported version of gem5.
the same physical memory, memory usage is not increased by this
technique.
-%\includegraphics[width=\linewidth]{figures/memory_layout}
-
-Figure 1 shows the memory layout of the single-core ARMv7-a port of
-Barrelfish. We have a memory split at 2GB, where everything upwards is
-only accessible in privileged mode and the lower 2GB of memory is
-accessible for user space programs. The position of the kernel in the
-virtual space is hard- coded. The L1 page table of the kernel address
-space is located right after the kernel and aligned to 16KB. We map
-the whole available physical memory into the kernel’s virtual address
-space. The locations for the 64KB kernel stack, the ramdisk aswell as
-the section for memory mapped devices are hardcoded. Overall the
-memory layout is very static and turned out to be problematic with
-regard to multicore support, which will be explained in section 4.2.
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=\linewidth]{figures/memory_layout.png}
+ \caption{Barrelfish memory layout for ARMv7 on gem5}
+ \label{fig:memory_layout}
+\end{figure}
+
+Figure~\ref{fig:memory_layout} shows the memory layout of the
+single-core ARMv7-a port of Barrelfish. We have a memory split at 2GB,
+where everything upwards is only accessible in privileged mode and the
+lower 2GB of memory is accessible for user space programs. The
+position of the kernel in the virtual space is hard- coded. The L1
+page table of the kernel address space is located right after the
+kernel and aligned to 16KB. We map the whole available physical memory
+into the kernel’s virtual address space. The locations for the 64KB
+kernel stack, the ramdisk aswell as the section for memory mapped
+devices are hardcoded. Overall the memory layout is very static and
+turned out to be problematic with regard to multicore support, which
+will be explained in section 4.2.
We still implement a memory split the same way we did in the
number = 013,
month = mar}
+@article{gem5:sigarch11,
+ author = {Binkert, Nathan and Beckmann, Bradford and Black, Gabriel and Reinhardt, Steven K. and Saidi, Ali and Basu, Arkaprava and Hestness, Joel and Hower, Derek R. and Krishna, Tushar and Sardashti, Somayeh and Sen, Rathijit and Sewell, Korey and Shoaib, Muhammad and Vaish, Nilay and Hill, Mark D. and Wood, David A.},
+ title = {The Gem5 Simulator},
+ journal = {SIGARCH Comput. Archit. News},
+ volume = {39},
+ number = {2},
+ month = aug,
+ year = {2011},
+ pages = {1--7},
+ address = {New York, NY, USA},
+}
+
+@article{m5:micro06,
+ title={The M5 simulator: Modeling networked systems},
+ author={Binkert, Nathan L. and Dreslinski, Ronald G. and Hsu, Lisa R. and Lim, Kevin T. and Saidi, Ali G. and Reinhardt, Steven K.},
+ journal={Micro, IEEE},
+ volume={26},
+ number={4},
+ pages={52--60},
+ year={2006},
+}
+
+@article{gems:sigarch05,
+ title={Multifacet's general execution-driven multiprocessor simulator ({GEMS}) toolset},
+ author={Martin, Milo MK. and Sorin, Daniel J. and Beckmann, Bradford M. and Marty, Michael R. and Xu, Min and Alameldeen, Alaa R. and Moore, Kevin E. and Hill, Mark D. and Wood, David A.},
+ journal={ACM SIGARCH Computer Architecture News},
+ volume={33},
+ number={4},
+ pages={92--99},
+ year={2005},
+ publisher={ACM}
+}
+
@TechReport{btn019-devicedrivers,
author = bft,