From 0f3cc3aa55bcc6476d721f9fbb8dfe8559d85ff7 Mon Sep 17 00:00:00 2001 From: Rob Austein Date: Mon, 27 Jun 2016 16:26:25 -0400 Subject: First cut at consolidated alpha releng. Undoubtedly doesn't work yet, and still needs doc, but perhaps now ready for testing on build machine. --- README.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 66 insertions(+), 1 deletion(-) (limited to 'README.md') 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. -- cgit v1.2.3