Re: 2.6.38 in Freescale Feb 2012 BSP

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 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