aboutsummaryrefslogtreecommitdiff
path: root/README.md
blob: e3f3eff85a59fadd707c6cdde19cb4c1f79ca134 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66

   

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.