Re: h5400/h5550 Bluetooth troubles (possible cause: wlan driver)

Hi,

I tried writing a patch to enable the HWUART for Bluetooth.
First, let me note that much of this code has been written already,
and it is either in -rmk or -pxa patches for higher versions of
the 2.4 kernels (than 2.4.19-rmk6-pxa1) or in the 2.6 kernels or, for
example, in the Gumstix project. It seems quite a shame to duplicate
all this effort.

One of the necessary steps to enable this is to change the following line
in include/asm-arm/arch-pxa/irqs.h from
#define PXA_IRQ_SKIP 8
to
#define PXA_IRQ_SKIP 7
(HWUART irqs are on the 7th bit of the interrupt register)

This has been done in the other patches I mentioned above (e.g. for 2.6).
However, I could not boot a 2.4.19-rmk6-pxa1-hh37.5-r4 kernel with just
the above modification. It gets stuck right before "Calibrating delay
loop..." (so very early in the booting). At first I wondered if that's a
problem of some objects not getting recompiled and having the old values
of the irqs hardcoded in, but I did a "make clean" and then rebuilt the
kernel, to no success.

What it's very strange is that I tried the same patch on Saturday (the
full patch including the modification above) and that booted fine, I tried
to hciattach to ttyS3 (where the HWUART is) but no bytes were received.
Later I figured out that I had forgotten to enable the clock line for
HWUART. I think it was a different kernel that I was working on Saturday,
but for a bunch of strange reasons (the codebase got deleted by accident),
I can't tell for sure which (maybe -r3 instead of -r4).

Anyways, if anyone has some suggestions, they're welcome,

Catalin

On Fri, 4 Mar 2005, Erik Hovland wrote:

> Keep plugging away! I will provide as much support as I can. Bluetooth
> is the one major non-working piece of the h5400 port.
>
> E
>
> > --- Catalin Drula <Catalin.Drula_at_imag.fr> wrote:
> >
> > > Hi,
> > >
> > > I am running Familiar 0.8.0 and 0.8.1 on h5400 and
> > > h5550 iPaqs. I have
> > > been running into trouble while using Bluetooth on
> > > these devices. The
> > > problem has been reported previously on this list.
> > > Basically what happens
> > > is that under any kind of sustained transfer rate
> > > through Bluetooth, bytes
> > > get lost between the host and the Bluetooth
> > > controller. The immediate
> > > effect of this is that of losing data, but worse,
> > > control data is also
> > > lost, which eventually leads to a loss of
> > > synchronization with the
> > > controller and effectively a "freeze" of the
> > > Bluetooth interface. Hard
> > > reinitialization is usually required to get it into
> > > a working state again.
> > >
> > > I have noticed that these lost bytes between the
> > > host and the controller
> > > are due to overruns on the UART (the BTUART, that
> > > is) of the PXA
> > > processor. These can be seen in
> > > /proc/tty/driver/serial. The immediate
> > > cause of the overruns seemed to be the irqs
> > > generated by the BTUART were
> > > not handled in a timely manner. It seems that the
> > > usb-ohci irqs (for the
> > > wlan interface) are to blame here. Once the wlan is
> > > taken down (ifconfig
> > > down) no more overruns occur. Sustained transfer
> > > rates (80kB/sec) can be
> > > acheived for extended periods of time (e.g. 12
> > > hours) with no errors. I am
> > > not sure why the usb-ohci (or wlan driver) is
> > > causing this. Even if the
> > > wlan is not actually connected to a network, but
> > > it's "up" (thus
> > > generating only few irqs) it still causes overruns
> > > at the BTUART.
> > >
> > > This seems to be the biggest problem of Bluetooth on
> > > the h5550 and h5400.
> > > Some issues and instability still remains however.
> > > For example, somewhere
> > > between every 30MB and every 300MB of data
> > > transfered, a sequence of bytes
> > > (e.g. 10 to 50) is not what was transmitted. The
> > > test program that I use
> > > is l2test from the bluez-utils package. The contents
> > > of the L2CAP packets
> > > that it sends consists of a small header and then
> > > the rest is filled with
> > > the value 0x7F. Like I said, very very rarely a
> > > small sequence of bytes is
> > > wrong on the receiving end (i.e. it is corrupted,
> > > having a different value
> > > than 0x7F) . At first I was leaning to blame this on
> > > the inherent error
> > > rate of the Bluetooth baseband (which can vary
> > > between 10^-6 and 10^-16
> > > depending on packet type and BER - bit error rate
> > > -), but there might be
> > > another cause (errors of transmission between the
> > > UART of the Bluetooth
> > > module and the UART in the CPU?).
> > >
> > > Another issue is that the Bluetooth chip in the
> > > iPaqs does not seem to
> > > like concurrent ACL connections. Generally speaking
> > > a single L2CAP
> > > connection is quite stable and performs well for
> > > extended periods of time.
> > > As soon as you start experimenting with tearing down
> > > connections,
> > > injecting faults by moving out of range, more
> > > complex piconet topologies,
> > > things seem to get a bit unstable.
> > >
> > > On one occasion, in /proc/tty/driver/serial several
> > > "framing errors" were
> > > reported (this are under the rubric "fe:"). This
> > > only happened once and I
> > > do not know how to easily reproduce it, but I think
> > > it is very bad news.
> > > The PXA manual says that framing errors (quoting
> > > from memory) occur when
> > > the stop bit (which should always be a 1, if I
> > > remember correctly) is a 0
> > > (again, quoting from memory). This spells "buggy
> > > hardware" all over for
> > > me. I am more willing to believe that the UART in
> > > the RTX Telecom module
> > > (as I understand the chip is a National LMX9814) is
> > > buggy rather than the
> > > BTUART in the PXA, but it could be either, or both.
> > > As I said, this has
> > > happened only once.
> > >
> > > To conclude, removing the wlan interface, gets rid
> > > of most of the problems
> > > with Bluetooth on an h5400 and h5550. With the wlan
> > > interface up, overrun
> > > errors occur in a matter of seconds (under a
> > > sustained transfer rate) at
> > > the BTUART. Although disabling the wlan cures the
> > > overrun problems, there
> > > are stability issues with the Bluetooth interface on
> > > these devices, some
> > > of which may even be due to buggy hardware.
> > >
> > > Any comments are welcome, please cc: me in your
> > > replies as I am not
> > > subscribed to the mailing list,
> > >
> > > Catalin
> > >
> > >
> > > _______________________________________________
> > > H5400-port mailing list
> > > H5400-port_at_handhelds.org
> > >
> > https://www.handhelds.org/mailman/listinfo/h5400-port
> > >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > H5400-port mailing list
> > H5400-port_at_handhelds.org
> > https://www.handhelds.org/mailman/listinfo/h5400-port
>
> --
> Erik Hovland
> mail: erik AT hovland DOT org
> web: http://hovland.org/
> PGP/GPG public key available on request
> _______________________________________________
> H5400-port mailing list
> H5400-port_at_handhelds.org
> https://www.handhelds.org/mailman/listinfo/h5400-port
>
Received on Mon Mar 07 2005 - 12:50:28 EST