Building the client
The Makefile will build several binaries -- cli, flasher, snooper, proxmark. The "cli" and "snooper" tools are simple demo programs which most people will not use; the "flasher" program can be used to reprogram the FPGA and application sections of the device. The main binary you will use will be 'proxmark'.
There are two different ways to build the 'proxmark' program -- with and without Qt support. The program is fundamentally a console-mode program that you will run using Terminal; the Qt support is only used with the 'plot' command, and not strictly necessary.
The non-Qt case is the easy one; running "make" should be sufficient. It's supposed to automagically detect if you have Qt installed, but that logic is broken right now, so you'll have to comment a couple of lines out in the Makefile to make it happen.
The Qt case is a little harder. As of right now in ToT SVN, the way that is easiest to accomplish this is to download and install http://get.qt.nokia.com/qt/source/qt-ma … 4.6.0.dmg, then run make; it will link against QtCore.framework and QtGui.framework (in /Library/Frameworks). Other options include using MacPorts to install the qt4-mac port -- in fact, that's originally what I was doing, but there are some issues with build architecture on SnowLeopard and the naming of the pkgconfig files.
(Ideally, we would build a standalone, statically-linked binary; however, the the Qt Cocoa implementation does not support static linking. Other options would be using an app bundle and including the framework, or switching to the Qt Carbon implementation, both of which have their own disadvantages; I may create a binary that has everything linked into it except for the above Qt libraries, which are easily installed using the Qt installer.)
Installing
There's not much to this -- copy the binaries to somewhere on your path. The only special thing to note here is the "make install_kext" target in the Makefile. This takes the place of the unbind-proxmark script for Linux -- running "sudo make install_kext" will create a "codeless kext" that will prevent OS X's built-in HID driver from binding to the Proxmark3. After this step completes, you will need to reboot your machine.
Choosing an ARM toolchain
There are a number of choices for an ARM toolchain to build the device firmware.
* Macports's arm-elf-gcc -- this doesn't seem to work at all right now 
* the install-gnuarm4.sh script in the tools directory -- this shows promise, but seems a bit brittle in the face of bad network connections (... such as at CCC....) and I haven't had a chance to really dig into it to figure out why.
* Our BootMii/MINI "buildit" script -- http://gitweb.bootmii.org/?a=tree&p … toolchain. I'm obviously a bit biased towards this script, but it won't generate a libgcc that supports thumb interworking, which may case other problems (see below)
* devkitARM (a toolchain for building Nintendo DS games) -- this is what the Windows ProxSpace seems to use. http://sourceforge.net/projects/devkitp … devkitARM/
Thumb interworking support is not (AFAIK) critical to the project -- not having it should only generate larger binaries. It's something we should get working eventually, but if your toolchain doesn't support it (and you're getting error messages about a missing interwork/libgcc.a), you may want to try backing out the patch that (re-)enabled it (http://code.google.com/p/proxmark3/source/detail?r=279) until we can get this sorted out.
Hope this helps people get started, I'd be more than happy to answer any questions.
]]>