Dear Larry and all,
many thanks for your kind reply,
i enabled all the kernel debug / dump support options i found, but still
my application, together with the kernel, locks silently, blocking the
whole system without any message. Once the system is locked, i don't
have any network or console access anymore.
/var/tmp # cat /proc/buddyinfo
Node 0, zone DMA 1 6 16 5 3 5 3
1 0 0 1
/var/tmp #
My application in c++ has now about 500K, shouldn't be a memory space
problem.
/var/tmp # ls
cfbm jffs2
/var/tmp # ls -al
drwxr-xr-x 3 root 0 1024 Jan 14 17:36 .
drwxr-xr-x 6 root 0 1024 Jan 14 17:27 ..
-rwxr-xr-x 1 root 0 580956 Jan 14 17:36 cfbm
drwxr-xr-x 6 root 0 0 Jan 1 1970 jffs2
/var/tmp # cat /proc/meminfo
MemTotal: 13560 kB
MemFree: 5988 kB
Buffers: 28 kB
Cached: 724 kB
SwapCached: 0 kB
Active: 128 kB
/var/tmp # ./cfbm
s 1
s 2
s 3
s 6
After launching the app, i just see some traces i "cout" and then the
whole system stops.
Some time i see "s6" trace, some time "s3"only.
Strangely, i never had any issue with C apps until now, but they are
generally much smaller.
Regards,
Angelo
On 24/01/2014 22:50, Larry Baker wrote:
Angelo,
My most frustrating experience with uClinux was with the memory
allocator. Linux uses a "buddy" system power-of-2 allocator. It is
VERY easy to fragment memory such that no more can be allocated.
Usually I received an error message, which you say does not happen
for you. Perhaps that is because in my case, the memory allocation
failure occurs during program loading, while yours occurs during
program execution (C++ startup vs. a plain C program?).
The current memory free list is in . Memory is organized into blocks
by powers-of-2. The first one is the 2^0 * PAGESIZE. PAGESIZE is
4096 on x86 systems. To find out the PAGESIZE, try "getconf PAGESIZE"
or "getconf PAGE_SIZE" (unless someone on the list knows what it is
for a coldfire mcf5307). Even if there are, for example, 6 MB free
memory and your program only needs 5 MB, you won't be able to run your
program, because the next higher power-of-2 is 8 MB.
Maybe this is what is happening to you. I moved on to using SoC ARM
chips with lots more RAM and MMUs because I was wasting so much time
trying to squeeze a program to fit in an uClinux system.
Larry Baker
US Geological Survey
650-329-5608
ba...@usgs.gov <mailto: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 <mailto: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 <http://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 <mailto: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
