From: Markus S. <msv...@ae...> - 2014-02-26 20:27:06
|
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 |
From: Wenjia Z. <thi...@gm...> - 2014-02-26 20:43:59
|
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 <msv...@ae...> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > -- Airie Zhou |
From: Markus S. <msv...@ae...> - 2014-02-26 21:37:22
|
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 msv...@ae... +1 705 626 7257 Aeonyx Research Corporation www.aeonyx.ca |
From: bhamadicharef <bha...@ho...> - 2014-02-27 08:08:22
|
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... -- View this message in context: http://gumstix.8.x6.nabble.com/Serial-port-write-issue-omap-serial-driver-230400-baud-tp4968825p4968835.html Sent from the Gumstix mailing list archive at Nabble.com. |
From: Florian V. <flo...@ep...> - 2014-02-27 09:02:50
|
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. |
From: Markus S. <msv...@ae...> - 2014-02-27 19:46:03
|
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 |
From: Florian V. <flo...@ep...> - 2014-02-27 20:39:06
|
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 |
From: Markus S. <msv...@ae...> - 2014-03-12 22:33:32
|
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 |
From: Markus S. <msv...@ae...> - 2014-03-12 23:00:14
|
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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Florian V. <flo...@ep...> - 2014-03-13 08:04:23
|
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 |
From: Markus S. <msv...@ae...> - 2014-03-14 16:25:40
|
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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Markus S. <msv...@ae...> - 2014-03-16 16:50:18
Attachments:
defconfig
|
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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Markus S. <msv...@ae...> - 2014-03-16 21:54:58
Attachments:
0002-nand-troubleshooting.patch
|
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 >> gum...@li... >> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |
From: Patrick M. <pat...@dr...> - 2014-02-27 20:23:49
|
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 |
From: Florian V. <flo...@ep...> - 2014-02-27 20:43:33
|
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 |
From: bhamadicharef <bha...@ho...> - 2014-03-13 00:07:41
|
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. |
From: Markus S. <msv...@ae...> - 2014-03-13 00:13:44
|
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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users |