Angelo,

Try leaving off the -Wl-M... option when you use the uClinux toolchain.  That 
assumes you do not need a map.  If you do, you might have to manually run ld to 
generate that.

The last Code Sourcery ColdFire gcc I worked with can be downloaded from 
https://sourcery.mentor.com/public/gnu_toolchain/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2.
  I could not see ColdFire listed any longer on the Lite Edition web page, 
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition,
 so that may or may not be the last release.

You may have to use gdb to track down the location of your problem.  Here's an 
article about setting up a remote gdb debugger session: 
http://luv.asn.au/overheads/embedded/Debugging_uClinux_on_Coldfire.pdf.

Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov



On 23 Jan 2014, at 2:31 PM, Angelo Dureghello wrote:

> Dear Larry,
> 
> many thanks for the very useful info, unfortunately i have still not solved.
> 
> Original stack size in the header was 4096, i set it up growing until 65535, 
> same result, program block and paralize the uclinux system without any 
> wanring. 
> 
> I have some doubt, 
> 1) for example about the fact that i see that ti have compiled uclinux with 
> CodeSourcery toolchain (i did it some time ago don't remember exactly the 
> reason now), can this be an issue ? Anyway, actually i am compiling my c++ 
> program with this same toolchain (gcc 4.6.1).
> 2) could i have some uclinux configuration issues ? In particular i have 
> doubt on general setup and processor 
> 
> General Setup:
>  [*] Prompt for development and/or incomplete code/drivers
>  ()  Cross-compiler tool prefix  
>  ()  Local version - append to kernel release
>  [*] Automatically append version information to the version string 
>  [*] System V IPC
>  [ ] POSIX Message Queues 
>  [ ] BSD Process Accounting 
>  [ ] Export task/process statistics through netlink (EXPERIMENTAL)   
>  [ ] Auditing support 
> RCU Subsystem  --->  
>  [ ] Kernel .config support 
>  (14) Kernel log buffer size (16 => 64KB, 17 => 128KB)  
>  [ ] enable deprecated sysfs features to support old userspace tools 
>  [ ] Kernel->user space relay support (formerly relayfs) 
>  [ ] Namespaces support  
>  [ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
>  [ ] Optimize for size  
>  [*] Configure standard kernel features (for small systems)  --->
> Kernel Performance Events And Counters  --->    
>  [ ] Enable VM event counters for /proc/vmstat
>  [*] Enable SLUB debugging support   
>  [*] Disable heap randomization 
> Choose SLAB allocator (SLUB (Unqueued Allocator))  ---> 
>  [ ] Allow mmapped anonymous memory to be uninitialized 
>  [ ] Profiling support 
> GCOV-based kernel profiling  --->
> 
>     CPU (MCF5307)  --->
>  [*] Enable setting the CPU clock frequency 
>  (90000000) Set the core clock frequency
>  (2)   Set the core/bus clock divide ratio 
>  [ ] Old mask 5307 (1H55J) silicon 
>  *** Platform *** 
>  [*] Sysam AMCORE board support 
>  [ ] Arnewsh 5307 board support
>  [ ] Motorola M5307C3 board support
>  [ ] SnapGear SecureEdge/MP3 platform support 
>  [ ] Feith CLEOPATRA board support 
>  [ ] SecureEdge/NETtel board support  
>  [*] Support for U-Boot command line parameters  
>  [*] Use 4Kb for kernel stacks instead of 8Kb
>  *** RAM configuration *** 
>  (0) Address of the base of RAM 
>  (0x1000000) Size of RAM (in bytes), or 0 for automatic 
>  (0x0) Address of the base of system vectors 
>  (0x20000) Address of the base of kernel code
>  RAM bus width (AUTO)  --->
>  *** ROM configuration *** 
>  [ ] Specify ROM linker regions
>  Kernel executes from (RAM)  --->
>  Preemption Model (No Forced Preemption (Server))  --->  
>  Memory model (Flat Memory)  --->  
>    (1) Turn on mmap() excess space trimming before booting
> 
> Do you see something strange here ?
> 
> I go on investingating,
> 
> Many thanks,
> angelo
> 
> 
> 
> On 23/01/2014 19:49, Larry Baker wrote:
>> Angelo,
>> 
>> This sounds like your application stack size is too small and you are 
>> overflowing the stack.  Remember, uClinux has no MMU to protect for that.  
>> Try increasing the stack size.  Ted Ma told me once the application flthdr 
>> can manipulate the stack size in the executable's header:
>> 
>>> Hi Larry,
>>>   flthdr is the utility to manipulate the header
>>> ====
>>> The flat format also defines the stack size for an application as a field 
>>> in the flat header. To increase the stack allocated to an application, a 
>>> simple change of this field is all that is required. This can be done with 
>>> the flthdr command, like this:
>>> flthdr -s  flat-executable
>>> 
>>> The flat format also allows two compression options. The entire executable 
>>> can be compressed, providing maximum ROM savings. It also offers the often 
>>> useful side effect that the application is loaded entirely into a 
>>> contiguous RAM block. You also may choose data-segment-only compression. 
>>> This is important if you want to save ROM space but still want the option 
>>> to utilize XIP. The following:
>>> 
>>> flthdr -z flat-executable
>>>   creates a fully compressed executable, and
>>> 
>>> flthdr -d flat-executable
>>>   compresses only the data segment.
>>> ====
>>>                               ...MaTed
>> 
>> 
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> ba...@usgs.gov
>> 
>> 
>> 
>> On 23 Jan 2014, at 1:15 AM, Angelo Dureghello wrote:
>> 
>>> Dear all,
>>> 
>>> i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.
>>> 
>>> I have loaded on it this ucLinux:
>>> 
>>> ~ # cat /proc/version 
>>> uClinux version 2.6.36.2 (angelo@angel3) (gcc version 4.6.1 (Sourcery 
>>> CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 2012
>>> 
>>> I am now trying to upload and run a simple c++ program, with just 3 simple 
>>> classes,
>>> and a main().
>>> 
>>> Fist issue, 
>>> 
>>> I tried to use the most recent uclinux.org supplied toolchanin 
>>> (m68k-uclinux-20101118), 
>>> i get :
>>> 
>>> make
>>> /usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o 
>>> obj/base64.o src/base64.cc
>>> /usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o 
>>> obj/main.o src/main.cc
>>> /usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o 
>>> obj/sha256.o src/sha256.cc
>>> /usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o obj/sha256.o -m5307 
>>> -o bin/cfbm  -Wl,-Map,bin/cfbm.map
>>> ERROR: text=0x1c100 overlaps data=0x0 ?
>>> collect2: ld returned 1 exit status
>>> make: *** [bin/cfbm] Error 1
>>> 
>>> Surfing the net, i don't find any good explaination to this, and the common 
>>> workaround 
>>> suggested is to use the CodeSourcery toolchain.
>>> So as a first thing i was wondering if the uclinux "user" folder does 
>>> contain some cpp 
>>> projects, how do they compile ? 
>>> 
>>> Then i moved to the CodeSourcery toolchain, that i copied from an old hard 
>>> disk, since
>>> seems is not free to download anymore, is it ? Are there any alternative ?
>>> 
>>> 
>>> With this toolchain strange things happen, until a certain point, adding 
>>> code, everything 
>>> works fine, program is correctly compiled on my host and executed on the 
>>> board. Then, 
>>> strangely, as the code increase, the program execution crash (without 
>>> errors on console) 
>>> and paralize the system. As i remove (comment out) some lines, ini random 
>>> places, program
>>> start to work correctly again.
>>> So for now, also the CodeSourcery toolchain solution is not helping me.
>>> 
>>> I have now the suspect that uClinux itself has not been correctly 
>>> configured, or that i am
>>> suffering for my 16MB of ram, even if i see 6,8MB still free before 
>>> executing.
>>> 
>>> ~ # cat /proc/meminfo
>>> MemTotal:          13684 kB
>>> MemFree:            6984 kB
>>> Buffers:              16 kB
>>> Cached:              144 kB
>>> SwapCached:            0 kB
>>> Active:               64 kB
>>> Inactive:             48 kB
>>> Active(anon):          0 kB
>>> Inactive(anon):        0 kB
>>> Active(file):         64 kB
>>> Inactive(file):       48 kB
>>> Unevictable:           0 kB
>>> Mlocked:               0 kB
>>> MmapCopy:            412 kB
>>> SwapTotal:             0 kB
>>> SwapFree:              0 kB
>>> Dirty:                40 kB
>>> Writeback:             0 kB
>>> AnonPages:             0 kB
>>> Mapped:                0 kB
>>> Shmem:                 0 kB
>>> Slab:               1292 kB
>>> SReclaimable:         64 kB
>>> SUnreclaim:         1228 kB
>>> KernelStack:         108 kB
>>> PageTables:            0 kB
>>> NFS_Unstable:          0 kB
>>> Bounce:                0 kB
>>> WritebackTmp:          0 kB
>>> CommitLimit:        6840 kB
>>> Committed_AS:          0 kB
>>> VmallocTotal:          0 kB
>>> VmallocUsed:           0 kB
>>> VmallocChunk:          0 kB
>>> 
>>> 
>>> I don't know actually how to move, every help is accepted.
>>> 
>>> Many thanks,
>>> angelo
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> uClinux-dev mailing list
>>> uClinux-dev@uclinux.org
>>> http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
>>> This message was resent by uclinux-dev@uclinux.org
>>> To unsubscribe see:
>>> http://mailman.uclinux.org/mailman/options/uclinux-dev
>> 
> 

_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to