Installing EmStar

by The EmStar Team
2007-12-06

Site and Mailing List Search:

Contents

Prerequisites
Downloading the Source
Configuring the EmStar Source
Configuring for Cross Compilation
Compilation
Assigning a Node ID
Running and Testing FUSD
Transferring EmStar applications to non-x86
Installing and Running the MoteNIC
Advanced Configuration
Troubleshooting - For EmStar release 2.1 and Linux kernel 2.6 issues look here!
Linux Distribution Tips

Note:

As of Jan 27, 2006, CVS versions have a simpler installation process (use a recent CVS snapshot or download via pserver). If you are using a _release_ prior to that date, please disregard this box.

Several packages that were formerly "prerequisite" are now optional, including libreadline5-dev, libgsl and libcurl-dev. If these packages are missing, some of the EmStar software will not build.

After downloading the source, run ./configure to see if you are missing anything. Missing required packages will cause it to quit with an error message; missing optional packages will cause a warning message indicating some features that won't be available without that package.

In most cases, after installing the necessary packages and running ./configure, you should be able to successfully run make to build all of the user-space software.

The kernel configuration is more difficult to auto-detect and may require additional effort; see the section on compilation for details if it fails to compile.

Cross-compilation for supported platforms usually does not require configuration; all necessary configuration is built into the tool package. See Configuring for Cross Compilation for details.

Also see Make.conf to

Prerequisites

To build EmStar you need the following prerequisites:

To build EmTOS targets, you need these additional prerequisites:

Downloading the Source

You can download the EmStar source as a tar file from the Downloads Page, or you can get it from CVS via anonymous pserver access.

Configuring the EmStar Source

The next step is to perform some configuration of the EmStar source tree.

Edit Make.conf

Most user configuration of the EmStar build system is limited to the Make.conf file. In this file, you can configure certain paths, flags and options that control what is built.

Integrating with TinyOS

If you are planning to use EmStar to integrate Microservers with Mote hardware, you will need to integrate the EmStar sources with your TinyOS source tree.

If you don't need to use a special or custom-modified version of TinyOS, EmStar can automatically download a compatible version of TinyOS for you. If the EmStar build system does not find a tinyos-1.x directory in the emstar root, it will automatically download the latest tarball from the EmStar web site. This version is known to work and is pre-configured to work with EmTOS (the two symlinks required to add the emstar platform).

Note:

To use EmTOS, you will also need to modify the Make.conf file, to set BUILD_EMTOS to 1.

Life on the Edge: Using some other version of TinyOS

In some cases, you may need to use a specific version of TinyOS. This might be because you need to use a special locally modified version, or because you have been developing in the TinyOS core, or because you need features that are not present in the latest release published on the EmStar web site.

While this is possible, we don't guarantee that it will work -- we only test EmTOS with the version of TinyOS that we publish. If you run into problems with your installation, please verify as much as you can with the published version of TinyOS before submitting bug reports. We have limited resources available to track changes to TinyOS, but we are interested in keeping fairly current -- and we certainly appreciate any helpful patches or hints that would help us keep up-to-date.

So, given all those warnings, here is how you can integrated your existing TinyOS tree with EmStar: 

tinyos-1.x/tos/platform/emstar -> $EMSTAR_ROOT/mote/emtos
tinyos-1.x/tools/make/emstar.target -> $EMSTAR_ROOT/mote/emtos/emstar.target

# The following bash snippet will work (with modifications)
export EMSTAR_ROOT=<location of your EmStar tree>
cd <location of your TinyOS tree>/tinyos-1.x
cd tos/platform
ln -s $EMSTAR_ROOT/mote/emtos emstar
cd ../../tools
# Next line only if pre-1.1.5
ln -s ../beta/make .
cd make
ln -s $EMSTAR_ROOT/mote/emtos/emstar.target .

Configuring EmStar Source for Cross Compilation

EmStar supports any platform that can run Linux and supports all of the software Prerequisites. Compiling EmStar for different platforms requires the proper toolchains and kernel sources for those platforms.

At CENS, the two primary EmStar platforms are x86 and Stargate/XScale. Definitions for compiling for these platforms are already setup, but may require some tweaking if you are using a different toolchain or kernel. The only required changes would be to the make/make.platform file.

Toolchains

A platform toolchain is the set of compilers and libraries that are required to cross compile most programs. To point EmStar to the proper toolchain and kernel, you will either have to install the toolchains that CENS provides, or edit the make/make.platform file.

Stargate/XScale/ARM

For Stargate and other XScale/ARM based platforms: the arm toolchain. The CENS provided toolchain, which EmStar will work 'out of the box' for, is available here. The final location of the toolchain should be /usr/local/lecs/stargate/.

The other toolchains which will require changes to the make/make.platform file are available here, or here. These toolchains typically extract to /usr/local/arm/. We have tested with gcc-3.2 and gcc-3.3.

Kernels

EmStar requires the FUSD kfusd kernel module to be compiled and running on a platform before any EmStar component or application can run on it. To compile the kfusd kernel module, the kernel source is required for both 2.4 and 2.6 kernels.

Pointing the EmStar build system to the kernel requires modification of the make/make.platform file for the specific platform (or new platform you may create).

Stargate

There are two places to get the Stargate. If you downloaded the CENS Stargate-7 toolchain, then the standard Stargate kernel was included and will be in /usr/local/lecs/stargate/kernel/linux-2.4.19-rmk7-pxa2-star/. The make.platform file is already configured to support this kernel.

Alternatively, you can get the newest Stargate kernel from the PlatformX/Stargate CVS. This will require you to change the make/make.platform Stargate section.

Note:

Some of the Stargate file systems out there might require you to install glib and any of its dependencies. An ipkg is available here. If there are unmet dependencies, you can use ipkgfind to locate them. Use the only ipkgs from the Familiar 7.2 or earlier release.

Alternatively, you can copy over the glib that comes with EmStar into the /lib or /usr/lib directories on the Stargate and then run ldconfig. The binaries are available in EmStar/glib/obj.stargate directory.

Compilation

Once the source is downloaded and configured, EmStar can be compiled by running make from the top level emstar directory. This will compile the complete EmStar system in a single Make, and will recursively make various EmTOS targets if enabled.

Getting Kernel Headers

FUSD is a kernel module that is the basis of EmStar IPC. To run FUSD, you must first compile it to work with the kernel you use on the target platform. This requires configuring the build system to point to kernel headers that match your kernel. Nothing special needs to be done for the 2.6 kernel anymore. 

apt-get install kernel-headers-`uname -a | cut -f 3 -d' '`

-- apt-get install linux-headers-uname -a | cut -f 3 -d' ' --

Next you should make /usr/src/linux a symlink that points your kernel headers. 

ln -s /usr/src/kernel-headers-2.4.27-1-386 /usr/src/linux

Note:

If you are using 2.6 and are having problems making the fusd module, you might need to start making part of the kernel to get the appropriate header files. 

cd /usr/src/linux
sudo make oldconfig
sudo make prepare

Additionally, the /usr/src/linux/include/linux/config.h header file was removed in kernel 2.6.19 and as a result the fusd module does not compile. The solution is just to create this file with the content 

#ifndef _LINUX_CONFIG_H
#define _LINUX_CONFIG_H
/* This file is no longer in use and kept only for backward compatibility.
 * autoconf.h is now included via -imacros on the commandline
 */
#include <linux/autoconf.h>

#endif

The compilation of the fusd module also uses the /usr/src/linux/scripts/mod/modpost script, which is not compiled by default with the kernel source or kernel header files. The solution is to go to /usr/src/linux and run 

make scripts

Note:

If you receive an error "Invalid module format" when inserting the fusd module, it usually means that the compiler you are using the compile the fusd module is different than the compiler used to complier the existing kernel modules.

Use modinfo on an exisiting module to determine what compiler was used. Make sure the compiler version you are using to compile fusd matches the compiler version used to compile the existing kernel modules. For the rest of the EmStar binaries and libraries the compiler version does not matter.

Note:

We don't recommend the use of DevFS for EmStar systems. In Linux 2.4, DevFS seems to have problems with race conditions, which are sometimes triggered by EmStar simulations. In Linux 2.6, DevFS is deprecated in favor of udev.

Building EmStar

To build for the native platform (i686-linux), just type make in the emstar root directory: 

cd emstar
make

To build for other platforms, type make ARCH=<platform>. If you have EmTOS enabled, the EmStar build system can also build some targets (e.g. Transceiver) for Mote platforms such as mica2.

Some common errors you may encounter:

Cross Compiling

To cross compile, you must have first installed the proper toolchain and kernel as described in the Configuring for Cross Compilation Section.

Once the toolchains and kernel are installed, and any necessary changes have been made to the make/make.platform file, simply type make and provide the ARCH=myplatform argument where myplatform corresponds to the correct entries in the make/make.platform file. For example, to compile for the Stargate platform, type: 

make ARCH=stargate

Assigning a Node ID

EmStar requires a non-zero node ID to be assigned to each node. This ID is stored in the file /etc/id. Often for convenience it makes sense for this ID to be the same as the IP address or the last octet of the IP address, but you can choose any number, as long as it is unique within a set of interoperating nodes and it is non-zero. Many EmStar components will generate an error and quit if no ID is set. 

echo 1 > /etc/id

Running and Testing FUSD

Testing FUSD

After you have compiled EmStar, you will need to use insmod to insert the kfusd.o module for the 2.4 kernel and the kfusd.ko modules for the 2.6 kernel, located in emstar/obj.<platform>/fusd/:

Example: For 2.4

/sbin/insmod obj.i686-linux/fusd/kfusd.o

Example: For 2.6

/sbin/insmod obi.i686-linux/fusd/kfusd.ko

After inserting, check dmesg to make sure there weren't any errors: 

dmesg | tail

Please heed any warnings or errors reported by insmod. NEVER use the -f option to force insertion of a module that does not match your kernel. Even if it initially appears to work, it is quite likely to crash your system at some later point. Most errors reported by insmod point to a version mismatch between your kernel headers and the kernel you are running. If you can't find headers that match, and you can't find an the .config that was used to generate that kernel, the safest alternative may be to recompile the kernel and install it. If you are using a standard kernel that comes with your distribution, you can usually download kernel headers that match.

Once inserted, become root and run the fusdd daemon, located in emstar/obj.<platform>/fusd/fusdd. The fusdd daemon may emit an error message about modprobe failing. This message normal and merely indicates that your kfusd.o or kfusd.ko module is not yet installed in the normal place: 

fusdd: FUSDd Starting...
modprobe: Can't locate module kfusd
fusdd: modprobe returned '65280', can't find fusd?  Continuing...
FUSDd startup OK.

Please ignore the error returned by modprobe.

Once kfusd.o pr kfusd.ko is inserted and fusdd has started, you should be able to verify that FUSD is present by the following tests: 

$ dmesg | tail
fusd: starting, Revision: 1.113, $Date: 2007-12-06 03:41:08 $,
      release None, debugging messages disabled
fusd: Allocated new major 242

If any unusual errors appear in the output of dmesg, this is a sign of problems. This can be caused by headers that don't match your running kernel. Another common cause has to do with switching between DevFS and non-DevFS versions of FUSD; this is usually the cause of messages that complain that FUSD cannot allocate major number 242. See the Advanced Configuration section for more information about using DevFS. 

$ /sbin/lsmod
Module                  Size  Used by    Not tainted
kfusd                  54784   0
nfsd                   80176   8 (autoclean)
nfs                    81240   3 (autoclean)
... etc.

$ cat /dev/fusd/status
  PID  KDev    Open Name
------ ------- ---- -----------------

FUSD Revision: 1.113 , release: None
0 devices used by 0 clients; 1024 Hash buckets, min 0, max 0

If kfusd does not show up in the output of lsmod, then the module has not correctly inserted: check the output of dmesg for error messages. If kfusd shows up in the output of lsmod, but /dev/fusd/status does not exist, then either DevFS is compiled in but not running, or you have not run fusdd. See the Advanced Configuration section below for more details on DevFS.

If all of these outputs appear to be OK, try running a simple test program. The drums program creates several devices that report their name back when using cat: 

$ cd emstar/obj.i686-linux/fusd
$ ./drums &
[1] 425
calling fusd_run...
$ ls /dev/drums
bam  bang  beat  boom  bum  crash
$ cat /dev/drums/bam
bam

Once FUSD is working, then you should be ready to use EmStar.

Note:

The same instructions above apply to getting FUSD working on other platforms such as the Stargate. The only difference is that you must transfer the kfusd.o kernel module, the fusdd daemon, and any other binaries mentioned above to the Stargate.

Installing FUSD

To make life easier the EmStar Makefile provides an install-fusd targate which will install the kfusd module and the fusdd daemon. Once these two files are install, you will only have to run fusdd since fusdd will insert the kernel module for you. To install the two files, run: 

make install-fusd

YOU MUST BE ROOT for this to work. Anytime after this point, just run fusdd as root and everything should work: 

$ /usr/sbin/fusdd
fusdd: FUSDd Starting...
FUSDd startup OK.

Transferring and EmStar application to non-x86

When you cross compile an EmStar application you have two options for running the code directly on the platform. You can NFS mount with the Stargate or just directly transfer them to the platform.

Using NFS

For development it is sometimes useful to have the Stargate NFS mount your emstar directory on you development PC. This will let you run your application directly on the Stargate without having to directly transfer the binaries to the platform and so speeds up the development process.

Note:

The ethernet chipset on the Stargate has some wiring problems. This will slow down all your transfers and possible cause nfs mounting problems. To get around this without adding the hardware fix, just add the following options to your mount line: -o rsize=512,wsize=512. If you would like to find out about the hardware fix you can do, ask on the stargate-users mailing list.

Transferring

The emrun component of EmStar provides the ability to pull out only the required components for you application from the appropriate obj directory.

Statically Linked Binaries

The default for EmStar is to statically build in all the libraries into each component. Using the --copy-deps flag for emrun will pull out all the components your application depends on and will copy them to a specified directory. It will also consolidate and expand all the .run macros into one .run file.

The key thing to understand about using the copydeps flag of emrun is that you have to run the x86 version, but make it clear that you are trying to get the Stargate/otherplatform version of the binaries (work is underway to make this easier). The other key thing to understand is that the .run files always expect that you are running from one of the obj.* directories.

The following is an example of how to copy over the linkstats and neighbord components. 

cd obj.stargate
mkdir /tmp/copytostargate
../obj.i686-linux/emrun/emrun --copy-deps /tmp/copytostargate/ ../link/examples/neighbors/neighbors.run
cd /tmp/copytostargate
tar jcvf ../s-files.tar.bz2 *
cd ..
scp s-files.tar.bz2 root@mystargateip:~/

Then, on the Stargate, just untar the file and you should be good to go!

Dynamically Linked Binaries

Using shared libraries are useful because they reduce the binary size dramatically, which is important for many resource limited embedded platforms. To tell EmStar to compile your program to use the shared libraries, change the USE_SHARED option in the Make.conf file to 1 (you will probably want to delete your obj directory). Once compiled the shared libraries will be put in the obj.*/lib directory.

Transferring your application to a Stargate or other embedded platform when you are using shared libraries is almost identical to the transferring your application when the libraries are compiled into the binaries. The only difference is that copydeps DOES NOT copy the libraries over for you. You will have to copy them from the obj.*/lib/ directory into the destination directory that you provided to copy deps. You do not have to include libraries like libchannel.a or libemtos.a (if you are not using emtos), to help reduce size.

Once they are copied into the destination directory, just transfer the binaries as you would with the static versions. The final difference is that you have to let Linux know where to find the libraries. This can be done using the LD_LIBRARY_PATH environment variable. The two ways to export the variable, or to just perpend the command with it. Here are both versions: 

cd /root/emstar
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/emstar/lib/ emrun/emrun app.run
# where /root/emstar/lib points to where you copied the libraries to

OR 

cd /root/emstar
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/emstar/lib/
emrun/emrun app.run

Installing and Running the MoteNIC

The MoteNIC is a system that allows EmStar code to use an attached Mote to send and receive radio messages, and allows EmStar software to interoperate with Motes in the field.

The MoteNIC is composed of firmware that runs on the Mote, along with software that runs within EmStar to provide interfaces to other EmStar components. The Mote "firmware" is a TinyOS application called Transceiver; the corresponding EmStar component is called motenicd.

Installing the MoteNIC

The Transceiver application is automatically built by the EmStar build system when you build for Mote platforms such as mica2. After building, the script bin/tosinstall can be used to install the firmware on a Mote. Note that you may need to do this as root, or setuid bin/uisp*, or modify port permissions on your system. 

$ cd emstar
$ make ARCH=mica2
...

# if you have a mib510 connected to /dev/ttyS0
$ bin/tosinstall obj.mica2/mote/Transceiver

# if you have a mib510 connected to /dev/ttyS1
$ bin/tosinstall --serial /dev/ttyS1 obj.mica2/mote/Transceiver

# if you have a parallel programming board
$ bin/tosinstall --prog parport obj.mica2/mote/Transceiver

Using ARCH=mica2 will install using the default frequency for a 433 MHz mica2. If you want to run using a different frequency, you can do this by using a different ARCH value: 

ARCH=mica2-433     for 433 Mhz                 (freq 0)
ARCH=mica2-433-alt for 433 Mhz alternate freq  (freq 2)
ARCH=mica2-918     for 918 Mhz                 (freq 1)
ARCH=mica2-918-alt for 918 Mhz alternate freq  (freq 3)

You can also set an arbitrary frequency from the make command line: 

$ cd emstar
$ make ARCH=mica2 EMSTAR_MOTE_FREQ=-DCC1K_DEFAULT_FREQ=X
...

Running MoteNIC

Once your Mote is programmed, you can try using it by running the EmStar side of the MoteNIC. Be sure that FUSD is installed and running. 

# make sure you have set a non-zero node ID in /etc/id
$ cat /etc/id
1
$ cd emstar/obj.i686-linux
$ emrun/emrun ../mote/testtabs/motenic.run

Tip

You may have to edit the mote/testtabs/motenic.run file to point to the correct serial port. For the Stargate platform, the mote connector is at /dev/tts/2

Tip

Pass the --daemon option to emrun to suppress error messages to the console. This is especially important when your console is exported over the network, as latency incurred sending messages over the network can adversely affect the performance of EmStar.

From another window, you should now be able to see that EmStar recognizes and talks to the Mote. The samples below are shown after the MoteNIC has been in use. The /dev/mote/0/status file is the low level status information provided by the hostmoted daemon, while the /dev/link/mote0/status file is the link level status information provided by the motenicd daemon. 

$ cat /dev/mote/0/status
Current Mote Status:
  MAC type=            S-MAC
  Version number=      [mote:004, pc:004]
  if id=               0001 [     1] (0.1)
  MTU=                 188
  fault count=         00
  pot=                 6
  TX packets=          1036
  TX errors=           0
  RX packets=          43304
  RX drops=            0
  Pkt CRC errors=      1777
  PC->Mote CRC errors= 140
  Mote->PC CRC errors= 0
  reTX packets=        0

$ cat /dev/link/mote0/status
Root Device: MoteNIC (mote 0)
  Stack: [/dev/ttyS0],mote0

Interface Addr: 0.0.0.1
MTU: 185
Stats:
  packets_rx: 54866
  packets_tx: 1036
  bytes_rx: 1245510
  bytes_tx: 20306
  errors_tx: 140
  errors_rx: 1777
Active: 1
Promisc: 0
POT: 6

Note that the MTU is configured by options that are passed in when building Transceiver. Environment variables that control the MTU can be set in the tosflags variable in the BUILD file. The EmStar side software detects the MTU from the Mote that is connected.

Errors reported in the status output are helpful for debugging networking problems. The packet CRC Error field gives an indication of the number of collisions in the channel. The TX errors field indicates the number of packets that failed to transmit. The `Serial CRC Errors` fields indicate errors on the serial channel. The PC->Mote field is less important because these messages are acked and retransmitted.

You can monitor the traffic forwarded through the Mote using linkdump. The -d option causes it to report the data portions of the packets. The -l option reports transmitted as well as received packets, annotating the transmitted packets with >>. 

$ obj.i686-linux/bin/linkdump --uses mote0 -d -l
    src=0.0.0.3 dst=0.0.0.1 type=TOS[61,0] seqno=8 data_len=29
        0000: 05 00 12 BF 17 00 12 00 01 00 00 00 01 00 14 00  ................
        0016: 00 00 0D 0B 7B 07 00 5E 5D 5F 5D 60 5D           ....{..^]_]`]

    src=0.0.0.3 dst=0.0.0.1 type=TOS[61,0] seqno=9 data_len=29
        0000: 0C 00 0F BD 17 00 12 00 01 00 00 00 01 00 14 00  ................
        0016: 00 00 0D 0B 7B 07 00 58 5D 59 5D 5A 5D           ....{..X]Y]Z]

>>  src=0.0.0.1 dst=255.255.255.255 type=TOS[61,0] seqno=60 data_len=26
        0000: 01 00 14 00 14 00 12 01 01 00 14 07 01 00 00 00  ................
        0016: 00 00 01 00 DE 01 03 00 00 00                    ..........

    src=0.0.0.3 dst=0.0.0.1 type=TOS[61,0] seqno=10 data_len=29
        0000: 04 00 13 BF 17 00 12 00 01 00 00 00 01 00 14 00  ................
        0016: 00 00 0D 0B 7B 07 00 5E 5D 5F 5D 60 5D           ....{..^]_]`]

    src=0.0.0.3 dst=0.0.0.1 type=TOS[61,0] seqno=11 data_len=29
        0000: 03 00 14 C0 17 00 12 00 01 00 00 00 01 00 14 00  ................
        0016: 00 00 0D 0B 7B 07 00 61 5D 62 5D 63 5D           ....{..a]b]c]

You can integrate the MoteNIC into your EmStar application by including the contents of mote/testtabs/motenic.run in your application .run file, and then using the /dev/link/mote0 link device to communicate.

Using S-MAC

Transceiver can be built to use either s-mac or the standard Berkeley MAC. This is controlled by the environment variable USE_SMAC, and is used to create the s-mac version of Transceiver, called SMACSceiver.

Advanced Configuration

This section covers less common installation issues. Before attempting the steps discussed in this section, it is often best to try to get the system working using the "known-good" default setup, on x86 hardware.

Installing FUSD to Start on Boot

In the section on Running and Testing FUSD, we saw how to start up FUSD by manually inserting the module. You can make FUSD start up automatically on boot by following these steps:

You can also add a startup script to your system to start up fusdd and insert kfusd.o on boot. A sample startup script for the Fedora/Redhat and Debian distributions that loads kfusd.o and starts the fusdd at boot time can be found in emstar/fusd/initscripts. You have to copy this manually as root. If you placed the fusdd binary somewhere other than /usr/sbin, be sure to edit the FUSDD_PATH variable to point to the new location.

If using Redhat: 

# cp emstar/fusd/initscripts/fusdd-redhat /etc/init.d/fusdd
# /sbin/chkconfig --add fusdd

By default, the fusdd daemon will be started in runlevels 2 through 5.

If using Debian: 

# cp emstar/fusd/initscripts/fusdd-debian /etc/init.d/fusdd
# update-rc.d fusdd start 98 2 5 .

Installing FUSD to Start on boot for non x86 platforms

To install FUSD on a platform such as the stargate, just do what the install-fusd target does on an x86 system:

Building for Kernel 2.6

The EmStar build system now automatically build the kernel modules for 2.6 systems! So, no more special instructions!

FUSD and DevFS

Because of race conditions in DevFS, we do not recommend using DevFS, especially on machines running EmStar simulations. These races typically result in zombie processes that can't be killed.

If you do use DevFS and you are running simulations, you will notice an enormous performance improvement on startup if you kill devfsd. devfsd will attempt to run modprobe every time your simulation creates a new device file, which is very slow.

Building for Non-standard Platforms

All platform dependencies are configured in the emstar/make/make.platform file. For each platform, this file defines any special flags or include directories required for that platform, as well as the locations of the kernel header flies and compiler tools. For example, if you are using a compiler other than the one that is distributed from our site, you may need to change this file to point to the right locations:

Troubleshooting

Some users have been reporting problems building the 2.1 release for 2.6 kernels. NOTE: with the newest cvs version of EmStar, these instructions are different!

The solution is:

Linux Distribution Tips

Our recommendation is to use Ubuntu or Debian Testing. These have a realativly easy to use package manager and are our primary development distributions.

Debian

Debian testing is what we mostly use in our lab. You will have to install the -dev versions of the packages as well as the linux-source package.

Ubuntu

Ubuntu is great. It is debian, but with a nice clean interface, easy to install, and a graphical package manager. It also all fits on one CD.

The only thing you need to do here is install gcc and the -dev packages for all the software requirements listed above. As you are trying to get and compile EmStar you will find what packages you are missing

You will also need to use synaptic to install the linux-source package since Ubuntu uses a 2.6 kernel.

Fedora

EmStar works on Fedora. You will need to isntall the kernel source and the development versions of glib and gtk.

Typically you can use the yum package manager for this. We find yum to be a little difficult to use, so we prefer using apt for rpm.

Redhat

Redhat 9 is about as low as you want to go. Redhat 9 does not have yum, so we strongly suggest you get apt for rpm. It will resolve all the dependancies for you (and we have even see it fix some broken isntalls just by fixing all the dependancies). You should be able to easily download all the -devel rpm's and the kernel source using apt for rpm.

Yellow Dog Linux

Some folks have successfully compiled and run EmStar on Yellow Dog Linux on the PowerPC. Just as with all the other distributions, you need the kernel hearders and maybe the sources.

SUSE

Instructions for SuSE10 are available here. Note, you may not need to recomplie your kernel. SuSE probably has a kernel headers or kernel source package which matches the running kernel.

Mandrake

No feedback yet. Should be similar to Fedora.

Slackware

No feedback yet.

Gentoo

It works. All you need to do is make sure you have all the software installed. You may need to force an upgrade of readline to get the newest version, but other than that, it should work out of the box.