Quantcast

Serial port write issue, omap-serial driver, 230400 baud

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

Serial port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
Dear gumstix-users,

I need some help troubleshooting an interesting serial communication
problem with the Gumstix Overo.

Recently I switched from a tried and tested kernel 2.6.34 to a newer
kernel 3.5 for a Gumstix Overo embedded project.

One of the OMAP serial ports is used to communicate with another device,
at 230400 baud 8-N-1. We are running the serial link at ~85% capacity.
This has been working very well with kernel 2.6.34 so far.

With kernel 3.5, we are having some serious problems. There is now a gap
of 200-300us between each group of 16 bytes in UART transmissions coming
out of the Gumstix.
Here are screenshots from my scope to illustrate:

http://postimg.org/image/7kc48xkij/
http://postimg.org/image/sxgg60p1b/

The gaps should not be there. There should be a continuous burst of
RS-232 activity.

We are sending frames ~1300 bytes in size. The time gaps increase the
transmission time for each frame, preventing our system from functioning
normally.

Here are several of the things I've tried, none of which has made any
difference:
- Changed serial port from blocking to non-blocking, and back
- Changed kernel from preemptible, voluntary preemptible, non-preemptible
- Changed tick rate from 128 (default) to 1024 and back
- Disable tickless kernel, re-enabled tickless
- Played with thread priorities in software that transmits via serial
port -- made them all default priority, reduced priority, increased
some, not others -- various permutations
- Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back

One main difference I am aware of between between kernels 2.6.34 and 3.5
is that in 3.5 the omap-serial driver is used, versus the classic 8250
driver that was used in 2.6.34.

Here are my best guesses at the moment:
- 16 bytes is the common Uart Tx FIFO size
- Suspect there is something happening in the omap-serial driver,
preventing a continuous stream of data. Instead there is a pause
inserted each time the Tx FIFO is emptied.

Has anyone seen something like this? Any solutions in later driver versions?

Any assistance at this point would be vastly appreciated.

Best regards,
Markus



------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

thinair89
I may have that problem as well. I'm using a 434MHZ RF transmitter and receiver. The rate of receiving data correctly is low, even though the waveform on the oscilloscope is perfect. 
And data shows on the screen in a burst, not continuously. 
I guess its because the Serial port has a buffer. My baud rate is 2400, and my RF module is simple and probably unreliable.
I tried 2 method (non-blocking, some change in setserial, I forgot..) and no change on the behavior.

Any suggestions?


On Wed, Feb 26, 2014 at 2:07 PM, Markus Svilans <[hidden email]> wrote:
Dear gumstix-users,

I need some help troubleshooting an interesting serial communication
problem with the Gumstix Overo.

Recently I switched from a tried and tested kernel 2.6.34 to a newer
kernel 3.5 for a Gumstix Overo embedded project.

One of the OMAP serial ports is used to communicate with another device,
at 230400 baud 8-N-1. We are running the serial link at ~85% capacity.
This has been working very well with kernel 2.6.34 so far.

With kernel 3.5, we are having some serious problems. There is now a gap
of 200-300us between each group of 16 bytes in UART transmissions coming
out of the Gumstix.
Here are screenshots from my scope to illustrate:

http://postimg.org/image/7kc48xkij/
http://postimg.org/image/sxgg60p1b/

The gaps should not be there. There should be a continuous burst of
RS-232 activity.

We are sending frames ~1300 bytes in size. The time gaps increase the
transmission time for each frame, preventing our system from functioning
normally.

Here are several of the things I've tried, none of which has made any
difference:
- Changed serial port from blocking to non-blocking, and back
- Changed kernel from preemptible, voluntary preemptible, non-preemptible
- Changed tick rate from 128 (default) to 1024 and back
- Disable tickless kernel, re-enabled tickless
- Played with thread priorities in software that transmits via serial
port -- made them all default priority, reduced priority, increased
some, not others -- various permutations
- Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back

One main difference I am aware of between between kernels 2.6.34 and 3.5
is that in 3.5 the omap-serial driver is used, versus the classic 8250
driver that was used in 2.6.34.

Here are my best guesses at the moment:
- 16 bytes is the common Uart Tx FIFO size
- Suspect there is something happening in the omap-serial driver,
preventing a continuous stream of data. Instead there is a pause
inserted each time the Tx FIFO is emptied.

Has anyone seen something like this? Any solutions in later driver versions?

Any assistance at this point would be vastly appreciated.

Best regards,
Markus



------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



--
Airie Zhou

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
In reply to this post by Markus Svilans-2
Further to my earlier message, here are some scope screenshots comparing
the Overo UART transmit electrical activity, when running the different
kernel versions.

Kernel 2.6.34 / 8250 driver
http://postimg.org/image/5rcadjg6n/

Kernel 3.5.0 / omap-serial driver
http://postimg.org/image/klb5mb2vx/

The identical user space software is running in each. The only
differences are kernel and serial driver.

Any ideas?

Regards,
Markus



On 2014-02-26 15:07, Markus Svilans wrote:

> Dear gumstix-users,
>
> I need some help troubleshooting an interesting serial communication
> problem with the Gumstix Overo.
>
> Recently I switched from a tried and tested kernel 2.6.34 to a newer
> kernel 3.5 for a Gumstix Overo embedded project.
>
> One of the OMAP serial ports is used to communicate with another
> device, at 230400 baud 8-N-1. We are running the serial link at ~85%
> capacity. This has been working very well with kernel 2.6.34 so far.
>
> With kernel 3.5, we are having some serious problems. There is now a
> gap of 200-300us between each group of 16 bytes in UART transmissions
> coming out of the Gumstix.
> Here are screenshots from my scope to illustrate:
>
> http://postimg.org/image/7kc48xkij/
> http://postimg.org/image/sxgg60p1b/
>
> The gaps should not be there. There should be a continuous burst of
> RS-232 activity.
>
> We are sending frames ~1300 bytes in size. The time gaps increase the
> transmission time for each frame, preventing our system from
> functioning normally.
>
> Here are several of the things I've tried, none of which has made any
> difference:
> - Changed serial port from blocking to non-blocking, and back
> - Changed kernel from preemptible, voluntary preemptible, non-preemptible
> - Changed tick rate from 128 (default) to 1024 and back
> - Disable tickless kernel, re-enabled tickless
> - Played with thread priorities in software that transmits via serial
> port -- made them all default priority, reduced priority, increased
> some, not others -- various permutations
> - Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back
>
> One main difference I am aware of between between kernels 2.6.34 and
> 3.5 is that in 3.5 the omap-serial driver is used, versus the classic
> 8250 driver that was used in 2.6.34.
>
> Here are my best guesses at the moment:
> - 16 bytes is the common Uart Tx FIFO size
> - Suspect there is something happening in the omap-serial driver,
> preventing a continuous stream of data. Instead there is a pause
> inserted each time the Tx FIFO is emptied.
>
> Has anyone seen something like this? Any solutions in later driver
> versions?
>
> Any assistance at this point would be vastly appreciated.
>
> Best regards,
> Markus
>
>


--
Markus Svilans
[hidden email]
+1 705 626 7257

Aeonyx Research Corporation
www.aeonyx.ca


------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

bhamadicharef
There is a need to check the omap-serial driver indeed ... I think it uses DMA !
I can try with Sakoman kernel 3.0 and see how it behaves, I will serial for GPS
data soon...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Serial port write issue, omap-serial driver, 230400 baud

Florian Vaussard
In reply to this post by Markus Svilans-2
Hi Markus,

On 02/26/2014 09:07 PM, Markus Svilans wrote:

> Dear gumstix-users,
>
> I need some help troubleshooting an interesting serial communication
> problem with the Gumstix Overo.
>
> Recently I switched from a tried and tested kernel 2.6.34 to a newer
> kernel 3.5 for a Gumstix Overo embedded project.
>
> One of the OMAP serial ports is used to communicate with another device,
> at 230400 baud 8-N-1. We are running the serial link at ~85% capacity.
> This has been working very well with kernel 2.6.34 so far.
>
> With kernel 3.5, we are having some serious problems. There is now a gap
> of 200-300us between each group of 16 bytes in UART transmissions coming
> out of the Gumstix.
> Here are screenshots from my scope to illustrate:
>
> http://postimg.org/image/7kc48xkij/
> http://postimg.org/image/sxgg60p1b/
>
> The gaps should not be there. There should be a continuous burst of
> RS-232 activity.
>
> We are sending frames ~1300 bytes in size. The time gaps increase the
> transmission time for each frame, preventing our system from functioning
> normally.
>
> Here are several of the things I've tried, none of which has made any
> difference:
> - Changed serial port from blocking to non-blocking, and back
> - Changed kernel from preemptible, voluntary preemptible, non-preemptible

Should be preemptible to decrease the scheduling latency

> - Changed tick rate from 128 (default) to 1024 and back
> - Disable tickless kernel, re-enabled tickless

Tickless will improve power savings, don't do this (see below)

> - Played with thread priorities in software that transmits via serial
> port -- made them all default priority, reduced priority, increased
> some, not others -- various permutations
> - Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back

SHCED_FIFO if you like to live dangerously (see man page). You also have
to consider the scheduling of the UART irq / dma thread, if any.

>
- Flow control? If the remote end is holding CTS, the UART will wait.

Try to disable power management, especially dynamic idling. Power
management is often against throughput, it hit me a while ago (I can see
that the omap-serial driver is requesting pm_qos, but it may not be
sufficient for your application).

> One main difference I am aware of between between kernels 2.6.34 and 3.5
> is that in 3.5 the omap-serial driver is used, versus the classic 8250
> driver that was used in 2.6.34.
>
> Here are my best guesses at the moment:
> - 16 bytes is the common Uart Tx FIFO size

Hardware FIFO in the UART peripheral is 64 bytes, but the interrupt
threshold is configurable.

> - Suspect there is something happening in the omap-serial driver,
> preventing a continuous stream of data. Instead there is a pause
> inserted each time the Tx FIFO is emptied.
>

3.5 is pretty old, and looking at the changelog compared to the current
3.14-rc4, the list is pretty long (see below). Some commits are
especially "suspects". So I would try a recent kernel first, as the
driver may be faulty.

Regards,
Florian



a64c1a1 serial: omap: fix rs485 probe on defered pinctrl
ce6acca serial: omap-serial: Move info message to probe function
80d8611 serial: omap: fix missing comma
e5f9bf7 serial: omap: fix a few checkpatch warnings
018e744 serial: omap: improve RS-485 performance
2a0b965 serial: omap: Add support for optional wake-up
e701bca serial: omap: delete .set_wake callback
18d8519 OMAP/serial: Fix Mode13 vs Mode16 priority
4250b5d OMAP/serial: Fix misnamed variable
355fe56 Revert "OMAP: UART: Keep the TX fifo full when possible"
7b013e4 Revert "serial: omap: Fix IRQ handling return value"
e438ac9 OMAP: serial: Remove incorrect disabling of IER interrupt
4a0ac0f OMAP: add RS485 support
574de55 serial: use dev_get_platdata()
3026d14 serial: omap: enable PM runtime only when its fully configured
908fd7e serial: omap: Fix IRQ handling return value
a0a490f serial: omap: Initialize platform_data
76bac19 OMAP: UART: Fix the revision register read.
c441508 OMAP: UART: Keep the TX fifo full when possible
f64ffda OMAP2+: UART: enable tx wakeup bit for wer reg
e84f54f drivers/tty/serial: don't use devm_pinctrl_get_select_default()
in probe
a630fbf serial: omap: Fix device tree based PM runtime
7f25301 serial: omap: fix potential NULL pointer dereference in
serial_omap_runtime_suspend()
2cb5a2f serial: omap: repair building without PM_SLEEP
ddd85e2 serial: omap: prevent runtime PM for "no_console_suspend"
7f18d05 SERIAL: OMAP: Remove the slave idle handling from the driver
1f66396 OMAP/serial: Revert bad fix of Rx FIFO threshold granularity
1776fd0 OMAP/serial: Fix incorrect Rx FIFO threshold setting, LSR
validation on Tx, and Tx FIFO IRQ generation
5fe2123 OMAP/serial: Support 1Mbaud and similar baudrates that require
Mode16 instead of Mode13
2e124b4 TTY: switch tty_flip_buffer_push
fdbc735 serial: omap: add the functionality of a 9-bit UART with
userspaces CMSPAR
d9ba573 ARM: OMAP: Move plat/omap-serial.h to
include/linux/platform_data/serial-omap.h
ae8d8a1 tty: remove use of __devexit
9671f09 tty: remove use of __devinit
2d47b71 tty: serial: remove use of __devexit_p
3af08bd SERIAL: omap: fix hardware assisted flow control
2405464 SERIAL: omap: simplify (2)
c533e51 SERIAL: omap: move xon/xoff setting earlier
c7d059c SERIAL: omap: always set TCR
18f360f SERIAL: omap: simplify
1fe8aa8 SERIAL: omap: don't read back LCR/MCR/EFR
01d70bb SERIAL: omap: serial_omap_configure_xonxoff() contents into
set_termios
820344f SERIAL: omap: configure xon/xoff before setting modem control lines
f91b55a SERIAL: omap: move driver private definitions and structures to
driver
4073a53 SERIAL: omap: remove 'irq_pending' bitfield
08bd490 SERIAL: omap: fix MCR TCRTLR bit handling
9363f8f SERIAL: omap: fix set_mctrl() breakage
511e74f SERIAL: omap: no need to re-read EFR
d864c03 SERIAL: omap: remove setting of EFR SCD bit
da5d01f SERIAL: omap: allow hardware assisted IXANY mode to be disabled
0d5b166 SERIAL: omap: allow hardware assisted rts/cts modes to be disabled
40477d0 serial: omap: Remove the hardcode serial_omap_console_ports array.
7ba897d serial: omap: Remove the default setting of special character
39aee51 serial: omap: Make context_loss_cnt signed
a4f7438 Revert "serial: omap: fix software flow control"
9a12fcf serial: omap: fix the reciever line error case
ac57e7f serial: omap: Remove unnecessary checks from suspend/resume
3dbc5ce serial: omap: Request pins using pinctrl framework
ce2f08d serial: omap: fix DeviceTree boot
e36851d serial: omap: fix compile breakage
6721ab7 serial: omap: enable RX and TX FIFO usage
d37c6ce serial: omap: move uart_omap_port definition to C file
d21e400 serial: omap: remove unnecessary header and add a missing one
957ee72 serial: omap: fix software flow control
a6b19c3 serial: omap: make sure to put() on poll_get_char
9727faf serial: omap: implement set_wake
0324a82 serial: omap: unlock the port lock
52c5513 serial: omap: drop "inline" from IRQ handler prototype
6d608ef serial: omap: optimization with section annotations
856e35b serial: omap: fix sequence of pm_runtime_* calls.
6c3a30c serial: omap: don't save IRQ flags on hardirq
7e9c8e7 serial: omap: make sure to suspend device before remove
1b42c8b serial: omap: drop unnecessary check from remove
93220dc serial: omap: set dev->drvdata before enabling pm_runtime
660ac5f serial: omap: stick to put_autosuspend
bf63a08 serial: omap: move THRE check to transmit_chars()
72256cb serial: omap: refactor receive_chars() into rdi/rlsi handlers
81b75ae serial: omap: simplify IRQ handling
4945743 serial: omap: drop DMA support
d8ee4ea serial: omap: don't access the platform_device
e5b57c0 serial: omap: define helpers for pdata function pointers
c990f35 serial: omap: define and use to_uart_omap_port()
4382973 workqueue: deprecate flush[_delayed]_work_sync()
9574f36 OMAP/serial: Add support for driving a GPIO as DTR.

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
Hi Florian,

Thanks very much for the helpful response. A couple of more questions,
below...


On 02/27/2014 04:02 AM, Florian Vaussard wrote:
> Here are several of the things I've tried, none of which has made any
> difference:
> - Changed serial port from blocking to non-blocking, and back
> - Changed kernel from preemptible, voluntary preemptible, non-preemptible
> Should be preemptible to decrease the scheduling latency

Agreed, I just turned off kernel preemption as an experiment, to see
what effect it would have on the serial port write timing.

>> - Changed tick rate from 128 (default) to 1024 and back
>> - Disable tickless kernel, re-enabled tickless
> Tickless will improve power savings, don't do this (see below)

Also agreed. Disabling NO_HZ was also an experiment.

>
>> - Played with thread priorities in software that transmits via serial
>> port -- made them all default priority, reduced priority, increased
>> some, not others -- various permutations
>> - Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back
> SHCED_FIFO if you like to live dangerously (see man page). You also have
> to consider the scheduling of the UART irq / dma thread, if any.

Between SCHED_FIFO and SCHED_RR, I'll stay safe (for now) and use only
RR for the more time sensitive threads :-)

> - Flow control? If the remote end is holding CTS, the UART will wait.
>
> Try to disable power management, especially dynamic idling. Power
> management is often against throughput, it hit me a while ago (I can see
> that the omap-serial driver is requesting pm_qos, but it may not be
> sufficient for your application).


Flow control is off. For this we are using 3-wire RS-232 (Tx, Rx, Gnd).


>> One main difference I am aware of between between kernels 2.6.34 and 3.5
>> is that in 3.5 the omap-serial driver is used, versus the classic 8250
>> driver that was used in 2.6.34.
>>
>> Here are my best guesses at the moment:
>> - 16 bytes is the common Uart Tx FIFO size
> Hardware FIFO in the UART peripheral is 64 bytes, but the interrupt
> threshold is configurable.


Can you give me some hints on how to do that?

I had a search in the Linux kernel docs about serial / omap-serial, and
couldn't immediately locate anything. Any tips would be appreciated!


> 3.5 is pretty old, and looking at the changelog compared to the current
> 3.14-rc4, the list is pretty long (see below). Some commits are
> especially "suspects". So I would try a recent kernel first, as the
> driver may be faulty.


I think 3.8 is the most recent kernel with support for Gumstix Overo?
(Is that true?)

I will try a test with kernel 3.8, to see if there is any change with
the serial port write performance.

Thanks for the list of changes. I'm feeling more optimistic that maybe
an updated kernel version will help solve this. If you have any info on
getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.

Thanks again & best regards,
Markus



------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Patrick Maheral
Hi Marcus,

Sorry I'm a little late to this thread, but we had a problem with serial
port _read_ at high data rates, and I thought I'd at least
share my experience.

On 27/02/14 02:45 PM, Markus Svilans wrote:
> Hi Florian,
>
> Thanks very much for the helpful response. A couple of more questions,
> below...
>
[...]

>>> One main difference I am aware of between between kernels 2.6.34 and 3.5
>>> is that in 3.5 the omap-serial driver is used, versus the classic 8250
>>> driver that was used in 2.6.34.
>>>
>>> Here are my best guesses at the moment:
>>> - 16 bytes is the common Uart Tx FIFO size
>> Hardware FIFO in the UART peripheral is 64 bytes, but the interrupt
>> threshold is configurable.
>
>
> Can you give me some hints on how to do that?
>
> I had a search in the Linux kernel docs about serial / omap-serial, and
> couldn't immediately locate anything. Any tips would be appreciated!
>
>> 3.5 is pretty old, and looking at the changelog compared to the current
>> 3.14-rc4, the list is pretty long (see below). Some commits are
>> especially "suspects". So I would try a recent kernel first, as the
>> driver may be faulty.
>

We are using an "ancient" (v3.2.0) kernel, and it includes the
omap-serial driver.  We needed to receive at 460800baud (and now
1.5Mbaud), but the irq latency was too large to prevent the FIFO from
overflowing.  This version of the omap-serial driver contained support
for DMA transfers, but that support was _not_ enabled.  We modified the
kernel to enable DMA, and it has worked quite nicely.

We would have moved up to a newer version of the kernel, but the kernel
DMA infrastructure was being reworked and the code for DMA in the
omap-serial driver was dropped.  It may have been added back since that
time, and if so, you may need to enable it.  Not sure how you might do
that though.

Patrick




------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Florian Vaussard
In reply to this post by Markus Svilans-2
Hi,

On 02/27/2014 08:45 PM, Markus Svilans wrote:

> Hi Florian,
>
> Thanks very much for the helpful response. A couple of more questions,
> below...
>
>
> On 02/27/2014 04:02 AM, Florian Vaussard wrote:
>> Here are several of the things I've tried, none of which has made any
>> difference:
>> - Changed serial port from blocking to non-blocking, and back
>> - Changed kernel from preemptible, voluntary preemptible, non-preemptible
>> Should be preemptible to decrease the scheduling latency
>
> Agreed, I just turned off kernel preemption as an experiment, to see
> what effect it would have on the serial port write timing.
>
>>> - Changed tick rate from 128 (default) to 1024 and back
>>> - Disable tickless kernel, re-enabled tickless
>> Tickless will improve power savings, don't do this (see below)
>
> Also agreed. Disabling NO_HZ was also an experiment.
>
>>
>>> - Played with thread priorities in software that transmits via serial
>>> port -- made them all default priority, reduced priority, increased
>>> some, not others -- various permutations
>>> - Changed thread scheduler from SCHED_RR to SCHED_OTHER, and back
>> SHCED_FIFO if you like to live dangerously (see man page). You also have
>> to consider the scheduling of the UART irq / dma thread, if any.
>
> Between SCHED_FIFO and SCHED_RR, I'll stay safe (for now) and use only
> RR for the more time sensitive threads :-)
>
>> - Flow control? If the remote end is holding CTS, the UART will wait.
>>
>> Try to disable power management, especially dynamic idling. Power
>> management is often against throughput, it hit me a while ago (I can see
>> that the omap-serial driver is requesting pm_qos, but it may not be
>> sufficient for your application).
>
>
> Flow control is off. For this we are using 3-wire RS-232 (Tx, Rx, Gnd).
>
>
>>> One main difference I am aware of between between kernels 2.6.34 and 3.5
>>> is that in 3.5 the omap-serial driver is used, versus the classic 8250
>>> driver that was used in 2.6.34.
>>>
>>> Here are my best guesses at the moment:
>>> - 16 bytes is the common Uart Tx FIFO size
>> Hardware FIFO in the UART peripheral is 64 bytes, but the interrupt
>> threshold is configurable.
>
>
> Can you give me some hints on how to do that?
>
> I had a search in the Linux kernel docs about serial / omap-serial, and
> couldn't immediately locate anything. Any tips would be appreciated!
>

I just saw the possibility in the hardware (by looking at the TRM). I do
not know how it is used. Someone should have a look to the driver (but I
am currently a bit busy, sorry).

>
>> 3.5 is pretty old, and looking at the changelog compared to the current
>> 3.14-rc4, the list is pretty long (see below). Some commits are
>> especially "suspects". So I would try a recent kernel first, as the
>> driver may be faulty.
>
>
> I think 3.8 is the most recent kernel with support for Gumstix Overo?
> (Is that true?)
>

The latest stable kernel (3.13) has still the legacy support for Overo.
So it should work. I am currently developing the "next-gen" support
(device tree), and 3.13 has already enough support to boot. I just
posted the patches to enable WiFi and a few other things, but this will
not be merged before 3.15.

> I will try a test with kernel 3.8, to see if there is any change with
> the serial port write performance.
>
> Thanks for the list of changes. I'm feeling more optimistic that maybe
> an updated kernel version will help solve this. If you have any info on
> getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.
>

Just try 3.13, it should work.

Regards,
Florian

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Florian Vaussard
In reply to this post by Patrick Maheral


On 02/27/2014 09:11 PM, Patrick Maheral wrote:

> Hi Marcus,
>
> Sorry I'm a little late to this thread, but we had a problem with serial
> port _read_ at high data rates, and I thought I'd at least
> share my experience.
>
> On 27/02/14 02:45 PM, Markus Svilans wrote:
>> Hi Florian,
>>
>> Thanks very much for the helpful response. A couple of more questions,
>> below...
>>
> [...]
>>>> One main difference I am aware of between between kernels 2.6.34 and 3.5
>>>> is that in 3.5 the omap-serial driver is used, versus the classic 8250
>>>> driver that was used in 2.6.34.
>>>>
>>>> Here are my best guesses at the moment:
>>>> - 16 bytes is the common Uart Tx FIFO size
>>> Hardware FIFO in the UART peripheral is 64 bytes, but the interrupt
>>> threshold is configurable.
>>
>>
>> Can you give me some hints on how to do that?
>>
>> I had a search in the Linux kernel docs about serial / omap-serial, and
>> couldn't immediately locate anything. Any tips would be appreciated!
>>
>>> 3.5 is pretty old, and looking at the changelog compared to the current
>>> 3.14-rc4, the list is pretty long (see below). Some commits are
>>> especially "suspects". So I would try a recent kernel first, as the
>>> driver may be faulty.
>>
>
> We are using an "ancient" (v3.2.0) kernel, and it includes the
> omap-serial driver.  We needed to receive at 460800baud (and now
> 1.5Mbaud), but the irq latency was too large to prevent the FIFO from
> overflowing.  This version of the omap-serial driver contained support
> for DMA transfers, but that support was _not_ enabled.  We modified the
> kernel to enable DMA, and it has worked quite nicely.
>
> We would have moved up to a newer version of the kernel, but the kernel
> DMA infrastructure was being reworked and the code for DMA in the
> omap-serial driver was dropped.  It may have been added back since that
> time, and if so, you may need to enable it.  Not sure how you might do
> that though.
>

Indeed, the DMA was dropped from the driver in kernel 3.7 (commit
[4945743 serial: omap: drop DMA support]). Looking at the current
driver, DMA was not added back... :-(

Without DMA, no surprise if you have bad throughput on a serial interface.

Regards,
Florian

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
In reply to this post by Florian Vaussard
Hi Florian,

Thanks for your continued assistance.
Sorry for the delayed response. I had some unexpected personal matters
to attend to.


On 02/27/2014 03:38 PM, Florian Vaussard wrote:

(snip)

>>> 3.5 is pretty old, and looking at the changelog compared to the current
>>> 3.14-rc4, the list is pretty long (see below). Some commits are
>>> especially "suspects". So I would try a recent kernel first, as the
>>> driver may be faulty.
>>
>> I think 3.8 is the most recent kernel with support for Gumstix Overo?
>> (Is that true?)
>>
> The latest stable kernel (3.13) has still the legacy support for Overo.
> So it should work. I am currently developing the "next-gen" support
> (device tree), and 3.13 has already enough support to boot. I just
> posted the patches to enable WiFi and a few other things, but this will
> not be merged before 3.15.
>
>> I will try a test with kernel 3.8, to see if there is any change with
>> the serial port write performance.
>>
>> Thanks for the list of changes. I'm feeling more optimistic that maybe
>> an updated kernel version will help solve this. If you have any info on
>> getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.
>>
> Just try 3.13, it should work.


Ok, I am trying 3.13.6.
I configured the kernel for Gumstix Overo. The compile task is failing:


|   OBJCOPY arch/arm/boot/zImage
|   Kernel: arch/arm/boot/zImage is ready
| multiple (or no) load addresses:
| This is incompatible with uImages
| Specify LOADADDR on the commandline to build an uImage
| make[1]: *** [arch/arm/boot/uImage] Error 1
| make: *** [uImage] Error 2
| ERROR: oe_runmake failed


I looked up the LOADADDR parameter, and it looks like it supposed to be
set to 0x80008000. My vague understanding is that this value should come
from the UBOOT_LOADADDRESS variable, which seems to be correctly set:

$ bitbake -e linux-gumstix | grep LOADADDR
# $UBOOT_LOADADDRESS [2 operations]
UBOOT_LOADADDRESS="0x80008000"


Someone else had a similar issue:
https://github.com/beagleboard/kernel/issues/52

... but there was no further explanation on what they did to fix it.

I've been able to build other kernels normally.
There don't appear to be any kernel config parameters to set LOADADDR.

I have the feeling it's something really simple... could you give me a hint?

Thanks very much,
Markus



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
Upon reading further, it looks like zImages are now the recommended way
to go, since U-boot supports them via the new bootz command:

http://lists.denx.de/pipermail/u-boot/2013-March/149243.html

Comments / thoughts?

Regards,
Markus


On 03/12/2014 06:33 PM, Markus Svilans wrote:

> Hi Florian,
>
> Thanks for your continued assistance.
> Sorry for the delayed response. I had some unexpected personal matters
> to attend to.
>
>
> On 02/27/2014 03:38 PM, Florian Vaussard wrote:
>
> (snip)
>>>> 3.5 is pretty old, and looking at the changelog compared to the current
>>>> 3.14-rc4, the list is pretty long (see below). Some commits are
>>>> especially "suspects". So I would try a recent kernel first, as the
>>>> driver may be faulty.
>>> I think 3.8 is the most recent kernel with support for Gumstix Overo?
>>> (Is that true?)
>>>
>> The latest stable kernel (3.13) has still the legacy support for Overo.
>> So it should work. I am currently developing the "next-gen" support
>> (device tree), and 3.13 has already enough support to boot. I just
>> posted the patches to enable WiFi and a few other things, but this will
>> not be merged before 3.15.
>>
>>> I will try a test with kernel 3.8, to see if there is any change with
>>> the serial port write performance.
>>>
>>> Thanks for the list of changes. I'm feeling more optimistic that maybe
>>> an updated kernel version will help solve this. If you have any info on
>>> getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.
>>>
>> Just try 3.13, it should work.
>
> Ok, I am trying 3.13.6.
> I configured the kernel for Gumstix Overo. The compile task is failing:
>
>
> |   OBJCOPY arch/arm/boot/zImage
> |   Kernel: arch/arm/boot/zImage is ready
> | multiple (or no) load addresses:
> | This is incompatible with uImages
> | Specify LOADADDR on the commandline to build an uImage
> | make[1]: *** [arch/arm/boot/uImage] Error 1
> | make: *** [uImage] Error 2
> | ERROR: oe_runmake failed
>
>
> I looked up the LOADADDR parameter, and it looks like it supposed to be
> set to 0x80008000. My vague understanding is that this value should come
> from the UBOOT_LOADADDRESS variable, which seems to be correctly set:
>
> $ bitbake -e linux-gumstix | grep LOADADDR
> # $UBOOT_LOADADDRESS [2 operations]
> UBOOT_LOADADDRESS="0x80008000"
>
>
> Someone else had a similar issue:
> https://github.com/beagleboard/kernel/issues/52
>
> ... but there was no further explanation on what they did to fix it.
>
> I've been able to build other kernels normally.
> There don't appear to be any kernel config parameters to set LOADADDR.
>
> I have the feeling it's something really simple... could you give me a hint?
>
> Thanks very much,
> Markus
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

bhamadicharef
In reply to this post by Markus Svilans-2
This is set for the bootagrs

At the very beginning of the booting sequence press a key
your system will prompt for commands ... Type

setenv loadaddr 0x80008000
saveenv
Reset
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Serial port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
Not sure if that's it.

The kernel compile fails because of it. It appears to be something
related to creating the uImage file.

Markus


On 03/12/2014 08:07 PM, bhamadicharef wrote:

> This is set for the bootagrs
>
> At the very beginning of the booting sequence press a key
> your system will prompt for commands ... Type
>
> setenv loadaddr 0x80008000
> saveenv
> Reset
>
>
>
> --
> View this message in context: http://gumstix.8.x6.nabble.com/Serial-port-write-issue-omap-serial-driver-230400-baud-tp4968825p4968914.html
> Sent from the Gumstix mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Florian Vaussard
In reply to this post by Markus Svilans-2
Hi Marcus,

On 03/12/2014 11:33 PM, Markus Svilans wrote:

> Hi Florian,
>
> Thanks for your continued assistance.
> Sorry for the delayed response. I had some unexpected personal matters
> to attend to.
>
>
> On 02/27/2014 03:38 PM, Florian Vaussard wrote:
>
> (snip)
>>>> 3.5 is pretty old, and looking at the changelog compared to the current
>>>> 3.14-rc4, the list is pretty long (see below). Some commits are
>>>> especially "suspects". So I would try a recent kernel first, as the
>>>> driver may be faulty.
>>>
>>> I think 3.8 is the most recent kernel with support for Gumstix Overo?
>>> (Is that true?)
>>>
>> The latest stable kernel (3.13) has still the legacy support for Overo.
>> So it should work. I am currently developing the "next-gen" support
>> (device tree), and 3.13 has already enough support to boot. I just
>> posted the patches to enable WiFi and a few other things, but this will
>> not be merged before 3.15.
>>
>>> I will try a test with kernel 3.8, to see if there is any change with
>>> the serial port write performance.
>>>
>>> Thanks for the list of changes. I'm feeling more optimistic that maybe
>>> an updated kernel version will help solve this. If you have any info on
>>> getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.
>>>
>> Just try 3.13, it should work.
>
>
> Ok, I am trying 3.13.6.
> I configured the kernel for Gumstix Overo. The compile task is failing:
>
>
> |   OBJCOPY arch/arm/boot/zImage
> |   Kernel: arch/arm/boot/zImage is ready
> | multiple (or no) load addresses:
> | This is incompatible with uImages
> | Specify LOADADDR on the commandline to build an uImage
> | make[1]: *** [arch/arm/boot/uImage] Error 1
> | make: *** [uImage] Error 2
> | ERROR: oe_runmake failed
>
>
> I looked up the LOADADDR parameter, and it looks like it supposed to be
> set to 0x80008000. My vague understanding is that this value should come
> from the UBOOT_LOADADDRESS variable, which seems to be correctly set:
>
> $ bitbake -e linux-gumstix | grep LOADADDR
> # $UBOOT_LOADADDRESS [2 operations]
> UBOOT_LOADADDRESS="0x80008000"
>
>
> Someone else had a similar issue:
> https://github.com/beagleboard/kernel/issues/52
>
> ... but there was no further explanation on what they did to fix it.
>
> I've been able to build other kernels normally.
> There don't appear to be any kernel config parameters to set LOADADDR.
>
> I have the feeling it's something really simple... could you give me a hint?
>

Sure. You have to specify LOADADDR when compiling the kernel:

make ARCH=arm LOADADDR=0x80008000 CROSS_COMPILE=[...] uImage

of course, replace the [...] with your cross-toolchain prefix.

Regards,
Florian

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
Hi Florian,

On 03/13/2014 04:04 AM, Florian Vaussard wrote:

> Hi Marcus,
>
> On 03/12/2014 11:33 PM, Markus Svilans wrote:
> Sure. You have to specify LOADADDR when compiling the kernel:
>
> make ARCH=arm LOADADDR=0x80008000 CROSS_COMPILE=[...] uImage
>
> of course, replace the [...] with your cross-toolchain prefix.
>
> Regards,
> Florian

Thank you!
Now I can build uImage.

However soon after I updated to the newer U-Boot 2013.07, and started
using zImage. First I had to #define CONFIG_CMD_BOOTZ in the U-boot
omap3_overo.h file.

My next experiment will be to try the U-Boot Falcon mode (fast boot)
with this kernel...

All the best,
Markus


>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
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 port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
In reply to this post by Florian Vaussard
Hi Florian,

Thanks to your help, I'm able to build a booting 3.13.6 kernel.

However the kernel does not seem to be able to talk to the Gumstix NAND
memory.

 From boot-up messages:

> [    2.265594] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc
> (Micron omap2-nand.0)
> [    2.273681] NAND bus width 8 instead 16 bit
> [    2.278137] No NAND device found
> [    2.281555] nand device scan failed, may be bus-width mismatch


And then later:

> [    2.694702] List of all partitions:
> [    2.698516] No filesystem could mount root, tried:  vfat msdos
> [    2.704956] Kernel panic - not syncing: VFS: Unable to mount root
> fs on unknown-block(1,0)


I've checked and re-checked the kernel config, to make sure the NAND
related entries match the ones from kernel 3.5.7, the latest "official"
Overo kernel from Gumstix. (Just in case it helps, I've attached the
defconfig I am using.)


The "NAND bus width 8 instead of 16" message seems to originate from
drivers/mtd/nand/nand_base.c:

line 3446:
                 pr_warn("NAND bus width %d instead %d bit\n",
                            (chip->options & NAND_BUSWIDTH_16) ? 16 : 8,
                            busw ? 16 : 8);

which seems to indicate that the NAND chip options is reporting the
wrong bus width? However I'm at a loss where to look next (my limited
knowledge of Linux kernel internals).

Any ideas?

Google turned up a couple of things from years ago, but no definite
solutions (that I could see at least).

Thanks very much,
Markus



On 03/13/2014 04:04 AM, Florian Vaussard wrote:

> Hi Marcus,
>
> On 03/12/2014 11:33 PM, Markus Svilans wrote:
>> Hi Florian,
>>
>> Thanks for your continued assistance.
>> Sorry for the delayed response. I had some unexpected personal matters
>> to attend to.
>>
>>
>> On 02/27/2014 03:38 PM, Florian Vaussard wrote:
>>
>> (snip)
>>>>> 3.5 is pretty old, and looking at the changelog compared to the current
>>>>> 3.14-rc4, the list is pretty long (see below). Some commits are
>>>>> especially "suspects". So I would try a recent kernel first, as the
>>>>> driver may be faulty.
>>>> I think 3.8 is the most recent kernel with support for Gumstix Overo?
>>>> (Is that true?)
>>>>
>>> The latest stable kernel (3.13) has still the legacy support for Overo.
>>> So it should work. I am currently developing the "next-gen" support
>>> (device tree), and 3.13 has already enough support to boot. I just
>>> posted the patches to enable WiFi and a few other things, but this will
>>> not be merged before 3.15.
>>>
>>>> I will try a test with kernel 3.8, to see if there is any change with
>>>> the serial port write performance.
>>>>
>>>> Thanks for the list of changes. I'm feeling more optimistic that maybe
>>>> an updated kernel version will help solve this. If you have any info on
>>>> getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.
>>>>
>>> Just try 3.13, it should work.
>>
>> Ok, I am trying 3.13.6.
>> I configured the kernel for Gumstix Overo. The compile task is failing:
>>
>>
>> |   OBJCOPY arch/arm/boot/zImage
>> |   Kernel: arch/arm/boot/zImage is ready
>> | multiple (or no) load addresses:
>> | This is incompatible with uImages
>> | Specify LOADADDR on the commandline to build an uImage
>> | make[1]: *** [arch/arm/boot/uImage] Error 1
>> | make: *** [uImage] Error 2
>> | ERROR: oe_runmake failed
>>
>>
>> I looked up the LOADADDR parameter, and it looks like it supposed to be
>> set to 0x80008000. My vague understanding is that this value should come
>> from the UBOOT_LOADADDRESS variable, which seems to be correctly set:
>>
>> $ bitbake -e linux-gumstix | grep LOADADDR
>> # $UBOOT_LOADADDRESS [2 operations]
>> UBOOT_LOADADDRESS="0x80008000"
>>
>>
>> Someone else had a similar issue:
>> https://github.com/beagleboard/kernel/issues/52
>>
>> ... but there was no further explanation on what they did to fix it.
>>
>> I've been able to build other kernels normally.
>> There don't appear to be any kernel config parameters to set LOADADDR.
>>
>> I have the feeling it's something really simple... could you give me a hint?
>>
> Sure. You have to specify LOADADDR when compiling the kernel:
>
> make ARCH=arm LOADADDR=0x80008000 CROSS_COMPILE=[...] uImage
>
> of course, replace the [...] with your cross-toolchain prefix.
>
> Regards,
> Florian
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/13534_NeoTech
> _______________________________________________
> gumstix-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/gumstix-users

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

defconfig (58K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Serial port write issue, omap-serial driver, 230400 baud

Markus Svilans-2
Hi Florian,

Some additional info:

I looked further into the "No NAND device found" error I was getting. It turns out a small fix in nand_base.c was able to resolve the issue.

Now the kernel was finding the NAND device properly:

[    0.975738] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron MT29F4G16ABBDA3W)
[    0.984222] NAND device: 512MiB, SLC, page size: 2048, OOB size: 64
[    0.990844] nand: error: CONFIG_MTD_NAND_OMAP_BCH not enabled
[    0.996978] omap2-nand: probe of omap2-nand.0 failed with error -22

... and there was the next problem. The kernel was trying to use hardware ECC because that's what board_nand_init() in board-flash.c told it to do. Fixed that, and now it looks like the kernel is finding the NAND partitions properly:

[    0.968902] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron MT29F4G16ABBDA3W)
[    0.977416] NAND device: 512MiB, SLC, page size: 2048, OOB size: 64
[    0.984039] nand: using OMAP_ECC_HAM1_CODE_HW
[    0.989410] Creating 6 MTD partitions on "omap2-nand.0":


The attached patch shows both changes.


In case anyone else is having this problem, you can apply the patch in your Yocto recipe like any other, by appending to your SRC_URI variable. Here is how my recipe looks:


# v3.13.6 = 404df65d0480f6da2b768f6c9b5259436b1de10f
SRCREV = "404df65d0480f6da2b768f6c9b5259436b1de10f"
SRC_URI = " \
    git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git;branch=linux-3.13.y \
    file://defconfig \
    file://0001-board-overo-customizations.patch \
    file://0002-nand-troubleshooting.patch \
"

and the file "0002-nand-troubleshooting.patch" goes in your linux/linux-gumstix-3.13.6/overo/ directory.

Regards,
Markus



On 03/16/2014 12:50 PM, Markus Svilans wrote:
Hi Florian,

Thanks to your help, I'm able to build a booting 3.13.6 kernel.

However the kernel does not seem to be able to talk to the Gumstix NAND memory.

From boot-up messages:

[    2.265594] NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron omap2-nand.0)
[    2.273681] NAND bus width 8 instead 16 bit
[    2.278137] No NAND device found
[    2.281555] nand device scan failed, may be bus-width mismatch


And then later:

[    2.694702] List of all partitions:
[    2.698516] No filesystem could mount root, tried:  vfat msdos
[    2.704956] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)


I've checked and re-checked the kernel config, to make sure the NAND related entries match the ones from kernel 3.5.7, the latest "official" Overo kernel from Gumstix. (Just in case it helps, I've attached the defconfig I am using.)


The "NAND bus width 8 instead of 16" message seems to originate from drivers/mtd/nand/nand_base.c:

line 3446:
                pr_warn("NAND bus width %d instead %d bit\n",
                           (chip->options & NAND_BUSWIDTH_16) ? 16 : 8,
                           busw ? 16 : 8);

which seems to indicate that the NAND chip options is reporting the wrong bus width? However I'm at a loss where to look next (my limited knowledge of Linux kernel internals).

Any ideas?

Google turned up a couple of things from years ago, but no definite solutions (that I could see at least).

Thanks very much,
Markus



On 03/13/2014 04:04 AM, Florian Vaussard wrote:
Hi Marcus,

On 03/12/2014 11:33 PM, Markus Svilans wrote:
Hi Florian,

Thanks for your continued assistance.
Sorry for the delayed response. I had some unexpected personal matters
to attend to.


On 02/27/2014 03:38 PM, Florian Vaussard wrote:

(snip)
3.5 is pretty old, and looking at the changelog compared to the current
3.14-rc4, the list is pretty long (see below). Some commits are
especially "suspects". So I would try a recent kernel first, as the
driver may be faulty.
I think 3.8 is the most recent kernel with support for Gumstix Overo?
(Is that true?)

The latest stable kernel (3.13) has still the legacy support for Overo.
So it should work. I am currently developing the "next-gen" support
(device tree), and 3.13 has already enough support to boot. I just
posted the patches to enable WiFi and a few other things, but this will
not be merged before 3.15.

I will try a test with kernel 3.8, to see if there is any change with
the serial port write performance.

Thanks for the list of changes. I'm feeling more optimistic that maybe
an updated kernel version will help solve this. If you have any info on
getting kernel 3.14-rc4 or 3.13 running on the Overo, I'd welcome it.

Just try 3.13, it should work.

Ok, I am trying 3.13.6.
I configured the kernel for Gumstix Overo. The compile task is failing:


|   OBJCOPY arch/arm/boot/zImage
|   Kernel: arch/arm/boot/zImage is ready
| multiple (or no) load addresses:
| This is incompatible with uImages
| Specify LOADADDR on the commandline to build an uImage
| make[1]: *** [arch/arm/boot/uImage] Error 1
| make: *** [uImage] Error 2
| ERROR: oe_runmake failed


I looked up the LOADADDR parameter, and it looks like it supposed to be
set to 0x80008000. My vague understanding is that this value should come
from the UBOOT_LOADADDRESS variable, which seems to be correctly set:

$ bitbake -e linux-gumstix | grep LOADADDR
# $UBOOT_LOADADDRESS [2 operations]
UBOOT_LOADADDRESS="0x80008000"


Someone else had a similar issue:
https://github.com/beagleboard/kernel/issues/52

... but there was no further explanation on what they did to fix it.

I've been able to build other kernels normally.
There don't appear to be any kernel config parameters to set LOADADDR.

I have the feeling it's something really simple... could you give me a hint?

Sure. You have to specify LOADADDR when compiling the kernel:

make ARCH=arm LOADADDR=0x80008000 CROSS_COMPILE=[...] uImage

of course, replace the [...] with your cross-toolchain prefix.

Regards,
Florian

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users



------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech


_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users


------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
_______________________________________________
gumstix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gumstix-users

0002-nand-troubleshooting.patch (1K) Download Attachment
Loading...