Alex's Handheld Tinkering

Kernel changes for USB host

2008-11-06T19:41:00.006+11:00

Oh, in case anyone wants to experiment with this, just add this to your machine file (arch/arm/mach-pxa/palmXX.c). I'm not going to post binaries or even a full patch now as this is still pretty experimental and you'll need to compile your own kernel with the drivers for whatever you want to connect anyway. Add the following headers, functions and a call in machine_init(). This should work on most of the PXA270 Palms.

#include <mach/pxa27x-udc.h>
#include <mach/ohci.h>

/*
 * USB Host (OHCI)
 */
static int palmt650_ohci_init(struct device *dev)
{
       UP2OCR = UP2OCR_HXS | UP2OCR_HXOE;
       UHCRHDA |= UHCRHDA_NOCP;
       UHCHR &= ~(UHCHR_SSEP2 | UHCHR_SSE);
       return 0;
}

static struct pxaohci_platform_data palmt650_ohci_platform_data = {
       .port_mode      = PMM_NPS_MODE,
       .init           = palmt650_ohci_init,
};

static void __init palmt650_init(void)
{
        ...
        pxa_set_ohci_info(&palmt650_ohci_platform_data);
}

You'll need to enable OHCI under USB host. I have been disabling USB gadget (client) support and I haven't tested what happens if you have both host and client enabled. I assume though that host probably takes precedence.

The easiest way to get a full speed device to enumerate is to plug the device in and use the "USB console" menu in Cocoboot before starting Linux. That'll turn on the USB pullups which will trick Linux into realizing there's a full speed device connected. You can also try turning on/off the pullups directly in Linux (GPIO 114 on the Treo 650). You can use gpio-val.c to control them within Linux (or a kernel module like GPIOed if you're using our older linux-hnd kernels).

Plus, someone was asking for a copy of the rootfs I use. For development work I just have an SD card with Debian/armel installed on it. This is not completely suitable for mobile devices but Debian has a ton of precompiled packages which you can just install with apt-get. This saves mucking around compiling. A few weeks ago I wrote some instructions in the forum including a tarball of a bare bones Debian image. I just install gcc, git-core and such on there and compile stuff on the device itself must of the time.

First attempt at a wifi dongle

2008-11-06T19:15:00.006+11:00

...was unfortunately only partially successful. I picked up a few cheap link cables and the smallest USB wifi dongle I found in a brief search. The wifi dongles turned out to be based on the Zydas ZD1211 chipset (actually rebranded as Atheros AR5524) which is excellent for two reasons: they have drivers in the mainstream Linux kernel and they can run fine off a 3.3V power source. I went for the cheap after-market link cables (actually retractable ones) as they have easy to solder connectors which have all the pins.

I chopped the ends off one of each and soldered the GND, USB+ and USB- appropriately. For the dongles' power supply I tried the "EXT_POWER" pin on the multiconnector, which is supposed to be for powering accessories. To make Palm OS activate the power pin, tie the serial pins on the multiconnector to ground. In Linux on the Treo 650 you can toggle it with GPIO 37.

The dongle was detected fine by Linux and the driver sucessfully uploaded the firmware. Unfortunately on powering up the radio though the device appears to hang and the driver starts reporting timeouts. My guess was the "EXT_POWER" pin cannot supply enough current. To check this, I used my usual trick of stealing power from a molex connector in my PC. Sure enough, it started working fine and I was able to scan and connect to a network and then SSH in from my PC.

This is unfortunate as I'll probably end up having to add a battery pack of some sort. It's much neater a tidier without one. Oh well, probably a smallish Polymer Lithium-ion battery would be suitable. However, the fact that the device enumerates and can have the firmware uploaded while powered by "EXT_POWER" means it may be suitable for lower power USB devices, like flash drives or mice.

Yes, I have heard of SDIO, but it's more fun this way.

USB host mode on the Treo 650

2008-10-17T19:47:00.007+11:00

Previously I'd always just assumed the USB host pins were separate from the USB client ones, so we wouldn't be able to use the USB port on the multiconnector as a host. Turns out I was wrong. Sleep_Walker pointed out that the PXA27x's USB client pins can the routed to the host controller. I had to try it. So I cut the USB connectors of an old dead motherboard with a jigsaw and soldered the D+ pins and D- pins of each connector respectively together. I then ran +5V from my PC because the Treo can't supply it. Any +5V source should do, so a battery pack or some kind of charge powered by the treo's 3.7V output would also work, the PC was just the closest handy source. I then configured USB port 2 in host mode and powered it up.

UP2OCR = UP2OCR_HXS | UP2OCR_HXOE;
UHCRHDA |= UHCRHDA_NOCP;
UHCHR &= ~(UHCHR_SSEP2 | UHCHR_SSE);

I found low-speed devices (like old mice) just work, but full-speed (USB1.1+ devices) fail to detect. There seems to be an extra strong pull-down on the USB+ pin, probably as part of the USB client hardware. To get around this we can turn on the Treo's own usb client pullups and trick itself into realising there's a full-speed device attached. ;-) Anyway here's the result, a USB keyboard (with builtin hub) and mouse controlling the Treo directly:

Virtually every USB device with a Linux driver I've tried works. I'm looking to get a USB wifi dongle. Not sure it'll be so easy to mount inside as the Eee PC upgrades are. ;-) Update: Sleep_Walker has now tried the same thing on the 680. He reports that there's no pulldown problems on the 680 so full-speed devices detect correctly without any hacks. He also tried a slightly easy way of doing it, all you need is standard powered USB hub (to supply the +5V) and a USB gender changer, no soldering required.

Success: Two-way phone call with Treo 650 in Linux

2008-10-10T20:00:00.006+11:00

Now that I have a VOIP account that can make unmetered calls to mobiles I decided to try having a play with getting two-way phone calls working from Linux on the Treo 650. I turned on the phone part in Palm OS, booted this kernel and reset the power on the gsm module with:

echo 0 > /sys/devices/platform/palmt650-pm-gsm/power_on
echo 1 > /sys/devices/platform/palmt650-pm-gsm/power_on
echo 1 > /sys/devices/platform/palmt650-pm-gsm/wake

I then fired open minicom and opened /dev/ttyS0 at baud 460800 without flow control. I then connected the modem to the network and entered my subsidy unlock pin:

AT+CFUN=1
AT+CPIN="xxxxxxxxx"

Once connected, I called my phone via VOIP and then answered with the ATA command:

RING
RING

ATA
OK

At that point I opened up a few terminal windows and started fiddling with ALSA. I first started playing some white noise so I could heer when I started transmitting:

cat /dev/urandom > /dev/dsp

I discovered you can divert PCM to be transmitted by the phone using:

      Master Mono: Enable, set transmit volume
              PCM: Enable, set PCM volume
PCM Play to Phone: Enable to route PCM signal to the phone module

After some more fiddling I routed the microphone to the phone. The labeling of the Mic controls in the ALSA driver is rather strange but here are the key settings:

      Master Mono: Enable, set transmit volume
Mic Select Source: mic1=handset, mic2=headset
            Mic 2: Selected mic volume
   Mic 1 to phone: Enable/disable handset mic 
   Mic 2 to phone: Enable/disable oheadset mic
   Mic 20dB Boost: Useful in speakerphone mode, you can talk from quite a distance.

Mic 1: [irrelevant?]
Mic select:  [irrelevant?]

After that I managed to get the incoming audio going out the handset earpiece with these settings:

         Master: Enable, earpiece volume
Master Left Inv: Enable
          Phone: Seems you don't need to unmute, but need to set volume.
Phone to Master: Enable
            Aux: Set a high volume (weird stuff happens if low)
    Out3 LR Mux: Master Mix (mislabeled, it's actually out2)

I've made an ALSA state file for working two-way phone audio with the handset.

Hang on palmt650 first printk

2008-08-14T21:16:00.001+10:00

Locks up in kernel/printk.c with time enabled:

asmlinkage int vprintk(const char *fmt, va_list args)
{
...
                        if (printk_time) {
                                /* Follow the token with the time */
                                char tbuf[50], *tp;
                                unsigned tlen;
                                unsigned long long t;
                                unsigned long nanosec_rem;

                                t = cpu_clock(printk_cpu);
                                nanosec_rem = do_div(t, 1000000000);
                                tlen = sprintf(tbuf, "[%5lu.%06lu] ",
                                                (unsigned long) t,
                                                nanosec_rem / 1000);

                                for (tp = tbuf; tp < tbuf + tlen; tp++)
                                        emit_log_char(*tp);
                                printed_len += tlen;
                        }

Palm Tungsten C wifi in Linux

2008-04-18T23:36:00.006+10:00

Just noting this before I forget it. Use fc447e3213efb31cb16b5d9a2b0ebb77fbafd131 from git://git.hackndev.com/linux-2.6 with the defconfig. You'll need to load standard RAM prism firmware (pm010102.hex and rf010804.hex should work), but prism2_srec has to be patched as the production data area ("PDA") has an invalid CRC. A patch like this should do the trick:

diff -ru hostap-utils-0.4.7/util.c hostap-utils-0.4.7-hacked/util.c
--- hostap-utils-0.4.7/util.c   2004-02-14 18:50:12.000000000 +0000
+++ hostap-utils-0.4.7-hacked/util.c    2008-04-18 21:32:17.000000000 +0000
 -372,7 +372,7 @@
 
        fclose(f);
 
-       return parse_wlan_pda(pda_info, 0);
+       return parse_wlan_pda(pda_info, 1);
 }

Add to /etc/pcmcia/hostap_cs.conf (or equivalent)

card "PRISM ISL37101P-SSF Adapter"                                                                                                 
  manfid 0x000b, 0x7110
  bind "hostap_cs"

Then start the "cardmgr" daemon. It should detect and bind the card to hostap_cs, so you can see it as "wlan0" and "wifi0" in "ifconfig -a". You should then be able to load firmware using something like:

prism2_srec -gs wlan0 pm010102.hex
prism2_srec -gp wlan0 pm010102.hex
prism2_srec -rp wlan0 rf010804.hex

You can then configure and use as normal:

ifconfig wifi0 up
ifconfig wlan0 up
iwconfig mode wlan0 managed
iwlist scan
...or whatever

Hello! Hello?!

2007-07-31T23:40:00.000+10:00

Well there's been much progress. I've basically finished off the kernel driver aside from waking the CPU from suspend upon an incoming call. Also adding basic BCM2132 to gsmd turned out to be a fairly simple procedure aside from some strangenesses of the platform. See the gsmd list for my patches. So now we can make and receive calls and SMS with the only remaining problem being routing of audio.

I've setup a skeleton SoC audio driver. This is enough after some fiddling with alsamixer to at least be able to hear what the other person says but outgoing sound doesn't work. The diagram to the left shows how I think things are wired up and should be of use to anyone trying to understand the huge number of alsamixer controls. At the moment I'm trying to get OE building an OpenMoko image with MACHINE=palmt650. :-)

Wake up!

2007-07-27T22:35:00.000+10:00

I've been playing around with the Treo's GPIOs and I've finally discovered how to prevent the GSM module from going to sleep! Setting GPIO 57 high seems to force the module to stay awake. I also discovered GPIO 11 is a wake signal from the GSM to the CPU. This GPIO has a rising edge whenever some message is sent (or is ready to be sent) .

Also, while CTS seems to be always set when the GSM is powered, it will queue data while RTS is deasserted. So while in sleep we should probably deassert RTS, wait for GPIO 11 to awaken us (on eg incoming call) and then assert RTS to receive our data.

Trying to put all this information into a driver is going to be interesting. I wonder how pluggable the PXA serial driver is. Maybe I'll have to resort to just keeping the modem constantly awake for now.

Update: On first glance set_txrx() may do the trick.

Ring Ring

2007-07-22T22:06:00.001+10:00

I figured out the trick to making calls with the GSM modem in the Treo 650, you just need to give it the subsidy unlock code with AT+CPIN="xxxxxxx". I also found something else interesting:

AT+CFUN=6
The handset is in Calibration Mode:
                                   

********Main Menu:********
                          
0  HELP                   
1  ARFCN arfcn
2  MODULATION 0=GMSK/1=8PSK
3  DACVAL FREQ_DAC_ZERO    
4  ALL_RAMPS           
5  RAMP_SELECT txlev(0-19)
6  AGC rxlev              
7  GSYS band step
8  START 0=norm/1=rach
9  STOP               
10 OAKWR addr val
11 ARMWR size addr val
12 ISPCS 1=TRUE       
13 OAKRD? addr 
14 ARMRD? size addr
15 RXLEV?          
16 GSYS? band index
17 MULTISLOT       
18 EN_AUTO_SIM 
19 L1 TEST     
20 EDGE/GPRS TEST 
21 TXDB_WRITE Row(0-7) [v0 v2 v3 ....v15]
22 CHANGEMODE mode :0=normal,1=cal,2=download

It doesn't respond to commands after that. I guess it may be expecting some binary protocol.

I'm still having the problem of after receiving *MRDY: 3 after powering on the radio the connection seems to freeze up. Messages are still received it's just outgoing keypresses that seem to be ignored. I found if I hold down a key long enough it'll eventually receive it and I can issue commands like that. Something strange must be going, perhaps there's some time window which it will receive in.

If I pull out the SIM the device will drop to MRDY: 5 and the AT console becomes usable again. Curious.

Update: Ah. I've found references to something called cyclic sleep mode. So perhaps the baseband goes to sleep for some cycles and then wakes up and can receive commands again.

A cure for insomnia

2007-07-21T18:02:00.000+10:00

Our qemu tree has finally made itself really useful. By running the Treo's bootloader inside it I was able to figure out how to get suspend to ram working properly. It turns out to be really easy, all you have to do is set PSPR to some non-zero value and put the code you want to run on resume at 0xa000000.

Also after a lot of messing with qemu, Sergey Lapin and I also figured out how to resume Zire 72. Probably. It's untested on a physical device yet. On going to sleep you need to point PSPR at the physical address of the structure below. Set resume_addr to the argument passed into pxa_ll_pm_suspend(). It may be the same or similar for other devices with the "SmallROM" bootloader (such as T3).

static struct {                                                                                                                                                                       
        u32 magic0;             /* 0x0 */                                                                                                                                             
        u32 magic1;             /* 0x4 */                                                                                                                                             
        u32 resume_addr;        /* 0x8 */                                                                                                                                             
        u32 pad[11];            /* 0xc..0x37 */                                                                                                                                       
                                                                                                                                                                                      
        /* bootloader will configure co-processor 15 with these values: */
        u32 arm_control;        /* 0x38 */                                                                                                                                            
        u32 aux_control;        /* 0x3c */                                                                                                                                            
        u32 ttb;                /* 0x40 */                                                                                                                                            
        u32 domain_access;      /* 0x44 */                                                                                                                                            
        u32 process_id;         /* 0x48 */                                                                                                                                            
} palmz72_resume_info = {                                                                                                                                                             
        .magic0 = 0xb4e6,                                                                                                                                                             
        .magic1 = 1,                                                                                                                                                                  
                                                                                                                                                                                      
        /* reset state, MMU off etc */                                                                                                                                                
        .arm_control = 0,                                                                                                                                                             
        .aux_control = 0,                                                                                                                                                             
        .ttb = 0,                                                                                                                                                                     
        .domain_access = 0,                                                                                                                                                           
        .process_id = 0,                                                                                                                                                              
};

How to bake a loopy initramfs

2007-07-21T10:33:00.000+10:00

If you follow Paul Sokolovsky's blog you'll know we've been developing some recipes for building initramfs images using OE. I won't repeat the details here, check Paul's blog for an overview but I will describe the loopback booting module (since he hinted so politely).

First, why would you want to boot off a loopback device? The most difficult thing for new users coming to Linux is probably installing it. You have to understand how to partition a disk and hope you don't accidentally wipe all your data in the first place. To make things quick for testing and easy for new users, over at Hack&Dev we usually release a boot pack which contains a kernel zImage, an initramfs and a root filesytem image. The user just unpacks all these files into the root directory of a memory card, installs Cocoboot and taps boot, no dangerous and confusing partitioning required. So after Paul showed me his nifty method for building an NFS booting initramfs I couldn't resist adding another recipe that you can use for loopback booting. We later went on to merge them into a nice modular system that you can plug in whatever boot methods you need.

Okay, how to use it? First build an initramfs image with the initramfs-module-loop package installed. The easiest way to do this is just bitbake initramfs-image. Next pop the initramfs in the appropriate place for your bootloader (or compile it into the kernel) and add to the kernel command-line something like

root=/dev/loop looproot=/dev/mmcblk0p1:rootfs.ext2

The initramfs will note the root option and start the loopboot module which will mount partition one of the MMC card (mmcblk0p1), then loopback mount the rootfs.ext2 and finally switch_root to it. The full syntax for the looproot option is

looproot=[device:]file[:offset]

device is the device file resides on, file is a filesystem image and offset is the offset into the image to mount from (see losetup(8) manpage, the -o option). In theory you should be able to include multiple looproot options and to allow recursive mounting (ie an image within an image), but this is untested. So to boot an image off the LifeDrive's data partition you might use something like:

root=/dev/loop
looproot=:/dev/hda:91814912
looproot=rootfs.ext2

Note I'm giving a block device as the file argument here. This is because Palm OS writes an invalid partition table (their partition start/end offset calculations are wrong) to the HDD so we have to use a loopback device to manually specify the offset into the disk. The second looproot option then will mount the filesystem image.

Treo650 gpios

2007-07-14T13:25:00.000+10:00

Been doing some playing with GPIOs Clearing outputs: 23 turns of backlight, LEDs and causes palmos to think battery is dead. 24 turns off LEDs and causes palmos to think battery is dead. 25 as well... 79 - backlight power 114 - disables usb USB detect is in ASIC: bit 3 of register 0x36. High when disconnected.

Possibly power reg for T650 bluetooth

2007-07-09T12:35:00.000+10:00

BT on:

08000044: 001f00fa001800bc

BT off:

08000044: 001f00ff00180080
                        ^^

Writing the ff into 0x44 had no effect, but 0x80 into 0x48 killed the connection. :D

bit 2: no effect
bit 3: no effect
bit 4: breaks connection
bit 5: breaks connection

Bingo! I'd say 4 and 5 are BT power and reset (although which is which?). Overwriting 0x0 (RBR/THR) also kills the connection while powering down BTUART has no effect indicating it's definately connect to ASIC UART.

LifeDrive necromancy

2007-07-07T14:55:00.001+10:00

I've just had some success in bringing my poor LifeDrive back from the grave. While the HDD is still unusable due to a broken cable, I was able to get the Linux kernel to boot. I chopped the end off a Nokia DKU-5 data cable (USB -> TTL serial converter) and soldered it to some test points corresponding to the serial port on the LD's mainboard. You might be able to make out the tiny red wires in bottom-left corner of the photo. (The yellow stuff is Blu Tack, preventing things from moving around). By holding down the hotsync button and resetting the device, minicom at 115200 baud and no flow control on my PC gets me to the "Sandal" recovery console:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
  Sandal
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>

There are a couple of different commands you can use in the Sandal console but the important ones are "w" which reads and writes memory and "x" which executes code at the given address. I wrote a small script bin2sandal.py which converts a binary image into a series of Sandal commands enabling you to upload and execute a tiny bootloader I wrote in ARM assembly called quickload:

$ ./bin2sandal.py -d quickload.bin > /dev/ttyUSB0
...
>w 0xa00000e8=0xe5950000                                                                                                                                                              
0xA00000E8 : 0xE5950000                                                                                                                                                               
>w 0xa00000ec=0xe1a0f00e                                                                                                                                                              
0xA00000EC : 0xE1A0F00E                                                                                                                                                               
>x 0xa0000000                                                                                                                                                                         
Executing at 0xA0000000                                                                                                                                                               
Q?

The Q? prompt is quickload asking us to upload a kernel image. Well we'd better give it what it wants:

$ ./ql.py < zImage > /dev/ttyUSB0
Q?
  ql.py: uploading image...                                                                                                                                                           
G.............................

A little while later:
.............................D
Uncompressing Linux..........................................
........................... done, booting the kernel.                                                                                           
Linux version 2.6.21-hnd2 (ato@shion) (gcc version 4.1.2) 
#38 Sat Jul 7 12:50:15 EST 2007                                                                                   
CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f                                                                                                                       
Machine: Palm LifeDrive
... boot messages ...
# echo "I'm alive!"
I'm alive!                                                                                                                           
#

Unfortunately neither LCD nor MMC is working. I suspect this is because we normally rely on Palm OS to configure and power them up. I'll try overwriting the GPIO configuration with that from a working device later. The tools I used are in linux4palm/tools/serial-loader in Hack&Dev's SVN. Quickload should work on any PXA device, however you'll need to change the machine code that's passed to the kernel.

Testing Linux4Palm on qemu

2007-06-24T15:05:00.001+10:00

Anyone who's done some handheld hacking will know that testing on a physical device is usually a real pain. If the lack of decent input and tiny screen don't get to you then it's the tiring compile, copy-to-sd, put-sd-in-handheld, test, reboot, put-sd-back-in-pc, fix-code cycle. Today I'm going to explain how you can boot an unmodified linux4palm kernel zImage and rootfs inside the emulator qemu. First though a big thanks to Andrzej "balrog-kun" Zaborowski who as part of his work for OpenedHand added support for XScale processors to qemu and helped Marek and I get the Hack&Dev kernel working properly within it.

Installing qemu (with H&D patches)

Windows

It's your lucky day, we're making things easy. Grab these binaries and unzip them somewhere.

Linux and others

Today I committed the OpenMoko qemu tree with the palm machine support patches into H&D SVN. So the first step is to grab a copy of tree:

svn co https://hackndev.svn.sourceforge.net/svnroot/hackndev/qemu/trunk qemu-hnd
cd qemu-hnd

Alternatively get the version I wrote this guide against from the SF release page. Next you'll need to make sure you have gcc 3.x installed (look for /usr/bin/gcc-3.*). Unfortunately qemu will not build with gcc 4. Gentoo users can grab 3.4.6 with:

emerge -av =gcc-3.4.6-r2

Next we configure and make, choosing only to build the arm-softmmu target and using the 3.4.6 compiler:

./configure --disable-system --disable-user --target-list=arm-softmmu --cc=gcc-3.4.6
make -j3

Once the build is complete, you'll find a qemu-system-arm executable in arm-softmmu/.

Booting qemu

You can check which machines qemu supports using this command:

./arm-softmmu/qemu-system-arm -M ?

As of this writing the partially supported palms are palmld, palmt650, palmt680, palmtc, palmz72 and palmtx. Grab and unpack a bootpack for your desired machine. I'm going to use Stepan's Fire and Water 0.0.3 palmld bootpack as an example.

Now simply fire up qemu, telling it to use the kernel and rootfs from the bootpack. I'm omitting the initrd since the palmld bootpack expects to boot off the HDD but it's easier to boot it off the SD card in qemu. The psplash=false option is to disable the OE splash screen so that I can view the startup messages.

./arm-softmmu/qemu-system-arm -M palmld -kernel zImage \
    -sd Angstrom-opie-image-palmld-0.0.3-alpha.rootfs.ext2 \
    -append "root=/dev/mmcblk0 psplash=false"

It may take a while to boot so be patient. Eventually you should see the OPIE touchscreen callibration screen:

Since qemu doesn't currently support the palms' touchscreens press Ctrl+Alt+3 to get to the serial console. You can then login as root. Press Ctrl+Alt+1 if you want to get back to the graphical output.

Edit: More screenshots

Hack&Dev Upgrades

2007-06-23T13:03:00.000+10:00

Lately I've been discussing the problems with Hack&Dev. We have a major communication problem, the only way anybody finds out what's going on is if they jump on IRC and ask people. Even then it's not all that helpful. Since I've got a couple of weeks relatively relaxed at the moment, I thought I'd have a shot at this problem. See the forum for the current ideas. I'd mention Planet Hack&Dev here but you're probably reading this post from there. ;-) Email me alex (at-sign) hackndev (dot) com if you write or know of a Hack&Dev developer's blog (with RSS) that should be added to the planet.