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.
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.
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.