First cut at consolidated alpha releng.

Undoubtedly doesn't work yet, and still needs doc, but perhaps now
ready for testing on build machine.

1 files changed, 66 insertions, 1 deletions

diff --git a/README.md b/README.md
index 9ec137c..e3f3eff 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,66 @@
-Unified release engineering stuff for Cryptech Alpha.
+Alpha Releng
+============
+
+Release engineering stuff for Cryptech Alpha.
+
+Work in progress, currently a merge in progress of two separate
+release engineering repositories, one for HSM firmware, one for host
+software.
+
+This README is probably obsolete by the time you're reading it.
+
+## Old Firmware README ##
+
+Preliminary release engineering super-repository for building firmware
+for the Cryptech "Alpha" board.
+
+Primary tasks here are to build a bitstream for the FPGA and the
+"bootstrap" and "hsm" images for the Alpha's CPU.
+
+Eventually there will be a lot of packaging and versioning glorp here,
+but let's start with basic build and clean targets.
+
+Current repository structure is, um, complicated.  On the RTL side, we
+have a tree of simple subrepositories, each representing one RTL core.
+
+On the software side, we have a subrepository which has several
+subrepositories of its own: current thinking is that this should
+probably be replaced by separate repositories and Makefile VPATH
+magic, but this is what we have today so it's what we build with
+today.
+
+This README is probably obsolete by the time you're reading it.
+
+## Old Software README ##
+
+Preliminary release engineering super-repository for building software
+to work with the Cryptech "Alpha" board.
+
+Primary task here is to build the PKCS #11 library and any needed
+support tools for whichever platforms we support.  This will involve
+some packaging voodoo.
+
+Our first targets for this are Debian and Ubuntu, probably the Jessie
+and Xenial releases, respectively.  If we really need to support
+multiple releases for each of these platforms, the packaging mechanics
+become more complicated, so we may just stop here for these platforms
+and assume we can fill any odd corners using the associated source
+package.
+
+Our next target for this is likely to be Mac OS X.  This should be
+relatively straightforward so long as we only have to support Homebrew
+and we don't have to produce Homebrew "bottles" (binary packages).  If
+we do need to bottle, we either need one or more Mac build machines or
+we need some kind of cross-compilation scheme (eg,
+https://github.com/tpoechtrager/osxcross).
+
+Supporting Homebrew at all requires a bit of extra voodoo on top of
+supporting Debian packaging, but none of it looks particularly
+difficult, and the Debian packaging will produce the source tarball we
+need for the Homebrew formula, so integrating production of these two
+kinds of packaging makes some sense.
+
+Windoze is not currently on the radar.  In theory, MinGW would suffice
+as a cross compiler if and when we have to do something about it.
+
+This README is probably obsolete by the time you're reading it.