Quantcast

serial driver & high uart rates

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

serial driver & high uart rates

Brad Midgley-3
Hey,

My understanding is that for some time we couldn't use bluetooth at
anything above 115k because of a serial driver issue. Ostensibly,
linaro had the fixed kernel and Steve Sakoman had images that would
work as well.

What is the status on that? Is the serial driver problem fixed at this
point? Could a new problem have appeared?

I used to be able to run "hciattach ttyS1 csr" using linaro on an
overo fire but on a newer board this always produces:

Can't get port settings: Input/output error
Can't initialize device: Input/output error

this linaro image was built last year and reports running

Linux linaro 2.6.38-1003-linaro-omap #4~ppa5-Ubuntu SMP PREEMPT Wed
May 25 14:44:32 UTC 2011 armv7l armv7l armv7l GNU/Linux

--
Brad Midgley

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Patrick Maheral (DWI - CA/Ottawa)
Hi Brad,

I've used the stock (Linux 3.0) serial drivers at 460800bps and
patched drivers up to 1.5Mbps.  The patched drivers should work
up to 3Mbps.

One of my collegues noticed that a couple of zero bytes are
transmitted by the omap processor at a fixed interval (can't
remember exactly how long, but I think it was 192us) after the
start of a block of received data.  On short receive bursts,
the TX line stays idle, but on long receive bursts, 1 or 2 "0"
bytes are transmitted.

The patches only change the baud rate clock divider from 13 to
16 for speeds of 1M, 1.5M, and 3.0M.

Patrick

> -----Original Message-----
> From: Brad Midgley [mailto:[hidden email]]
> Sent: March 9, 2012 14:05
> To: General mailing list for gumstix users.
> Subject: [Gumstix-users] serial driver & high uart rates
>
> Hey,
>
> My understanding is that for some time we couldn't use bluetooth at
> anything above 115k because of a serial driver issue. Ostensibly,
> linaro had the fixed kernel and Steve Sakoman had images that would
> work as well.
>
> What is the status on that? Is the serial driver problem fixed at this
> point? Could a new problem have appeared?
>
> I used to be able to run "hciattach ttyS1 csr" using linaro on an
> overo fire but on a newer board this always produces:
>
> Can't get port settings: Input/output error
> Can't initialize device: Input/output error
>
> this linaro image was built last year and reports running
>
> Linux linaro 2.6.38-1003-linaro-omap #4~ppa5-Ubuntu SMP PREEMPT Wed
> May 25 14:44:32 UTC 2011 armv7l armv7l armv7l GNU/Linux
>
> --
> Brad Midgley
>
> --------------------------------------------------------------
> ----------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Brad Midgley-3
Patrick

> I've used the stock (Linux 3.0) serial drivers at 460800bps and
> patched drivers up to 1.5Mbps.  The patched drivers should work
> up to 3Mbps.

The rate we really need is 921k.

> One of my collegues noticed that a couple of zero bytes are
> transmitted by the omap processor at a fixed interval (can't
> remember exactly how long, but I think it was 192us) after the
> start of a block of received data.  On short receive bursts,
> the TX line stays idle, but on long receive bursts, 1 or 2 "0"
> bytes are transmitted.

Is that a hardware bug? this would probably kill the hci connection.

> The patches only change the baud rate clock divider from 13 to
> 16 for speeds of 1M, 1.5M, and 3.0M.

was 921k fixed by this? iirc it was not getting set properly.

--
Brad Midgley

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Patrick Maheral (DWI - CA/Ottawa)

> -----Original Message-----
> From: Brad Midgley [mailto:[hidden email]]
>
> Patrick
>
> > I've used the stock (Linux 3.0) serial drivers at 460800bps and
> > patched drivers up to 1.5Mbps.  The patched drivers should work
> > up to 3Mbps.
>
> The rate we really need is 921k.


The stock code sets that oversampling rate to 13 for all baud rates
above 230400 bps. The patch I used only fixes the baud rate
oversampling setting for speeds that should use 16x oversampling
rather than 13x.  921k is unaffected by this patch, but if you're
Using a recent kernel with omap_serial support, 921k should already
be supported.

>
> > One of my collegues noticed that a couple of zero bytes are
> > transmitted by the omap processor at a fixed interval (can't
> > remember exactly how long, but I think it was 192us) after the
> > start of a block of received data.  On short receive bursts,
> > the TX line stays idle, but on long receive bursts, 1 or 2 "0"
> > bytes are transmitted.
>
> Is that a hardware bug? this would probably kill the hci connection.

I don't know if this is caused by a hardware, driver, or software
bug.  If I find anything, I'll post back here.

>
> > The patches only change the baud rate clock divider from 13 to
> > 16 for speeds of 1M, 1.5M, and 3.0M.
>
> was 921k fixed by this? iirc it was not getting set properly.
>
> --
> Brad Midgley


Are your serial ports named "ttyS?" or "ttyO?".  The kernels that
support the higher (than 230k) baud rates name the serial ports
"ttyO?".

Patrick
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Brad Midgley-3
Patrick,

>> > One of my collegues noticed that a couple of zero bytes are
>> > transmitted
> I don't know if this is caused by a hardware, driver, or software
> bug.  If I find anything, I'll post back here.

So this is the current state I'm seeing. Each of these is attempted on
a clean reboot since any dialog with the bt chip can put it in a weird
state. So the old way:

hciattach ttyO1 csr 115200 noflow

works, adapter is up when you check hciconfig, hcitool scan works

hciattach ttyO1 csr 921600 flow

sometimes (rarely) works, adapter is up when you check hciconfig,
hcitool scan works. Usually, it seems to work but hciconfig shows the
adapter is down and hciconfig up operations time out. maybe the
problem with 921k has been garbage introduced on the line but there
could be some interaction with something else since it sometimes
works.

Is there anything to suggest that the serial driver can have random
failures? Are the transmitted zeroes on the line always present or
only sometimes?

--
Brad Midgley

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Patrick Maheral (DWI - CA/Ottawa)
Brad,

> -----Original Message-----
> From: Brad Midgley [mailto:[hidden email]]
>
> Patrick,
>
> >> > One of my collegues noticed that a couple of zero bytes are
> >> > transmitted
> > I don't know if this is caused by a hardware, driver, or software
> > bug.  If I find anything, I'll post back here.
 
[ ... ]

> Is there anything to suggest that the serial driver can have random
> failures? Are the transmitted zeroes on the line always present or
> only sometimes?

I just checked, and the zeroes are not always present. However, when
a pair of (spurious) zero are transmitted, the first always starts
391.25us after the start of the received data burst.  The time between
The first and second zero appears to vary (iirc) but is around
300-500us after the first.

BTW, we are using ttyO0 and ttyO2 for communication with a custom I/O
board.  We are not using the bluetooth interface, so I don't have any
experience with that particular connection.

Patrick
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Thots
So far I've only been able to use the default speed of 115200 for Bluetooth.  I'm trying to get Bluetooth as fast as possible.  However, I don't know about linaro.  I'm using Sakoman's 3.2 kernel (works great) with the normal Gumstix/Angstrom file system.

Any suggestions on how to increase the speed would be appreciated.  Bluetooth should be going faster than a 115200 baud.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Brad Midgley-3
maybe someone at gumstix could comment on the driver situation. We
could confirm corruption by looking at the hcidump output and
comparing it to what is actually sent over the uart. I don't have a
setup to spy on the uart though.

On Mon, Mar 12, 2012 at 5:51 PM, Thots <[hidden email]> wrote:
> So far I've only been able to use the default speed of 115200 for Bluetooth.
> I'm trying to get Bluetooth as fast as possible.  However, I don't know
> about linaro.  I'm using Sakoman's 3.2 kernel (works great) with the normal
> Gumstix/Angstrom file system.
>
> Any suggestions on how to increase the speed would be appreciated.
> Bluetooth should be going faster than a 115200 baud.

--
Brad Midgley

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Patrick Maheral (DWI - CA/Ottawa)
> -----Original Message-----
> From: Brad Midgley [mailto:[hidden email]]
>
> maybe someone at gumstix could comment on the driver situation. We
> could confirm corruption by looking at the hcidump output and
> comparing it to what is actually sent over the uart. I don't have a
> setup to spy on the uart though.
>

We did a bit of testing yesterday with the CPU speed.  We are processing
receiving about 100 bursts of data per second.  At a core speed of 125MHz,
we see the zero's being transmitted once or twice a second.  At a core
speed of 250MHz, this drops down to once or twice a minute.  There is
very little (if any) improvement at 500MHz.

I'll post here as I find more info.  I have a suspicion that it might be
XON/XOFF characters being transmitted by the UART even though, AFAIK,
software flow control is turned off.

Patrick


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Brad Midgley-3
this sounds like something gumstix should take up with TI

On Fri, Mar 16, 2012 at 7:07 AM, Patrick Maheral (DWI - CA/Ottawa)
<[hidden email]> wrote:

>> -----Original Message-----
>> From: Brad Midgley [mailto:[hidden email]]
>>
>> maybe someone at gumstix could comment on the driver situation. We
>> could confirm corruption by looking at the hcidump output and
>> comparing it to what is actually sent over the uart. I don't have a
>> setup to spy on the uart though.
>>
>
> We did a bit of testing yesterday with the CPU speed.  We are processing
> receiving about 100 bursts of data per second.  At a core speed of 125MHz,
> we see the zero's being transmitted once or twice a second.  At a core
> speed of 250MHz, this drops down to once or twice a minute.  There is
> very little (if any) improvement at 500MHz.
>
> I'll post here as I find more info.  I have a suspicion that it might be
> XON/XOFF characters being transmitted by the UART even though, AFAIK,
> software flow control is turned off.
>
> Patrick
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users



--
Brad Midgley

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Patrick Maheral (DWI - CA/Ottawa)
Just noticed an entry in the Linux kernel 3.1 Changelog labeled:

    omap-serial: Allow IXON and IXOFF to be disabled.

That looks like it would cause the problem I'm seeing.  I've
Install a 3.2 kernel and will test to see if the zero bytes
are transmitted.

Patrick

> -----Original Message-----
> From: Brad Midgley [mailto:[hidden email]]
> Sent: March 16, 2012 12:29
> To: General mailing list for gumstix users.
> Subject: Re: [Gumstix-users] serial driver & high uart rates
>
> this sounds like something gumstix should take up with TI
>
> On Fri, Mar 16, 2012 at 7:07 AM, Patrick Maheral (DWI - CA/Ottawa)
> <[hidden email]> wrote:
> >> -----Original Message-----
> >> From: Brad Midgley [mailto:[hidden email]]
> >>
> >> maybe someone at gumstix could comment on the driver situation. We
> >> could confirm corruption by looking at the hcidump output and
> >> comparing it to what is actually sent over the uart. I don't have a
> >> setup to spy on the uart though.
> >>
> >
> > We did a bit of testing yesterday with the CPU speed.  We
> are processing
> > receiving about 100 bursts of data per second.  At a core
> speed of 125MHz,
> > we see the zero's being transmitted once or twice a second.
>  At a core
> > speed of 250MHz, this drops down to once or twice a minute.
>  There is
> > very little (if any) improvement at 500MHz.
> >
> > I'll post here as I find more info.  I have a suspicion
> that it might be
> > XON/XOFF characters being transmitted by the UART even
> though, AFAIK,
> > software flow control is turned off.
> >
> > Patrick
> >
> >
> >
> --------------------------------------------------------------
> ----------------
> > This SF email is sponsosred by:
> > Try Windows Azure free for 90 days Click Here
> > http://p.sf.net/sfu/sfd2d-msazure
> > _______________________________________________
> > gumstix-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
>
>
> --
> Brad Midgley
>
> --------------------------------------------------------------
> ----------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Steve Sakoman
On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa)
<[hidden email]> wrote:
> Just noticed an entry in the Linux kernel 3.1 Changelog labeled:
>
>    omap-serial: Allow IXON and IXOFF to be disabled.
>
> That looks like it would cause the problem I'm seeing.  I've
> Install a 3.2 kernel and will test to see if the zero bytes
> are transmitted.

That bug does look like it could potentially cause the type of issues
you are seeing.

I've added the patch to my omap-3.0-pm branch:

http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9

Builds of my GNOME and console images now include this patch:

http://www.sakoman.com/category/8-gnome-daily-builds-r13.html

Let me know if this improves the situation for you.

Steve

>> -----Original Message-----
>> From: Brad Midgley [mailto:[hidden email]]
>> Sent: March 16, 2012 12:29
>> To: General mailing list for gumstix users.
>> Subject: Re: [Gumstix-users] serial driver & high uart rates
>>
>> this sounds like something gumstix should take up with TI
>>
>> On Fri, Mar 16, 2012 at 7:07 AM, Patrick Maheral (DWI - CA/Ottawa)
>> <[hidden email]> wrote:
>> >> -----Original Message-----
>> >> From: Brad Midgley [mailto:[hidden email]]
>> >>
>> >> maybe someone at gumstix could comment on the driver situation. We
>> >> could confirm corruption by looking at the hcidump output and
>> >> comparing it to what is actually sent over the uart. I don't have a
>> >> setup to spy on the uart though.
>> >>
>> >
>> > We did a bit of testing yesterday with the CPU speed.  We
>> are processing
>> > receiving about 100 bursts of data per second.  At a core
>> speed of 125MHz,
>> > we see the zero's being transmitted once or twice a second.
>>  At a core
>> > speed of 250MHz, this drops down to once or twice a minute.
>>  There is
>> > very little (if any) improvement at 500MHz.
>> >
>> > I'll post here as I find more info.  I have a suspicion
>> that it might be
>> > XON/XOFF characters being transmitted by the UART even
>> though, AFAIK,
>> > software flow control is turned off.
>> >
>> > Patrick
>> >
>> >
>> >
>> --------------------------------------------------------------
>> ----------------
>> > This SF email is sponsosred by:
>> > Try Windows Azure free for 90 days Click Here
>> > http://p.sf.net/sfu/sfd2d-msazure
>> > _______________________________________________
>> > gumstix-users mailing list
>> > [hidden email]
>> > https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>>
>>
>> --
>> Brad Midgley
>>
>> --------------------------------------------------------------
>> ----------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> gumstix-users mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Brad Midgley-3
Patrick, great find. Steve, thanks for applying the patch to your
release. The good news is that I'm now able to repeatably init and use
the bluetooth adapter with

hciattach ttyO1 csr 921600 noflow

We may have a solution here! It sounds like 921k was just fast enough
that xon/xoff was trying to throttle things. Everyone thought the
kernel was actually disabling flow control when we asked it to :(

On Tue, Mar 20, 2012 at 7:47 AM, Steve Sakoman <[hidden email]> wrote:

> On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa)
> <[hidden email]> wrote:
>> Just noticed an entry in the Linux kernel 3.1 Changelog labeled:
>>
>>    omap-serial: Allow IXON and IXOFF to be disabled.
>>
>> That looks like it would cause the problem I'm seeing.  I've
>> Install a 3.2 kernel and will test to see if the zero bytes
>> are transmitted.
>
> That bug does look like it could potentially cause the type of issues
> you are seeing.
>
> I've added the patch to my omap-3.0-pm branch:
>
> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9
>
> Builds of my GNOME and console images now include this patch:
>
> http://www.sakoman.com/category/8-gnome-daily-builds-r13.html
>
> Let me know if this improves the situation for you.
>
> Steve

--
Brad Midgley

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Brad Midgley-3
Steve,

A few questions about your distro, first related to the topic at hand, bt:

I created a user account so pulse would start but it shows no hardware
available, even when a bluetooth headset is connected. Not even wired
audio. There should be pulseaudio/hal/d-bus magic that goes into this
for ubuntu etc, but for these any connected bt headset appears in the
devices part of the pulse control panel and also has device-specific
tweaks, like choosing voice or hifi.

Too bad there's not a firefox 4 or newer. Has anyone tried webgl in
firefox with sgx?

Monitor resolutions are stuck at 1024x768 max which usually means
image stretching.

I am very excited about the prospect of having full support for
bluetooth. Guys, let's figure out how to get closer... :)

I can now boot without any usb devices and use bt keyboard/mouse. I
did have to let things settle first, so in rcS.d I have a script:

(sleep 30 ; hciattach ttyO1 csr 921600 noflow ) &

Brad

On Tue, Mar 20, 2012 at 3:20 PM, Brad Midgley <[hidden email]> wrote:

> Patrick, great find. Steve, thanks for applying the patch to your
> release. The good news is that I'm now able to repeatably init and use
> the bluetooth adapter with
>
> hciattach ttyO1 csr 921600 noflow
>
> We may have a solution here! It sounds like 921k was just fast enough
> that xon/xoff was trying to throttle things. Everyone thought the
> kernel was actually disabling flow control when we asked it to :(
>
> On Tue, Mar 20, 2012 at 7:47 AM, Steve Sakoman <[hidden email]> wrote:
>> On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa)
>> <[hidden email]> wrote:
>>> Just noticed an entry in the Linux kernel 3.1 Changelog labeled:
>>>
>>>    omap-serial: Allow IXON and IXOFF to be disabled.
>>>
>>> That looks like it would cause the problem I'm seeing.  I've
>>> Install a 3.2 kernel and will test to see if the zero bytes
>>> are transmitted.
>>
>> That bug does look like it could potentially cause the type of issues
>> you are seeing.
>>
>> I've added the patch to my omap-3.0-pm branch:
>>
>> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9
>>
>> Builds of my GNOME and console images now include this patch:
>>
>> http://www.sakoman.com/category/8-gnome-daily-builds-r13.html
>>
>> Let me know if this improves the situation for you.
>>
>> Steve
>
> --
> Brad Midgley



--
Brad Midgley

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Steve Sakoman
On Tue, Mar 20, 2012 at 9:02 PM, Brad Midgley <[hidden email]> wrote:

> Steve,
>
> A few questions about your distro, first related to the topic at hand, bt:
>
> I created a user account so pulse would start but it shows no hardware
> available, even when a bluetooth headset is connected. Not even wired
> audio. There should be pulseaudio/hal/d-bus magic that goes into this
> for ubuntu etc, but for these any connected bt headset appears in the
> devices part of the pulse control panel and also has device-specific
> tweaks, like choosing voice or hifi.

I fussed around with pulse a bit, but never got it to work right.
Sadly the OE recipes for pulse don't seem to work "out of the box" and
I haven't had the motivation to debug it.  If you can figure out what
is broken I'm happy to fix recipes to do the right thing.  I suspect
it is just a bunch of config/init work.

> Too bad there's not a firefox 4 or newer. Has anyone tried webgl in
> firefox with sgx?

No, sgx has been broken for omap35xx in the last few TI SDK releases,
37xx seems to work ok.  Haven't tried to get sgx working in Firefox --
another case of no strong motivation to do so.

> Monitor resolutions are stuck at 1024x768 max which usually means
> image stretching.

Not true!  I use higher resolutions all the time!  You need to set the
monitor resolution in the u-boot environment:

http://www.sakoman.com/OMAP/how-to-change-the-display-resolution.html

> I am very excited about the prospect of having full support for
> bluetooth. Guys, let's figure out how to get closer... :)

I don't normally use bluetooth, but I am happy to tweak my images to
fix any issues you find -- as long as you give me good instructions on
what needs to change :-)

Steve


> I can now boot without any usb devices and use bt keyboard/mouse. I
> did have to let things settle first, so in rcS.d I have a script:
>
> (sleep 30 ; hciattach ttyO1 csr 921600 noflow ) &
>
> Brad
>
> On Tue, Mar 20, 2012 at 3:20 PM, Brad Midgley <[hidden email]> wrote:
>> Patrick, great find. Steve, thanks for applying the patch to your
>> release. The good news is that I'm now able to repeatably init and use
>> the bluetooth adapter with
>>
>> hciattach ttyO1 csr 921600 noflow
>>
>> We may have a solution here! It sounds like 921k was just fast enough
>> that xon/xoff was trying to throttle things. Everyone thought the
>> kernel was actually disabling flow control when we asked it to :(
>>
>> On Tue, Mar 20, 2012 at 7:47 AM, Steve Sakoman <[hidden email]> wrote:
>>> On Fri, Mar 16, 2012 at 10:08 AM, Patrick Maheral (DWI - CA/Ottawa)
>>> <[hidden email]> wrote:
>>>> Just noticed an entry in the Linux kernel 3.1 Changelog labeled:
>>>>
>>>>    omap-serial: Allow IXON and IXOFF to be disabled.
>>>>
>>>> That looks like it would cause the problem I'm seeing.  I've
>>>> Install a 3.2 kernel and will test to see if the zero bytes
>>>> are transmitted.
>>>
>>> That bug does look like it could potentially cause the type of issues
>>> you are seeing.
>>>
>>> I've added the patch to my omap-3.0-pm branch:
>>>
>>> http://www.sakoman.com/cgi-bin/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=f77d38b6ccbd9cb1e4e5fe92f7dd939b9f6f86d9
>>>
>>> Builds of my GNOME and console images now include this patch:
>>>
>>> http://www.sakoman.com/category/8-gnome-daily-builds-r13.html
>>>
>>> Let me know if this improves the situation for you.
>>>
>>> Steve
>>
>> --
>> Brad Midgley
>
>
>
> --
> Brad Midgley
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Thots
In reply to this post by Brad Midgley-3
Brad, I was also able to run bluetooth at a speed of 921600.  My thanks to the three of you that worked on the problem.  I'm using Sakoman's 3.2 kernel so I already had the patch.

I tried using your method of switching baud rates: "hciattach ttyO1 csr 921600 noflow".
But I got this error:
Failed to write init command (GET_BUILD_ID): Success
Can't initialize device: Success

I got it running by changing "/etc/default/bluetooth".  I changed "HCIATTACH_SPEED" from 115200 to 921600.

In order to test that the speed of my bluetooth connection was actually 921600, I ran a few different internet speed test programs over my laptop.  I connected my laptop to my gumstix over a pand connection.  I then used this pand connection for my laptop to access the internet (my Gumstix had internet coming into it via Ethernet, but my laptop could only get internet over the pand connection).

When I ran these various speed tests, I wouldn't get a speed near 921600.  I got a speed of about 470 kbps.  This is about half of what I expected.  This lead to testing with different baud rates:

baud                       kbps
115200                      75
230400                     160
460800                     280
921600                     470

Does anyone have any suggestions as to why these bluetooth connections don't seem as fast as they should be for their given baud rates?



Brad Midgley-3 wrote
Patrick, great find. Steve, thanks for applying the patch to your
release. The good news is that I'm now able to repeatably init and use
the bluetooth adapter with

hciattach ttyO1 csr 921600 noflow

We may have a solution here! It sounds like 921k was just fast enough
that xon/xoff was trying to throttle things. Everyone thought the
kernel was actually disabling flow control when we asked it to :(

--
Brad Midgley

------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Thots
At first I was excited about being able to set the baud rate to 921600 for Bluetooth.  However, I have found out that it is very unreliable at that speed.  If I'm not doing anything on my Gumstix besides using Bluetooth, everything works great.  However, it always breaks when I start using the Gumstix for lots of other things.  For example, as soon as I start using VLC to capture and display video from a normal USB webcam, Bluetooth barfs.  Bluetooth stops working at all, and from the console I see a stream of these errors:

Bluetooth: Frame Reassembly Failed

If I switch back to a baud rate of 115200, everything works perfectly.

Does anyone have a suggestion as to how to get Bluetooth working reliably at the 921600 baud rate.  It is sad to be running Bluetooth at such a low speed when the hardware supports faster.

Thanks for your time,
Thots
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Patrick Maheral (DWI - CA/Ottawa)
Hi Thots,

Are you using a cpu frequency governor?  

We noticed that the serial overflows disappeared when
The system was busy (ie. high CPU usage) which seemed
counter-intuitive until we realized that, under those
conditions, the CPU frequency never dropped below 500MHz.
We found that with the default "On Demand" governor,
it would drop the frequency down to 125MHz, and it
wouldn't switch to a higher speed fast enough to handle
the bursty serial data.  We solved our overflow issue by
switching to the "Conservative" governor and set the low
limit to 250MHz.

Patrick

> -----Original Message-----
> From: Thots [mailto:[hidden email]]
>
> At first I was excited about being able to set the baud
> rate to 921600 for Bluetooth.  However, I have found out
> that it is very unreliable at that speed.  If I'm not
> doing anything on my Gumstix besides using Bluetooth,
> everything works great.  However, it always breaks when
> I start using the Gumstix for lots of other things.  For
> example, as soon as I start using VLC to capture and
> display video from a normal USB webcam, Bluetooth barfs.
> Bluetooth stops working at all, and from the console I see
> a stream of these errors:
>
> Bluetooth: Frame Reassembly Failed
>
> If I switch back to a baud rate of 115200, everything works
> perfectly.
>
> Does anyone have a suggestion as to how to get Bluetooth
> working reliably at the 921600 baud rate.  It is sad to be
> running Bluetooth at such a low speed when the hardware
> supports faster.
>
> Thanks for your time,
> Thots
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: serial driver & high uart rates

Thots
Thanks for your suggestion, Patrick.  I've tried setting the CPU frequency governor a couple of different ways.  Unfortunately, it hasn't solved the problem of Bluetooth not working at 921600 during the heavy CPU load of capturing and displaying video with VLC.

I've used a Fire Storm Gumstix running at 800MHz.  The current governor is set to "userspace".  I tried using menu_config to set the governor to "conservative".  Then I rebuilt the kernel.  However, the Gumstix crashes before the new kernel ever finishes booting.

Next I tried setting the governor to conservative during run-time via:
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

However, this definitely doesn't work for high CPU loads.  The kernel crashes as soon as I turn on VLC and start capturing and displaying video (I don't even have Bluetooth running).  If I don't set the governor to "conservative", I can run VLC without any problem.

Are there any other suggestions how to fix Bluetooth not working reliably at the 921600 speed?

Thanks for your time,
Thots

Patrick Maheral (DWI - CA/Ottawa) wrote
Hi Thots,

Are you using a cpu frequency governor?  

We noticed that the serial overflows disappeared when
The system was busy (ie. high CPU usage) which seemed
counter-intuitive until we realized that, under those
conditions, the CPU frequency never dropped below 500MHz.
We found that with the default "On Demand" governor,
it would drop the frequency down to 125MHz, and it
wouldn't switch to a higher speed fast enough to handle
the bursty serial data.  We solved our overflow issue by
switching to the "Conservative" governor and set the low
limit to 250MHz.

Patrick
Loading...