diff --git a/templates/page.tmpl b/templates/page.tmpl
index 21f4d2b..9f7014f 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -62,7 +62,7 @@
 <TMPL_IF RECENTCHANGESURL>
 <li><a href="<TMPL_VAR RECENTCHANGESURL>">RecentChanges</a></li>
 </TMPL_IF>
-<TMPL_IF HISTORYURL>
+<TMPL_IF MORPHURL>
 <li><a href="<TMPL_VAR MORPHURL>">Morph</a></li>
 </TMPL_IF>
 <TMPL_IF GETSOURCEURL>

diff --git a/sidebar.mdwn b/sidebar.mdwn
index 0e9255a..b8074d6 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,7 +1,9 @@
-This is the sidebar. To be edited very soon.
 
-* [[Edit]]
-* [[RecentChanges]]
-* [[History]]
-* [[Preferences]]
+* [[Overview]]
+* [[Morph]]
+* [[Trebuchet]]
+* [Source](http://gitorious.org/baserock)
+* [[Policy]]
+
+
 
diff --git a/templates/page.tmpl b/templates/page.tmpl
index 94d653c..21f4d2b 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -63,7 +63,7 @@
 <li><a href="<TMPL_VAR RECENTCHANGESURL>">RecentChanges</a></li>
 </TMPL_IF>
 <TMPL_IF HISTORYURL>
-<li><a href="<TMPL_VAR HISTORYURL>">History</a></li>
+<li><a href="<TMPL_VAR MORPHURL>">Morph</a></li>
 </TMPL_IF>
 <TMPL_IF GETSOURCEURL>
 <li><a href="<TMPL_VAR GETSOURCEURL>">Source</a></li>

diff --git a/sidebar.mdwn b/sidebar.mdwn
index 640516a..0e9255a 100644
--- a/sidebar.mdwn
+++ b/sidebar.mdwn
@@ -1,6 +1,7 @@
 This is the sidebar. To be edited very soon.
 
-* [[overview]]
-* [[Morph]]
-* [[Trebuchet]]
+* [[Edit]]
+* [[RecentChanges]]
+* [[History]]
+* [[Preferences]]
 

diff --git a/sidebar.mdwn b/sidebar.mdwn
new file mode 100644
index 0000000..640516a
--- /dev/null
+++ b/sidebar.mdwn
@@ -0,0 +1,6 @@
+This is the sidebar. To be edited very soon.
+
+* [[overview]]
+* [[Morph]]
+* [[Trebuchet]]
+

diff --git a/templates/page.tmpl b/templates/page.tmpl
index 167b756..94d653c 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -38,7 +38,7 @@
 <span>
 <span class="parentlinks">
 <TMPL_LOOP PARENTLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ 
+<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE>/</a> 
 </TMPL_LOOP>
 </span>
 <span class="title">

diff --git a/local.css b/local.css
index 61bafef..a9e3e63 100644
--- a/local.css
+++ b/local.css
@@ -24,10 +24,11 @@ div.pageheader {
     background: none repeat scroll 0 0 #28170B;
     border-color: #28170B;
     border-style: solid solid none;
-    border-width: 0px;
+    border-width: 0;
     margin: 0;
-    padding: 0.1em 0.5em 0.5em 1em;
-    float:right;
+    bottom: 15px;
+    width: 400px;
+    position: relative;
 }
 
 .pageheader li a:hover {

diff --git a/index.mdwn b/index.mdwn
index be3735d..d73ff01 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -3,7 +3,7 @@ Baserock
 
 Welcome to the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, helped immensely by the upstream work of [Linaro](http://linaro.org). Project background, objectives and design thinking are outlined in the [[overview]]. 
 
-You can join the conversation at #baserock on freenode - currently there is no mailing list.
+You can join the conversation at #baserock on freenode - there is a [[mailinglist]] for developers.
 
 Baserock is a new project - documentation is incomplete and likely to change. As a result early readers will probably need a lot of background knowledge to understand the project e.g.
 

diff --git a/mailinglist.mdwn b/mailinglist.mdwn
index 44348a7..04c3878 100644
--- a/mailinglist.mdwn
+++ b/mailinglist.mdwn
@@ -1,7 +1,7 @@
 Baserock Mailing list
 =====================
 
-The Baserock mailing list is currently hosted by [Pepperfish]:http://www.pepperfish.net/ and the web-ui for the list can be found at http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/baserock-dev-baserock.org
+The Baserock mailing list is currently hosted by [Pepperfish](http://www.pepperfish.net/) and the web-ui for the list can be found on [Pepperfish's List server](http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/baserock-dev-baserock.org).
 
 The list may move, so do not rely on deep links beyond this page on the Baserock wiki.
 

diff --git a/mailinglist.mdwn b/mailinglist.mdwn
new file mode 100644
index 0000000..44348a7
--- /dev/null
+++ b/mailinglist.mdwn
@@ -0,0 +1,7 @@
+Baserock Mailing list
+=====================
+
+The Baserock mailing list is currently hosted by [Pepperfish]:http://www.pepperfish.net/ and the web-ui for the list can be found at http://vlists.pepperfish.net/cgi-bin/mailman/listinfo/baserock-dev-baserock.org
+
+The list may move, so do not rely on deep links beyond this page on the Baserock wiki.
+

diff --git a/local.css b/local.css
index 5e198d1..61bafef 100644
--- a/local.css
+++ b/local.css
@@ -26,7 +26,7 @@ div.pageheader {
     border-style: solid solid none;
     border-width: 0px;
     margin: 0;
-    padding: 0.1em 0.5em 1em;
+    padding: 0.1em 0.5em 0.5em 1em;
     float:right;
 }
 
@@ -35,8 +35,12 @@ div.pageheader {
     color: #BF2400;
 }
 
+.parentlinks {
+    font: 13px Verdana, Sans-serif;
+}
+
 .title {
-    font: 100% sans-serif;
+    font: 13px Verdana,sans-serif;
     margin-top: 0.2em;
     display:inline;
 }

diff --git a/Trebuchet.mdwn b/Trebuchet.mdwn
index 77ed01f..2a10968 100644
--- a/Trebuchet.mdwn
+++ b/Trebuchet.mdwn
@@ -1,6 +1,8 @@
 # Trebuchet
 
-Trebuchet is a generic update mechanism for a Linux system. It delivers updates through a binary patch for the filesystem. It rolls the update during runtime on a writeable snapshot of the root filesystem allowing runtime safe, reliable and revertible updates.
+Trebuchet is a generic update mechanism for a Linux system. It delivers updates through a binary patch for the filesystem. Trebuchet requires Btrfs - it rolls the update during runtime on a writeable snapshot of the root filesystem allowing runtime safe, reliable and revertible updates. 
+
+
 
 ## Core components
 

diff --git a/Morph.mdwn b/Morph.mdwn
index a477537..625685f 100644
--- a/Morph.mdwn
+++ b/Morph.mdwn
@@ -5,4 +5,5 @@ in there may still change.
 
 [[repositories]] describes our current thinking on how Morph will handle branching, patching and releases for multiple upstream projects and a range of stakeholders.
 
-
+**Note** that Morph is in its very early stages yet. There are many
+rough corners. But see [[getting-started]].
diff --git a/Morph/getting-started.mdwn b/Morph/getting-started.mdwn
new file mode 100644
index 0000000..cd4a9f4
--- /dev/null
+++ b/Morph/getting-started.mdwn
@@ -0,0 +1,17 @@
+Getting started with `morph`
+============================
+
+* Install [cliapp](http://liw.fi/cliapp/). You need version 0.21.
+* Check out `morph` and `morphs` from <https://gitorious.org/baserock>.
+* Check out `fhs-dirs`, `eglibc`, and `busybox` from 
+  <https://gitorious.org/baserock-morphs>.
+* Create a cache directory in a suitable place.
+* Adapt the following command to your directories, and run it in the
+  `morph` checkout:
+  `./morph build ../morphs/base.morph --log=morph.log --verbose 
+  --git-base-url=file://$HOME/baserock/gits/ --cachedir=$HOME/baserock/cache`
+* Run the resulting system image:
+  `kvm -hda $HOME/baserock/cache/*.system -kernel ../bzImage  -append 
+  'root=/dev/sda1 init=/bin/sh quiet'`
+
+This will all become easier.

diff --git a/overview.mdwn b/overview.mdwn
index b195604..b8ca299 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -1,6 +1,6 @@
 # Background
 
-Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in the mobile market, where Android, Maemo, Moblin, MeeGo, OpenMoko, Limo, Bada, WebOS and soon Tizen show leading players choosing Linux-based technologies for small form factor devices. 
+Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in the mobile market, where Android, Maemo, Moblin, MeeGo, OpenMoko, Limo, Bada, WebOS and soon Tizen and Meltemi show leading players choosing Linux-based technologies for small form factor devices. 
 
 Perhaps less obvious is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
 

diff --git a/overview.mdwn b/overview.mdwn
index 07a0954..b195604 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -1,6 +1,6 @@
 # Background
 
-Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in mobile phones, where Android, Maemo, OpenMoko, Limo, Bada, WebOS and soon Tizen show leading players choosing Linux-based technologies for small form factor devices. 
+Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in the mobile market, where Android, Maemo, Moblin, MeeGo, OpenMoko, Limo, Bada, WebOS and soon Tizen show leading players choosing Linux-based technologies for small form factor devices. 
 
 Perhaps less obvious is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
 

diff --git a/overview.mdwn b/overview.mdwn
index 2b5c39c..07a0954 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -2,7 +2,7 @@
 
 Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in mobile phones, where Android, Maemo, OpenMoko, Limo, Bada, WebOS and soon Tizen show leading players choosing Linux-based technologies for small form factor devices. 
 
-Less obvious to consumers is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
+Perhaps less obvious is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
 
 # The problem
 Most current Linux distribution mechanisms are not well suited to embedded device projects, where we usually have to deal with some or all of the following characteristics:

diff --git a/Morph/repositories.mdwn b/Morph/repositories.mdwn
index 0d907ad..9947f4a 100644
--- a/Morph/repositories.mdwn
+++ b/Morph/repositories.mdwn
@@ -113,8 +113,7 @@ Using git repositories with Baserock
     and upgrading and removal of specific strata on some of the systems,
     but that's getting beyond the scope of this
 
-What a lotta branches
----------------------
+# What a lotta branches
 
 Keeping things in feature branches sounds like a good idea so that:
 
@@ -125,8 +124,7 @@ Keeping things in feature branches sounds like a good idea so that:
 * it's easy to combine the same fix into many deliverables
   (e.g., an eglibc bug fix might be backported into several releases)
 
-I hate this
------------
+# I hate this
 
 The above sounds like a lot of bureaucratic hassle that will get
 really annoying and horrifically error prone very quickly. However,

diff --git a/overview.mdwn b/overview.mdwn
index c765724..2b5c39c 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -26,7 +26,7 @@ The current best-of-breed approaches for building constrained systems with Linux
 We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 
 # Our solution
-Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are using the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, GNOME, Linaro, OpenEmbedded/Poky.
+Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are drawing on the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, GNOME, Linaro, OpenEmbedded/Poky.
 
 # Design approach
 We have identified a core set of steps for the kinds of systems we are targeting as follows:

diff --git a/overview.mdwn b/overview.mdwn
index eadec85..c765724 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -26,7 +26,7 @@ The current best-of-breed approaches for building constrained systems with Linux
 We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 
 # Our solution
-Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are using the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
+Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are using the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, GNOME, Linaro, OpenEmbedded/Poky.
 
 # Design approach
 We have identified a core set of steps for the kinds of systems we are targeting as follows:

diff --git a/overview.mdwn b/overview.mdwn
index 4084edb..eadec85 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -11,17 +11,17 @@ Most current Linux distribution mechanisms are not well suited to embedded devic
 - limited communications bandwidth
 - custom, limited or no user interface 
 - there is no "desktop" 
-- fast boot required
-- realtime performance required
+- fast boot
+- realtime performance
 - BSP is probably customised
 
 The current best-of-breed approaches for building constrained systems with Linux conversely miss functionality we see as critical:
 
-- built-in security required
+- built-in security
 - unattended upgrade, and possibly factory reset, in the field
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
-- Speed and stability of build
+- fast, stable build
 
 We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 

diff --git a/overview.mdwn b/overview.mdwn
index e9df3a5..4084edb 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -26,7 +26,7 @@ The current best-of-breed approaches for building constrained systems with Linux
 We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 
 # Our solution
-Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
+Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are using the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
 
 # Design approach
 We have identified a core set of steps for the kinds of systems we are targeting as follows:

diff --git a/overview.mdwn b/overview.mdwn
index 9c75d74..e9df3a5 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -21,7 +21,7 @@ The current best-of-breed approaches for building constrained systems with Linux
 - unattended upgrade, and possibly factory reset, in the field
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
-- Speed and fragility of build
+- Speed and stability of build
 
 We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 

diff --git a/overview.mdwn b/overview.mdwn
index d672eea..9c75d74 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -21,6 +21,7 @@ The current best-of-breed approaches for building constrained systems with Linux
 - unattended upgrade, and possibly factory reset, in the field
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
+- Speed and fragility of build
 
 We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 

diff --git a/index.mdwn b/index.mdwn
index 99df19e..be3735d 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,7 @@
 Baserock
 ========
 
-Welcome to the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, helped immensely by the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. 
+Welcome to the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, helped immensely by the upstream work of [Linaro](http://linaro.org). Project background, objectives and design thinking are outlined in the [[overview]]. 
 
 You can join the conversation at #baserock on freenode - currently there is no mailing list.
 

diff --git a/index.mdwn b/index.mdwn
index 3736add..99df19e 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,7 @@
 Baserock
 ========
 
-Welcome to the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. 
+Welcome to the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, helped immensely by the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. 
 
 You can join the conversation at #baserock on freenode - currently there is no mailing list.
 

diff --git a/local.css b/local.css
index 3a8e867..5e198d1 100644
--- a/local.css
+++ b/local.css
@@ -38,13 +38,21 @@ div.pageheader {
 .title {
     font: 100% sans-serif;
     margin-top: 0.2em;
+    display:inline;
 }
 
 #logo a {
-  background: url("logo.png");
+    height: 40px;
+    width: 282px;
+    display: block;
+    padding-bottom: 10px;
+    background: url(logo.png) no-repeat;
 }
 #logo a span {
-  visibility: hidden;
+    visibility: hidden;
+}
+#logo a:hover {
+    text-decoration: none;
 }
 
 .pageheader .actions a { color: #fbebbc; }
@@ -52,7 +60,7 @@ div.pageheader {
 div.header {
     background-repeat: no-repeat;
     min-width: 282px;
-    padding-top: 50px;
+    padding-top: 0px;
 }
 
 div#footer {

diff --git a/local.css b/local.css
index 24bc4cb..3a8e867 100644
--- a/local.css
+++ b/local.css
@@ -40,10 +40,16 @@ div.pageheader {
     margin-top: 0.2em;
 }
 
+#logo a {
+  background: url("logo.png");
+}
+#logo a span {
+  visibility: hidden;
+}
+
 .pageheader .actions a { color: #fbebbc; }
 
 div.header {
-    background-image: url("logo.png");
     background-repeat: no-repeat;
     min-width: 282px;
     padding-top: 50px;

diff --git a/templates/page.tmpl b/templates/page.tmpl
index 3216d51..167b756 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -34,7 +34,7 @@
 <TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
 
 <TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
-<TMPL_IF HTML5><header class="header"><div class="header"><<div id="logo"><a href="../"><span>wiki.baserock.org</span></a></div></a><TMPL_ELSE><div class="header"><<div id="logo"><a href="../"><span>wiki.baserock.org</span></a></div></TMPL_IF>
+<TMPL_IF HTML5><header class="header"><div class="header"><div id="logo"><a href="../"><span>wiki.baserock.org</span></a></div><TMPL_ELSE><div class="header"><div id="logo"><a href="../"><span>wiki.baserock.org</span></a></div></TMPL_IF>
 <span>
 <span class="parentlinks">
 <TMPL_LOOP PARENTLINKS>

diff --git a/templates/page.tmpl b/templates/page.tmpl
index 5d0e016..3216d51 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -34,7 +34,7 @@
 <TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
 
 <TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
-<TMPL_IF HTML5><header class="header"><a href="../"></a><TMPL_ELSE><div class="header"><a href="../"></a></TMPL_IF>
+<TMPL_IF HTML5><header class="header"><div class="header"><<div id="logo"><a href="../"><span>wiki.baserock.org</span></a></div></a><TMPL_ELSE><div class="header"><<div id="logo"><a href="../"><span>wiki.baserock.org</span></a></div></TMPL_IF>
 <span>
 <span class="parentlinks">
 <TMPL_LOOP PARENTLINKS>

diff --git a/templates/page.tmpl b/templates/page.tmpl
index 769aca5..5d0e016 100644
--- a/templates/page.tmpl
+++ b/templates/page.tmpl
@@ -34,7 +34,7 @@
 <TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
 
 <TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
-<TMPL_IF HTML5><header class="header"><TMPL_ELSE><div class="header"></TMPL_IF>
+<TMPL_IF HTML5><header class="header"><a href="../"></a><TMPL_ELSE><div class="header"><a href="../"></a></TMPL_IF>
 <span>
 <span class="parentlinks">
 <TMPL_LOOP PARENTLINKS>

diff --git a/local.css b/local.css
index 434694d..24bc4cb 100644
--- a/local.css
+++ b/local.css
@@ -38,7 +38,6 @@ div.pageheader {
 .title {
     font: 100% sans-serif;
     margin-top: 0.2em;
-    display:inline;
 }
 
 .pageheader .actions a { color: #fbebbc; }

diff --git a/local.css b/local.css
index 362f9a4..434694d 100644
--- a/local.css
+++ b/local.css
@@ -26,7 +26,7 @@ div.pageheader {
     border-style: solid solid none;
     border-width: 0px;
     margin: 0;
-    padding: 0.1em 0.5em 1.1em;
+    padding: 0.1em 0.5em 1em;
     float:right;
 }
 
@@ -38,6 +38,7 @@ div.pageheader {
 .title {
     font: 100% sans-serif;
     margin-top: 0.2em;
+    display:inline;
 }
 
 .pageheader .actions a { color: #fbebbc; }

diff --git a/local.css b/local.css
index 12f9ac4..362f9a4 100644
--- a/local.css
+++ b/local.css
@@ -35,6 +35,11 @@ div.pageheader {
     color: #BF2400;
 }
 
+.title {
+    font: 100% sans-serif;
+    margin-top: 0.2em;
+}
+
 .pageheader .actions a { color: #fbebbc; }
 
 div.header {

diff --git a/local.css b/local.css
index d4e37f5..12f9ac4 100644
--- a/local.css
+++ b/local.css
@@ -26,7 +26,13 @@ div.pageheader {
     border-style: solid solid none;
     border-width: 0px;
     margin: 0;
-    padding: 0.1em 0.5em 0;
+    padding: 0.1em 0.5em 1.1em;
+    float:right;
+}
+
+.pageheader li a:hover {
+    background: none repeat scroll 0 0 #FBEBBC;
+    color: #BF2400;
 }
 
 .pageheader .actions a { color: #fbebbc; }

diff --git a/Trebuchet/tb-update.mdwn b/Trebuchet/tb-update.mdwn
index 32d091c..c060108 100644
--- a/Trebuchet/tb-update.mdwn
+++ b/Trebuchet/tb-update.mdwn
@@ -11,10 +11,11 @@ Trebuchet update takes care of deploying a tbdiff update image in the background
 * Reboot
 
 Once we put in place a smarter bootloader for tb-update we should check if the filesystem booted correctly, and if not, rollback to snapshots/previous.
-## Code
+
+# Code
 The repository can be found in <https://gitorious.org/baserock/tb-update>
 
-## Filesystem layout
+# Filesystem layout
 For tb-update to work we need the following prerequisites:
 
 * A system running a BtrFS (or equivalent copy-on-write snapshot capable FS such as ZFS) root filesystem
@@ -25,12 +26,12 @@ For tb-update to work we need the following prerequisites:
 * A read only subvolume of the root file system should be in snapshots/current and a read only copy of the previous one in snapshots/previous
 * / (specially /etc) should not be writeable, no configuration performed by a user should affect the root file system
 
-## Known issues in BtrFS
+# Known issues in BtrFS
 * Once you set-default a subvolume id other than 0 (the original one), you cannot set it back to 0, you can however, set it to any other subvolume. This means that during system setup, we need to install everything in snapshots/root
 * subvolumes cannot be mounted in arbitrary places (like /home), we need to fix this to avoid updating user data on the initial prototypes
 * There's no way to generate an image of differences between subvolumes that are part of a common history. Eventually we should generate a tbdiff compatible image once the format is stable and use this to implement the ZFS send/receive counterpart.
 
-## TODO
+# TODO
 * The current tb-update tool relies on a .tar.gz implementation of the update delivery format. Since tbdiff is close to finished, tp-update should be updated to use tbdiff-deploy
 * Client daemon: We need a client daemon that pokes the update server for new updates or rollback commands.
 * Server side: We need to develop a web service with a frontend to demonstrate easy update deployments

diff --git a/overview.mdwn b/overview.mdwn
index dfdff5d..d672eea 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -15,7 +15,7 @@ Most current Linux distribution mechanisms are not well suited to embedded devic
 - realtime performance required
 - BSP is probably customised
 
-The current best-of-breed approaches for building constrained systems with linux conversely miss functionality we see as critical:
+The current best-of-breed approaches for building constrained systems with Linux conversely miss functionality we see as critical:
 
 - built-in security required
 - unattended upgrade, and possibly factory reset, in the field

diff --git a/overview.mdwn b/overview.mdwn
index 089be50..dfdff5d 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -5,21 +5,24 @@ Increasingly software companies, OEMs, ODMs and system integrators are adopting
 Less obvious to consumers is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
 
 # The problem
-Current Linux distribution mechanisms are not well suited to embedded device projects, where we usually have to deal with some or all of the following characteristics:
+Most current Linux distribution mechanisms are not well suited to embedded device projects, where we usually have to deal with some or all of the following characteristics:
 
 - constrained cpu, memory and power 
 - limited communications bandwidth
-- limited (probably custom) user interface 
+- custom, limited or no user interface 
 - there is no "desktop" 
 - fast boot required
 - realtime performance required
+- BSP is probably customised
+
+The current best-of-breed approaches for building constrained systems with linux conversely miss functionality we see as critical:
+
 - built-in security required
 - unattended upgrade, and possibly factory reset, in the field
-- BSP is probably customised
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
 
-After assessing the work of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
+We believe that we need a new open source solution to meet all of these requirements. Hence Baserock.
 
 # Our solution
 Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.

diff --git a/overview.mdwn b/overview.mdwn
index f8387da..089be50 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -45,7 +45,7 @@ These are to be addressed by
 
 # Roadmap
 
-To be defined
+Coming soon!
 
 
 

diff --git a/overview.mdwn b/overview.mdwn
index 727eb24..f8387da 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -21,7 +21,7 @@ Current Linux distribution mechanisms are not well suited to embedded device pro
 
 After assessing the work of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
 
-# Baserock
+# Our solution
 Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
 
 # Design approach

diff --git a/index.mdwn b/index.mdwn
index f439828..3736add 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,7 @@
 Baserock
 ========
 
-This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. 
+Welcome to the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. 
 
 You can join the conversation at #baserock on freenode - currently there is no mailing list.
 

diff --git a/local.css b/local.css
index 91e86da..d4e37f5 100644
--- a/local.css
+++ b/local.css
@@ -58,7 +58,7 @@ padding:2;
 h1 {
     border-bottom: 2px solid #E0E0E0;
     border-top: 2px solid #E0E0E0;
-    color: #BF2400;
+    color: #58595B;
     font-size: 14px;
     font-weight: bold;
     margin: 0 0 18px;

diff --git a/local.css b/local.css
index ce57d17..91e86da 100644
--- a/local.css
+++ b/local.css
@@ -56,13 +56,13 @@ padding:2;
 }
 
 h1 {
-    border-bottom: 2px solid #BF2400;
-    border-top: 2px solid #BF2400;
+    border-bottom: 2px solid #E0E0E0;
+    border-top: 2px solid #E0E0E0;
     color: #BF2400;
     font-size: 14px;
     font-weight: bold;
     margin: 0 0 18px;
-    padding: 8px 0 8px 35px;
+    padding: 8px 0 8px 0px;
 }
 .pagedate{
 font-size:10px;

diff --git a/local.css b/local.css
index d43908d..ce57d17 100644
--- a/local.css
+++ b/local.css
@@ -56,11 +56,14 @@ padding:2;
 }
 
 h1 {
-    border-bottom: 2px solid #C3CABA;
-    border-top: 2px solid #CAC3BA;
-    color: #58595B;
-    font-size: 16px;
+    border-bottom: 2px solid #BF2400;
+    border-top: 2px solid #BF2400;
+    color: #BF2400;
+    font-size: 14px;
     font-weight: bold;
     margin: 0 0 18px;
     padding: 8px 0 8px 35px;
 }
+.pagedate{
+font-size:10px;
+}

diff --git a/overview.mdwn b/overview.mdwn
index dfa358d..727eb24 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -22,10 +22,10 @@ Current Linux distribution mechanisms are not well suited to embedded device pro
 After assessing the work of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
 
 # Baserock
-Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of projects - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
+Baserock will provide an optimised build approach for embedded Linux solutions specifically designed to use on projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of FOSS initiatives - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
 
 # Design approach
-We have identified a core approach for the kinds of systems we are targeting as follows:
+We have identified a core set of steps for the kinds of systems we are targeting as follows:
 
 - we start with Linux, a boot loader, a file system, and the minimum set of software packages and configuration required to boot
 - then we need additional system software stacks, probably optimised for the target
@@ -37,6 +37,7 @@ We are starting from the ground up, including only the components that we are *s
 * minimum bootable software set
 * field upgrade and rollback
 
+These are to be addressed by
 
 [[Morph]] - a tool to build and integrate multiple upstream open and closed source project components into *erratics*, *chunks*, *strata* and *morphologies*
 

diff --git a/page.tmpl b/page.tmpl
deleted file mode 100644
index 769aca5..0000000
--- a/page.tmpl
+++ /dev/null
@@ -1,197 +0,0 @@
-<TMPL_IF HTML5><!DOCTYPE html>
-<html>
-<TMPL_ELSE><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
- "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
-<html xmlns="http://www.w3.org/1999/xhtml">
-</TMPL_IF>
-<head>
-<!-- Copyright 2011 Codethink Limited -->
-<TMPL_IF DYNAMIC>
-<TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE>
-<TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF>
-</TMPL_IF>
-</TMPL_IF>
-<TMPL_IF HTML5><meta charset="utf-8" /><TMPL_ELSE><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></TMPL_IF>
-<title><TMPL_VAR TITLE></title>
-<TMPL_IF FAVICON>
-<link rel="icon" href="<TMPL_VAR BASEURL><TMPL_VAR FAVICON>" type="image/x-icon" />
-</TMPL_IF>
-<link rel="stylesheet" href="<TMPL_VAR BASEURL>style.css" type="text/css" />
-<TMPL_IF LOCAL_CSS>
-<link rel="stylesheet" href="<TMPL_VAR BASEURL><TMPL_VAR LOCAL_CSS>" type="text/css" />
-<TMPL_ELSE>
-<link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" />
-</TMPL_IF>
-<TMPL_IF EDITURL>
-<link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" />
-</TMPL_IF>
-<TMPL_IF FEEDLINKS><TMPL_VAR FEEDLINKS></TMPL_IF>
-<TMPL_IF RELVCS><TMPL_VAR RELVCS></TMPL_IF>
-<TMPL_IF META><TMPL_VAR META></TMPL_IF>
-</head>
-<body>
-
-<TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
-
-<TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
-<TMPL_IF HTML5><header class="header"><TMPL_ELSE><div class="header"></TMPL_IF>
-<span>
-<span class="parentlinks">
-<TMPL_LOOP PARENTLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ 
-</TMPL_LOOP>
-</span>
-<span class="title">
-<TMPL_VAR TITLE>
-<TMPL_IF ISTRANSLATION>
-&nbsp;(<TMPL_VAR PERCENTTRANSLATED>%)
-</TMPL_IF>
-</span>
-</span>
-<TMPL_IF SEARCHFORM>
-<TMPL_VAR SEARCHFORM>
-</TMPL_IF>
-<TMPL_IF HTML5></header><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_IF HAVE_ACTIONS>
-<TMPL_IF HTML5><nav class="actions"><TMPL_ELSE><div class="actions"></TMPL_IF>
-<ul>
-<TMPL_IF EDITURL>
-<li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li>
-</TMPL_IF>
-<TMPL_IF RECENTCHANGESURL>
-<li><a href="<TMPL_VAR RECENTCHANGESURL>">RecentChanges</a></li>
-</TMPL_IF>
-<TMPL_IF HISTORYURL>
-<li><a href="<TMPL_VAR HISTORYURL>">History</a></li>
-</TMPL_IF>
-<TMPL_IF GETSOURCEURL>
-<li><a href="<TMPL_VAR GETSOURCEURL>">Source</a></li>
-</TMPL_IF>
-<TMPL_IF PREFSURL>
-<li><a href="<TMPL_VAR PREFSURL>">Preferences</a></li>
-</TMPL_IF>
-<TMPL_IF ACTIONS>
-<TMPL_LOOP ACTIONS>
-<li><TMPL_VAR ACTION></li>
-</TMPL_LOOP>
-</TMPL_IF>
-<TMPL_IF COMMENTSLINK>
-<li><TMPL_VAR COMMENTSLINK></li>
-<TMPL_ELSE>
-<TMPL_IF DISCUSSIONLINK>
-<li><TMPL_VAR DISCUSSIONLINK></li>
-</TMPL_IF>
-</TMPL_IF>
-</ul>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF OTHERLANGUAGES>
-<TMPL_IF HTML5><nav id="otherlanguages"><TMPL_ELSE><div id="otherlanguages"></TMPL_IF>
-<ul>
-<TMPL_LOOP OTHERLANGUAGES>
-<li>
-<a href="<TMPL_VAR URL>"><TMPL_VAR LANGUAGE></a>
-<TMPL_IF MASTER>
-(master)
-<TMPL_ELSE>
-&nbsp;(<TMPL_VAR PERCENT>%)
-</TMPL_IF>
-</li>
-</TMPL_LOOP>
-</ul>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_IF SIDEBAR>
-<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF>
-<TMPL_VAR SIDEBAR>
-<TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<div id="pagebody">
-
-<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF>
-<TMPL_VAR CONTENT>
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_UNLESS DYNAMIC>
-<TMPL_IF COMMENTS>
-<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
-<TMPL_VAR COMMENTS>
-<TMPL_IF ADDCOMMENTURL>
-<div class="addcomment">
-<a href="<TMPL_VAR ADDCOMMENTURL>">Add a comment</a>
-</div>
-<TMPL_ELSE>
-<div class="addcomment">Comments on this page are closed.</div>
-</TMPL_IF>
-<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-</TMPL_UNLESS>
-
-</div>
-
-<TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
-<TMPL_UNLESS DYNAMIC>
-<TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
-
-<TMPL_IF TAGS>
-<TMPL_IF HTML5><nav class="tags"><TMPL_ELSE><div class="tags"></TMPL_IF>
-Tags:
-<TMPL_LOOP TAGS>
-<TMPL_VAR LINK>
-</TMPL_LOOP>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF BACKLINKS>
-<TMPL_IF HTML5><nav id="backlinks"><TMPL_ELSE><div id="backlinks"></TMPL_IF>
-Links:
-<TMPL_LOOP BACKLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>
-</TMPL_LOOP>
-<TMPL_IF MORE_BACKLINKS>
-<span class="popup">...
-<span class="balloon">
-<TMPL_LOOP MORE_BACKLINKS>
-<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>
-</TMPL_LOOP>
-</span>
-</span>
-</TMPL_IF>
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-</TMPL_IF>
-
-<TMPL_IF COPYRIGHT>
-<div class="pagecopyright">
-<a name="pagecopyright"></a>
-<TMPL_VAR COPYRIGHT>
-</div>
-</TMPL_IF>
-
-<TMPL_IF LICENSE>
-<div class="pagelicense">
-<a name="pagelicense"></a>
-License: <TMPL_VAR LICENSE>
-</div>
-</TMPL_IF>
-
-<div class="pagedate">
-Last edited <TMPL_VAR MTIME>
-<!-- Created <TMPL_VAR CTIME> -->
-</div>
-
-<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
-<TMPL_IF EXTRAFOOTER><TMPL_VAR EXTRAFOOTER></TMPL_IF>
-</TMPL_UNLESS>
-<!-- from <TMPL_VAR WIKINAME> -->
-<TMPL_IF HTML5></footer><TMPL_ELSE></div></TMPL_IF>
-
-<TMPL_IF HTML5></article><TMPL_ELSE></div></TMPL_IF>

(Diff truncated)

diff --git a/page.tmpl b/page.tmpl
index 8659018..769aca5 100644
--- a/page.tmpl
+++ b/page.tmpl
@@ -5,6 +5,7 @@
 <html xmlns="http://www.w3.org/1999/xhtml">
 </TMPL_IF>
 <head>
+<!-- Copyright 2011 Codethink Limited -->
 <TMPL_IF DYNAMIC>
 <TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE>
 <TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF>

diff --git a/page.tmpl b/page.tmpl
new file mode 100644
index 0000000..8659018
--- /dev/null
+++ b/page.tmpl
@@ -0,0 +1,196 @@
+<TMPL_IF HTML5><!DOCTYPE html>
+<html>
+<TMPL_ELSE><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
+<html xmlns="http://www.w3.org/1999/xhtml">
+</TMPL_IF>
+<head>
+<TMPL_IF DYNAMIC>
+<TMPL_IF FORCEBASEURL><base href="<TMPL_VAR FORCEBASEURL>" /><TMPL_ELSE>
+<TMPL_IF BASEURL><base href="<TMPL_VAR BASEURL>" /></TMPL_IF>
+</TMPL_IF>
+</TMPL_IF>
+<TMPL_IF HTML5><meta charset="utf-8" /><TMPL_ELSE><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /></TMPL_IF>
+<title><TMPL_VAR TITLE></title>
+<TMPL_IF FAVICON>
+<link rel="icon" href="<TMPL_VAR BASEURL><TMPL_VAR FAVICON>" type="image/x-icon" />
+</TMPL_IF>
+<link rel="stylesheet" href="<TMPL_VAR BASEURL>style.css" type="text/css" />
+<TMPL_IF LOCAL_CSS>
+<link rel="stylesheet" href="<TMPL_VAR BASEURL><TMPL_VAR LOCAL_CSS>" type="text/css" />
+<TMPL_ELSE>
+<link rel="stylesheet" href="<TMPL_VAR BASEURL>local.css" type="text/css" />
+</TMPL_IF>
+<TMPL_IF EDITURL>
+<link rel="alternate" type="application/x-wiki" title="Edit this page" href="<TMPL_VAR EDITURL>" />
+</TMPL_IF>
+<TMPL_IF FEEDLINKS><TMPL_VAR FEEDLINKS></TMPL_IF>
+<TMPL_IF RELVCS><TMPL_VAR RELVCS></TMPL_IF>
+<TMPL_IF META><TMPL_VAR META></TMPL_IF>
+</head>
+<body>
+
+<TMPL_IF HTML5><article class="page"><TMPL_ELSE><div class="page"></TMPL_IF>
+
+<TMPL_IF HTML5><section class="pageheader"><TMPL_ELSE><div class="pageheader"></TMPL_IF>
+<TMPL_IF HTML5><header class="header"><TMPL_ELSE><div class="header"></TMPL_IF>
+<span>
+<span class="parentlinks">
+<TMPL_LOOP PARENTLINKS>
+<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>/ 
+</TMPL_LOOP>
+</span>
+<span class="title">
+<TMPL_VAR TITLE>
+<TMPL_IF ISTRANSLATION>
+&nbsp;(<TMPL_VAR PERCENTTRANSLATED>%)
+</TMPL_IF>
+</span>
+</span>
+<TMPL_IF SEARCHFORM>
+<TMPL_VAR SEARCHFORM>
+</TMPL_IF>
+<TMPL_IF HTML5></header><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_IF HAVE_ACTIONS>
+<TMPL_IF HTML5><nav class="actions"><TMPL_ELSE><div class="actions"></TMPL_IF>
+<ul>
+<TMPL_IF EDITURL>
+<li><a href="<TMPL_VAR EDITURL>" rel="nofollow">Edit</a></li>
+</TMPL_IF>
+<TMPL_IF RECENTCHANGESURL>
+<li><a href="<TMPL_VAR RECENTCHANGESURL>">RecentChanges</a></li>
+</TMPL_IF>
+<TMPL_IF HISTORYURL>
+<li><a href="<TMPL_VAR HISTORYURL>">History</a></li>
+</TMPL_IF>
+<TMPL_IF GETSOURCEURL>
+<li><a href="<TMPL_VAR GETSOURCEURL>">Source</a></li>
+</TMPL_IF>
+<TMPL_IF PREFSURL>
+<li><a href="<TMPL_VAR PREFSURL>">Preferences</a></li>
+</TMPL_IF>
+<TMPL_IF ACTIONS>
+<TMPL_LOOP ACTIONS>
+<li><TMPL_VAR ACTION></li>
+</TMPL_LOOP>
+</TMPL_IF>
+<TMPL_IF COMMENTSLINK>
+<li><TMPL_VAR COMMENTSLINK></li>
+<TMPL_ELSE>
+<TMPL_IF DISCUSSIONLINK>
+<li><TMPL_VAR DISCUSSIONLINK></li>
+</TMPL_IF>
+</TMPL_IF>
+</ul>
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<TMPL_IF OTHERLANGUAGES>
+<TMPL_IF HTML5><nav id="otherlanguages"><TMPL_ELSE><div id="otherlanguages"></TMPL_IF>
+<ul>
+<TMPL_LOOP OTHERLANGUAGES>
+<li>
+<a href="<TMPL_VAR URL>"><TMPL_VAR LANGUAGE></a>
+<TMPL_IF MASTER>
+(master)
+<TMPL_ELSE>
+&nbsp;(<TMPL_VAR PERCENT>%)
+</TMPL_IF>
+</li>
+</TMPL_LOOP>
+</ul>
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_IF SIDEBAR>
+<TMPL_IF HTML5><aside class="sidebar"><TMPL_ELSE><div class="sidebar"></TMPL_IF>
+<TMPL_VAR SIDEBAR>
+<TMPL_IF HTML5></aside><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<div id="pagebody">
+
+<TMPL_IF HTML5><section id="content"><TMPL_ELSE><div id="content"></TMPL_IF>
+<TMPL_VAR CONTENT>
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_UNLESS DYNAMIC>
+<TMPL_IF COMMENTS>
+<TMPL_IF HTML5><section id="comments"><TMPL_ELSE><div id="comments"></TMPL_IF>
+<TMPL_VAR COMMENTS>
+<TMPL_IF ADDCOMMENTURL>
+<div class="addcomment">
+<a href="<TMPL_VAR ADDCOMMENTURL>">Add a comment</a>
+</div>
+<TMPL_ELSE>
+<div class="addcomment">Comments on this page are closed.</div>
+</TMPL_IF>
+<TMPL_IF HTML5></section><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+</TMPL_UNLESS>
+
+</div>
+
+<TMPL_IF HTML5><footer id="footer" class="pagefooter"><TMPL_ELSE><div id="footer" class="pagefooter"></TMPL_IF>
+<TMPL_UNLESS DYNAMIC>
+<TMPL_IF HTML5><nav id="pageinfo"><TMPL_ELSE><div id="pageinfo"></TMPL_IF>
+
+<TMPL_IF TAGS>
+<TMPL_IF HTML5><nav class="tags"><TMPL_ELSE><div class="tags"></TMPL_IF>
+Tags:
+<TMPL_LOOP TAGS>
+<TMPL_VAR LINK>
+</TMPL_LOOP>
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<TMPL_IF BACKLINKS>
+<TMPL_IF HTML5><nav id="backlinks"><TMPL_ELSE><div id="backlinks"></TMPL_IF>
+Links:
+<TMPL_LOOP BACKLINKS>
+<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>
+</TMPL_LOOP>
+<TMPL_IF MORE_BACKLINKS>
+<span class="popup">...
+<span class="balloon">
+<TMPL_LOOP MORE_BACKLINKS>
+<a href="<TMPL_VAR URL>"><TMPL_VAR PAGE></a>
+</TMPL_LOOP>
+</span>
+</span>
+</TMPL_IF>
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+</TMPL_IF>
+
+<TMPL_IF COPYRIGHT>
+<div class="pagecopyright">
+<a name="pagecopyright"></a>
+<TMPL_VAR COPYRIGHT>
+</div>
+</TMPL_IF>
+
+<TMPL_IF LICENSE>
+<div class="pagelicense">
+<a name="pagelicense"></a>
+License: <TMPL_VAR LICENSE>
+</div>
+</TMPL_IF>
+
+<div class="pagedate">
+Last edited <TMPL_VAR MTIME>
+<!-- Created <TMPL_VAR CTIME> -->
+</div>
+
+<TMPL_IF HTML5></nav><TMPL_ELSE></div></TMPL_IF>
+<TMPL_IF EXTRAFOOTER><TMPL_VAR EXTRAFOOTER></TMPL_IF>
+</TMPL_UNLESS>
+<!-- from <TMPL_VAR WIKINAME> -->
+<TMPL_IF HTML5></footer><TMPL_ELSE></div></TMPL_IF>
+
+<TMPL_IF HTML5></article><TMPL_ELSE></div></TMPL_IF>
+

(Diff truncated)

diff --git a/local.css b/local.css
index 8c089ec..d43908d 100644
--- a/local.css
+++ b/local.css
@@ -50,7 +50,17 @@ div#footer {
 }
 html, body, p, h1, h2, h3, h4, h5, h6, address, ul, li, input, form, textarea, select {
 color:#58595B;
-font:12px Verdana,Arial,Sans-serif;
+font:13px Verdana,Arial,Sans-serif;
 margin:1;
 padding:2;
 }
+
+h1 {
+    border-bottom: 2px solid #C3CABA;
+    border-top: 2px solid #CAC3BA;
+    color: #58595B;
+    font-size: 16px;
+    font-weight: bold;
+    margin: 0 0 18px;
+    padding: 8px 0 8px 35px;
+}

diff --git a/Morph/repositories.mdwn b/Morph/repositories.mdwn
index ce4f358..0d907ad 100644
--- a/Morph/repositories.mdwn
+++ b/Morph/repositories.mdwn
@@ -14,6 +14,7 @@ Using git repositories with Baserock
     `baserock/foo` off `baserock/morphologies`, merge in changes from
     upstream's `master` branch , make and test any fixes, and then merge the
     changes to `baserock/morphologies`
+
 * Additionally, there is at least one more **git repository for stratum and
   system morphologies**. For simplicity, we will assume they're all in one
   repo and call this the `morphs` repo.
@@ -26,6 +27,7 @@ Using git repositories with Baserock
     in upstream project repos, so that when we build from master, we get
     the current development version of everything
   - they also refer to any `baserock/morphologies` branches if they exist
+
 * When something needs to be changed, it always affects at least the
   `morphs` repository, and may affect one or more upstream repositories.
   The changes will be done in dedicated **feature branches**.
@@ -43,6 +45,7 @@ Using git repositories with Baserock
     to refer to their original repositories and branches; this avoids
     creating a lot of unnecessary branches all over the place
   - changes will remain in the new branches; see below for integration
+
 * Feature branches are **integrated** by specifying several branches
   for an upstream project in a morphology. The `morph` tool will 
   merge the changes into a unified branch for building.
@@ -55,6 +58,7 @@ Using git repositories with Baserock
     explicit and version controlled
   - if the merging fails, e.g., because the various feature branches
     conflict, the build fails
+
 * When it is time to prepare for a release, it is necessary to **branch
   all constituent projects** in such a way that normal development changes
   are no longer automatically included in the release candidate, 
@@ -74,6 +78,7 @@ Using git repositories with Baserock
     `baserock/petrifying/foo` branches manually; no upstream
     changes will automatically flow into the release candidate, they must
     all be merged in by hand
+
 * When a release is ready, it is **petrified**. At this point, the
   versions (commits) of all **constituent projects are nailed down** in such
   a way that they cannot be (easily) changed again.
@@ -91,6 +96,7 @@ Using git repositories with Baserock
     (e.g, `baserock/petrifying/1.2-series` would be tagged
     `version-1.2.0`), so that it's easier to find where the release
     happened
+
 * A **continuous integration tool** builds and tests system images from
   the `morphs` repository.
   - `master` is always tested whenever it or any constituent project

diff --git a/index.mdwn b/index.mdwn
index 31c7b50..f439828 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,9 @@
 Baserock
 ========
 
-This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. You can join the conversation at #baserock on freenode - currently there is no mailing list.
+This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. 
+
+You can join the conversation at #baserock on freenode - currently there is no mailing list.
 
 Baserock is a new project - documentation is incomplete and likely to change. As a result early readers will probably need a lot of background knowledge to understand the project e.g.
 

diff --git a/local.css b/local.css
index b0fe765..8c089ec 100644
--- a/local.css
+++ b/local.css
@@ -49,8 +49,8 @@ div#footer {
     max-width: 50em;
 }
 html, body, p, h1, h2, h3, h4, h5, h6, address, ul, li, input, form, textarea, select {
-����color:�#58595B;
-����font:�12px Verdana,Arial,Sans-serif;
-����margin:�1;
-����padding:�2;
+color:#58595B;
+font:12px Verdana,Arial,Sans-serif;
+margin:1;
+padding:2;
 }

diff --git a/index.mdwn b/index.mdwn
index c6cd317..31c7b50 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -26,3 +26,4 @@ General Pages
 * [[policy]] (cf. Debian Policy Manual)
 * [[build-host]]
 * [[glossary]] 
+

diff --git a/local.css b/local.css
index 49cc6ec..b0fe765 100644
--- a/local.css
+++ b/local.css
@@ -1,50 +1,56 @@
-a { color: #bf2400; }
-
-input#searchbox {
-    background: url("wikiicons/search-bg.gif") no-repeat scroll 100% 50% #fbebbc;
-    color: #000000;
-    padding-right: 16px;
-}
-
-div.pageheader {
-    background-color: #28170b;
-    border-top:2px solid #bf2400; 
-    border-bottom:2px solid #bf2400;
-    color: #fbebbc;
-}
-
-.pageheader .actions ul li {
-    background: none repeat scroll 0 0 #28170b;
-    color: #fbebbc;
-    margin: 0;
-    padding: 0.1em 0.5em 0;
-}
-
-.pageheader .actions ul li {
-    background: none repeat scroll 0 0 #28170B;
-    border-color: #28170B;
-    border-style: solid solid none;
-    border-width: 0px;
-    margin: 0;
-    padding: 0.1em 0.5em 0;
-}
-
-.pageheader .actions a { color: #fbebbc; }
-
-div.header {
-    background-image: url("logo.png");
-    background-repeat: no-repeat;
-    min-width: 282px;
-    padding-top: 50px;
-}
-
-div#footer {
-    border-top: 4px solid #28170b;
-}
-#pageinfo {
-    border-top: 0;
-}
-
-#content {
-    max-width: 50em;
-}
+a { color: #bf2400; }
+
+input#searchbox {
+    background: url("wikiicons/search-bg.gif") no-repeat scroll 100% 50% #fbebbc;
+    color: #000000;
+    padding-right: 16px;
+}
+
+div.pageheader {
+    background-color: #28170b;
+    border-top:2px solid #bf2400; 
+    border-bottom:2px solid #bf2400;
+    color: #fbebbc;
+}
+
+.pageheader .actions ul li {
+    background: none repeat scroll 0 0 #28170b;
+    color: #fbebbc;
+    margin: 0;
+    padding: 0.1em 0.5em 0;
+}
+
+.pageheader .actions ul li {
+    background: none repeat scroll 0 0 #28170B;
+    border-color: #28170B;
+    border-style: solid solid none;
+    border-width: 0px;
+    margin: 0;
+    padding: 0.1em 0.5em 0;
+}
+
+.pageheader .actions a { color: #fbebbc; }
+
+div.header {
+    background-image: url("logo.png");
+    background-repeat: no-repeat;
+    min-width: 282px;
+    padding-top: 50px;
+}
+
+div#footer {
+    border-top: 4px solid #28170b;
+}
+#pageinfo {
+    border-top: 0;
+}
+
+#content {
+    max-width: 50em;
+}
+html, body, p, h1, h2, h3, h4, h5, h6, address, ul, li, input, form, textarea, select {
+����color:�#58595B;
+����font:�12px Verdana,Arial,Sans-serif;
+����margin:�1;
+����padding:�2;
+}

diff --git a/index.mdwn b/index.mdwn
index 34f66f0..c6cd317 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,7 @@
 Baserock
 ========
 
-This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. We are live on freenode at #baserock - currently there is no mailing list.
+This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. You can join the conversation at #baserock on freenode - currently there is no mailing list.
 
 Baserock is a new project - documentation is incomplete and likely to change. As a result early readers will probably need a lot of background knowledge to understand the project e.g.
 

diff --git a/index.mdwn b/index.mdwn
index 55085fe..34f66f0 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,7 @@
 Baserock
 ========
 
-This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]].
+This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]]. We are live on freenode at #baserock - currently there is no mailing list.
 
 Baserock is a new project - documentation is incomplete and likely to change. As a result early readers will probably need a lot of background knowledge to understand the project e.g.
 

diff --git a/build-host.mdwn b/build-host.mdwn
index 21c8cb2..f4c7767 100644
--- a/build-host.mdwn
+++ b/build-host.mdwn
@@ -1,10 +1,12 @@
 PRELIMINARY specification for build hosts for Baserock
 ======================================================
 
-This is currently for what we plan to set up at Codethink, in the
+This is currently for what we plan to set up at Codethink for build infrastructure equipment in the
 first phase. As we gain experience about that, we'll update the page
 to describe the minimum realistic setup for building Baserock.
 
+** note that these are specs for build machines - target devices may be much lower spec ** 
+
 For ARM:
 
 * At least 1 Hz core

diff --git a/overview.mdwn b/overview.mdwn
index a644452..dfa358d 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -19,7 +19,7 @@ Current Linux distribution mechanisms are not well suited to embedded device pro
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
 
-After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
+After assessing the work of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
 
 # Baserock
 Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of projects - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.

diff --git a/overview.mdwn b/overview.mdwn
index 0c00b0c..a644452 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -1,12 +1,10 @@
-# Baserock Overview
-
-## Background
+# Background
 
 Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in mobile phones, where Android, Maemo, OpenMoko, Limo, Bada, WebOS and soon Tizen show leading players choosing Linux-based technologies for small form factor devices. 
 
 Less obvious to consumers is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
 
-## The problem
+# The problem
 Current Linux distribution mechanisms are not well suited to embedded device projects, where we usually have to deal with some or all of the following characteristics:
 
 - constrained cpu, memory and power 
@@ -23,10 +21,10 @@ Current Linux distribution mechanisms are not well suited to embedded device pro
 
 After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
 
-## Baserock
+# Baserock
 Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of projects - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
 
-## Design approach
+# Design approach
 We have identified a core approach for the kinds of systems we are targeting as follows:
 
 - we start with Linux, a boot loader, a file system, and the minimum set of software packages and configuration required to boot
@@ -34,13 +32,17 @@ We have identified a core approach for the kinds of systems we are targeting as
 - then we need a secure way to deliver applications onto the above, both in the factory and in the field
 - and finally we need a robust way to upgrade everything in the field (e.g. for security updates), and to roll back failed upgrades
 
-We are starting from the ground up, including only the components that we are *sure* need to be in Baserock. In the first phase we are working on
+We are starting from the ground up, including only the components that we are *sure* need to be in Baserock. The immediate gaps we are addressing are
+
+* minimum bootable software set
+* field upgrade and rollback
+
 
 [[Morph]] - a tool to build and integrate multiple upstream open and closed source project components into *erratics*, *chunks*, *strata* and *morphologies*
 
 [[Trebuchet]] - a tool to apply these software blocks on to target devices, optimised for field upgrade, with rollback and reset
 
-## Roadmap
+# Roadmap
 
 To be defined
 

diff --git a/overview.mdwn b/overview.mdwn
index bb947bd..0c00b0c 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -21,26 +21,24 @@ Current Linux distribution mechanisms are not well suited to embedded device pro
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
 
-After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. 
-
-Hence Baserock.
+After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. Hence Baserock.
 
 ## Baserock
 Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of projects - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
 
 ## Design approach
-We identified the core requirements for the kinds of systems we are targeting as follows:
+We have identified a core approach for the kinds of systems we are targeting as follows:
 
 - we start with Linux, a boot loader, a file system, and the minimum set of software packages and configuration required to boot
 - then we need additional system software stacks, probably optimised for the target
-- then we need a secure way to deliver applications onto the above
+- then we need a secure way to deliver applications onto the above, both in the factory and in the field
 - and finally we need a robust way to upgrade everything in the field (e.g. for security updates), and to roll back failed upgrades
 
-We are working from the ground up, starting with only the components that we are *sure* need to be in Baserock. In the first phase we are working on
+We are starting from the ground up, including only the components that we are *sure* need to be in Baserock. In the first phase we are working on
 
-Morph - a tool to build and integrate multiple upstream open and closed source project components into *erratics*, *chunks*, *strata* and *morphologies*
+[[Morph]] - a tool to build and integrate multiple upstream open and closed source project components into *erratics*, *chunks*, *strata* and *morphologies*
 
-Trebuchet - a tool to apply these software blocks on to target devices, optimised for field upgrade, with rollback and reset
+[[Trebuchet]] - a tool to apply these software blocks on to target devices, optimised for field upgrade, with rollback and reset
 
 ## Roadmap
 

diff --git a/overview.mdwn b/overview.mdwn
index 00afaa4..bb947bd 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -9,21 +9,24 @@ Less obvious to consumers is the uptake of Linux in televisions, set-top-boxes,
 ## The problem
 Current Linux distribution mechanisms are not well suited to embedded device projects, where we usually have to deal with some or all of the following characteristics:
 
-- cpu, memory and power constraints 
+- constrained cpu, memory and power 
 - limited communications bandwidth
 - limited (probably custom) user interface 
 - there is no "desktop" 
 - fast boot required
 - realtime performance required
-- built-in security 
+- built-in security required
 - unattended upgrade, and possibly factory reset, in the field
 - BSP is probably customised
 - multi-level developer teams - OEM, System Integrator, ODM etc
 - repeatability and traceability for development, integration and test
 
-## Baserock
-Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work done by a wide range of projects - particularly Linux, Gnome, Linaro. 
+After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Yocto/OpenEmbedded, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current approaches is designed to address our core requirements. 
+
+Hence Baserock.
 
+## Baserock
+Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work and thinking done by a wide range of projects - particularly Linux, Gnome, Linaro, OpenEmbedded/Poky.
 
 ## Design approach
 We identified the core requirements for the kinds of systems we are targeting as follows:
@@ -33,16 +36,15 @@ We identified the core requirements for the kinds of systems we are targeting as
 - then we need a secure way to deliver applications onto the above
 - and finally we need a robust way to upgrade everything in the field (e.g. for security updates), and to roll back failed upgrades
 
-After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current FOSS approaches is designed to meet our core requirements. Hence Baserock.
-
-So now we are working from the ground up, starting with only the components that we are *sure* need to be in Baserock. In the first instance we are working on
+We are working from the ground up, starting with only the components that we are *sure* need to be in Baserock. In the first phase we are working on
 
 Morph - a tool to build and integrate multiple upstream open and closed source project components into *erratics*, *chunks*, *strata* and *morphologies*
+
 Trebuchet - a tool to apply these software blocks on to target devices, optimised for field upgrade, with rollback and reset
 
 ## Roadmap
-TBD
 
+To be defined
 
 
 

diff --git a/overview.mdwn b/overview.mdwn
index b32f303..00afaa4 100644
--- a/overview.mdwn
+++ b/overview.mdwn
@@ -19,11 +19,30 @@ Current Linux distribution mechanisms are not well suited to embedded device pro
 - unattended upgrade, and possibly factory reset, in the field
 - BSP is probably customised
 - multi-level developer teams - OEM, System Integrator, ODM etc
+- repeatability and traceability for development, integration and test
 
 ## Baserock
 Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work done by a wide range of projects - particularly Linux, Gnome, Linaro. 
 
 
+## Design approach
+We identified the core requirements for the kinds of systems we are targeting as follows:
+
+- we start with Linux, a boot loader, a file system, and the minimum set of software packages and configuration required to boot
+- then we need additional system software stacks, probably optimised for the target
+- then we need a secure way to deliver applications onto the above
+- and finally we need a robust way to upgrade everything in the field (e.g. for security updates), and to roll back failed upgrades
+
+After assessing the approaches of Debian, Ubuntu, Fedora, MeeGo, Gentoo, Android, iOS and the many closed-source embedded projects we have been involved in, we concluded that none of the current FOSS approaches is designed to meet our core requirements. Hence Baserock.
+
+So now we are working from the ground up, starting with only the components that we are *sure* need to be in Baserock. In the first instance we are working on
+
+Morph - a tool to build and integrate multiple upstream open and closed source project components into *erratics*, *chunks*, *strata* and *morphologies*
+Trebuchet - a tool to apply these software blocks on to target devices, optimised for field upgrade, with rollback and reset
+
+## Roadmap
+TBD
+
 
 
 

diff --git a/overview.mdwn b/overview.mdwn
new file mode 100644
index 0000000..b32f303
--- /dev/null
+++ b/overview.mdwn
@@ -0,0 +1,31 @@
+# Baserock Overview
+
+## Background
+
+Increasingly software companies, OEMs, ODMs and system integrators are adopting Linux for embedded systems. The most visible indication of this has been in mobile phones, where Android, Maemo, OpenMoko, Limo, Bada, WebOS and soon Tizen show leading players choosing Linux-based technologies for small form factor devices. 
+
+Less obvious to consumers is the uptake of Linux in televisions, set-top-boxes, network devices, automotive systems, aerospace, telemetry and industrial systems. 
+
+## The problem
+Current Linux distribution mechanisms are not well suited to embedded device projects, where we usually have to deal with some or all of the following characteristics:
+
+- cpu, memory and power constraints 
+- limited communications bandwidth
+- limited (probably custom) user interface 
+- there is no "desktop" 
+- fast boot required
+- realtime performance required
+- built-in security 
+- unattended upgrade, and possibly factory reset, in the field
+- BSP is probably customised
+- multi-level developer teams - OEM, System Integrator, ODM etc
+
+## Baserock
+Baserock will provide an optimised build approach for embedded Linux solutions for projects with the above drivers. We are leveraging the upstream work done by a wide range of projects - particularly Linux, Gnome, Linaro. 
+
+
+
+
+
+
+

diff --git a/index.mdwn b/index.mdwn
index af476a1..55085fe 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,16 +1,17 @@
 Baserock
 ========
 
-This wiki provides public documentation for the Baserock open source project. Baserock aims to provide an optimal approach for implementing Linux-based solutions for embedded devices. 
+This wiki provides documentation for the Baserock open source project. Baserock aims to be a great way to build embedded systems with Linux. We are initially targeting ARM-based devices, leveraging the upstream work of Linaro. Project background, objectives and design thinking are outlined in the [[overview]].
 
-This is a new project - documentation is incomplete and may change. As a result early readers probably need quite a lot of background knowledge to understand the project e.g.
+Baserock is a new project - documentation is incomplete and likely to change. As a result early readers will probably need a lot of background knowledge to understand the project e.g.
 
 * deployment and use of Linux-based software
 * software development for Linux
 * Linux configuration management
-* version control, particularly git
+* distributed version control, particularly git
+* BSP
 
-Ultimately our intention is to simplify the process of embedded Linux development and deployment - so clearly our documentation will need to   be extended to support less expert participants. 
+Ultimately our intention is to simplify the process of embedded Linux development and deployment - so clearly documentation will need to   be extended to support less expert participants. 
 
 Subproject Pages
 ===========

diff --git a/policy.mdwn b/policy.mdwn
index c4051ff..594f195 100644
--- a/policy.mdwn
+++ b/policy.mdwn
@@ -11,3 +11,14 @@ Location of files
 
 Use [FHS 2.3](http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard)
 for file location.
+
+
+Licenses
+--------
+
+Some of the use cases for Baserock are not compatible with the 
+"anti-Tivoization" clauses of GPL version 3. Thus software must
+be licenses under version two (with or without "or later") of
+the GPL.
+
+Non-copyleft free software licenses are OK.

diff --git a/Morph/repositories.mdwn b/Morph/repositories.mdwn
new file mode 100644
index 0000000..ce4f358
--- /dev/null
+++ b/Morph/repositories.mdwn
@@ -0,0 +1,130 @@
+Using git repositories with Baserock
+====================================
+
+* There is a **git repository corresponding to each upstream project**.
+  This repository gets **mirrored** (possibly with **conversion**) from 
+  upstream version control systems or release tarballs.
+  - exact details of the mirroring are not yet specified, but are irrelevant
+    for this discussion, as long as the result is a set of git repositories
+  - no non-upstream branches get automatically changed by the mirroring
+  - if upstream does not contain the morphologies, we add them in a
+    feature branch, `baserock/morphologies`, which has no other changes;
+    see below how this gets integrated during build
+  - if the morphologies need to be changed, we create a feature branch
+    `baserock/foo` off `baserock/morphologies`, merge in changes from
+    upstream's `master` branch , make and test any fixes, and then merge the
+    changes to `baserock/morphologies`
+* Additionally, there is at least one more **git repository for stratum and
+  system morphologies**. For simplicity, we will assume they're all in one
+  repo and call this the `morphs` repo.
+  - in reality, it may be more convenient or necessary to have several
+    repositories, e.g., GNOME might have their own, and NDAs may prevent
+    some custom hardware support projects from being kept on a public
+    git server until the hardware is released
+  - the `master` branch is where main development happens
+  - in `master`, the morphologies refer to the upstream `master` branches
+    in upstream project repos, so that when we build from master, we get
+    the current development version of everything
+  - they also refer to any `baserock/morphologies` branches if they exist
+* When something needs to be changed, it always affects at least the
+  `morphs` repository, and may affect one or more upstream repositories.
+  The changes will be done in dedicated **feature branches**.
+  - in all affected repos, create new branches `baserock/foo` (using the
+    same branch name in all repos)
+  - in the `morphs` repo, the new branch is based on whatever was the
+    current branch
+  - in other repositories, the new branch is based on whatever main
+    branch the morphologies refer to (i.e., the first branch)
+  - in the `morphs` repo, change the morphologies to refer to
+    the `baserock/foo` branch in the other affected repositories; this
+    allows you to build binaries that use the changes you make in the
+    other repositories
+  - however, repositories that are not affected by the change will continue
+    to refer to their original repositories and branches; this avoids
+    creating a lot of unnecessary branches all over the place
+  - changes will remain in the new branches; see below for integration
+* Feature branches are **integrated** by specifying several branches
+  for an upstream project in a morphology. The `morph` tool will 
+  merge the changes into a unified branch for building.
+  - a stratum morphology may specify, e.g., that `busybox` needs to be
+    built from the `baserock/master`, `baserock/bug-12765`, and
+    `baserock/mkfs.btrfs` branches
+  - the merging of feature branches into an integration branch is thus
+    specified in morphologies, rather than in an external configuration
+    file for a continuous integration tool; this keeps everything nicely
+    explicit and version controlled
+  - if the merging fails, e.g., because the various feature branches
+    conflict, the build fails
+* When it is time to prepare for a release, it is necessary to **branch
+  all constituent projects** in such a way that normal development changes
+  are no longer automatically included in the release candidate, 
+  but changes are still comfortable to make manually.
+  - `morphs` is branched into `baserock/petrifying/foo`, where `foo` is a name
+    or version number for the upcoming release, picked by the user
+  - the new branch in `morphs` may be based on `master` or any other suitable
+    branch
+  - for every upstream project referred to from any morphology, a similar
+    branch is made: `baserock/petrifying/foo`; these branches are based on 
+    whatever main (first) branches are referred to from the morphologies
+  - it is an error for the morphologies to refer to different main branches of
+    the same upstream project, since this causes a conflict of which
+    branch to base `baserock/petrifying/foo` on
+  - the morphologies are updated to refer to the new branches
+  - the release candidate can be updated by making changes to the
+    `baserock/petrifying/foo` branches manually; no upstream
+    changes will automatically flow into the release candidate, they must
+    all be merged in by hand
+* When a release is ready, it is **petrified**. At this point, the
+  versions (commits) of all **constituent projects are nailed down** in such
+  a way that they cannot be (easily) changed again.
+  - `morphs` is branched from `baserock/petrifying/foo` to
+    `baserock/petrified/foo`
+  - in all morphologies the reference to the upstream projects'
+    `baserock/petrifying/foo` branch is changed to the commit id of
+    the HEAD of the branch.
+  - this allows the release to be reproduced exactly at any later time,
+    regardless of what happens to the repositories, as long as the
+    specific commit id still exists
+  - the `baserock/petrifying/foo` branch is kept so that future releases
+    can be based on the work done so far
+  - `baserock/petrifying/foo` is tagged with the exact release number
+    (e.g, `baserock/petrifying/1.2-series` would be tagged
+    `version-1.2.0`), so that it's easier to find where the release
+    happened
+* A **continuous integration tool** builds and tests system images from
+  the `morphs` repository.
+  - `master` is always tested whenever it or any constituent project
+    changes
+  - `baserock/petrifying/*` are similarly always tested when something
+    in them changes
+  - `baserock/petrified/*` as well, though nothing in them should ever
+    actually change (any change in a release would result in a new
+    release being done)
+  - other branches may also be configured manually, when necessary
+  - for each branch, the CI tool builds the system image, and runs automatic
+    tests, reporting results in some suitable manner; the tests will include
+    upgrading from previous releases, and probably should include installation
+    and upgrading and removal of specific strata on some of the systems,
+    but that's getting beyond the scope of this
+
+What a lotta branches
+---------------------
+
+Keeping things in feature branches sounds like a good idea so that:
+
+* upstream can more easily see what we've changed, and can easily 
+  incorporate every change separately
+* it's easy to back out of a set of changes (just drop it from the
+  integration)
+* it's easy to combine the same fix into many deliverables
+  (e.g., an eglibc bug fix might be backported into several releases)
+
+I hate this
+-----------
+
+The above sounds like a lot of bureaucratic hassle that will get
+really annoying and horrifically error prone very quickly. However,
+fear not, the `morph` tool will be make it all painless. In fact,
+the above is an outline for a design for how `morph` will work 
+behind the scenes. What the user actually sees will be much simpler.
+
diff --git a/Morph/story.mdwn b/Morph/story.mdwn
new file mode 100644
index 0000000..419727a
--- /dev/null
+++ b/Morph/story.mdwn
@@ -0,0 +1,144 @@
+Baserock development: a bedside story
+=====================================
+
+Assumptions:
+
+* A native development system is installed: Baserock core and development
+  strata, and whatever else is considered essential for development.
+  (Until Baserock is bootstrapped, we can just pretend whatever Linux
+  system is native.)
+* Chunk morphologies are kept with the upstream projects they are for.
+  Initially, the upstream project is branched and the morphology is added,
+  and this branch is rebased with any new upstream developments. Eventually,
+  we hope that at least some upstreams will include the morphologies in
+  their upstream code.
+* All other morphologies (strata, systems) are kept in the same 
+  dedicated git repo. Having them all in different repos would be too
+  hard to deal with for users.
+* We want to only ever clone the git repositories we actively work on,
+  not everything. For example, if working on busybox, there should be
+  no need to clone (never mind build) the gcc repo.
+* The morph command can work on all cloned repositories at once, but only
+  when they're under the same parent directory.
+
+Configure morph (intended to be similar to what git does):
+
+    $ morph config --global cache=file://$HOME/.cache/morph/binaries
+    ... where built binaries (chunks, strata, system images) are stored
+    ... some day this will be a suitable server
+    $ morph config --global git-base-url=git://git.gitorious/baserock/
+    ... where git repositories are looked for by default
+    ... git-base-url is for resolving relative URLs
+    ... absolute URLs may always be specified
+
+Checkout a Baserock base system and rebuild it:
+
+    $ cd $HOME/baserock
+    ... this is the directory where we'll put all repos we work on
+    $ morph clone morphs
+    ... this clones git://git.gitorous.org/baserock/morphs
+    $ cd morphs
+    $ morph build base-system.morph
+
+The system image gets put into the cache. FIXME: There needs to be
+convenient ways of getting stuff out of a cache.
+
+Test built system in an emulator:
+
+    $ morph qemu base-system.morph
+    ... this will use the system image built for base.morph
+    ... the image could also be tested on an actual device, by
+    ... getting it out from the cache and installing onto the device
+    ... (in whatever manner is suitable for that specific device)
+
+Next, fix a bug in an upstream project. 
+
+Making changes is complicated by the fact that many projects need to be
+touched: the actual upstream project and the various morphologies, which
+may be distributed in several git repos. In order to make a change in,

(Diff truncated)

diff --git a/morph/repositories.mdwn b/morph/repositories.mdwn
deleted file mode 100644
index ce4f358..0000000
--- a/morph/repositories.mdwn
+++ /dev/null
@@ -1,130 +0,0 @@
-Using git repositories with Baserock
-====================================
-
-* There is a **git repository corresponding to each upstream project**.
-  This repository gets **mirrored** (possibly with **conversion**) from 
-  upstream version control systems or release tarballs.
-  - exact details of the mirroring are not yet specified, but are irrelevant
-    for this discussion, as long as the result is a set of git repositories
-  - no non-upstream branches get automatically changed by the mirroring
-  - if upstream does not contain the morphologies, we add them in a
-    feature branch, `baserock/morphologies`, which has no other changes;
-    see below how this gets integrated during build
-  - if the morphologies need to be changed, we create a feature branch
-    `baserock/foo` off `baserock/morphologies`, merge in changes from
-    upstream's `master` branch , make and test any fixes, and then merge the
-    changes to `baserock/morphologies`
-* Additionally, there is at least one more **git repository for stratum and
-  system morphologies**. For simplicity, we will assume they're all in one
-  repo and call this the `morphs` repo.
-  - in reality, it may be more convenient or necessary to have several
-    repositories, e.g., GNOME might have their own, and NDAs may prevent
-    some custom hardware support projects from being kept on a public
-    git server until the hardware is released
-  - the `master` branch is where main development happens
-  - in `master`, the morphologies refer to the upstream `master` branches
-    in upstream project repos, so that when we build from master, we get
-    the current development version of everything
-  - they also refer to any `baserock/morphologies` branches if they exist
-* When something needs to be changed, it always affects at least the
-  `morphs` repository, and may affect one or more upstream repositories.
-  The changes will be done in dedicated **feature branches**.
-  - in all affected repos, create new branches `baserock/foo` (using the
-    same branch name in all repos)
-  - in the `morphs` repo, the new branch is based on whatever was the
-    current branch
-  - in other repositories, the new branch is based on whatever main
-    branch the morphologies refer to (i.e., the first branch)
-  - in the `morphs` repo, change the morphologies to refer to
-    the `baserock/foo` branch in the other affected repositories; this
-    allows you to build binaries that use the changes you make in the
-    other repositories
-  - however, repositories that are not affected by the change will continue
-    to refer to their original repositories and branches; this avoids
-    creating a lot of unnecessary branches all over the place
-  - changes will remain in the new branches; see below for integration
-* Feature branches are **integrated** by specifying several branches
-  for an upstream project in a morphology. The `morph` tool will 
-  merge the changes into a unified branch for building.
-  - a stratum morphology may specify, e.g., that `busybox` needs to be
-    built from the `baserock/master`, `baserock/bug-12765`, and
-    `baserock/mkfs.btrfs` branches
-  - the merging of feature branches into an integration branch is thus
-    specified in morphologies, rather than in an external configuration
-    file for a continuous integration tool; this keeps everything nicely
-    explicit and version controlled
-  - if the merging fails, e.g., because the various feature branches
-    conflict, the build fails
-* When it is time to prepare for a release, it is necessary to **branch
-  all constituent projects** in such a way that normal development changes
-  are no longer automatically included in the release candidate, 
-  but changes are still comfortable to make manually.
-  - `morphs` is branched into `baserock/petrifying/foo`, where `foo` is a name
-    or version number for the upcoming release, picked by the user
-  - the new branch in `morphs` may be based on `master` or any other suitable
-    branch
-  - for every upstream project referred to from any morphology, a similar
-    branch is made: `baserock/petrifying/foo`; these branches are based on 
-    whatever main (first) branches are referred to from the morphologies
-  - it is an error for the morphologies to refer to different main branches of
-    the same upstream project, since this causes a conflict of which
-    branch to base `baserock/petrifying/foo` on
-  - the morphologies are updated to refer to the new branches
-  - the release candidate can be updated by making changes to the
-    `baserock/petrifying/foo` branches manually; no upstream
-    changes will automatically flow into the release candidate, they must
-    all be merged in by hand
-* When a release is ready, it is **petrified**. At this point, the
-  versions (commits) of all **constituent projects are nailed down** in such
-  a way that they cannot be (easily) changed again.
-  - `morphs` is branched from `baserock/petrifying/foo` to
-    `baserock/petrified/foo`
-  - in all morphologies the reference to the upstream projects'
-    `baserock/petrifying/foo` branch is changed to the commit id of
-    the HEAD of the branch.
-  - this allows the release to be reproduced exactly at any later time,
-    regardless of what happens to the repositories, as long as the
-    specific commit id still exists
-  - the `baserock/petrifying/foo` branch is kept so that future releases
-    can be based on the work done so far
-  - `baserock/petrifying/foo` is tagged with the exact release number
-    (e.g, `baserock/petrifying/1.2-series` would be tagged
-    `version-1.2.0`), so that it's easier to find where the release
-    happened
-* A **continuous integration tool** builds and tests system images from
-  the `morphs` repository.
-  - `master` is always tested whenever it or any constituent project
-    changes
-  - `baserock/petrifying/*` are similarly always tested when something
-    in them changes
-  - `baserock/petrified/*` as well, though nothing in them should ever
-    actually change (any change in a release would result in a new
-    release being done)
-  - other branches may also be configured manually, when necessary
-  - for each branch, the CI tool builds the system image, and runs automatic
-    tests, reporting results in some suitable manner; the tests will include
-    upgrading from previous releases, and probably should include installation
-    and upgrading and removal of specific strata on some of the systems,
-    but that's getting beyond the scope of this
-
-What a lotta branches
----------------------
-
-Keeping things in feature branches sounds like a good idea so that:
-
-* upstream can more easily see what we've changed, and can easily 
-  incorporate every change separately
-* it's easy to back out of a set of changes (just drop it from the
-  integration)
-* it's easy to combine the same fix into many deliverables
-  (e.g., an eglibc bug fix might be backported into several releases)
-
-I hate this
------------
-
-The above sounds like a lot of bureaucratic hassle that will get
-really annoying and horrifically error prone very quickly. However,
-fear not, the `morph` tool will be make it all painless. In fact,
-the above is an outline for a design for how `morph` will work 
-behind the scenes. What the user actually sees will be much simpler.
-
diff --git a/morph/story.mdwn b/morph/story.mdwn
deleted file mode 100644
index 419727a..0000000
--- a/morph/story.mdwn
+++ /dev/null
@@ -1,144 +0,0 @@
-Baserock development: a bedside story
-=====================================
-
-Assumptions:
-
-* A native development system is installed: Baserock core and development
-  strata, and whatever else is considered essential for development.
-  (Until Baserock is bootstrapped, we can just pretend whatever Linux
-  system is native.)
-* Chunk morphologies are kept with the upstream projects they are for.
-  Initially, the upstream project is branched and the morphology is added,
-  and this branch is rebased with any new upstream developments. Eventually,
-  we hope that at least some upstreams will include the morphologies in
-  their upstream code.
-* All other morphologies (strata, systems) are kept in the same 
-  dedicated git repo. Having them all in different repos would be too
-  hard to deal with for users.
-* We want to only ever clone the git repositories we actively work on,
-  not everything. For example, if working on busybox, there should be
-  no need to clone (never mind build) the gcc repo.
-* The morph command can work on all cloned repositories at once, but only
-  when they're under the same parent directory.
-
-Configure morph (intended to be similar to what git does):
-
-    $ morph config --global cache=file://$HOME/.cache/morph/binaries
-    ... where built binaries (chunks, strata, system images) are stored
-    ... some day this will be a suitable server
-    $ morph config --global git-base-url=git://git.gitorious/baserock/
-    ... where git repositories are looked for by default
-    ... git-base-url is for resolving relative URLs
-    ... absolute URLs may always be specified
-
-Checkout a Baserock base system and rebuild it:
-
-    $ cd $HOME/baserock
-    ... this is the directory where we'll put all repos we work on
-    $ morph clone morphs
-    ... this clones git://git.gitorous.org/baserock/morphs
-    $ cd morphs
-    $ morph build base-system.morph
-
-The system image gets put into the cache. FIXME: There needs to be
-convenient ways of getting stuff out of a cache.
-
-Test built system in an emulator:
-
-    $ morph qemu base-system.morph
-    ... this will use the system image built for base.morph
-    ... the image could also be tested on an actual device, by
-    ... getting it out from the cache and installing onto the device
-    ... (in whatever manner is suitable for that specific device)
-
-Next, fix a bug in an upstream project. 
-
-Making changes is complicated by the fact that many projects need to be
-touched: the actual upstream project and the various morphologies, which
-may be distributed in several git repos. In order to make a change in,

(Diff truncated)

diff --git a/Morph.mdwn b/Morph.mdwn
new file mode 100644
index 0000000..a477537
--- /dev/null
+++ b/Morph.mdwn
@@ -0,0 +1,8 @@
+Morph is the name of the tool to build Baserock binary elements - strata, erratics, morphologies etc.
+
+[[story]] describes the **evolving** user story - what a user can do with Morph. Anything and everything
+in there may still change.
+
+[[repositories]] describes our current thinking on how Morph will handle branching, patching and releases for multiple upstream projects and a range of stakeholders.
+
+
diff --git a/Morph2.mdwn b/Morph2.mdwn
deleted file mode 100644
index a477537..0000000
--- a/Morph2.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-Morph is the name of the tool to build Baserock binary elements - strata, erratics, morphologies etc.
-
-[[story]] describes the **evolving** user story - what a user can do with Morph. Anything and everything
-in there may still change.
-
-[[repositories]] describes our current thinking on how Morph will handle branching, patching and releases for multiple upstream projects and a range of stakeholders.
-
-

diff --git a/Morph2.mdwn b/Morph2.mdwn
new file mode 100644
index 0000000..a477537
--- /dev/null
+++ b/Morph2.mdwn
@@ -0,0 +1,8 @@
+Morph is the name of the tool to build Baserock binary elements - strata, erratics, morphologies etc.
+
+[[story]] describes the **evolving** user story - what a user can do with Morph. Anything and everything
+in there may still change.
+
+[[repositories]] describes our current thinking on how Morph will handle branching, patching and releases for multiple upstream projects and a range of stakeholders.
+
+
diff --git a/morph.mdwn b/morph.mdwn
deleted file mode 100644
index a477537..0000000
--- a/morph.mdwn
+++ /dev/null
@@ -1,8 +0,0 @@
-Morph is the name of the tool to build Baserock binary elements - strata, erratics, morphologies etc.
-
-[[story]] describes the **evolving** user story - what a user can do with Morph. Anything and everything
-in there may still change.
-
-[[repositories]] describes our current thinking on how Morph will handle branching, patching and releases for multiple upstream projects and a range of stakeholders.
-
-

diff --git a/local.css b/local.css
index 85a051c..49cc6ec 100644
--- a/local.css
+++ b/local.css
@@ -1,5 +1,11 @@
 a { color: #bf2400; }
 
+input#searchbox {
+    background: url("wikiicons/search-bg.gif") no-repeat scroll 100% 50% #fbebbc;
+    color: #000000;
+    padding-right: 16px;
+}
+
 div.pageheader {
     background-color: #28170b;
     border-top:2px solid #bf2400; 

diff --git a/local.css b/local.css
index e94865f..85a051c 100644
--- a/local.css
+++ b/local.css
@@ -14,6 +14,15 @@ div.pageheader {
     padding: 0.1em 0.5em 0;
 }
 
+.pageheader .actions ul li {
+    background: none repeat scroll 0 0 #28170B;
+    border-color: #28170B;
+    border-style: solid solid none;
+    border-width: 0px;
+    margin: 0;
+    padding: 0.1em 0.5em 0;
+}
+
 .pageheader .actions a { color: #fbebbc; }
 
 div.header {

diff --git a/local.css b/local.css
index 9088037..e94865f 100644
--- a/local.css
+++ b/local.css
@@ -14,6 +14,8 @@ div.pageheader {
     padding: 0.1em 0.5em 0;
 }
 
+.pageheader .actions a { color: #fbebbc; }
+
 div.header {
     background-image: url("logo.png");
     background-repeat: no-repeat;

diff --git a/local.css b/local.css
index 743434b..9088037 100644
--- a/local.css
+++ b/local.css
@@ -8,10 +8,8 @@ div.pageheader {
 }
 
 .pageheader .actions ul li {
-    background: none repeat scroll 0 0 #e98716;
-    border-color: #28170b;
-    border-style: solid solid none;
-    border-width: 1px;
+    background: none repeat scroll 0 0 #28170b;
+    color: #fbebbc;
     margin: 0;
     padding: 0.1em 0.5em 0;
 }

diff --git a/local.css b/local.css
index 136aa5d..743434b 100644
--- a/local.css
+++ b/local.css
@@ -8,8 +8,8 @@ div.pageheader {
 }
 
 .pageheader .actions ul li {
-    background: none repeat scroll 0 0 #28170b;
-    border-color: #999999;
+    background: none repeat scroll 0 0 #e98716;
+    border-color: #28170b;
     border-style: solid solid none;
     border-width: 1px;
     margin: 0;

diff --git a/local.css b/local.css
index 18645b2..136aa5d 100644
--- a/local.css
+++ b/local.css
@@ -1,6 +1,5 @@
 a { color: #bf2400; }
 
-
 div.pageheader {
     background-color: #28170b;
     border-top:2px solid #bf2400; 
@@ -8,6 +7,15 @@ div.pageheader {
     color: #fbebbc;
 }
 
+.pageheader .actions ul li {
+    background: none repeat scroll 0 0 #28170b;
+    border-color: #999999;
+    border-style: solid solid none;
+    border-width: 1px;
+    margin: 0;
+    padding: 0.1em 0.5em 0;
+}
+
 div.header {
     background-image: url("logo.png");
     background-repeat: no-repeat;

diff --git a/local.css b/local.css
index d4e1ff7..18645b2 100644
--- a/local.css
+++ b/local.css
@@ -1,6 +1,11 @@
+a { color: #bf2400; }
+
+
 div.pageheader {
     background-color: #28170b;
-    color: #58595b;
+    border-top:2px solid #bf2400; 
+    border-bottom:2px solid #bf2400;
+    color: #fbebbc;
 }
 
 div.header {

diff --git a/index.mdwn b/index.mdwn
index 6516205..af476a1 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -5,7 +5,7 @@ This wiki provides public documentation for the Baserock open source project. Ba
 
 This is a new project - documentation is incomplete and may change. As a result early readers probably need quite a lot of background knowledge to understand the project e.g.
 
-* deployment and use Linux-based software
+* deployment and use of Linux-based software
 * software development for Linux
 * Linux configuration management
 * version control, particularly git

diff --git a/index.mdwn b/index.mdwn
index 4f0203b..6516205 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,11 +1,9 @@
 Baserock
 ========
 
-This wiki provides public documentation for the Baserock open source project. 
+This wiki provides public documentation for the Baserock open source project. Baserock aims to provide an optimal approach for implementing Linux-based solutions for embedded devices. 
 
-Baserock aims to provide an optimal approach for implementing Linux-based solutions for embedded devices. This is a new project - documentation is incomplete and may change. 
-
-As a result early readers probably need quite a lot of background knowledge to understand the project e.g.
+This is a new project - documentation is incomplete and may change. As a result early readers probably need quite a lot of background knowledge to understand the project e.g.
 
 * deployment and use Linux-based software
 * software development for Linux

diff --git a/index.mdwn b/index.mdwn
index 4b838e6..4f0203b 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,7 +1,18 @@
 Baserock
 ========
 
-This is the Baserock wiki. It provides public documentation for the Baserock open source project. 
+This wiki provides public documentation for the Baserock open source project. 
+
+Baserock aims to provide an optimal approach for implementing Linux-based solutions for embedded devices. This is a new project - documentation is incomplete and may change. 
+
+As a result early readers probably need quite a lot of background knowledge to understand the project e.g.
+
+* deployment and use Linux-based software
+* software development for Linux
+* Linux configuration management
+* version control, particularly git
+
+Ultimately our intention is to simplify the process of embedded Linux development and deployment - so clearly our documentation will need to   be extended to support less expert participants. 
 
 Subproject Pages
 ===========

diff --git a/index.mdwn b/index.mdwn
index 6989dd6..4b838e6 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -1,9 +1,9 @@
 Baserock
 ========
 
-This is the Baserock wiki. 
+This is the Baserock wiki. It provides public documentation for the Baserock open source project. 
 
-Subprojects
+Subproject Pages
 ===========
 
 * [[Morph]]

diff --git a/wiki-theming.mdwn b/wiki-theming.mdwn
new file mode 100644
index 0000000..b8e6007
--- /dev/null
+++ b/wiki-theming.mdwn
@@ -0,0 +1,6 @@
+To change the layout and typography and other theming and branding
+of the Baserock wiki, edit `local.css`, and add any images you need
+to the wiki as attachments to the front page (or a suitable subpage).
+
+<http://ikiwiki.info/css/> is a starting place for learning about
+theming of ikiwiki sites.

diff --git a/local.css b/local.css
index c9597da..d4e1ff7 100644
--- a/local.css
+++ b/local.css
@@ -16,3 +16,7 @@ div#footer {
 #pageinfo {
     border-top: 0;
 }
+
+#content {
+    max-width: 50em;
+}

diff --git a/local.css b/local.css
index d1a06e1..c9597da 100644
--- a/local.css
+++ b/local.css
@@ -13,3 +13,6 @@ div.header {
 div#footer {
     border-top: 4px solid #28170b;
 }
+#pageinfo {
+    border-top: 0;
+}

diff --git a/local.css b/local.css
new file mode 100644
index 0000000..d1a06e1
--- /dev/null
+++ b/local.css
@@ -0,0 +1,15 @@
+div.pageheader {
+    background-color: #28170b;
+    color: #58595b;
+}
+
+div.header {
+    background-image: url("logo.png");
+    background-repeat: no-repeat;
+    min-width: 282px;
+    padding-top: 50px;
+}
+
+div#footer {
+    border-top: 4px solid #28170b;
+}
diff --git a/logo.png b/logo.png
new file mode 100644
index 0000000..ed8dda8
Binary files /dev/null and b/logo.png differ

diff --git a/glossary.mdwn b/glossary.mdwn
index 5b496c2..8eaa36e 100644
--- a/glossary.mdwn
+++ b/glossary.mdwn
@@ -1,5 +1,30 @@
 This describes the concepts and terms we are using in Baserock
 
-**morphology**
-**stratum**
-**erratic**
+**Epoch**
+ - A release version 
+
+**Age**
+ - Non-backward-compatible points on epoch timeline
+
+**Stratum/Strata**
+ - Collection of software geared towards a common functional block or concept.
+   For example, core, connectivity, gnome
+
+**Erratic**
+ - Addon type application (May be installed in an image rather than by the user)
+   For example dropbear, gedit, angry birds.
+
+**Chunk**
+ - Already-petrified sub-section of a morphology
+
+**Morphology**
+ - The instructions and resources necessary to build an erratic, chunk or stratum.
+
+**Petrification**
+ - The process by which a morphology is turned into its output.  i.e. by running the build script or simliar.
+
+**Manifest**
+ - The part of the morphology which details which git trees / refs are used.
+
+**Integration Script**
+ - The part of the morphology which explains how to turn the manifest into the output of the morphology (which could be an image, erratic, chunk, stratum etc)

diff --git a/morph.mdwn b/morph.mdwn
index 5d791d9..a477537 100644
--- a/morph.mdwn
+++ b/morph.mdwn
@@ -1,4 +1,8 @@
-Morph is the name of the tool to build Baserock binary stuff.
+Morph is the name of the tool to build Baserock binary elements - strata, erratics, morphologies etc.
+
+[[story]] describes the **evolving** user story - what a user can do with Morph. Anything and everything
+in there may still change.
+
+[[repositories]] describes our current thinking on how Morph will handle branching, patching and releases for multiple upstream projects and a range of stakeholders.
+
 
-See [[story]] for the **evolving** user story (anything and everything
-in there may still change).

diff --git a/morph/story.mdwn b/morph/story.mdwn
index 69836ed..419727a 100644
--- a/morph/story.mdwn
+++ b/morph/story.mdwn
@@ -40,21 +40,16 @@ Checkout a Baserock base system and rebuild it:
     $ cd morphs
     $ morph build base-system.morph
 
-Alternatively, without cloning a repo explicitly:
-
-    $ morph build morphs master base-system.morph
-    ... use the git://git.gitorious.org/baserock/morphs repository
-    ... and its master branch
-    ... and the file base-system.morph there
-
-Either way, the system image gets put into the cache.
+The system image gets put into the cache. FIXME: There needs to be
+convenient ways of getting stuff out of a cache.
 
 Test built system in an emulator:
 
-    $ morph disk-image --image-size=1G base-system.morph
-    ... this takes the system image tarball and creates a disk image
     $ morph qemu base-system.morph
-    ... this will use the latest disk image built for base.morph
+    ... this will use the system image built for base.morph
+    ... the image could also be tested on an actual device, by
+    ... getting it out from the cache and installing onto the device
+    ... (in whatever manner is suitable for that specific device)
 
 Next, fix a bug in an upstream project. 
 
@@ -66,43 +61,54 @@ change the stratum morph to refer to that branch instead of the default
 one, and then percolate the change up to the system image. Thus, we must
 "fork" all the relevant parts of the stack.
 
-    $ cd $HOME/baserock
-    $ morph fork morphs busybox --branch-name=baserock/fix-bug-12765 \
-        --morph=morphs/base-system.morph
-    ... this git clones any named repos, if necessary
+    $ cd $HOME/baserock/morphs
+    $ git checkout master
+    ... base the changes on the current master branch
+    $ morph fork --fork-name=baserock/fix-bug-12765 busybox
+    ... this git clones any named repos, if necessary, to the parent directory
+    ... of the current repository (i.e., busybox goes into ../busybox)
     ... it also creates and checkouts a new branch in each repo
     ... it tries to be safe: no uncommitted changes, etc
-    ... also changes the specified morphs so that they build the fork
+    ... also changes the all morphs in the morphs repository so that 
+    ... they build the forked busybox
     ... if necessary, the branch may be manually adjusted (e.g., rebased)
 
-FIXME: How to deal with unrelated repositories cloned at the same place?
+Now make some actual changes.
 
-    $ cd busybox
+    $ cd ../busybox
     $ $EDITOR miscutils/time.c && make && make check
-    ... user makes the necessary changes and tests them in the source tree
+    ... user makes the necessary changes and tests them locally
+    ... e.g., they might run an upstream test suite
     $ git commit -m "Fix bug 12765 by doing foo to bar."
-    $ morph build ../systems/base.morph
-    $ morph disk-image ../systems/base.morph
-    $ morph qemu ../systems/base.morph
+    ... commit the changes so that they can be built by morph
+    $ morph build ../morphs/base.morph
+    ... build the new system image
+    $ morph qemu ../morphs/base.morph
+    ... run the new system image in an emulator
     ... manually verify that changes actually fix the problem
-    $ morph system-test ../systems/base.morph --test-system=qemu
-    ... run automatic system integration tests
-    $ morph install ../systems/base.morph
-    ... install the new stratum onto the current system, for testing
+    $ morph system-test ../morphs/base.morph --test-system=qemu
+    ... run automatic system integration tests using an emulator
+    ... with suitable options, this should be able to run the tests against
+    ... a real device, after the user has manually installed the new system
+    ... image on the device
+    $ morph install ../morphs/base.morph
+    ... install the new stratum onto the current system
+    ... manually test the bug fix
     ... might be done on an actual device instead of the development system
     $ morph rollback base
-    ... revert any changes to the base stratum in the current system
+    ... revert any changes to the stratum on the current system
 
-    $ cd ..
-    $ morph patch --old-branch=baserock/integration/master | less
-    ... this generates diffs from all repos below the current directory
-    ... (or just in the current directory, if it's a git repo)
+    $ cd ../morphs
+    $ morph patch --old-branch=master | less
+    ... this generates diffs from all the upstream repos affected by the change
+    ... i.e., the busybox one
     ... repos can also be specified explicitly
-    ... this ignores changes done to morphs by the fork command
+    ... this does not include changes to the morphologies outside morphs repo
     $ morph patch --old-branch=master --send=patches@busybox.org
     ... send patch upstream
     $ morph push
     ... push changes to the git server
+    ... affects both the morphs repo and all other affected repos
 
 FIXME: Figure out what patch submission formats are needed. For example,
 patch series?
@@ -111,33 +117,28 @@ However, sometimes it takes a while for upstreams to incorporate
 patches. Meanwhile, we'll want to continue development as if they
 already had. For this, we'll want to have some branch management.
 
-Some assumptions about branch management:
-
-* Upstream source is mirrored as is.
-* When upstream source can be used without changes (e.g., they include
-  a working morphology), we do that. In that case, the stratum refers
-  to the upstream's "master" branch, or whatever they call it.
-* When we need to make a custom change, we put the branch under the
-  `baserock/` directory (or prefix).
-* We want to have one branch per feature or bug fix or other change:
-  `baserock/bug-12765`, `baserock/morph`, etc. These branches are
-  removed once they're no longer needed (e.g., patch has been integrated
-  upstream).
-* We also want an integration branch, or several:
-  `baserock/integration/master`, `baserock/integration/alice-experimental`,
-  etc. Integration branches are updated manually.
+See [[repositories]] for a discussion on branch management.
 
 In order to use the changes done in the branches created by
-`morph fork`, we need to merge them into an integration branch:
+`morph fork`, we need to change the `master` branch of `morphs`
+to use them.
 
-    $ morph join --branch-name=baserock/fix-bug-12765 \
-        --join-with=baserock/integration/master
-    ... this avoids changes to morphs made by fork
+    $ git checkout master
+    $ $EDITOR base.morph
+    ... add the busybox baserock/bug-12765 feature branch to the 
+    ... branches to use for integration
 
-Make a release of Baserock:
+Make a release candidate of Baserock:
 
     $ cd $HOME/baserock/morphs
+    $ morph release-candidate --release-name=1.23.4.7.1
+    ... create a baserock/petrifying/1.23.4.7.1 branch
+    ... create a similar branch in all constituent projects
+    ... update morphologies to refer to those branches
+
+Make an actual release:
+
     $ morph release --release-name=1.23.4.7.1
-    ... create a baserock/releases/1.23.4.7.1 branch
-    ... convert all git commit references to being absolute SHA-1 ids
+    ... create branch baserock/petrified/1.23.4.7.1
+    ... convert all branch references in morphologies to absolute SHA-1 ids
 

diff --git a/morph/repositories.mdwn b/morph/repositories.mdwn
new file mode 100644
index 0000000..ce4f358
--- /dev/null
+++ b/morph/repositories.mdwn
@@ -0,0 +1,130 @@
+Using git repositories with Baserock
+====================================
+
+* There is a **git repository corresponding to each upstream project**.
+  This repository gets **mirrored** (possibly with **conversion**) from 
+  upstream version control systems or release tarballs.
+  - exact details of the mirroring are not yet specified, but are irrelevant
+    for this discussion, as long as the result is a set of git repositories
+  - no non-upstream branches get automatically changed by the mirroring
+  - if upstream does not contain the morphologies, we add them in a
+    feature branch, `baserock/morphologies`, which has no other changes;
+    see below how this gets integrated during build
+  - if the morphologies need to be changed, we create a feature branch
+    `baserock/foo` off `baserock/morphologies`, merge in changes from
+    upstream's `master` branch , make and test any fixes, and then merge the
+    changes to `baserock/morphologies`
+* Additionally, there is at least one more **git repository for stratum and
+  system morphologies**. For simplicity, we will assume they're all in one
+  repo and call this the `morphs` repo.
+  - in reality, it may be more convenient or necessary to have several
+    repositories, e.g., GNOME might have their own, and NDAs may prevent
+    some custom hardware support projects from being kept on a public
+    git server until the hardware is released
+  - the `master` branch is where main development happens
+  - in `master`, the morphologies refer to the upstream `master` branches
+    in upstream project repos, so that when we build from master, we get
+    the current development version of everything
+  - they also refer to any `baserock/morphologies` branches if they exist
+* When something needs to be changed, it always affects at least the
+  `morphs` repository, and may affect one or more upstream repositories.
+  The changes will be done in dedicated **feature branches**.
+  - in all affected repos, create new branches `baserock/foo` (using the
+    same branch name in all repos)
+  - in the `morphs` repo, the new branch is based on whatever was the
+    current branch
+  - in other repositories, the new branch is based on whatever main
+    branch the morphologies refer to (i.e., the first branch)
+  - in the `morphs` repo, change the morphologies to refer to
+    the `baserock/foo` branch in the other affected repositories; this
+    allows you to build binaries that use the changes you make in the
+    other repositories
+  - however, repositories that are not affected by the change will continue
+    to refer to their original repositories and branches; this avoids
+    creating a lot of unnecessary branches all over the place
+  - changes will remain in the new branches; see below for integration
+* Feature branches are **integrated** by specifying several branches
+  for an upstream project in a morphology. The `morph` tool will 
+  merge the changes into a unified branch for building.
+  - a stratum morphology may specify, e.g., that `busybox` needs to be
+    built from the `baserock/master`, `baserock/bug-12765`, and
+    `baserock/mkfs.btrfs` branches
+  - the merging of feature branches into an integration branch is thus
+    specified in morphologies, rather than in an external configuration
+    file for a continuous integration tool; this keeps everything nicely
+    explicit and version controlled
+  - if the merging fails, e.g., because the various feature branches
+    conflict, the build fails
+* When it is time to prepare for a release, it is necessary to **branch
+  all constituent projects** in such a way that normal development changes
+  are no longer automatically included in the release candidate, 
+  but changes are still comfortable to make manually.
+  - `morphs` is branched into `baserock/petrifying/foo`, where `foo` is a name
+    or version number for the upcoming release, picked by the user
+  - the new branch in `morphs` may be based on `master` or any other suitable
+    branch
+  - for every upstream project referred to from any morphology, a similar
+    branch is made: `baserock/petrifying/foo`; these branches are based on 
+    whatever main (first) branches are referred to from the morphologies
+  - it is an error for the morphologies to refer to different main branches of
+    the same upstream project, since this causes a conflict of which
+    branch to base `baserock/petrifying/foo` on
+  - the morphologies are updated to refer to the new branches
+  - the release candidate can be updated by making changes to the
+    `baserock/petrifying/foo` branches manually; no upstream
+    changes will automatically flow into the release candidate, they must
+    all be merged in by hand
+* When a release is ready, it is **petrified**. At this point, the
+  versions (commits) of all **constituent projects are nailed down** in such
+  a way that they cannot be (easily) changed again.
+  - `morphs` is branched from `baserock/petrifying/foo` to
+    `baserock/petrified/foo`
+  - in all morphologies the reference to the upstream projects'
+    `baserock/petrifying/foo` branch is changed to the commit id of
+    the HEAD of the branch.
+  - this allows the release to be reproduced exactly at any later time,
+    regardless of what happens to the repositories, as long as the
+    specific commit id still exists
+  - the `baserock/petrifying/foo` branch is kept so that future releases
+    can be based on the work done so far
+  - `baserock/petrifying/foo` is tagged with the exact release number
+    (e.g, `baserock/petrifying/1.2-series` would be tagged
+    `version-1.2.0`), so that it's easier to find where the release
+    happened
+* A **continuous integration tool** builds and tests system images from
+  the `morphs` repository.
+  - `master` is always tested whenever it or any constituent project
+    changes
+  - `baserock/petrifying/*` are similarly always tested when something
+    in them changes
+  - `baserock/petrified/*` as well, though nothing in them should ever
+    actually change (any change in a release would result in a new
+    release being done)
+  - other branches may also be configured manually, when necessary
+  - for each branch, the CI tool builds the system image, and runs automatic
+    tests, reporting results in some suitable manner; the tests will include
+    upgrading from previous releases, and probably should include installation
+    and upgrading and removal of specific strata on some of the systems,
+    but that's getting beyond the scope of this
+
+What a lotta branches
+---------------------
+
+Keeping things in feature branches sounds like a good idea so that:
+
+* upstream can more easily see what we've changed, and can easily 
+  incorporate every change separately
+* it's easy to back out of a set of changes (just drop it from the
+  integration)
+* it's easy to combine the same fix into many deliverables
+  (e.g., an eglibc bug fix might be backported into several releases)
+
+I hate this
+-----------
+
+The above sounds like a lot of bureaucratic hassle that will get
+really annoying and horrifically error prone very quickly. However,
+fear not, the `morph` tool will be make it all painless. In fact,
+the above is an outline for a design for how `morph` will work 
+behind the scenes. What the user actually sees will be much simpler.
+

diff --git a/morph/story.mdwn b/morph/story.mdwn
index da81c48..69836ed 100644
--- a/morph/story.mdwn
+++ b/morph/story.mdwn
@@ -16,7 +16,7 @@ Assumptions:
   dedicated git repo. Having them all in different repos would be too
   hard to deal with for users.
 * We want to only ever clone the git repositories we actively work on,
-  not everything. For example, if working on buxybox, there should be
+  not everything. For example, if working on busybox, there should be
   no need to clone (never mind build) the gcc repo.
 * The morph command can work on all cloned repositories at once, but only
   when they're under the same parent directory.

diff --git a/morph/story.mdwn b/morph/story.mdwn
index 1029b68..da81c48 100644
--- a/morph/story.mdwn
+++ b/morph/story.mdwn
@@ -89,6 +89,7 @@ FIXME: How to deal with unrelated repositories cloned at the same place?
     ... run automatic system integration tests
     $ morph install ../systems/base.morph
     ... install the new stratum onto the current system, for testing
+    ... might be done on an actual device instead of the development system
     $ morph rollback base
     ... revert any changes to the base stratum in the current system
 

diff --git a/morph/story.mdwn b/morph/story.mdwn
index b624c56..1029b68 100644
--- a/morph/story.mdwn
+++ b/morph/story.mdwn
@@ -79,14 +79,18 @@ FIXME: How to deal with unrelated repositories cloned at the same place?
 
     $ cd busybox
     $ $EDITOR miscutils/time.c && make && make check
-    ... user makes the necessary changes and tests them isolated if possible
+    ... user makes the necessary changes and tests them in the source tree
     $ git commit -m "Fix bug 12765 by doing foo to bar."
     $ morph build ../systems/base.morph
     $ morph disk-image ../systems/base.morph
     $ morph qemu ../systems/base.morph
-    ... verify that changes actually fix the problem
+    ... manually verify that changes actually fix the problem
     $ morph system-test ../systems/base.morph --test-system=qemu
-    ... also run automatic system integration tests
+    ... run automatic system integration tests
+    $ morph install ../systems/base.morph
+    ... install the new stratum onto the current system, for testing
+    $ morph rollback base
+    ... revert any changes to the base stratum in the current system
 
     $ cd ..
     $ morph patch --old-branch=baserock/integration/master | less

diff --git a/morph/story.mdwn b/morph/story.mdwn
index 24493a0..b624c56 100644
--- a/morph/story.mdwn
+++ b/morph/story.mdwn
@@ -106,10 +106,6 @@ However, sometimes it takes a while for upstreams to incorporate
 patches. Meanwhile, we'll want to continue development as if they
 already had. For this, we'll want to have some branch management.
 
-    $ morph join --branch-name=baserock/fix-bug-12765 \
-        --join-with=baserock/integration/master
-    ... this avoids changes to morphs made by fork
-
 Some assumptions about branch management:
 
 * Upstream source is mirrored as is.
@@ -126,6 +122,13 @@ Some assumptions about branch management:
   `baserock/integration/master`, `baserock/integration/alice-experimental`,
   etc. Integration branches are updated manually.
 
+In order to use the changes done in the branches created by
+`morph fork`, we need to merge them into an integration branch:
+
+    $ morph join --branch-name=baserock/fix-bug-12765 \
+        --join-with=baserock/integration/master
+    ... this avoids changes to morphs made by fork
+
 Make a release of Baserock:
 
     $ cd $HOME/baserock/morphs

diff --git a/build-host.mdwn b/build-host.mdwn
index 317a235..4c39810 100644
--- a/build-host.mdwn
+++ b/build-host.mdwn
@@ -1,6 +1,10 @@
 PRELIMINARY specification for build hosts for Baserock
 ======================================================
 
+This is currently for what we plan to set up at Codethink, in the
+first phase. As we gain experience about that, we'll update the page
+to describe the minimum realistic setup for building Baserock.
+
 For x86:
 
 * Intel i5 CPU with 4 cores