docs: Added references and figure for memory layout
authorStefan Kaestle <stefan.kaestle@inf.ethz.ch>
Mon, 9 Dec 2013 21:58:58 +0000 (22:58 +0100)
committerKornilios Kourtis <kkourt@inf.ethz.ch>
Wed, 11 Dec 2013 13:49:24 +0000 (14:49 +0100)
doc/017-arm/ARM.tex
doc/017-arm/figures/memory_layout.png [new file with mode: 0644]
doc/style/barrelfish.bib

index 6004884..630f1e2 100644 (file)
@@ -258,12 +258,14 @@ and allows to tailor nearly every aspect of the system to our needs.
 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.
 
@@ -397,19 +399,25 @@ to the kernel, leads to a pagefault. Since many mappings can point to
 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
diff --git a/doc/017-arm/figures/memory_layout.png b/doc/017-arm/figures/memory_layout.png
new file mode 100644 (file)
index 0000000..98e8694
Binary files /dev/null and b/doc/017-arm/figures/memory_layout.png differ
index 1cb7718..590ab3c 100644 (file)
@@ -1193,6 +1193,39 @@ D. E. Long and Carlos Maltzahn},
   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,