Re: 2.6.38 in Freescale Feb 2012 BSP
Steve deRosier <[email protected]>
| Newsgroups | gmane.linux.uclinux.devel |
|---|---|
| Message-ID | <CALLGbRLNgA2SF1U1RJOq_OQQi-6ihkFotTeE8zZAujy==3F7PA@mail.gmail.com> |
I think it was already suggested: you need to enable flow-control. Either hardware if you've got the pins setup right on that port or software (xon/xoff) if you don't. On Tue, Nov 12, 2013 at 4:11 AM, Raju B <[email protected]> wrote: > Hi Michael, > > I have tried with baudrate = 9600 and 19200, then it is working fine(i.e > getting data, no overruns). but i want to use high speed(115200). can u > please give any suggestion to over come this. > > Thanks &r Regards, > Raju > > > On Thu, Nov 7, 2013 at 10:06 PM, Michael Durrant <[email protected]>wrote: > >> Raju, >> >> I would expect data overruns causing lost characters if your CPU >> utilization is high and your kernel >> driver can't get back to servicing the UART IRQ fast enough. Your >> MCF523x part appears to have >> only a small FIFO buffer (a shift register and 3 receiver registers). >> So if the data rate is faster than >> the kernel can remove the data hardware FIFO it is likely you will miss >> data due to overruns. So >> in your case the 10th character was lost (overwritten) by the next >> character. Sounds like you need >> DMA support for the UART you are using or perhaps slow down the incoming >> data or perhaps >> turn hardware flow control on. >> >> Michael >> >> On 11/06/2013 04:40 AM, Raju B wrote: >> >> Hi Michael, >> >> The ColdFire is 523x and using UART serial interface. >> >> Thanks & regards, >> Raju B >> >> >> On Tue, Nov 5, 2013 at 10:47 PM, Michael Durrant <[email protected]>wrote: >> >>> >>> Raj, >>> >>> Which ColdFire are you using? >>> Which serial interface are you seeing this with (UART/SPI/I2C/..)? >>> >>> Michael >>> >>> >>> On 11/05/2013 07:40 AM, Raju B wrote: >>> >>> whenever i am trying to receive data from serial communication >>> continuously in uClinux, I am getting every 10th byte is overwrite by 11 >>> byte and so on.... >>> >>> Iam using freescale coldfire processor. Could you any body please >>> help me to resolve this issue. >>> >>> Thanks & Regards, >>> Raj >>> >>> >>> On Fri, Sep 13, 2013 at 10:16 PM, Lennart Sorensen < >>> [email protected]> wrote: >>> >>>> On Fri, Sep 13, 2013 at 11:28:52AM -0400, Bair, Richard wrote: >>>> > I have a 4.7MB application that runs on the 2.6.26 kernel (Freescale >>>> BSP) and am working to make it run on the 2.6.38 kernel released in the >>>> ColdFire BSP in Feb 2012. I'm concerned about memory allocation as my >>>> first attempt to run on the 38 kernel appears to be using 2^n memory >>>> allocation vs. allocation that sizes just 1-page over the application. >>>> > >>>> > 1) Can anyone tell me the exact kernel config name that needs to be >>>> adjusted for the 38 kernel to set the default memory allocation? >>>> > - Older posts indicate modules like page_alloc2 or Kmalloc2 >>>> control this so I'm going to investigate these in more detail >>>> > - RTFMing indicate that this might be the area but I don't see >>>> it in the 38 version (LTIB or make menucionfig): >>>> > menuconfig -> kernel settings -> general settings, try >>>> enabling either the "Permit large allocations" setting, or the >>>> "non-power-of-2" >>>> > >>>> > 2) Historically, we use LTIB to create the kernel. Does LTIB expose >>>> most/all settings of the 2.6.38 kernel? Can it be out of sync with the >>>> make menuconfig uClinus kernel? >>>> >>>> Maybe this changed the behaviour you see: >>>> >>>> commit fc4d5c292b68ef02514d2072dcbf82d090c34875 >>>> Author: David Howells <[email protected]> >>>> Date: Wed May 6 16:03:05 2009 -0700 >>>> >>>> nommu: make the initial mmap allocation excess behaviour Kconfig >>>> configurable >>>> >>>> NOMMU mmap() has an option controlled by a sysctl variable that >>>> determines >>>> whether the allocations made by do_mmap_private() should have the >>>> excess >>>> space trimmed off and returned to the allocator. Make the initial >>>> setting >>>> of this variable a Kconfig configuration option. >>>> >>>> The reason there can be excess space is that the allocator only >>>> allocates >>>> in power-of-2 size chunks, but mmap()'s can be made in sizes that >>>> aren't a >>>> power of 2. >>>> >>>> There are two alternatives: >>>> >>>> (1) Keep the excess as dead space. The dead space then remains >>>> unused for the >>>> lifetime of the mapping. Mappings of shared objects such as >>>> libc, ld.so >>>> or busybox's text segment may retain their dead space forever. >>>> >>>> (2) Return the excess to the allocator. This means that the dead >>>> space is >>>> limited to less than a page per mapping, but it means that for >>>> a transient >>>> process, there's more chance of fragmentation as the excess >>>> space may be >>>> reused fairly quickly. >>>> >>>> During the boot process, a lot of transient processes are created, >>>> and >>>> this can cause a lot of fragmentation as the pagecache and various >>>> slabs >>>> grow greatly during this time. >>>> >>>> By turning off the trimming of excess space during boot and >>>> disabling >>>> batching of frees, Coldfire can manage to boot. >>>> >>>> A better way of doing things might be to have /sbin/init turn this >>>> option >>>> off. By that point libc, ld.so and init - which are all >>>> long-duration >>>> processes - have all been loaded and trimmed. >>>> >>>> Reported-by: Lanttor Guo <[email protected]> >>>> Signed-off-by: David Howells <[email protected]> >>>> Tested-by: Lanttor Guo <[email protected]> >>>> Cc: Greg Ungerer <[email protected]> >>>> Signed-off-by: Andrew Morton <[email protected]> >>>> Signed-off-by: Linus Torvalds <[email protected]> >>>> >>>> After all before this commit, trimming after allocating was always done. >>>> Now it is only done if you enable this CONFIG, or set the sysctl flag >>>> at runtime, which of course affects behaviour for all allocations after >>>> you change the setting. >>>> >>>> -- >>>> Len Sorensen >>>> _______________________________________________ >>>> uClinux-dev mailing list >>>> [email protected] >>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>>> This message was resent by [email protected] >>>> To unsubscribe see: >>>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>>> >>> >>> >>> >>> _______________________________________________ >>> uClinux-dev mailing [email protected]://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by [email protected] >>> To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >>> >>> >>> _______________________________________________ >>> uClinux-dev mailing list >>> [email protected] >>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >>> This message was resent by [email protected] >>> To unsubscribe see: >>> http://mailman.uclinux.org/mailman/options/uclinux-dev >>> >> >> >> >> _______________________________________________ >> uClinux-dev mailing [email protected]://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by [email protected] >> To unsubscribe see:http://mailman.uclinux.org/mailman/options/uclinux-dev >> >> >> >> _______________________________________________ >> uClinux-dev mailing list >> [email protected] >> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev >> This message was resent by [email protected] >> To unsubscribe see: >> http://mailman.uclinux.org/mailman/options/uclinux-dev >> > > > _______________________________________________ > uClinux-dev mailing list > [email protected] > http://mailman.uclinux.org/mailman/listinfo/uclinux-dev > This message was resent by [email protected] > To unsubscribe see: > http://mailman.uclinux.org/mailman/options/uclinux-dev > _______________________________________________ uClinux-dev mailing list [email protected] http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by [email protected] To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev