![]() |
|||||||||||||||||||||||||||||
![]() |
hardware ... the firmware ... the OS ... networking ... drivers ... libraries ... compilers, linkers, and languages .. run-time environment ... applications ... utilities Hardware and Software Upgrade InformationQuestions about the HardwareQuestions about the Firmware
Questions about the Operating System
Questions about NetworkingQuestions about System DriversQuestions about System LibrariesQuestions about Compilers, Linkers, and Languages
Questions about the Run-time Environment
Questions about Applications
Questions about UtilitiesHardwareMy 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 FirmwareWhat is stored in the flash memory on the motherboard?
The Operating SystemWhat 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:
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 ProblemOn 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:
You can enable traps using e..g, echo 0 > /proc/sys/mm/alignment 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?
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):
NetworkingHelp! 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 & 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 LibrariesCompilers, Linkers, and LanguagesHow 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:
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:
Recommended linker flags: none for elf. 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:
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 arg5ldmea 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. CompilersWe 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 LibrariesAlthough 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 EnvironmentWhat 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. ApplicationsHow 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:
Note that we do not recommend using aout unless you need it. If you want both simultaneously:
UtilitiesWhat 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