Re: 2.6.38 in Freescale Feb 2012 BSP

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