CPU transparency is an Scratchbox feature required when cross-compiling software that uses GNU Autotools
('configure' scripts) to configure itself. CPU Transparency will run the test programs for features that the configured
software depends on, on a networked device with the same CPU as the cross-compilation target device, in a way that is
transparent to the configuration system. Some build systems also benefit from it when they attempt to execute a
target-binary which is used to generate certain data files.
NOTE Some of the tasks listed here require root access and involve editing files and performing tasks that, if done
wrong, might seriously damage your system and/or compromise it's security.
Pre-requirements
A Linux ARM device with lots of RAM (at least 32MB) and as fast network as possible. An iPAQ is recommended as it
has known stable Linux support. Handhelds.org has information about Linux support
for Ipaqs.
You have a suitable ARM distribution installed on the ARM device.
For Ipaqs the Familiar distribution from handhelds.org is strongly
recommended.
Support distribution is also available from scratchbox.org, but
it is no longer maintained and very limited in functionality.
Your kernel has the /proc/sys/fs/binfmt_misc/ feature which is required by Scratchbox CPU Transparency functionality
(on by default on most Linux distributions).
CPU transparency works by sharing your home (build) and target directory in your Scratchbox with the ARM device.
This is done using NFS, so you have to setup your machine to export the required directories with NFS. NFS setup has to
be done as root.
(NFS is inherently insecure so you should run it only on trusted networks.)
2.1. STEP 1
On Linox and RedHat you need 'nfs-utils' and 'portmap' packages. If they are not installed, you have to install
them.
2.2. STEP 2
Then you need to allow portmap to accept connections from the CPU transparency device in /etc/hosts.allow :
ALL: [ARM device IP-number]
2.3. STEP 3
Then add NFS exports for Scratchbox users home and ARM-target directories -directories to the '/etc/exports ' file
on the host machine The export lines should look something like this:
Where $IP is replaced with the IP-address of your ARM device, $UID with user's user-id and $GROUPS with the default
group id for that user (last two values you can see by echoing those variables from shell as that user).
2.4. STEP 4
Now you can start your NFS server with:
# /etc/init.d/nfs start
2.5. STEP 5
Then you have to let your firewall to accept NFS connections from the ARM device to your machine. Making holes for
all the services required by NFS is complicated as port numbers are not static but assigned by portmap daemon. It's
easier just to accept all the connections from ARM device with something like this:
If you boot your machine you have to restart NFS (unless you've added it to a correct runlevel) and re-modify your
firewall rules.
If you make changes to the /etc/exports file, you need to tell the NFS server to reread the /export/exports
file:
# /usr/sbin/exportfs
Or restart NFS:
# /etc/init.d/nfs restart
In case you want to make tighter firewall rules specific for you machine, you can see the used port numbers
from:
# /usr/sbin/rpcinfo -p localhost
(At least portmap, nfs and mountd ports have to be open. If busybox mount is used on the CPU transparency device,
that seems to require also 635 port be open.) More information on NFS is in NFS-HOWTO.
2.7. Disabling NFS
If you don't want to export any filesystems anymore, run this:
# /usr/sbin/exportfs -uav
Or you could stop the NFS service:
# /etc/init.d/nfs stop
Then you can disable the hole in your firewall:
# /sbin/iptables -D INPUT 1
NOTE: above assumes there have been no changes to your firewall rules after you've added the hole for the CPU
transparency device! The number at the end of the line has to correspond to the position of the CPU transparency rule
in the INPUT chain in iptables rules:
# /sbin/iptables -L -v
3. Testing CPU Transparency
If you want to test if the CPU Transparency works just try running any ARM binary inside the Scratchbox, or
compiling software that tries to run cross-compiled binaries during the build process. You can see whether program is
an ARM binary by using 'file' utility.
When running ARM binaries you should get following notice that informs you about CPU Transparency:
### INFO ### cpuTransparency! See /tmp/cputransp_username.log for details!
If you don't see the notice and environment variable $CPUTRANSPARENCY_VERBOSE is set (done by default) then ARM
binaries have not been registered to the kernel of your host machine when Scratchbox was installed. To register arm
binaries to the kernel of your host machine you must run /scratchbox/sbin/register_arm . /scratchbox/sbin/register_arm
should have already been run by /scratchbox/run_me_first.sh and/or /scratchbox/sbin/sbox_ctl .
4. Notes
Do all the work you intend to be visible to the target device inside your Scratchbox home directory as otherwise you
will have trouble with CPU transparency!
/etc, /bin, and /tmp directories in the Scratchbox are not visible to the target (because they've been specially
setup for Scratchbox tools). If some target software installs files to these directories, you have to manually copy
them to the corresponding directories under the Scratchbox target directory.
