Pocket Computing @ WRL

Frequently Asked Questions


     
 

hardware ... the firmware ... the OS ... networking ... drivers ... libraries ... compilers, linkers, and languages .. run-time environment ... applications ... utilities

Hardware and Software Upgrade Information

Questions about the Hardware

Questions about the Firmware

Questions about the Operating System

Questions about Networking

Questions about System Drivers

Questions about System Libraries

Questions about Compilers, Linkers, and Languages

Questions about the Run-time Environment

Questions about Applications

Questions about Utilities


Hardware

My touchscreen needs recalibration, what do I do?

If your touchscreen is currently working, select the Calibrate button from the System manager menu, and then recalibrate.

If your touchscreen is currently not responding properly, run the erasecal program (in /usr/local/bin). The next time your reboot your Itsy, it will make you recalibrate on startup..

You may also be able to reach the calibration program by doing the following operation: while the manager is in the foreground, press and release the left cursor button, then press and release the right cursor button.


The Firmware

What is stored in the flash memory on the motherboard?

Starting Address Entity
0x000000
monitor and its data structures (including reset vectors)
0x060000
boot parameters for linux (i.e., the param file)
0x070000
motherboard ramdisk
0x340000
kernel
0xXXXXff00
auxiliary hardware identification structure
0xXXXXff30
Unused/reserved
0xXXXXff94
Itsy version
0xXXXXff98
Logical region sizes
0xXXXXffa8
hostname information
0xXXXXffb8
date
0xXXXXffc0
calibration information
0xXXXXffe0
hardware identification structure
  • The auxiliary hardware identification structure block is 48 bytes long, starting at 0xXXXXff00. It is documented in the hardware documentation.
  • The Itsy version number data is 4 bytes, starting at 0xXXXXff94.
  • The regions size information block is 16 bytes long, starting at 0xXXXXff98. It is used to determine which of the four logical regions of the flash bank are being used for the FTL file system and which are for plain data storage, with each having a separate minor device.
  • The name data is 16 bytes long, starting at 0xXXXXffa8. A name is composed of characters that the C library function 'isalnum' returns true for. There is no magic number for this block; however, when reading this block the length of the name is determined by finding the first non-isalnum character (up to a maximum of 16 characters). The Itsy hostname is derived from the name by prepending the string 'itsy-' to the block, and if this forms a valid hostname several system files are set up (eg /etc/sysconfig/network, /etc/sysconfig/radio).
  • The date data is 8 bytes long, starting at 0xXXXXffb8. The first four bytes must be the magic number 0x0bedead0 for the date data to be valid. The next four bytes are the time in time_t format.
  • The calibration data is 32 bytes long, starting at 0xXXXXffc0. The first four bytes must be the magic number 0x0babedee for the calibration data to be valid. The next 20 bytes are the five parameters required by the setCalibration function of wm1. The rest are currently unused.
  • The hardware identification structure block is 32 bytes long, starting at 0xXXXXffe0. It is documented in the hardware documentation.

The Operating System

What operating systems are supported?

Linux.

What support exists for floating point?

The StrongARM 1100 chip that is used in the Itsy prototypes does not have hardware support for floating point. There are currently two ways for programs to use floating point on our system:

  1. floating point through kernel traps (emulation) and
  2. floating point through library calls ("softfloat").

The softfloat version should be faster, but exactly how much faster depends on the application (we've measured about 15% faster).

In our elf environment, we have no support for softfloat, and the emulator appears to be completely IEEE compliant (the 'paranoia' benchmark reports 'Excellent').

In the 'aout' world, the emulator was not IEEE compliant, so softfloat was necessary to get compliance. We are moving away from this system, since it was not entirely bug free.

To use the floating point emulator, compile your application as normal, and link it using the '-lm' flag. For example:

arm-unknown-linuxelf-gcc -o test test.c -lm

To use the softfloat library, compile your application using the '-msoft-float' flag, and link it with the '-lsoftfloat' flag. Do not use the '-lm' flag. For example:

arm-unknown-linuxaout-gcc -o test test.c -msoft-float -lsoftfloat

How do I create a new ramdisk?

Use the newrd script. The script, if you need it, is located here .

This script accepts the same flags as do mkrd and ldrd. For example, "newrd -r ram4 -s 2048" will create a 2M (2048K) ramdisk on /dev/ram4 and mount it as /mnt/ram4. After the script is run, use "df" to check that the new ramdisk filesystem is mounted, its size, and the space available.

What do I do when I get a "INIT ... respawing too fast" message on the console?

If you are getting the following message on your console,

INIT: Id "it" respawning too fast: disabled for 5 minutes

here's why. This message occurs when the init program is trying to start a "restarting" process from the /etc/inittab, and that process is exiting quickly. Init will keep trying to restart the process until it decides it is restarting ("respawing") too quickly, and then will complain.

You can figure out which process is causing this by looking at the Id field of the error message (in this case, it's "it"), and then searching for this field in the /etc/inittab file.

What I should I know about unaligned accesses?

Brief Statement of Problem

On early versions of the ARM architecture, unaligned loads had an "odd" behavior best explained by an example. Assume the first 8 words of memory contains the (character) values '01234567'. On most architectures, if you load a 32-bit item from address '2', you will receive the string '2345'. On the ARM, you would receive the value '3012' -- the processors loads the word that word be addressed if the lower two bits were zero and then rotates the specified item into place. Although ANSI C explicitly says that unaligned loads are a no-no, this unexpected behavior may impact applications. Implementations after ARM6 allow you to specify an alignment trap handler, and that alignment handler can load the "proper" data. See the alignment FAQ at NetWinder.org for more information.

The behavior of the ARM processor with respect to unaligned accesses is different than that of normal processors, by default. In our old system, we used the default ARM behavior; we believe that this behavior is not what people expect, in general, and so we are going to phase that out.

Starting with the ELF distribution, we are configuring gcc so that the -march=strongarm flag is on by default. We believe that the compiler will not generate any unaligned accesses with the flag on (and thus that all recompiled applications will work properly, regardless of how the processor treats unaligned accesses).

The default behavior, on ARM processors (including the SA1100), is as follows. If you ask for a non-aligned word, the processor automatically returns the aligned word, but rotated such that the requested byte is at the least significant position. We have added an alignment fault handler to the Itsy kernel which will catch alignment faults and fix them up properly; however, applications compiled with old flags (including some system binaries) may take these alignment faults, and may or may not work properly (as far as we know all of the system binaries that we have work properly both ways, but not all application programs will). We are thus shipping the kernel with the fault handler off; documentation about how to change its state is given in the remainder of this answer.

Setting and Using the Alignment Handler

The alignment handler interface uses file /proc/sys/mm/alignment to control how alignment traps are processed. Simply viewing that file ( e.g., cat /proc/sys/mm/alignment ) will show the current alignment trap handler being used. Setting the value ( e.g., echo 2 > /proc/sys/mm/alignment ) modifies the setting

There are three possible settings for the alignment handler, specified by an integer value of 0, 1, 2:

  • 0 - alignment trap handler installed
  • 1 - alignment trap handler installed w/reporting to syslog
  • 2 - disable alignment trap handler

You can enable traps using e..g,

    	echo 0 > /proc/sys/mm/alignment
    
and then disable them again using
    	echo 2 > /proc/sys/mm/alignment
    

The /proc/cpuinfo file returns the alignment fault statistics (number of faults, user vs. system and kind of instruction) and the current state of the alignment handler. You can use this mechanism to determine if alignment faults are occuring and what is causing them. A sample output is shown below.

bash# cat /proc/cpuinfo
CPU:
Type            : sa1100
Revision        : 9
Manufacturer    : DEC
32bit modes     : yes
BogoMips        : 124.52
Alignment handler: Alignment, no reporting

Misaligned Accesses     : 168 (sys: 84) (usr: 84)
  LDR/STR accesses      : 168
  LDRH/STRH accesses    : 0
  LDM/STM accesses      : 0
  SWP accesses          : 0
  Invalid accesses      : 0

Hardware:
Mem System      : MMU
IOEB            : absent

The current reporting of alignment faults is a bit problematic since "syslogd" is one of the processes that generates alignment traps.

What about the flash filesystem?

See here for a disclaimer and important information concerning FTL.

On the Itsy v1 prototypes, the motherboard had 4MB of flash, which was always dedicated to storing the monitor, kernel, initial ramdisk, etc., and memory-extension daughtercards were used for additional flash. The extra flash is usually accessed through the FTL flash filesystem. On the v2 prototypes, the motherboard has 32MB of flash, which is software-partitioned into a 4MB region (for the monitor, kernel, initial ramdisk, etc.) and a 28 MB region containing a FTL flash filesystem (in the current release). This partitioning can be changed using the flash_region command; extensive documentation on this is available in the apps subtree under ftl_utils (the command is called flash_region). Memory-extension daughtercards are also available for the v2, and can also be partitioned if you like, although there is no need.

The naming convention for filesystems is as follows. /dev/flash1 refers to the entire motherboard flash (4MB for v1 Itsy, 32MB for v2). /dev/flash1a refers to the first region (default of 4MB for Itsy v2), /dev/flash1b refers to the second region (default of 28MB for Itsy v2), and /dev/flash1c the third (empty for Itsy v2). System software searches for either a ramdisk or an FTL flash filesystem in every possibly region of every present flash bank, and mounts the corresponding filesystem. It also will create a symbolic link so that it can be referred to as /disk1b or /disk2 or whatever is appropriate.

An example: the following set of commands will partition the v2 motherboard flash filesystem into the abovementioned 4MB/28MB set, and then will install a flash filesystem on the 28MB, leaving the 4MB partition undisturbed. This configuration is what should already exist on your Itsy; if you repeat it, you will destroy all of the data currently in the 28MB partition when you reformat the filesystem.

flash_region -s /dev/flash1 0 0x400000  0x400000 0x1bc0000
reboot
ftl_format /dev/flash1b
mke2fs /dev/ftl1b
reboot 

When you have a flash filesystem, you must make sure to synchronize the (transient) memory with the (permanent) flash before you turn off power to your Itsy. This can be done in a variety of ways (any one of these ways is enough):

  1. Putting the Itsy to sleep using the sleep button before removing power
  2. Typing /sbin/sync explicitly or selecting "Sync" from the session manager System menu before removing power
  3. Shutting down the Itsy by typing /sbin/shutdown explicitly or selecting "Shutdown" from the session manager System menu before removing power

Networking

Help! My PPP connection is misbehaving.

If your PPP connection appears to have hung (you can no longer ping your Itsy), but PPP is still running, you can neither tip nor rlogin to your Itsy. The solution is to kill the PPP connection on the host side -- the following command can be used to do so:

kill `cat /etc/ppp/ppp0.pid` 

Then wait a few seconds. The Itsy should automatically drop its side of the connection, and then you should be able to log in again using tip and, if desired, restart the PPP connection. If you are prevented from doing a rlogin/ftp/rcp to your Itsy, and get an "address in use" message, you can fix this problem without rebooting your Itsy. If you still have a window on the Itsy, type:

skill inetd
/usr/sbin/inetd 

and the problem should go away. If you have no window left on the Itsy, kill your PPP connection (as described above), then tip to the Itsy, and restart the inetd as described.

Help! How do I get Seyon to connect to my itsy.

Here are some notes for getting seyon to work with an Itsy prototype. We assume that you are connecting your Itsy to an Alpha workstation running Unix.

To execute Seyon, do:

setenv SHELL /bin/sh; seyon -modem /dev/ttyS0 -nodial &

Note that the serial devices in Linux are /dev/ttyS0 and /dev/ttyS1, and on the Alpha they are /dev/tty00 and /dev/tty01. You may need to change the access permission of those files. The speed associated with the serial device being used should be set to 38400 and 8-N-1 (try 9600 if that fails).

Seyon stores configuration parameters in a directory called .seyon. In the phonelist file, put the following line:

258-7096 Athena BITS=8 BPS=9600 SCRIPT=athena

In the protocols file, put the following two lines:

"SEND - Zmodem" "$ sz -b -vv" y
"RECEIVE - Zmodem" "$ rz -b -vv" n

And in the startup file, put the following lines

# almost all things below are commented out. Uncomment anything you want
# or use the resources instead


# see the manual page for a complete listing of the keywords
# that can be used with 'set'.


 set baud 38400


# can be 5, 6, 7, or 8
# set bits 8


# can be 0 (= no parity), 1 (= odd parity), or 2 (= even parity)
# set parity 0


# can be 1 or 2
# set stopBits 1


# can be nl, cr, or cr/lf
# set newlineTranslation cr


# set del on
# set meta_tr on
# set xoff off
# set rtscts on
# set autozm on
# set idleGuard on


# put the modem initialization string here if you like one.
# most modern modems do not need it since they store their setup in
# non-volatile memory.


# echo "Initializing modem..."
# transmit "ATZ^M"

 

System Drivers (see driver document)


System Libraries


Compilers, Linkers, and Languages

How do I compile an application?

We use a version of gcc that can generate code for ARM processors. You may either compile directly on an Itsy (not recommended) or cross compile for an Itsy by running the compiler on an x86-based Linux workstation. For help in setting up the cross compilation environment, see the build environment guide.

What issues should I know about when porting applications?

When porting an application on to an Itsy prototype, you should note the following:

  • 'char's are unsigned by default on the ARM architecture, and signed by default on nearly all other architectures. The '-fsigned-char' flag tells the compiler to make 'char's signed by default. We highly recommend you use this flag while compiling applications.

  • The compiler may compile structures to be a different size (larger) on the ARM than on some other architectures. Adding the keywords ' __attribute__ ((packed))' to the structure definition may fix this problem for you. For example:

        typedef struct {
           evtype_t     type;
           int          data1;
           int          data2;
           int data3;
        } __attribute__ ((packed)) event_t;

Why does the compiler die mysteriously?

We don't know. But, if the compiler dies mysteriously (e.g., not a syntactical or programming error) while compiling a particular file, try reducing the amount of optimization (e.g., go from '-O2' to '-O1').

What flags should I used when compiling? When linking?

Recommended compiler flags:

  • -fomit-frame-pointer - will result in smaller code
  • -fsigned-char - makes chars signed by default
  • -O2 or -O3 (-O2 should give the smallest code, -O3 the fastest)
  • -march=strongarm - emit strongarm-specific code. Should probably be used for all applications.

Recommended linker flags: none for elf.

What debuggers exist?

None, unfortunately. More exactly, gdb only partially works. In particular, it sometimes won't stop at breakpoints. Also, it seems to incorrectly read the values of variables that aren't on the current stack frame.

We are shipping two versions of gdb with the current release. Neither is installed on the Itsy ramdisk by default, as they are very large. One version is supposed to work with aout binaries, the other with elf, but neither is bugfree.

What are the calling conventions used by the EGCS compiler on ARM?

We believe the following to be true, but have not checked it out. This information was posted to the linux-arm mailing list.

Briefly:

  • r0 = first argument
  • r1 = second argument
  • r2 = third argument
  • r3 = fourth argument

  • r4 - r9 need to be preserved
  • r10 = stack limit (APCS) or PIC register
  • r11 = frame pointer
  • r12 = temporary register (need not preserved, but is destroyed over a function call)
  • r13 = stack pointer
  • r14 = link register (PC for function return)
  • r15 = program counter

  • the fifth, sixth, and so on, arguments can be found on the stack at the point when the function is called.

Minimal function entry and exit is as follows (fp = r11, ip = r12, sp = r13, lr = r14, pc = r15 )

mov ip, sp
stmfd sp!, {fp, ip, lr, pc}
sub fp, ip, #4 
@ r0 = arg1, r1 = arg2, r2 = arg3, r3 = arg4
@ ldr rd, [fp, #4] will load rd with arg5 
ldmea fp, {fp, sp, pc} 

Maximal function entry and exit is as follows ( fp = r11, ip = r12, sp = r13, lr = r14, pc = r15 )

mov ip, sp
stmfd sp!, {r4, r5, r6, r7, r8, r9, fp, ip, lr, pc}
sub fp, ip, #4

@ r0 = arg1, r1 = arg2, r2 = arg3, r3 = arg4
@ ldr rd, [fp, #4] will load rd with arg5

ldmea fp, {r4, r5, r6, r7, r8, r9, fp, sp, pc}

If you wish to do varargs type stuff, then the above is changed to :

mov ip, sp
stmfd sp!, {r0, r1, r2, r3}
stmfd sp!, {..., fp, ip, lr, pc}
sub fp, ip, #4 + 4 * 4 
@ 4 + sizeof(reg) * number of extra regs
@ argn is at [fp, #4 + 4 * n] 
ldmea fp, {..., fp, sp, pc} 

If you don't require the frame pointer, you can just use the stack conventionally, but so long as you follow the register preservation rules.

Also note that the frame pointer is either supposed to contain either a valid frame pointer or zero at all times.

There are other optimisations that you can do to all of these such as function epilog optimisation, eg:

ldmea fp, {..., fp, sp, lr}
b function

instead of:

bl function
ldmea fp, {..., fp, sp, pc} 

(message written by Russell King rmk@milldev.demon.co.uk)

What is the current status of the C++ environment?

This distribution includes an updated version of EGCS-1.1.2, including C++ support. The following is a log describing which pieces were used for this distribution. As far as we can determine, this version of EGCS works with pthreads and C++, but there are problems with exceptions that we haven't investigated.

Compilers

We used a stock version of egcs-1.1.2 with patches from Phil Blundell and Scott Bambrough to provide arm-elf support. We used a patch to fix a specific compiler bug. The patch we applied is..

Index: fold-const.c
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/fold-const.c,v
retrieving revision 1.56
diff -p -r1.56 fold-const.c
*** fold-const.c	1999/03/15 05:30:02	1.56
--- fold-const.c	1999/03/23 15:48:43
*************** make_range (exp, pin_p, plow, phigh)
*** 3132,3138 ****
  	  if (TREE_CODE_CLASS (code) == '<'
  	      || TREE_CODE_CLASS (code) == '1'
  	      || TREE_CODE_CLASS (code) == '2')
! 	    type = TREE_TYPE (arg0);
  	  if (TREE_CODE_CLASS (code) == '2'
  	      || TREE_CODE_CLASS (code) == '<'
  	      || (TREE_CODE_CLASS (code) == 'e'
--- 3132,3143 ----
  	  if (TREE_CODE_CLASS (code) == '<'
  	      || TREE_CODE_CLASS (code) == '1'
  	      || TREE_CODE_CLASS (code) == '2')
! 	    {
! 	      type = TREE_TYPE (arg0);
! 	      if (orig_type == NULL_TREE)
! 		orig_type = type;
! 	    }
!
  	  if (TREE_CODE_CLASS (code) == '2'
  	      || TREE_CODE_CLASS (code) == '<'
  	      || (TREE_CODE_CLASS (code) == 'e'

The compiler was configured using the following configuration command (which is typed all on one line without the '\')

configure --with-cpu=strongarm --prefix=/usr/local \
          --target=arm-unknown-linuxelf --without-objc \
          --without-f77 --enable-shared

Libraries

Although this installation of EGCS produces a version of libstdc++ , that version did not work in a multithreaded environment. Using a netwinder, we installed the following RPMS's prepared by Scott Bambrough


02/26/99 03:23PM      8,235,935 glibc-2.1-0nw1.armv4l.rpm
02/26/99 03:23PM          4,469 glibc-debug-2.1-0nw1.armv4l.rpm
02/26/99 03:24PM      6,253,037 glibc-devel-2.1-0nw1.armv4l.rpm
02/26/99 03:24PM      5,133,363 glibc-profile-2.1-0nw1.armv4l.rpm

We then copied the /usr/include installed by this installation and a set of libraries. A script was used to copy the critical libraries to the Itsy and to the cross compiler environment. The script is

#!/bin/csh -x
unsetenv LD_LIBRARY_PATH
setenv FROM /udir/grunwald/FROM-TESTWINDER
setenv TO /usr/local/arm-unknown-linuxelf/lib
#setenv TO /mnt/ram-grunwald/lib

setenv CP "cp -f"
setenv LN "ln -s -f"

cd $TO

$CP $FROM/ld-2.1.so .
$LN ld-2.1.so ld-linux.so.2
$CP $FROM/libc-2.1.so .
$LN libc-2.1.so ./libc.so.6
$CP $FROM/libc.so .
$CP $FROM/libcrypt-2.1.so .
$LN libcrypt-2.1.so libcrypt.so.1
$CP $FROM/libdl-2.1.so .
$LN libdl-2.1.so libdl.so
$LN libdl-2.1.so libdl.so.2
$CP $FROM/libext2fs.so.2.3 .
$LN libext2fs.so.2.3 libext2fs.so.2
$CP $FROM/libm-2.1.so .
$LN libm-2.1.so libm.so.6
$CP $FROM/libnsl-2.1.so .
$LN libnsl-2.1.so libnsl.so.1
$CP $FROM/libproc.so.1.2.6 .
$CP $FROM/libpthread-0.8.so   .
$LN libpthread-0.8.so libpthread.so
$LN libpthread-0.8.so libpthread.so.0
# $CP $FROM/libstdc++.so.2.8.1.1 .
#$LN libstdc++.so.2.8.1.1 ./libstdc++.so
#$LN libstdc++.so.2.8.1.1 ./libstdc++.so.2.8

$CP $FROM/libstdc++-2-libc6.1-1-2.9.0.so .
$LN libstdc++-2-libc6.1-1-2.9.0.so libstdc++.so
$LN libstdc++-2-libc6.1-1-2.9.0.so libstdc++-libc6.1-1.so.2
$CP $FROM/libuuid.so.1.1 .
$LN libuuid.so.1.1 libuuid.so.1
$CP $FROM/libutil-2.1.so .
$LN libutil-2.1.so libutil.so.1

#exit 0;
## Install only on bitsy

$CP $FROM/libc.a .
$CP $FROM/libc.sa .
$CP $FROM/libstdc++.a         .
$CP $FROM/libc_p.a            .
$CP $FROM/libc_nonshared.a    .

The files we copied were:

  -rwxrwxr-x   1 grunwald root         1341 Mar 29 17:40 INSTALL
  -rwxrwxr-x   1 grunwald root       110676 Mar 29 12:02 ld-2.1.so
  -rwxrwxr-x   1 grunwald root       959168 Mar 29 12:03 libc-2.1.so
  -rwxrwxr-x   1 grunwald root     18806072 Mar 26 09:48 libc.a
  -rwxrwxr-x   1 grunwald root       187026 Mar 26 09:48 libc.sa
  -rwxrwxr-x   1 grunwald root          164 Mar 29 10:28 libc.so
  -rwxrwxr-x   1 grunwald root        54546 Mar 26 09:48 libc_nonshared.a
  -rwxrwxr-x   1 grunwald root     18860838 Mar 26 09:53 libc_p.a
  -rwxr-xr-x   1 grunwald root        22364 Mar 29 12:03 libcrypt-2.1.so
  -rwxrwxr-x   1 grunwald root         8896 Mar 29 12:03 libdl-2.1.so
  -rwxr-xr-x   1 grunwald root        58984 Mar 29 12:03 libext2fs.so.2.3
  -rwxr-xr-x   1 grunwald root       177436 Mar 29 12:03 libm-2.1.so
  -rwxr-xr-x   1 grunwald root        78860 Mar 29 12:03 libnsl-2.1.so
  -r-xr-xr-x   1 grunwald root        30116 Mar 29 12:03 libproc.so.1.2.6
  -rwxrwxr-x   1 grunwald root        69648 Mar 29 12:03 libpthread-0.8.so
  -r-xr-xr-x   1 grunwald root       270976 Mar 29 13:29 libstdc++-2-libc6.1-1-2.9.0.so
  -rwxrwxr-x   1 grunwald root      3052254 Mar 29 10:24 libstdc++.a
  -rwxrwxr-x   1 grunwald root       289956 Mar 29 12:03 libstdc++.so.2.8.1.1
  -rwxr-xr-x   1 grunwald root         7484 Mar 29 12:03 libutil-2.1.so
  -rwxr-xr-x   1 grunwald root         6500 Mar 29 12:03 libuuid.so.1.1

What does the error message "BUG IN DYNAMIC LINKER ..." mean?

If you get the following error message when trying to run an executable you've just compiled:

BUG IN DYNAMIC LINKER ld.so: ../sysdeps/arm/dl-machine.h: 450: elf_machine_rel: Assertion `! "unexpected dynamic reloc type"' failed!

you probably forgot to use the gcc flag -fPIC when compiling your sources into object files. Note also that all component libraries you include into shared libraries must also be compiled using the -fPIC flag.


Run-time Environment

What run-time environments exist?

There exists three run-time enviroments: Linux, Java, and Squeak.

If I don't want the standard UNIX environment, how can I easily replace it?

See the package startup discussion in the Itsy Packages Document for information on how to implement a different environment.


Applications

How do I compile the applications in the apps subtree of the WRL source-code tree?

If you are just interested in using either the aout or the elf libraries:

  1. set BINFMT in apps/config to either aout or elf
  2. type 'make veryclean'
  3. type 'make apps' (which will build the appropriate libraries first)

Note that we do not recommend using aout unless you need it. If you want both simultaneously:

  1. set BINFMT in apps/config to aout
  2. type 'make veryclean'
  3. type 'make libs'
  4. set BINFMT in apps/config to elf
  5. type 'make veryclean'
  6. type 'make libs'
  7. at this point you will have both elf and aout libraries
  8. set BINFMT to either elf or aout, type 'make apps', and everything should work.

 


Utilities

What support is there for run-time profiling?

Use the profiling-based statistical Itsy profiler. See this document for more information.

 

The Itsy Project is a joint effort of the Western Research Lab and the Systems Research Center