Frequently Answered Questions

The use of the command ntpdate as instructed in the installation instructions will automatically set the current date and time if you have a network connection.

                        bash# ntpdate -b time.apple.com
                        22 Mar 09:32:47 ntpdate[31492]: step time server 16.11.0.58 offset -0.003510 sec
                    

If you do not have a network connection, or you do not have a time server available, then you can use the venerable unix date command:

                        bash# date 032214352002
                        Fri Mar 22 14:35:00 UTC
                    

This is currently rather involved.

Edit the file /etc/hostname

We recommend using ssh instead of telnet. The telnet protocol is extremely insecure, passing passwords across the in the network in the clear.

• One way to transfer files to the iPAQ is to use zmodem. The command to receive a file via zmodem is rz and the command to send a file viz zmodem is sz. These are provided by the lrzsz package.

  See the Section called Transferring files ot the iPAQ using zmodem for a more detailed description of how to do this.

• wget
• scp

If you are using minicom on the host PC, make sure that the lrzsz package is installed. It is not installed by default. The minicom does not give any indication of error if you attempt to use a file transfer command that does is not installed.

First, make sure that the login prompt was not obscured by other console messages. If I have a pcmcia or CF sleeve on when it boots, then messages from cardmgr often make it difficult to see the login prompt. I often just type enter to see whether it is really wedged or not.

If one of the startup actions is hanging, preventing you from logging in to fix the problem, you can bypass that by specifying a different init value on the kernel commandline. In the bootldr:

	    boot> set linuxargs "noinitrd init=/bin/sh console=ttySA0 root=/dev/mtdblock/1"
	    boot> boot jffs2 
	  

Thanks to Lars_G for this one:

boot> set linuxargs "noinitrd init=/sbin/getty ..." boot> boot jffs2

This message indicates that the specific IDE driver (e.g., ide-disk) has not been loaded but an operation for the drive has been queued. It is not a problem. The ide-disk module is automatically loaded when the device is opened. No operations are performed on the drive until it is opened.

This means that the DHCP client (pump) failed to get an address from a DHCP server. One cause of this is no DHCP server on the network.

See about editing /etc/pcmcia/network.opts if you are using static IP addresses.

You can use the Non-Volatile RamDisk (NVRD) driver to reserve a fraction of DRAM that can be used to mount a filesystem and that is preserved across reboots.

See the NVRD driver and NVRD usage page.

Remember, even in PocketPC it is only persistent as long as the iPAQ has power.

If the iPAQ is displaying anything on the screen, then it is not a brick. If it responds on the serial port, then it is not a brick.

See Q: 2.1.. Once you are at the boot> prompt, you can modify the parameters passed to the kernel at boot time, install a new Linux distribution, or install PocketPC.

If that does not work, try turning off power to the unit with the the Section called iPAQ ``Hard Reset'' Switch. Leave it off for a minute, then turn it back on and try again.

If that still does not work, contact the appropriate mailing list for your hardware.

On an iPAQ: Press and hold the center of the joypad, push and release the recessed reset button, wait a second, then release the joypad. You should see the bootldr splash screen.

There are some exceptions to this. Early versions of the bootldr do not support the splash screen. A few transitional versions of the bootldr required the same process but using the suspend button.

Resetting in this way also suppresses evaluation of the bootldr params. See the Section called Suppression of Params Evaluation

Here is the short answer for how to use the bootldr to install a jffs2 image that currently resides in a VFAT filesystem. When you buy a CF flash card or microdrive, it is formatted with VFAT. Use the ver command to verify that the bootldr is recent enough to support this.

	      boot> sleeve insert
	      boot> pcmcia insert
	      boot> vfat mount 0
	      boot> vfat ls rootimg.jf2
	      boot> vfat read 0xc0000000 rootimg.jf2
	      boot> program root 0xc0000000 0x[NUM]
	    

where NUM is the last number reported in the output from vfat read or as the size reported by vfat ls

Note that the bootldr currently only understands the 8.3 filename format used by the original FAT filesystem. Short mixed-case filenames, such as zImage, are represented as long filenames. They appear as zimage~1 in 8.3 format.

See the Section called Cloning an iPAQ Installation for more information on this topic.

The bootldr cannot currently create files on a vfat filesystem, although it can update the contents of files and adjust the lengths of files. This makes it somewhat inconvenient to save copies of flash to a raw partition on a CF card.

Here is a sequence of commands for saving a copy of flash into the first IDE partition on a CF or PCMCIA card.

	      boot> sleeve insert
	      boot> pcmcia insert
	      boot> ide write_partition 0x54000000 0 0x1fc00000
	    

The size of the root partition is 0x0fc00000 for a standard H3600 or H3100, 0x1fc00000 for a H3700, or 0x1f800000 for an H3800.

Note that this will erase any filesystem that might have been saved in this IDE partition.

This can be restored with the following sequence of commands:

	      boot> sleeve insert
	      boot> pcmcia insert
	      boot> ide read_partition 0xc0000000 0 0x1fc00000
	      boot> program root 0xc0000000 0x1fc00000
	    

See the Section called Cloning an iPAQ Installation for more information on this topic.

The portions of the bootldr written by Compaq are covered by a BSD-like license that let you do anything you want with the source, including distributing modified versions.

Other portions of the bootldr, including the JFFS2 support are covered by the GPL. If the bootldr is built and distributed with these portions, then the bootldr is covered by the GPL.

Use zmodem to transfer files to Linux on the iPAQ over the serial port, then use ipkg to install the local file.

              bash# ipkg install foo.ipk 
            

Use the ipkg info command:

              sh-2.03# ipkg info 8390-modules-2.4.18-rmk2
              Package: 8390-modules-2.4.18-rmk2
              Version: hh1
              Depends: kernel-modules-2.4.18-rmk2
              Status: install ok installed
              Section: kernel
              Architecture: arm
              Maintainer: Jamey Hicks (jamey.hicks@compaq.com)
                MD5sum: 178d26895553ce736a8b27f6ad8a34d4
                Size: 6086
                Filename: ./8390-modules-2.4.18-rmk2_hh1_arm.ipk
                Description: 8390 modules for kernel 2.4.18-rmk2
                8390 network device driver.
            

There is not a utility to recurse the dependences in the way you are asking for, but you can fetch the Packages file from the release or feed and do it yourself. You can also use the ipkg command.

              sh-2.03# ipkg status | grep Depends | grep input-modules
              sh-2.03#
            

It appears that none of the installed packages depends on input-modules.

If we repeat that query for the 8390-modules-2.4.18-rmk2, we find:

              sh-2.03# ipkg status | grep Depends | grep 8390-modules
              Depends: kernel-modules-2.4.18-rmk2, packet-modules-2.4.18-rmk2, pcmcia-modules-
              2.4.18-rmk2, 8390-modules-2.4.18-rmk2
            

Looking at the full Packages file or full output from ipkg status, we find that the pcnet-modules-2.4.18-rmk2 ipkg depends on it.

A task package is an iPKG whose sole purpose is to depend on all the other packages necessary for that task. A task iPKG contains no data files, only control files. A task iPKG might just contain the control file.

For example, the task-x iPKG contains the following control file:

Package: task-x Priority: optional Version: 0.2 Architecture: arm Maintainer: Alexander Guy (a7r@andern.org) Section: misc Depends: xserver-tiny-h3600, xbase-clients, xfonts-base, xfonts-75dpi, xfonts-ttf, ion, rxvt-aa, xcalibrate Description: Task package for a basic X system.

Not currently. It is likely that recursive remove and upgrade options will be added in the future, which will make management of task-foobar packages easier.

Not currently. It is likely that recursive remove and upgrade options will be added in the future, which will make management of task-foobar packages easier.

[David Woodhouse on irc.openprojects.net #handhelds.org ] [1]

A long press of the suspend button toggles the backlight.

See the Section called Keyboards HOWTO.

This answer is from the wiki

After xkbd is installed (it is a standard part of Familiar), edit /etc/xbkd. Each configuration line is either blank, a comment starting with two number signs, a row split, or a key definition.

A row split is a line with a single period.

Key definitions contains four items:

1. lowercase displayable text

2. uppercase displayable text

3. lowercase X11 keycode to generate when pressed

4. uppercase X11 keycode to generate when pressed

For example, a line to handle the 8 key looks like this:

8 * 8 asterisk

There is a sample layout at xkbd.fitaly

The application should access the keyboard through the standard Linux console interface. An application can connect to the current console by opening /dev/console or /dev/tty0.

No. The /dev/touschscreen/key interface on the ipaq is nonstandard and is not demultiplexed between applications. The application should access the buttons through the standard Linux console interface.

Andrew Christian wrote the following messages, from which this section was quoted: All you ever wanted to know about iPAQ batteries.... (March 14, 2002) and All you ever wanted to know about iPAQ batteries.... (March 15, 2002 9:16am)

Let me explain how the iPAQs read their batteries:

The iPAQ battery pack contains a Lithium-X battery and a Dallas Semiconductor Lithium battery monitor chip which measures the current voltage level of the battery pack, the current flowing in/out, the battery temperature, and the accumulated charge/discharge of the battery. It also comes from the factor with some basic calibration data, information about the battery chemistry/manufacturer, and a little bit of on-board storage space. You talk to the battery monitor chip over a one wire interface.

Option packs that have batteries may use either physically the same battery pack (E.g. the Compaq PCMCIA sleeve), or their own implementation (like the Nexion).

There have been a few different battery variants included in iPAQs over the last few years. The stored energy has gradually risen and (I believe) the chemistry has changed at least one (from Li-ion to Li-polymer). Changes to the chemistry and manufacturer result in slightly different voltage levels read by the battery monitor chip...the older 3600 series seems to max out at about 4.5 volts - the batteries in the 3800 seem to max out at 4.3 volts.

In theory, you can extract lots of useful information from the battery pack and use that to provide precise and accurate calibration data to the end user. Dallas Semiconductor has a documented system called "FuelPack" (check their website) which describes their recommended proceedure for doing exactly this.

In practice, the original iPAQ series (3100, 3600, 3700) and the battery-equipped expansion sleeves (the PCMCIA, the Dual slot, and things like the new Nexion) hide the Dallas Semiconductor battery monitor behind a microcontroller. The original iPAQ series (3100, 3600, 3700) has an Atmel microcontroller next to the StrongARM processor. The Atmel microcontroller talks to the battery, controls charging, and returns a (very) limited set of information about battery status to the StrongARM. If you look in the h3600_micro.c file, you'll see that the information given to the StrongARM (and hence to Linux) consists entirely of (a) battery chemistry, (b) a rough idea of status [critical, low, high, charging...], and (c) measured voltage [in units of 4.88 mV/division].

Option pack sleeves with batteries have their own microcontrollers and return similar information to the StrongARM - in their case, (a) battery chemistry, (b) status, and (d) an approximate percentage of battery used. In theory they are supposed to return measured voltage as well, but this doesn't seem to have been implemented.

The 3800-series iPAQ does battery control entirely on the StrongARM, so we can read the battery monitor chip directly. If you have a 3800, you can "cat /proc/asic/battery" and see a direct dump of the information on the battery monitor. However, the information from the option packs is still limited.

To calculated battery percentage used and time remaining is a challenge. On the 3100/3600/3700, we try to estimate this based on some rough calibration data provided by a user who let his battery discharge and wrote down the voltage levels he saw as it went down (I'm sorry, I can't remember his name. It's in the source file). As you might guess, if you have an iPAQ with a different battery chemistry, you're not going to get the same discharge characteristics.

The 3800 is a little more accurate because we have direct access to the battery monitor. But it's still based on a single calibration curve (look at h3600_asic.c to see the curve).

In both cases the time remaining is a _gross_ estimate ... something like 5 hours total time multiplied by calculated percentage of battery remaining.

- Andrew Christian

1. The original iPAQ series (3100, 3600, 3700) does not have a Dallas Semiconductor battery monitor. You can tell from my last message just how long it's been since I looked at a 3600 schematic. The Atmel microcontroller on the 3600 acts as the battery monitor.

2. To the best of my knowledge, no iPAQ has shipped with anything other than a LiPolymer battery. However, some older iPAQ models have incorrectly reported the battery chemistry in the firmware, and there are expansion packs that contain non-LiPolymer batteries.

   Let me draw a picture of the interconnections:

   iPAQ 3800 ========= StrongARM | | Memory-mapped I/O | Custom ASIC ------------------------------- | \ \ | One-wire | GPIO | SPI to option pack | interface | ADC (charge current) | | | | | TI Battery Charger Option pack Microcontroller | / | Dallas Semi / | Battery Monitor Option pack battery | LiPolymer battery

   iPAQ 3100/3600/3700 =================== StrongARM | | UART | Atmel Microcontroller---------------------- | \ \ | ADC for | GPIO | SPI to option pack | voltage | ADC (charge current) | | & temp | | | TI Battery Charger Option pack Microcontroller | / | Sense resistors | and protection circuit Option pack battery | LiPolymer battery

You may have a different type of battery chemistry, or your battery is running at a different temperature (that affects discharge), or your battery is simply older than the one used for the original calibration data.

Answer: The measured voltage of the battery is influenced by charging. When charging, you're pushing electrons in and that pushes up the voltage. When you unplug, there is an immediate drop. We try to compensate for that in the calibration curve, but it's just an offset.

1. Generate your own calibration curves for your iPAQ and post them. Make sure you provide iPAQ model, battery chemistry, etc.

2. Do some kernel hacking so you can plug in calibration curves. Or put the calibration curves in the apm program. Don't forget, we need to calibrate the option packs as well as the iPAQ, and some people have more than one option pack.

3. Do some kernel/apm hacking so your iPAQ learns its discharge characteristics over time, so you can get more accurate power profiles.

4. Grab the FuelPack spec from Dallas Semiconductor and look at implementing it in the kernel for the 3800-series.

5. Address the power-management in the kernel intelligently for the 3800 series. At the moment we're making some gross assumptions about battery charging. We really should be monitoring temperature and allowing charging while asleep on the cradle.

Not really. I have the basic specs, but not the details. And we can't change the behavior - the Atmel firmware is not open-source. Battery charging is an area where Compaq spends a great deal of engineering effort and testing. If you do it wrong, bad things can happen inside your computer.

3100/3600/3700: No. 3800: Yes.

We strongly recommend building an expansion sleeve: http://csa.compaq.com/CSA_For_iPAQ_Developers.shtml. A simple expansion sleeve requires very little more than a PIC serial EEPROM (for identification) and a few resistors/caps to pull up the correct lines. The Compaq web site / developer CD has detailed information and sample schematics.

All you ever wanted to know about iPAQ batteries.... (March 15, 2002 10:15am)

The cell voltage should be the same. The reading circuits are different. Both the Dallas Semi battery monitor and the Atmel microcontrollers have 10 bit ADC, but the circuits leading up to the ADC is quite different. The Dallas is probably the most accurate, being co-located with the battery. The Atmel has long leads, a voltage divider (to bring the 4.2 V battery signal down to 3V) and associated circuitry. To make a long answer short: on the 3600, you're seeing the voltage as interpreted by the Atmel micro. On the 3800, you're seeing the voltage as interpreted by the Dallas part. They aren't scaled the same way, so the numbers differ.

Yes.

The hardware (Philips UDA1341 codec) only supports stereo. However, we have modified the driver to support monophonic sound.

Install the orinoco_cs modules.

              sh# ipkg install orinoco-modules-2.4.16-rmk1
            

Although the orinoco_cs driver will often work with a Prism2-based WLAN card, it does not seem to support setting the keys for 128-bit WEP with those cards. Use the wlan-ng driver described above.

              sh# ipkg install wlan-ng-2.4.16-rmk1
            

The prism2_cs driver is configured by the file /etc/pcmcia/wlan-ng.opts

If your card uses the orinoco_cs, then edit the file /etc/pcmcia/wireless, setting the environment variable ESSID to the network name. If ESSID is unset, the card will automatically bind itself to the strongest access point.

              ESSID="my access point name"
            

If your card uses the prism2_cs, then edit the file /etc/pcmcia/wlan-ng.opts, setting the environment variable DesiredSSID to the network name.

              DesiredSSID="my access point name"
            

Although the orinoco_cs driver will often work with a Prism2-based WLAN card, it does not seem to support setting the keys for 128-bit WEP with those cards. Use the wlan-ng driver described above.

This behavior can be configured by editing the file /etc/pcmcia/ide.opts. Here is an example:

# ATA/IDE drive adapter configuration
#
# The address format is "scheme,socket,serial_no[,part]".
#
# For multi-partition devices, first return list of partitions in
# $PARTS.  Then, we'll get called for each partition.
#
case "$ADDRESS" in
*,*,*,1)
    #INFO="Sample IDE setup"
    DO_FSTAB="n" ; DO_FSCK="y" ; DO_MOUNT="y"
    FSTYPE=""
    #OPTS=""
    MOUNTPT="/mnt/hda"
    ;;
*,*,*)
    PARTS="1"
    # Card eject policy options
    NO_CHECK=n
    NO_FUSER=y
    ;;
esac
          

Setting the variable DO_FSTAB tells cardmgr not to insert this into /etc/fstab. Setting the variable DO_FSCK tells it to do a filesytem check. Setting the variable DO_MOUNT tells it to mount the filesystem and MOUNTPT tells it where to mount it.

One thing that is easy to miss is updating the second clause, which sets PARTS to a string containing the partition name to mount.

If cardmgr is trying to load the driver memory_cs, then almost certainly it is not properly identifying the card. In a few specialized instances, memory_cs is the right driver.

This problem seems to be due to the PCMCIA socket (e.g., the Compaq single pcmcia sleeve) having a slower bus than allowed by the PCMCIA specification. As of Linux version 2.4.18-rmk3-hh2 or newer, this timing can be adjusted before a card is inserted. Here is how to add 100ns to each bus operation:

	    bash# cardctl eject
	    bash# echo 100 > /proc/sys/bus/pcmcia/timing_increment_ns
	    bash# cardctl insert
	  

ipkg install ipv6-modules-2.4.16-rmk1 depmod -a modprobe ipv6

That's all there is to it.

Change the following line in /etc/init.d/qpe from:

              export QWS_DISPLAY=Transformed:Rot270:0
            

to

              export QWS_DISPLAY=Transformed:Rot90:0
            

For the most part,