Angelo, > I am now only confused now about the fact that uClinux die (blocks > completely) silently in this case, if this is normal.
Yes, this is indeed what can happen on a system like uClinux that does not have an MMU (memory management unit). The tiny controller chips that uClinux targets do not protect any part of the memory from being accidentally corrupted. As long as the memory being accessed exists, there is no hardware fence between a user program and the rest of memory. In a system that does have an MMU, accesses out of the bounds of an executing program cause an illegal access violation and the operating system will normally kill the program. Without such protection, any program can clobber the memory of any other program or the operating system, with unpredictable results -- usually a failure of some kind. Languages like C make it particularly easy to do. Larry Baker US Geological Survey 650-329-5608 ba...@usgs.gov On 12 Feb 2014, at 4:30 PM, Angelo Dureghello wrote: > Dear all, > > thanks for all the support, > > i could get back working on this, seems the issue was in my code, i was > someway breaking the memory with a bad pointer. > > I am now only confused now about the fact that uClinux die (blocks > completely) silently in this case, if this is normal. > > Many thanks > Angelo > > On 28/01/2014 20:38, Larry Baker wrote: >> 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
_______________________________________________ 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
