Tidying up techical notes
authorMothy <troscoe@inf.ethz.ch>
Thu, 12 Dec 2013 16:03:10 +0000 (17:03 +0100)
committerMothy <troscoe@inf.ethz.ch>
Thu, 12 Dec 2013 16:03:10 +0000 (17:03 +0100)
18 files changed:
README
doc/001-glossary/Glossary.tex
doc/001-glossary/Main.hs
doc/003-hake/Hake.tex
doc/005-scc/SCC.tex
doc/006-routing/Routing.tex
doc/008-tracing/Tracing.tex
doc/013-capability-mgmt/CapMgmt.tex
doc/013-capability-mgmt/Hakefile
doc/013-capability-mgmt/type_system.tex
doc/017-arm/ARM.tex
doc/018-Practical-guide/PracticalGuide.tex
doc/018-Practical-guide/readme.tex
doc/019-device-drivers/DeviceDriver.tex
doc/019-device-drivers/Hakefile
doc/style/barrelfish.bib
doc/style/bftn.sty
hake/symbolic_targets.mk

diff --git a/README b/README
index b58222e..d88a29f 100644 (file)
--- a/README
+++ b/README
@@ -7,7 +7,7 @@ If you do not find this file, copies can be found by writing to:
 ETH Zurich D-INFK, Haldeneggsteig 4, CH-8092 Zurich. Attn: Systems Group.
 ##########################################################################
 
-SUPPORTED HARDWARE
+Supported hardware
 --------------------------------
 
 Barrelfish currently runs on:
index 9182d5e..b1bf7f8 100644 (file)
@@ -29,6 +29,7 @@
 
 \begin{versionhistory}
 \vhEntry{1.0}{31.05.2010}{TR}{Initial version}
+\vhEntry{2.0}{01.12.2013}{TR}{Updated with new developments}
 \end{versionhistory}
 
 % \intro{Abstract}             % Insert abstract here
index f5e26d4..3f41225 100644 (file)
@@ -67,6 +67,17 @@ glossary = [ Entry "dispatcher control block" [ "DCB" ]
              \which is implemented for every type of core and provide \
              \communication between dispatchers running on that core.",
 
+             Entry "notification driver" [ "ND" ]
+
+             "A partial abstraction of a low-level message passing \
+             \mechanism which performs notification (sending an \
+             \event), rather than transferring data per se.  In \
+             \Barrelfish these mechanisms are separated where \
+             \possible for flexibility and to further decouple \
+             \sender and receiver.  Notification drivers exist in \
+             \Barrelfish for sending inter-processor interrupts on \
+             \most architectures, for example.",
+
              Entry "Flounder" []
 
              "The Interface Definition Language used for \
@@ -146,6 +157,20 @@ glossary = [ Entry "dispatcher control block" [ "DCB" ]
              \intra-machine multicast. The SKB runs as a system service \
              \accessed by message passing.",
 
+             Entry "Octopus" [] 
+
+             "A service built on (and colocated with) the SKB which \
+             \provides locking functionality inspired by Chubby and \
+             \Zookeeper, and publish/subscribe notification for \
+             \Barrelfish processes.",
+
+             Entry "Kaluga" []
+
+             "The Barrelfish device manager.  Kaluga is responsible \
+             \to starting and stopping device drivers in response to \
+             \hardware events, and based on configurable system \
+             \policies.",
+
              Entry "capability space" [ "cspace" ]
 
              "The set of capabilities held by a dispatcher on a core \
@@ -372,9 +397,25 @@ glossary = [ Entry "dispatcher control block" [ "DCB" ]
              \file with the constants, and a JSON file to be used by \
              \host visualization tools.",
 
+             Entry "Beehive" []
+
+             "Beehive was an experimental soft-core processor \
+             \designed by Chuck Thacker at Microsoft Research Silicon \
+             \Valley.  Beehive was implemented in a simulator and on \
+             \FPGAs, in particular the BEE3 processor emulation board \
+             \(which could run up to 15 Beehive cores at a time). \
+             \The architecture had a number of unusual features, in \
+             \particular, a ring interconnect for message passing, a \
+             \software-visible FIFO on each core for incoming messages, \
+             \and a memory system implemented using message passing \
+             \(loads and stores became RPCs to the memory system). \
+             \Barrelfish was ported to the Beehive processor but \
+             \support for the architecture was eventually dropped \
+             \after the Beehive project completed.", 
+
              Entry "ZZZ terms yet to be added" []
 
-             "cc-ump, init, Beehive, asmoffsets, retype, iref"
+             "asmoffsets, retype, iref"
 
            ]
 
index 8dba4fe..c01d3ce 100644 (file)
@@ -137,7 +137,7 @@ no need to hunt through 5 levels of include files.  The only thing
 Hake-generated Makefiles include are generated C dependency lists, and
 a single, top-level file giving symbolic targets.  The Makefile
 generated by Hake also makes minimal, and highly stylized, use of make
-variables: wherever, any variable substitution is done in Haskell
+variables: wherever possible, any variable substitution is done in Haskell
 before the Makefile is generated. 
 
 \paragraph{Hake is for building Barrelfish.}  We make no claims as to
@@ -308,7 +308,7 @@ When referring to files in Hake, files whose paths are ``relative''
 the path of their Hakefile, and are converted into
 ``absolute'' paths from the top of their tree when they appear.
 This is more intuitive than it sounds.  For example, a file referred
-to as \texttt{(SrcTree,``src'',''e1000.c'')} in
+to as \texttt{(SrcTree,"src","e1000.c")} in
 \texttt{drivers/e1000/Hakefile} will appear in the resulting Makefile
 as {drivers/e1000/e1000.c}.  
 
@@ -316,7 +316,7 @@ The Hake namespace is mapped onto the file system as follows: all
 files with architecture \texttt{src} are relative to the top of the
 source tree, whereas a file in a different architecture \texttt{foo}
 is relative to directory \texttt{foo/} in the build or install tree.
-Thus, \texttt{(BuildTree,``x86\_64'',''e1000.o'')} in
+Thus, \texttt{(BuildTree,"x86\_64","e1000.o")} in
 \texttt{drivers/e1000/Hakefile} will  appear in the resulting Makefile
 as {./x86\_64/drivers/e1000/e1000.o}. 
 
@@ -379,7 +379,7 @@ a file.   Note that for some file references, the tree is implicit:
 Rules in Hake differ from plain Makefile rules in that
 they only consist of rule bodies (i.e., exactly what needs to be
 done), and the targets and dependencies are inferred (so they only
-need to be written once).  An example may make this clear - here is a
+need to be written once).  An example may make this clear.  Here is a
 function which returns list of \texttt{RuleToken}s for maintaining a
 Unix library:
 \begin{verbatim}
@@ -686,7 +686,7 @@ Hake is missing many desirable features.  Hopefully, this list will
 reduce in size over time.  Here are a few:
 
 \begin{itemize}
-\item Support for multiple host build environments (such a Cygwin). 
+\item Support for multiple host build environments (such as Cygwin). 
 \item The bootstrapping process for Hake, while short, is a little
   unsatisfactory. 
 \end{itemize}
index 626e682..847b587 100644 (file)
@@ -35,6 +35,7 @@
 \vhEntry{1.3}{09.09.2010}{SP,RB}{Corrections to typos and for clarity}
 \vhEntry{1.4}{10.05.2012}{SP}{Fake VGA console removed. Physical
   memory layout added.}
+\vhEntry{1.5}{12.12.2013}{TR}{Final.  SCC program terminated.}
 \end{versionhistory}
 
 % \intro{Abstract}             % Insert abstract here
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Introduction}
 
+\textit{Note: the Intel MARC program involving the Single-Chip Cloud
+  Computer was a part, was terminated in 2013.  As a consequence,
+  Barrelfish support for the SCC also stopped at the end of the year
+  and this technical note should be regarded as historical.}
+
 This report describes the Barrelfish port to the Intel Single-chip
 Cloud Computer \cite{intel:scc:isscc10}.   It serves as a general
 repository for information about the SCC platform, and therefore
index d38af9d..a160210 100644 (file)
@@ -24,6 +24,7 @@
 \vhEntry{1.01}{14.06.2010}{AS}{Added discussion of design and unresolved issues}
 \vhEntry{1.02}{23.07.2010}{AS}{More work on design and API}
 \vhEntry{2.0}{31.05.2011}{Alexander Grest}{Multi-hop messaging}
+\vhEntry{2.1}{01.12.2013}{TR}{Some explanation}
 \end{versionhistory}
 
 % \intro{Abstract}             % Insert abstract here
 
 \chapter{Motivation}
 
-All inter-core communication in Barrelfish is performed using explicit messages, which are carried over ''Interconnect Drivers'' (ICDs), specialized messaging subsystems that carry data between cores. At present, all communication happens over direct point-to-point ICD links. However, there are multiple motivations for extending this. In this chapter, we motivate the introduction of a routing layer in Barrelfish.
+This technical note describes a set of design proposals (and prototype
+implementation) of multi-hop message routing in Barrelfish -- how to
+send messages between cores which do not have a direct connection
+between them.  This arises in, for example, Ethernet communication
+with a fully-distributed Barrelfish instance, or between multiple
+cores spread out over a PCIe bus (as is the case with Xeon Phi or
+Intel SCC). 
+
+All inter-core communication in Barrelfish is performed using explicit
+messages, which are carried over ''Interconnect Drivers'' (ICDs),
+specialized messaging subsystems that carry data between cores. At
+present, all communication happens over direct point-to-point ICD
+links. However, there are multiple motivations for extending this. In
+this note, we motivate the introduction of a routing layer in
+Barrelfish. 
 
 
 \section{Partial connectivity}
@@ -68,19 +83,20 @@ the number of messages in buffer.
 
 The more ICD links a core has, the more of its resources will be used for them. This is detrimental to a high-performance system. By limiting the number of links, we will limit the amount of resources required. One way to limit the number of links is to multiplex multiple channels over one ICD link and therefore not construct a fully connected network. 
 
-% Still valid?
-%\section{Heterogeneous IDC}
-%Barrelfish supports various IDC mechanisms.
-%Different mechanisms provide different semantics and guarantees such as maximum frame
-%size, notification mechanism, synchrony, etc.
 
-%An application can utilize multiple IDC mechanisms.
-%This can happen if a homogeneous machine supports multiple IDC mechanisms or if the
-%application runs on a heterogeneous machine.
-%To avoid the need for the application to understand the different semantics of all IDC,
-%it can conform to the semantics provided by the routing library.
+\section{Heterogeneous IDC}
+Barrelfish supports various IDC mechanisms.
+Different mechanisms provide different semantics and guarantees such
+as maximum frame size, notification mechanism, synchrony, etc.
+
+An application can utilize multiple IDC mechanisms.  This can happen
+if a homogeneous machine supports multiple IDC mechanisms or if the
+application runs on a heterogeneous machine.  To avoid the need for
+the application to understand the different semantics of all IDC, it
+can conform to the semantics provided by the routing library.
 
-%The semantics provided by the routing layer are discussed in section \ref{sec:semantics}.
+The semantics provided by the routing layer are discussed in section
+\ref{sec:semantics}.
 
 \section{Group communication}
 
@@ -94,8 +110,8 @@ also require communication among a group of nodes.
 A group of nodes that want to come to agreement on some value
 need to communicate with each other.
 
-\cite{nishtala:optimizing-collective:hotpar09, barrelfish:sosp09}
-showed that even in a fully connected 
+It has been shown \cite{nishtala:optimizing-collective:hotpar09,
+  barrelfish:sosp09} that even in a fully connected 
 machine, using some form of routing can improve the performance of group communication.
 The sender sends the message to a subset of nodes it wishes to communicate with.
 The subset will in turn forward it to the remaining set of nodes.
@@ -414,7 +430,7 @@ The set of semantics provided are as follows:
   Each message is eventually delivered and the contents are not corrupted.
 \item Causal ordering:
   If the delivery of message $m$ depends upon the delivery of message $m'$ as
-  per the \emph{happened before} relationship \cite{events-time},
+  per the \emph{happened before} relationship \cite{Lamport:1978:TCO:359545.359563},
   then $m$ is not delivered till $m'$ has been delivered.
 \item Failure:
   The routing library will not fail.
@@ -480,104 +496,99 @@ If such guarantees are required at all times in the application,
 the application must refrain from sending messages while
 group member is in flux.
 
-%\section{Flow control}
-%The IDC mechanisms that the routing library operates over are asynchronous.
-%When a message is sent over them,
-%it will eventually be delivered to the receiver.
-%Undelivered messages are maintained in a queue of fixed length.
-%If the sender tries to send messages too quickly the queue can fill up.
-%If the queue is full, the sender must wait
-%till the queue has room for more messages.
-%IDC mechanisms allow senders to register callbacks in such situations.
-%When a send fails with the transient error that
-%the queue is full, the sender can register
-%a callback which will be called when the next send should not fail.
-%While the sender waits for the callback, it has to handle the unsent message.
-
-%We discuss the simple scenario of two nodes and
-%then a more complex scenario of many nodes.
-
-%\subsection{Client-server model}
-
-%\begin{figure}[t]
-% \includegraphics[width=\columnwidth]{client-server.pdf}
-% \caption{Client-server model}\label{fig:client-server}
-%\end{figure}
-
-%Figure \ref{fig:client-server} shows a simple client-server model
-%of two nodes that are directly connected.
-%The weights on the edges is the length of the queue.
-%The client sends messages to the server, the server processes them
-%and sends replies to the client.
-%It is possible that link1 becomes full maybe because
-%the client has not been handling replies on it.
-%At this point the server has some options:%
-
-%\begin{itemize}
-%\item Drop the message.
-%  The server can simply drop the message if the queue is full.
-%  This will result in an unreliable channel.
-%\item Allocate some resources and queue the message up.
-%  This implies unbounded resource requirement.
-%\item Apply back pressure on the client.
-%  The server at this point can stop processing messages
-%  from the client till it is able to send messages to it again.
-%\end{itemize}
-
-%In this model the last option works well as it will force the client
-%to slow down and process replies before sending more requests.
-
-%\subsection{Multihop route}
+\section{Flow control}
+The IDC mechanisms that the routing library operates over are asynchronous.
+When a message is sent over them,
+it will eventually be delivered to the receiver.
+Undelivered messages are maintained in a queue of fixed length.
+If the sender tries to send messages too quickly the queue can fill up.
+If the queue is full, the sender must wait
+till the queue has room for more messages.
+IDC mechanisms allow senders to register callbacks in such situations.
+When a send fails with the transient error that
+the queue is full, the sender can register
+a callback which will be called when the next send should not fail.
+While the sender waits for the callback, it has to handle the unsent message.
+
+We discuss the simple scenario of two nodes and
+then a more complex scenario of many nodes.
+
+\subsection{Client-server model}
+
+\begin{figure}[t]
+ \includegraphics[width=\columnwidth]{client-server.pdf}
+ \caption{Client-server model}\label{fig:client-server}
+\end{figure}
+
+Figure \ref{fig:client-server} shows a simple client-server model
+of two nodes that are directly connected.
+The weights on the edges is the length of the queue.
+The client sends messages to the server, the server processes them
+and sends replies to the client.
+It is possible that link1 becomes full maybe because
+the client has not been handling replies on it.
+At this point the server has some options:%
+
+\begin{itemize}
+\item Drop the message.
+  The server can simply drop the message if the queue is full.
+  This will result in an unreliable channel.
+\item Allocate some resources and queue the message up.
+  This implies unbounded resource requirement.
+\item Apply back pressure on the client.
+  The server at this point can stop processing messages
+  from the client till it is able to send messages to it again.
+\end{itemize}
+
+In this model the last option works well as it will force the client
+to slow down and process replies before sending more requests.
+
+\subsection{Multihop route}
 
 \begin{figure}[t]
  \includegraphics[width=\columnwidth]{many-to-many.pdf}
  \caption{Example multihop route}\label{fig:many-to-many}
 \end{figure}
 
-%In this scenario the problem is more complex.
-%Figure \ref{fig:many-to-many} shows a group of 5 nodes,
-%the link weights specifies the queue length of the link.
-%If node1 and node2 are sending messages to node4,
-%link34 will fill up before link13 or link23 does.
-%Node3 cannot send additional messages to node4.
-%At this point, node3 has the following options:
-
-%\begin{itemize}
-%\item Continue to process incoming messages on link13 and link23.
-%  If they are destined for node4, drop them.
-%  This will result in an unreliable channel.
-%\item Continue to process incoming messages and if they are destined for node4,
-%  queue them up locally.
-%  This implies unbounded resource requirement.
-%\item Stop processing messages on link13 and link23.
-%  This will delay messages on those links that were not destined to node4.
-%  In literature, this is called \emph{Head of line blocking} \cite{cite}.
-%\end{itemize}
-
-%None of these solutions are particularly desirable.
-%Flow control in the context different types of networks has
-%been studied previously.
-%We should study the related work before we come up with our own designs.
-
-%I summarize some existing work I am aware of here that we should look into:
-%\begin{itemize}
-%\item Credit based flow control:
-%  The endpoints dictate maximum number of messages in flight.
-%\item TCP flow control
-%\item Ethernet flow control
-%\item Datacenter ethernet flow control
-%\item Related work in routing between sockets on a machine
-%\item QoS (DiffServ and IntServ).
-%\end{itemize}
-
-%Some applications may not be willing to pay the cost of flow control.
-%Further, a flow control mechanism that guarantees reliability
-%may not scale well with  number of nodes.
-%This can be an interesting research topic for us.
-
-%We discuss some abstract ideas we have for flow control below.
+In this scenario the problem is more complex.
+Figure \ref{fig:many-to-many} shows a group of 5 nodes,
+the link weights specifies the queue length of the link.
+If node1 and node2 are sending messages to node4,
+link34 will fill up before link13 or link23 does.
+Node3 cannot send additional messages to node4.
+At this point, node3 has the following options:
 
+\begin{itemize}
+\item Continue to process incoming messages on link13 and link23.
+  If they are destined for node4, drop them.
+  This will result in an unreliable channel.
+\item Continue to process incoming messages and if they are destined for node4,
+  queue them up locally.
+  This implies unbounded resource requirement.
+\item Stop processing messages on link13 and link23.
+  This will delay messages on those links that were not destined to node4.
+  In literature, this is called \emph{Head of line blocking} \cite{cite}.
+\end{itemize}
+
+None of these solutions are particularly desirable.
+Flow control in the context different types of networks has
+been studied previously.
+
+Relevant existing work includes:
+\begin{itemize}
+\item Credit based flow control:
+  The endpoints dictate maximum number of messages in flight.
+\item TCP flow control
+\item Ethernet flow control
+\item Datacenter ethernet flow control
+\item Related work in routing between sockets on a machine
+\item QoS (DiffServ and IntServ).
+\end{itemize}
 
+Some applications may not be willing to pay the cost of flow control.
+Further, a flow control mechanism that guarantees reliability
+may not scale well with  number of nodes.
+We discuss some abstract ideas we have for flow control below.
 
 \section{Open questions}
 Some open questions
@@ -656,7 +667,7 @@ Some benchmarks that validate the claims of above and show the performance of th
 \item Link state vs. distance vector routing
 \end{itemize}
 
-\bibliographystyle{abbrvnat}
+\bibliographystyle{abbrv}
 \bibliography{defs,barrelfish}
 
 \end{document}
index 7bff122..1a41d18 100644 (file)
@@ -702,7 +702,7 @@ This chapter describes how to use the Tracing framework in Barrelfish.
 \item Download and compile Aquarium2 as described in the README as
   part of the source code
 \end{itemize}
-
+\clearpage
 \begin{code}
 \begin{lstlisting}[frame=single, caption={Enable tracing for an application}, label={lst:app_example}]
 #include <trace/trace.h>
@@ -846,6 +846,4 @@ potentially affecting the outcome of the tracing heavily.
 
 % vim:set spell spelllang=en_us tw=80:
 
-
-
 \end{document}
index 9ae94c5..366dc27 100644 (file)
@@ -14,7 +14,7 @@
 \usepackage{color,listings,ctable}
 
 \title{Capability Management in Barrelfish}   % title of report
-\author{Akhilesh Singhania, Ihor Kuz}  % author
+\author{Akhilesh Singhania, Ihor Kuz, Mark Nevill}     % author
 \tnnumber{013}  % give the number of the tech report
 \tnkey{Capability Management} % Short title, will appear in footer
 
@@ -57,6 +57,9 @@
 %
 \begin{versionhistory}
 \vhEntry{1.0}{08.03.2011}{AS}{Initial version}
+\vhEntry{2.0}{27.1.2012}{MN}{New capability system design}
+\vhEntry{2.1}{8.7.2013}{SK}{Updates}
+\vhEntry{2.2}{1.12.2013}{TR}{Fixed missing references/citations}
 \end{versionhistory}
 
 % \intro{Abstract}             % Insert abstract here
@@ -167,7 +170,7 @@ highlights issues not yet covered in this document.
 This chapter will cover how capabilities are stored and what happens
 on capability invocation.
 
-\section{Storage}
+\section{Storage}\label{sec:cspace}
 For security reasons, capabilities are stored in kernel-space and
 users are given pointers to them. Each capability is stored in two
 separate databases:
@@ -185,7 +188,7 @@ separate databases:
        operations.
 \end{itemize}
 
-\section{Capability invocation}
+\section{Capability invocation}\label{sec:sys_invoke}
 When a dispatcher invokes a capability, it passes the kernel an
 address of the capability in the CSpace it wishes to invoke. The
 kernel locates the capability starting from the dispatcher's root
index 88873fc..48b689d 100644 (file)
@@ -6,7 +6,7 @@
 -- If you do not find this file, copies can be found by writing to:
 -- ETH Zurich D-INFK, Universitaetstr. 6, CH-8092 Zurich. Attn: Systems Group.
 --
--- Hakefile for /doc/004-virtual_memory
+-- Makefile for /doc/003-capabilities
 --
 ----------------------------------------------------------------------
 
index 62e2a75..147a0a5 100644 (file)
@@ -47,7 +47,7 @@ supported types in Barrelfish.
   representations: in the memory of each core on which it may appear,
   and in a canonical serialised representation used for transferring
   it in a message between cores. These are specified as
-  Hamlet\cite{hamlet} data types.
+  Hamlet\cite{dagand:fof:plos09} data types.
 
 \item[Invocations] Most capability types support one or more
   type-specific operations through the use of the invoke system call.
@@ -326,7 +326,7 @@ region of kernel-accessible memory.
 
 \subsection{Dispatcher}
 This capability type refers to the kernel object associated with a
-user-level dispatcher (see \ref{sec:dispatch}).
+user-level dispatcher.
 
 \begin{description}
 \item[Origin] Retyping from RAM capabilities.
@@ -412,7 +412,7 @@ is specified changed by minting an endpoint to another endpoint.
   
 \item[Invocation] Any invocation of an endpoint capability causes the
   entire message to be delivered to the dispatcher to which the
-  endpoint refers (see \ref{sec:IDC}).
+  endpoint refers.
   \end{description}
 
 \subsection{VNode}
@@ -421,7 +421,7 @@ manage a domain's virtual address space.  Frame and device frame
 capabilities can be copied or minted into them or deleted from them by
 invoking a CNode.  The architecture may impose limitations on the
 capabilities that may be copied into a VNode, or may allow extra
-attributes to be set when minting; see \ref{apx:arch_specific}.
+attributes to be set when minting.
 
 \begin{description}
 \item[Origin] Retyping from RAM type capabilities.
@@ -616,8 +616,8 @@ device interrupts.
 \end{invocation}
 This invocation sets the user-level handler endpoint that will receive
 a message when the given interrupt occurs.  While a handler is set,
-interrupts will be delivered as IDC messages, as described in
-\ref{sec:interrupts}.
+interrupts will be delivered as IDC messages.
+
 
 \begin{invocation}{Delete}
   \arg IRQ number
index 630f1e2..fe58eab 100644 (file)
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \chapter{Introduction}
 
-This document describes the state of the ARM port of
-Barrelfish~\cite{barrelfish:sosp09}.
+This document describes the state of support for ARM processors
+in Barrelfish.
 
-\todo{Explain architectures and platforms}
+ARM hardware is highly diverse, and has evolved over time.  As a
+research OS, Barrelfish focusses ARM support on a small number of
+platforms based on wide availability, ease of maintenance, and
+research interest.  
+
+The principal processors with ARM support in Barrelfish at present are
+as follows: 
+
+\begin{itemize}
+\item ARMv7a (Cortex A-series), in particular the Cortex A9. 
+\item ARMv7m (Cortex M-series), in particular the Cortex M3. 
+\item ARMv5 processors, in particular the Intel iXP2800 network
+  processor (which uses an XScale core). 
+\end{itemize}
+
+The main systems we target at present are:
+\begin{itemize}
+\item The Texas Instruments OMAP4460 SoC used in the PandaBoard ES
+  platform. 
+\item The ARM VExpress\_EMM board, under emulation in the GEM5
+  simulator. 
+\end{itemize}
+
+In addition there is limited (and not tested) support in the
+Barrelfish tree for:
+\begin{itemize}
+\item The Netronome i8000 card, incorporating a single Intel iXP2800
+  processor. 
+\end{itemize}
 
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\chapter{Barrelfish implementation on ARM}\label{chap:impl}
 
-\todo{Explain that we have several: ARMv5, OMAP4460 A9, OMAP4460 M3
-  and the VExpress\_EMM emulated by gem5}
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Implementations}\label{chap:impl}
 
 \section{ARM in general}
 
@@ -132,6 +158,13 @@ The intention is that the Cortex-A9 will be running a general purpose
 operating system, while the Cortex-M3 processors will only be running
 a real-time operating system to control the imaging subsystem.
 
+The processor configuration in the OMAP4460 is somewhat
+unconventional; for example, the Cortex-M3 processors share a
+custom MMU with page faults handled by code running on the Cortex-A9
+processors and hence are constrained to run in the same virtual
+address at all times.  They are also not cache-coherent with the
+Cortex-A9 cores. 
+
 \subsection{Compilation}
 
 To compile Barrelfish for the PandaBoard, first, make sure to
@@ -159,34 +192,30 @@ works: it waits for a signal from the BSP core (an interrupt), and when this
 signal is received, the application core will read an address from a well-
 defined register and start executing the code from this address.
 
-So, you can give some work to the other core by simply writing the address of
-a function to the register and sending the signal. Following are few pointers
-to the documentation to help you to understand the bootstrapping process
-in more details.
+To boot the second core, one can write the address of
+a function to the register and send the inter-processor
+interrupt. Following are some pointers to the documentation to help
+understand the bootstrapping process in more detail:
 
 \begin{itemize}
 \item Section 27.4.4 in the OMAP44xx manual talks about the boot process for
-  application cores
-\item Pages 1144f in the OMAP44xx manual have the register layout for the
-  registers that are used in the boot process of the second core.
+  application cores.
+\item Pages 1144 \textit{ff.} in the OMAP44xx manual have the register
+  layout for the registers that are used in the boot process of the
+  second core. 
 \end{itemize}
 
 Note that the Barrelfish codebase distinguishes between the BSP (bootstrap)
 processor and APP (application) processors. This distinction and naming
-originates from Intels x86 where the BIOS will choose a distinguished BSP processor
-for you at start-up and the OS programmer is responsible to start the rest
-of the processors (the APP processors). Altough it works a bit different on
+originates from Intel x86 support where the BIOS will choose a
+distinguished BSP processor at start-up and the OS 
+is responsible for starting the rest of the processors (the APP
+processors). Although it works somewhat differently on 
 ARM, the naming convention is applicable here as well.
 
-Remember that second core will start working with the MMU disabled, so
-it only understands physical addresses at this time.  As the second
-core will be doing function calls of it's own, it will need it's own
-stack and some assembly code to setup stack and CPU state. As we just
-want to get the second core up, you may want to setup and execute a
-function on the second core in a very early stage of boot-up before
-things become complicated with MMU, caching and interrupts.
-
-\stefan{Are we booting the second core from user-level in our tree?}
+Note that the second core will start working with the MMU disabled, so
+is running in physical address space.  The bootstrapping code sets up a
+stack, initial page tables and an initial Barrelfish dispatcher. 
 
 \subsection{Physical address space}
 
@@ -195,11 +224,23 @@ independently.
 
 \subsection{Interconnect driver}\label{sec:interconnect}
 
-Mention that there is a mailbox. I don't think we have a driver for it
-in the tree, but Claudio might have one.
+Communication between A9 cores on the OMAP processor is performed
+using a variant of the CC-UMP interconnect driver, modified for the
+32-byte cache line size of the ARMv7 architecture.  A notification
+driver for inter-processor interrupts exists. 
+
+The OMAP4460 also has mailbox hardware which can be used by both the
+A9 and M3 cores.  Barrelfish support for this hardware is in
+progress. 
 
 \subsection{M3 cores}
 
+Barrelfish also has rudimentary support for running on both the A9 and
+M3 cores.  This is limited by the requirement that the M3 cores must
+run in the same virtual address space, and do not have a way to
+automatically change address space on a kernel trap.  For this reason,
+we only execute on a single M3 core at present. 
+
 \subsubsection{Booting M3 cores}
 
 Before the Cortex-M3 can start executing code, the following steps
@@ -264,8 +305,6 @@ clocked at 1 GHz and main memory is 64 MB starting at 2 GB.
 
 \subsection{Compilation}
 
-% Source: Get from Samuel's README file
-
 In addition to the steps described in Section~\ref{sec:armcompile} you
 will need a supported version of gem5.
 
@@ -302,7 +341,6 @@ NOTE 2: If you use \code{--cpu-type=arm_detailed} (use \code{make
 arm_gem5_detailed}), the simulation takes a long time (depending on
 your machine up to an hour just to boot Barrelfish)
 
-
 \subsection{Boot process: first (bootstrap) core}
 
 % Source: Samuel's thesis, 4.1.1
@@ -439,13 +477,6 @@ reserved the first MB of physical memory for this purpose.
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\chapter{Reflections on ARM as a platform}\label{chap:refl}
-
-\section{Debugging}~\label{debugging}
-
-Experience with JTAG?
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 \bibliographystyle{abbrv}
 \bibliography{defs,barrelfish}
 
index 6805e54..aa82d22 100644 (file)
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\chapter{Introduction}
+
+This note describes how to build and boot Barrelfish on 64-bit PC
+hardware, which is the default configuration for Barrelfish.  It then
+goes on to work through a simple ``hello, world''-style application
+which illustrates client-server programming in C on Barrelfish, and
+the use of the message-passing subsystem. 
+
+Information on how to compile Barrelfish for other platforms, in
+particular ARM, are found in other documents.  However, the
+application programming section in this guide is still relevant. 
+
+\chapter{PC compilation and installation}\label{chap:compilationInstallation}
 
-\chapter{Barrelfish compilation and installation}\label{chap:compilationInstallation}
 \input{readme}
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
index d9d94c7..36a5cf4 100644 (file)
@@ -1,15 +1,11 @@
-\section{SUPPORTED HARDWARE%
+\section{Supported x86 hardware%
   \label{supported-hardware}%
 }
 
 Barrelfish currently runs on:
-%
-\begin{quote}
-%
 \begin{itemize}
-
-\item x86 CPUs in either IA-32 or AMD64 mode. The following are known to work:
-%
+\item x86 CPUs in either IA-32 or AMD64 mode. The following systems
+  are known to work: 
 \begin{itemize}
 
 \item Intel Xeon Clovertown, Gainestown, Beckton (X5355, E5520, X7560, L5520,
index 74177f4..b4b3a54 100644 (file)
@@ -556,12 +556,6 @@ if (err_is_fail(err)) {
 }
 \end{lstlisting}
 
-\chapter{Integrating your NIC driver with the Barrelfish network stack}
-\label{chap:network}
-
-TODO pravin?
-
-
 \chapter{Limitations \& Work in Progress}
 
 Altough we currently have the necessary support for user-space drivers
@@ -572,4 +566,8 @@ we mentioned briefly where the two approaches differ. In the future we will
 most likely unify both platforms under a standardized API which will have
 the best of both worlds.
 
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+\bibliographystyle{abbrv}
+\bibliography{barrelfish}
+
 \end{document}
index 12651fc..2b38604 100644 (file)
@@ -10,4 +10,4 @@
 --
 ----------------------------------------------------------------------
 
-[ buildTechNote "DeviceDriver.tex" "TN-019-DeviceDriver.pdf" False False [] ]
+[ buildTechNote "DeviceDriver.tex" "TN-019-DeviceDriver.pdf" True False [] ]
index 590ab3c..1902997 100644 (file)
@@ -1238,3 +1238,23 @@ D. E. Long and Carlos Maltzahn},
 
 
 
+@article{Lamport:1978:TCO:359545.359563,
+ author = {Lamport, Leslie},
+ title = {Time, Clocks, and the Ordering of Events in a Distributed System},
+ journal = {Commun. ACM},
+ issue_date = {July 1978},
+ volume = {21},
+ number = {7},
+ month = jul,
+ year = {1978},
+ issn = {0001-0782},
+ pages = {558--565},
+ numpages = {8},
+ url = {http://doi.acm.org/10.1145/359545.359563},
+ doi = {10.1145/359545.359563},
+ acmid = {359563},
+ publisher = {ACM},
+ address = {New York, NY, USA},
+ keywords = {clock synchronization, computer networks, distributed systems, multiprocess systems},
+} 
+
index 0deabb7..d56097b 100644 (file)
       \vhCurrentDate \\ %% @date \\
       \vspace{3ex}
       \large \rm
-      Systems Group, ETH Zurich\\
-      c/o Department of Computer Science \\
+      Systems Group\\
+      Department of Computer Science \\
       \large
-      ETH Zurich CAB F.79, Universit\"atstrasse 6, Zurich 8092, Switzerland \\[1ex]
+      ETH Zurich\\
+      CAB F.79, Universit\"atstrasse 6, Zurich 8092, Switzerland \\[1ex]
       \large
       \url{http://www.barrelfish.org/} \mbox{}
       \par
index cf82e29..2d8fbbc 100644 (file)
@@ -431,7 +431,10 @@ DOCS= \
        ./docs/TN-013-CapabilityManagement.pdf \
        ./docs/TN-014-bulk-transfer.pdf \
        ./docs/TN-015-DiskDriverArchitecture.pdf \
-       ./docs/TN-016-Serial.pdf 
+       ./docs/TN-016-Serial.pdf \
+       ./docs/TN-017-ARM.pdf \
+       ./docs/TN-018-PracticalGuide.pdf \
+       ./docs/TN-019-DeviceDriver.pdf 
 
 docs doc: $(DOCS)
 .PHONY: docs doc