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.
Network between your host machine and the ARM device has been setup and works correctly , see: Support distribution installation instructions or How to setup iPAQ networking in Familiar .
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).
You've created an ARM target for the Scratchbox as described in Setting up scratchbox for ARM .
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.)
On Linox and RedHat you need 'nfs-utils' and 'portmap' packages. If they are not installed, you have to install them.
Then you need to allow portmap to accept connections from the CPU transparency device in /etc/hosts.allow :
ALL: [ARM device IP-number]
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:
/scratchbox/users/username/targets/ARM $IP(rw,all_squash,anonuid=$UID,anongid=$GROUPS)
/scratchbox/users/username/home $IP(rw,all_squash,anonuid=$UID,anongid=$GROUPS)
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).
Now you can start your NFS server with:
# /etc/init.d/nfs start
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:
# /sbin/iptables -I INPUT 1 -s [ARM device IP-number] -j ACCEPT
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.
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
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 .
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.