Over the last couple of days I've been trying to use the BTUART on the 
Ballon 3 without much success. All I want is to be able to listen to bytes 
coming in on the BTRXD line. It appears that the PXA is actually holding 
this line low[1].

After some musing between Wookey, Peter Clifton and myself we decided that 
the appropriate GPIO Alternate Function Register were not being set 
anywhere[2]. After figuring out how and where they should be set, Wookey 
dutifully came up with a patch that adds:

        pxa_gpio_mode(GPIO42_BTRXD_MD);
        pxa_gpio_mode(GPIO43_BTTXD_MD);
        pxa_gpio_mode(GPIO44_BTCTS_MD);
        pxa_gpio_mode(GPIO45_BTRTS_MD);

to balloon_init() in linux/arch/arm/mach-pxa/balloon3.c. There is similar 
code in lubbock.c and idp.c, although they put the above lines in their 
foo_map_io() functions, which get called earlier. (I've also seen code that 
assigns the GPIOs to the HWUART RXD and TXD lines, but this was on a PXA255 
based board, and a 2.4 vintage kernel.)


Anyway - the patch does not appear to have achieved anything. The BTRXD line
is still being pulled down...

The kernel clearly thinks it has a BTUART. There is code in 
linux/drivers/serial/pxa.c that declares it, and the FFUART, BTUART and 
STUART are all listed during boot and all the /dev/ttyS* entries get 
mknod'ed. The BTUART isn't listed in /proc/interrupts until you actually 
try using it (cat /dev/ttyS1), and disappears again when you give up. The 
number of interrupts received is always zero.

Electrically, it looks like the line goes straight from the PXA, through a
68R resistor, and on to the outside world. It doesn't look like it goes
anywhere near the FPGA or anything else that could affect it.

Any suggestions? I'm a bit stumped.

  Paul.


[1] It's a bit fiddly trying to put a scope or meter on the line, and I can
    really only measure anything after the BTRXD line has gone through a 
    68R resistor pack. With nothing else connected, the line appears to be 
held
    at 0V. If I connect something (the TX line of the device that I'm 
trying
    to listen to - which I can measure quite easily) then the line is 
pulled
    up, but only to about 2.5V or less.

    A further puzzle is when the Balloon is first powered up, I can measure
    3.3V on the line, but this drops to 2.5Vish after about 3 seconds. This
    would suggest that it isn't an issue with any hardware, but is something
    software related in the bootldr and/or kernel.

[2] It may actually be being set in bootldr. There is code in there that 
does:
        ldr     r1, GAFR1L_Init_BALLOON3
        str     r1, [r0, #__OFFSET(GAFR1_L)]

    where GAFR1L_Init_BALLOON3 is defined as:
        GAFR1L_Init_BALLOON3:   .long GAFR1L_InitValue

    which in turn is computed in bootldr/asm-arm/arch-pxa/balloon3-init.h
    which lists all the GPIO Alternate functions and default directions -
    but it's hard to see what actually gets used and what doesn't with all
    the #ifdef everywhere...
    


Paul Fidler
-- 
Cambridge University Engineering Department | Tel: +44 1223 332816
Trumpington Street, Cambridge, CB2 1PZ, UK  | Fax: +44 1223 332662