Jon Simpson
Getting started with the Acroname Brainstem & Sharp Zaurus on Mac OS X
This document is intended to be a reasonably concise guide to cross-compiling & installing Acroname’s C Development Kit for the BrainStem on the Sharp Zaurus using the Mac OS X 10.3 operating system. This particular combination presents specific challenges and is different enough from the Linux procedure if you have no prior experience with cross-compiling to cause some issues. This document may also be of use to those compiling the C Development Kit under Linux or other platforms, like BSD.
Requirements
- A system running Mac OS X 10.3 with the Apple Developer Tools installed.
- Sharp Zaurus PDA (SL-5500 used below)
- A way to get files to the Zaurus (Wireless LAN, Compact Flash etc)
- A spare hour or so.
Process
The first step in the process is to obtain a version of GCC that is able to cross-compile for the ARM platform. For OS X this can be done one of two ways, either from source, or using pre-built binaries. I chose to use the pre-built binaries as I was not interested in customizing my cross compile environment. The instructions from here will assume the use of the binaries, and appropriate values will need to be changed for PATH values and other locations specific to the binary distributions.
After the relatively straightforward install, this binary package locates itself in /Developer/Zaurus-X-gcc/
, and the compiler binaries are located at /Developer/Zaurus-X-gcc/opt/Embedix/tools/bin/
.
At this point we can grab the source for Acroname’s C Development Kit for Linux. The version available at the time of writing was 1.0. This should result in a file called cdev.tgz
being downloaded, which unpacks to a directory brainstem/
. Open a copy of Terminal.app and change to this directory to continue.
Before we compile the code, we have to change the environment variables on the system to make the arm-linux-gcc
compiler take precedence over the system’s copy of gcc
. This requires modification of the path variable, as shown in Acroname’s instructions, however their instructions explicitly set PATH to the value of the cross-compiler’s location, which under OS X will result in binaries like make not being found, and the compile being unable to complete. I used the following line to add the location of the cross-compiler to the start of my existing PATH
variable.
PATH=/Developer/Zaurus-X-gcc/opt/Embedix/tools/bin/:$PATH
To compile the C Development kit, we can then follow very similar instructions to the Acroname readme file, but small changes must be made to accommodate the platform difference. The compile command is changed to:
make CC=arm-linux-gcc CCP=arm-linux-g++ ARCH=ARM PLATFORM=Linux
Note the additional assertion of the PLATFORM
variable, as the compiler will otherwise target the Darwin platform, for which there are no makefiles. Attempting the compile without the additional PLATFORM
assertion will result in errors finding files called makefile.Darwin
during the make stage. The compilation took 3-4 minutes on my iBook G4 800mhz, so that may be able to give you a rough idea how long it will take on your system.
If this builds cleanly, you will have binaries for the Acroname C Development Kit in brainstem/aDebug/aUnix/ARM
and brainstem/aRelease/aUnix/ARM
. At this point it is convenient to bundle the binaries into a tarball, using the command:
make ARCH=ARM tarball
This should result in a dist_ARM.tgz
file being put in your brainstem root directory (brainstem/
), which can be used to deploy the binaries on the host platform. You then need to get this file to the Zaurus somehow. I used scp over wireless LAN, but compact flash or a direct USB transfer would also work fine. The dist_ARM.tgz
file must end up in the root of the Zaurus’ filesystem (also known as /
). It can then be unpacked into the Zaurus’ filesystem by typing
tar -xvf dist_ARM.tgz
Once unpacked, the package puts itself in /usr/local/Acroname/brainstem/
, with the binaries for both the programs and libraries located in /usr/local/Acroname/brainstem/aBinary/
. The instructions provided by Acroname that refer to a run script being used to set the LD_LIBRARY_PATH
seem to be inaccurate, and that script was not functional after unpacking on the Zaurus in this instance.
To allow applications to reference the Acroread Brainstem libraries no matter where they are located in the Zaurus’ filesystem, I copied all of the *.so
files to /usr/local/lib
on the Zaurus. To me, this is easier than the alternative of adding the Acroname path to the system’s LD_LIBRARY_PATH
variable, as /usr/local/lib
is already in the LD_LIBRARY_PATH
on the Zaurus.
As Acroname suggest running the aIOTests
binary to check the build was clean and functional, if all tests pass the binaries can be said to be clean, and in this instance all of the IOTests indeed passed. The tests hung for around 15-20 minutes at high CPU usage (to a load average of over 3), after the statement…
MSSleep, NULL error.. passed.
…which seems to be consistent with information from Acroname, who say that this part of the test suite hammers the timing code.
These IOTests will die after the Open "testwritefile" writing
line if the necessary support files for the Acroname environment are not installed, as encountered when trying to produce a selective install of the binaries, with only a few .so
files and the aIOTests
binary. A full tarball install should not, and did not exhibit similar problems, because it includes all of the necessary support files for execution.
If the execution of aIOTests
results in the final line reading…
STDIO IO Tests Finished
…the tests completed successfully and the environment can be assumed to be functioning on the Zaurus. At this point you are ready to start working with the BrainStem module itself in combination with the Zaurus.