RT Page Fault.
Hello
I hope that this post won't be regarded as "dummy" one.
I'm struggling with 2.6.26.8-rt14 linux kernel for ARM architecture.
I'm using toolchain with uClibc 0.9.30, binutils 2.18 and gcc 4.2.4. I'm also using -msoft-float flag when I'm compiling my rt application. I'm performing heavy mathematical computations (mostly multiplication of double matrices).
The application is build around a simple static cyclic schedule with period of 20ms. During this time I'm performing my calculations for around 13 ms and sleep (with nanosleep) for 7ms. I'm using gettimeofday instead of clock_gettime. I've set it's rtprio as 71 (only posixtimer has 99 rtprio). I'm also using NFS to mount root file system from my host x86 ubuntu PC.
My application consist of several .c and .h files, which build several object files (.o). I'm also using some global variables defined at common_def.h header file. I'm linking this application statically (LDFLAG=-static), so executable binary has 113kB .My embedded system has 48MB of RAM to be used by Linux.
When I start my application it runs for some time and ends as expected. It seems that everything is OK. Static schedule is not violated. Unfortunately, after running this application for couple of times (6 to 10) I can see that static schedule is violated(delayed in execution) for about 2-4 seconds. Application is running for 1-2 seconds as expected and then crashes(I mean exits with static schedule delay of 2-4 seconds). It looks like page fault, but in my main() I've add mlockall() as writen in the examples from rt.wiki. Moreover I've prevent stack as written in "square_wave example". Before my application exits I'm calling munlockall(). When I log via ssh to my embedded system and start top,I cannot see that I've got some memory leaks or zombi processes during run of my RT application.
May it be possible that by some chance some global variable is not locked in the memory? What is the "scope" of mlockall? Is it only valid in one .o module or it lock all pages as they were loaded?
What is the order of loading binary executable to the memory? May it happen that in some case there is one page which was not locked and it causes page fault?
In my application I'm using some /dev/ files (like ttyS0). I'm opening it during startup of my program (with non block flag) and call read/write during my RT loop. I've checked that with of without call to this read/write functions bug described above shows up.
I have also try to replace NFS rootfs with the same rootfs from SD card. There was no difference and the bug was in both cases.
I'd appreciate any hints/comments what can cause this bug. I was trying to use strace and gdb to fix this problem, but this tools are to slow and they cause violation of my cyclic static schedule.
Thank's in advance,
Lukasz
Hello Lukasz,
Quoted 1 line
I'm also using NFS to mount root file system from my host x86 ubuntu PC.
Have you tried already running from a ram-disk?
Quoted 6 lines
When I start my application it runs for some time and ends as expected. It seems that everything is OK. Static schedule is not violated. Unfortunately, after running this application for couple of times (6 to 10) I can see that static schedule is violated(delayed in execution) for about 2-4 seconds. Application is running for 1-2 seconds as expected and then crashes(I mean exits with static schedule delay of 2-4 seconds). It looks like page fault,
You can trace the number of page-faults during run, by means of getrusage(), see rt-wiki.
2-4 seconds sounds quite long for page fault handling to me (unless you are using page/swap files)
Quoted 8 lines
but in my
main()I've addmlockall()as writen in the examples from rt.wiki. Moreover I've prevent stack as written in "square_waveexample". Before my application exits I'm callingmunlockall(). When I log via ssh to my embedded system and start top,I cannot see that I've got some memory leaks or zombi processes during run of my RT application.May it be possible that by some chance some global variable is not locked in the memory? What is the "scope" of mlockall? Is it only valid in one .o
mlockall() is somewhat tricky. It locks all allocated data pages (and future pages, if specified) in to RAM, but IIRC code segments are not forced to be loaded into RAM, but only code segments that are loaded once, will be locked. So, in theory, there could be pages still on the NFS share that are not loaded when the problem arises. So, this could be the problem you see, but it would not be the first suspect I would look for.
Quoted 1 line
I'd appreciate any hints/comments what can cause this bug.
I read you use uClibc, the last time I looked at it (quite some time ago), it lacked support for priority inheritance mutexes... Aren't you running in a mutex priority inversion?
Or priority inversion related to other interrupt threads? You run at prio 71, if you leave the network, or block device softirqs/irq-threads on 50, you could have a priority inversion on this level as well. This would be my prime suspect...
Quoted 3 lines
I was trying to
use strace and gdb to fix this problem, but this tools are to slow and they cause violation of my cyclic static schedule.
No ETM trace available? Really nice to have in such cases...
Kind Regards,
Remy
Hello,
Thank you for this extremely fast response. :-)
I haven't try to run my application from RAM disk (as suppose you suggest building initramrd or initramfs). It's inconvenient, for development, since size of such init ram disk is limited. I will try it anyway.
Now some explanation about uClibc. I know that this C library lacks of many features (for instance NTPL support for ARM). Unfortunately, for ARM architecture, there is nice utility -> buildroot for building toolchain and root filesystems. I'm not using x86 as target architecture, so cross compiling toolchain without errors is success as it is :-).
I've tried pxtdist tool from pengutronix.de , but I cannot build proper toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be precise). Or saying it in another way -> I gave up after spending some time and moved back toward working uClibc. I've build some toolchains, but during build I've encountered some errors and despite of that it, built arm-linux-gcc which worked, I wasn't sure if glibc is not cracked in some way.
On my first post I haven't mention that I was checking rusage struct for minor and major page faults.
In my program I checked it twice: first before calling mlockall() - on the beginning of the program and after munlockall() when program ends either when delay occurs or in normal termination. In both cases I've got the same number of minor and major page faults. So it looks that no page fault appears.
I've checked, and it turns out that uClibc 0.9.30 is not supporting PI (priority inversion) and futexes. This may cause my bug ,since I'm heavily using read/write on /dev/ files (read/write to 4 differen files). There's a lot of space for priority inversion in my code :-/. I was writing this code with holly faith that "in some way" priority inversion is avoided. I assumed, that access to some device (resource in this case) has some mechanism to inheritance the priority.
Is looks,that the only solution for me is to build toolchain with glibc at least 2.6 and gcc 4.+ with full support of Priority Inheritance, futexses and "clock_" set of functions. As I mentioned it's a bit tricky for ARM (especialy with proper ABI and software floating point support (msoft-float)). But it looks as the only feasible solution.
Thanks for advice.
Regards,
Lukasz
Quoted 68 lines · Remy Bohmer
Hello Lukasz,
Quoted 2 lines
I'm also using NFS to mount root file system from my host x86 ubuntu PC.
Have you tried already running from a ram-disk?
Quoted 7 lines
When I start my application it runs for some time and ends as expected. It seems that everything is OK. Static schedule is not violated. Unfortunately, after running this application for couple of times (6 to 10) I can see that static schedule is violated(delayed in execution) for about 2-4 seconds. Application is running for 1-2 seconds as expected and then crashes(I mean exits with static schedule delay of 2-4 seconds). It looks like page fault,
You can trace the number of page-faults during run, by means of
getrusage(), see rt-wiki.
2-4 seconds sounds quite long for page fault handling to me (unless you are using page/swap files)Quoted 9 lines
but in my
main()I've addmlockall()as writen in the examples from rt.wiki. Moreover I've prevent stack as written in "square_waveexample". Before my application exits I'm callingmunlockall(). When I log via ssh to my embedded system and start top,I cannot see that I've got some memory leaks or zombi processes during run of my RT application.May it be possible that by some chance some global variable is not locked in the memory? What is the "scope" of mlockall? Is it only valid in one .o
mlockall()is somewhat tricky. It locks all allocated data pages (and future pages, if specified) in to RAM, but IIRC code segments are not forced to be loaded into RAM, but only code segments that are loaded once, will be locked. So, in theory, there could be pages still on the NFS share that are not loaded when the problem arises. So, this could be the problem you see, but it would not be the first suspect I would look for.Quoted 2 lines
I'd appreciate any hints/comments what can cause this bug.
I read you use uClibc, the last time I looked at it (quite some time ago), it lacked support for priority inheritance mutexes... Aren't you running in a mutex priority inversion?
Or priority inversion related to other interrupt threads? You run at prio 71, if you leave the network, or block device softirqs/irq-threads on 50, you could have a priority inversion on this level as well. This would be my prime suspect...
Quoted 4 lines
I was trying to
use strace and gdb to fix this problem, but this tools are to slow and they cause violation of my cyclic static schedule.No ETM trace available? Really nice to have in such cases...
Kind Regards,
Remy
Hello Lukasz,
2009/2/23 Lukasz Majewski <[email protected]>:
Quoted 3 lines
Hello,
Thank you for this extremely fast response. :-)
No thanks :-)
Quoted 10 lines
Now some explanation about uClibc. I know that this C library lacks of many features (for instance NTPL support for ARM). Unfortunately, for ARM architecture, there is nice utility -> buildroot for building toolchain and
root filesystems. I'm not using x86 as target architecture, so cross
compiling toolchain without errors is success as it is :-).
I've tried pxtdist tool from pengutronix.de , but I cannot build proper toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be precise). Or saying it in another way -> I gave up after spending some time and moved back toward working uClibc. I've build some toolchains, but during build I've encountered some errors and despite of that it, built
If you have problems building compiler toolchains, there are other ways to do it.
You can use a precompiled (and tested) toolchain, for example:
* http://www.codesourcery.com/sgpp/lite/arm.
* http://www.denx.de/wiki/DULG/ELDK
* ....
The advantage of such a precompiled toolchain, is that it saves you a lot of build time, and you can focus on the things that matter for your application.
Quoted 10 lines
arm-linux-gcc which worked, I wasn't sure if glibc is not cracked in some way.
On my first post I haven't mention that I was checking rusage struct for minor and major page faults.
In my program I checked it twice: first before callingmlockall()- on the beginning of the program and aftermunlockall()when program ends either when delay occurs or in normal termination. In both cases I've got the same number of minor and major page faults. So it looks that no page fault appears.
Strange, normally mlockall generates a lot of pagefaults by just calling it, so there should be a difference before and directly after calling mlockall.
Quoted 7 lines
I've checked, and it turns out that uClibc 0.9.30 is not supporting PI (priority inversion) and futexes. This may cause my bug ,since I'm heavily using read/write on
/dev/files (read/write to 4 differen files). There's a lot of space for priority inversion in my code :-/. I was writing this code with holly faith that "in some way" priority inversion is avoided. I assumed, that access to some device (resource in this case) has some mechanism to inheritance the priority.
That depends on the driver behind it. In kernel there is always PI support on mutexes.
PI mutexes should be enabled for mutexes in your own code.
Do not forget to look at the priority of softirq-s/irq-threads related to your RT-threads.
if, for example, you have a thread running at prio 60, softirqs and irq-threads running at 50, and your RT thread is running at 70, and it has some dependency to the prio 50 irqs, then you could have an inversion problem here as well. The prio 60 task could prevent the softirqs and irq-threads from running, leaving the prio 70 task waiting for a very long time.
Quoted 5 lines
Is looks,that the only solution for me is to build toolchain with glibc at least 2.6 and gcc 4.+ with full support of Priority Inheritance, futexses and "
clock_" set of functions. As I mentioned it's a bit tricky for ARM (especialy with proper ABI and software floating point support (msoft-float)). But it looks as the only feasible solution.
As mentioned above, you could use a precompiled toolchain. It would at least safe you time to get it working, and if you still want to compile one yourself, you can always do it later...
Kind Regards,
Remy
Quoted 4 lines · Lukasz Majewski
Now some explanation about uClibc. I know that this C library lacks of many features (for instance NTPL support for ARM). Unfortunately, for ARM architecture, there is nice utility -> buildroot for building toolchain and root filesystems.
You can use ptxdist do do almost the same.
Quoted 4 lines
I've tried pxtdist tool from pengutronix.de, but I cannot build proper toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be precise). Or saying it in another way -> I gave up after spending some time and moved back toward working uClibc.
Well, you could have reported that to the OSELAS.Toolchain maintainers :)
What kind of problem do you see? We are using the the v5te toolchain quite intensively on AT91SAM9260 and AT91SAM9263 without problems.
So send us your error output and let's see what we can do. The ptxdist mailing list is probably the right list for that kind of discussion.
rsc
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hello Robert.
I'm building toolchain for AT572D940HF Atmel chip. It's ARM9 combined with DSP. I'd like to build toolchain for ARM9 (ARMv5tej) with -msoft-float support, EABI and full glibc ,to support all stuff connected with PREEMPT_RT patch - especially librt.
Now I've downloaded:
ptxdist-1.99.11 and ptxdist-1.99.11-patches.
and
OSELAS.Toolchain-1.99.3
I've selected ./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized
I need toolchain with -msoft-float support and EABI.
Unfortunately there is an error about mismatch in the linux-kernel headers. My Host PC has linux-kernel of 2.6.24 and not 2.6.27. My target is working under 2.6.26.8-rt14 kernel. The error is in building of NTPL library, after successfully compilation of gcc compiler.
How can I provide proper kernel headers?
Now I'm trying with arm-v5te-linux-gnueabi-gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18 ptxconfig. I hope that this will be sufficiently new to provide priority inheritance, futexes , librt with all features.
I'm building it now and hope that I won't encounter any problems.
Regards,
Lukasz
Quoted 27 lines · Robert Schwebel
Quoted 5 lines · Lukasz Majewski
Now some explanation about uClibc. I know that this C library lacks of many features (for instance NTPL support for ARM). Unfortunately, for ARM architecture, there is nice utility -> buildroot for building toolchain and root filesystems.
You can use ptxdist do do almost the same.
Quoted 5 lines
I've tried pxtdist tool from pengutronix.de, but I cannot build proper toolchain without errors for my Atmel's ARM9 device (ARMv5tej arch to be precise). Or saying it in another way -> I gave up after spending some time and moved back toward working uClibc.
Well, you could have reported that to the OSELAS.Toolchain maintainers :)
What kind of problem do you see? We are using the the v5te toolchain quite intensively on AT91SAM9260 and AT91SAM9263 without problems.
So send us your error output and let's see what we can do. The ptxdist mailing list is probably the right list for that kind of discussion.
rsc
Hi Lukasz,
Quoted 4 lines · Lukasz Majewski
I'm building toolchain for AT572D940HF Atmel chip. It's ARM9 combined with DSP. I'd like to build toolchain for ARM9 (ARMv5tej) with -msoft-float support, EABI and full glibc ,to support all stuff connected with
PREEMPT_RTpatch - especially librt.
Ok.
Quoted 2 lines
Now I've downloaded:
ptxdist-1.99.11 and ptxdist-1.99.11-patches.
yup
Quoted 2 lines
and
OSELAS.Toolchain-1.99.3
exactly
Quoted 4 lines
I've selected ./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized
I need toolchain with -msoft-float support and EABI.
The toolchain you've selected above actually is softfloat and EABI. You don't have to change anything, just do the steps you've mentioned above and 'ptxdist go'.
Quoted 2 lines
Unfortunately there is an error about mismatch in the linux-kernel headers.
Please send the exact error message (if too long, please off-list, to me and "Marc Kleine-Budde <[email protected]>").
Quoted 1 line
My Host PC has linux-kernel of 2.6.24 and not 2.6.27.
That's no problem; the toolchain you are trying to build is based on the 2.6.27 sanitized kernel headers. It's usually no problem at all using such a toolchain on a variety of other kernel versions.
Quoted 1 line
My target is working under 2.6.26.8-rt14 kernel.
Should work.
Quoted 4 lines
The error is in building of NTPL library, after successfully compilation of gcc compiler.
How can I provide proper kernel headers?
See above, error messages, please.
Quoted 4 lines
Now I'm trying with arm-v5te-linux-gnueabi-gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18 ptxconfig. I hope that this will be sufficiently new to provide priority inheritance, futexes , librt with all features.
Yes, it is.
Quoted 1 line
I'm building it now and hope that I won't encounter any problems.
You may want to check that we have an update for 1.99.3 here:
http://www.pengutronix.de/oselas/toolchain/download/OSELAS.Toolchain-1.99.3.1.tar.bz2
There has been a build error on some distros and it might happen that you are seeing exactly this issue.
rsc
Signature · 4 lines
Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Hello Robert,
I've tried to build toolchain using the following ptxconfig file:
./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized
I've also (as You advice) downloaded and used
OSELAS.Toolchain-1.99.3.1.tar.bz2
Then I've started building of my toolchain with
lukma@xxx:~/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1$ ../bin/ptxdist go
I've encountered following error (I hope that it's long enough to track it down.):
gawk -f ../scripts/gen-as-const.awk ../ports/sysdeps/arm/nptl/tcb-offsets.sym \
| /usr/bin/gcc -S -o /home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.hT3 -std=gnu99 -fgnu89-inline -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -g -Wstrict-prototypes -I../include -I/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/csu -I/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build -I../ports/sysdeps/arm/elf -I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl
-I../ports/sysdeps/unix/sysv/linux/arm/eabi -I../ports/sysdeps/unix/sysv/linux/arm/nptl -I../ports/sysdeps/unix/sysv/linux/arm -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv -I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/arm/eabi -I../ports/sysdeps/arm/nptl -I../ports/sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../np
tl -I.. -I../libio -I. -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.2.4/include -isystem /home/lukma/sbox_lukma/tools/arm-d940/arm-v5te-linux-gnueabi/gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/sysroot-arm-v5te-linux-gnueabi/usr/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -x c - \
-MD -MP -MF /home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h.dT -MT '/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h.d /home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h'
In file included from ../include/tls.h:6,
from ../ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:28,
from <stdin>:1:../ports/sysdeps/arm/nptl/tls.h:48:3: error: #error "TLS support is required."
In file included from ../include/tls.h:6,
from ../include/link.h:45,
from ../include/dlfcn.h:3,
from ../sysdeps/generic/ldsodefs.h:32,
from ../ports/sysdeps/arm/ldsodefs.h:39,
from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
from <stdin>:2:../ports/sysdeps/arm/nptl/tls.h:48:3: error: #error "TLS support is required."
In file included from ../ports/sysdeps/arm/nptl/tls.h:57,
from ../include/tls.h:6,
from ../include/link.h:45,
from ../include/dlfcn.h:3,
from ../sysdeps/generic/ldsodefs.h:32,
from ../ports/sysdeps/arm/ldsodefs.h:39,
from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
from <stdin>:2:../ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:31:3: error: #error Kernel headers are too old
In file included from <stdin>:1:
../ports/sysdeps/unix/sysv/linux/arm/eabi/sysdep.h:31:3: error: #error Kernel headers are too old
make[3]: *** [/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/rtld-global-offsets.h] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: *** [/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build/tcb-offsets.h] Error 1
make[3]: Leaving directory `/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8/csu'
make[2]: *** [csu/subdir_lib] Error 2
make[2]: Leaving directory `/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8'
make[1]: Leaving directory `/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/build-target/glibc-2.8-crt-build'
make[1]: *** [csu/subdir_lib] Error 2
make: *** [/home/lukma/sbox_lukma/build-tools/OSELAS.Toolchain-1.99.3.1/platform-arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/state/glibc-crt.compile] Error 2
I don't know what kind of error it is.
My host PC is running at Ubuntu 2.6.24-22-generic with gcc 4.2.4. I've only changed target directory from '/opt' to '/home/lukma/sbox_lukma/tools' with "ptxdist menuconfig". Above error is the same for
OSELAS.Toolchain-1.99.3 and OSELAS.Toolchain-1.99.3.1
Regards,
Lukasz.
Quoted 89 lines · Robert Schwebel
Hi Lukasz,
Quoted 5 lines · Lukasz Majewski
I'm building toolchain for AT572D940HF Atmel chip. It's ARM9 combined with DSP. I'd like to build toolchain for ARM9 (ARMv5tej) with -msoft-float support, EABI and full glibc ,to support all stuff connected with
PREEMPT_RTpatch - especially librt.Ok.
Quoted 3 lines
Now I've downloaded:
ptxdist-1.99.11 and ptxdist-1.99.11-patches.yup
Quoted 3 lines
and
OSELAS.Toolchain-1.99.3exactly
Quoted 5 lines
I've selected ./ptxconfigs/arm-v5te-linux-gnueabi-gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized
I need toolchain with -msoft-float support and EABI.
The toolchain you've selected above actually is softfloat and EABI. You don't have to change anything, just do the steps you've mentioned above and 'ptxdist go'.
Quoted 3 lines
Unfortunately there is an error about mismatch in the linux-kernel headers.
Please send the exact error message (if too long, please off-list, to me and "Marc Kleine-Budde <[email protected]>").
Quoted 2 lines
My Host PC has linux-kernel of 2.6.24 and not 2.6.27.
That's no problem; the toolchain you are trying to build is based on the 2.6.27 sanitized kernel headers. It's usually no problem at all using such a toolchain on a variety of other kernel versions.
Quoted 2 lines
My target is working under 2.6.26.8-rt14 kernel.
Should work.
Quoted 5 lines
The error is in building of NTPL library, after successfully compilation of gcc compiler.
How can I provide proper kernel headers?
See above, error messages, please.
Quoted 5 lines
Now I'm trying with arm-v5te-linux-gnueabi-gcc-4.1.2-glibc-2.5-binutils-2.17-kernel-2.6.18 ptxconfig. I hope that this will be sufficiently new to provide priority inheritance, futexes , librt with all features.
Yes, it is.
Quoted 2 lines
I'm building it now and hope that I won't encounter any problems.
You may want to check that we have an update for 1.99.3 here:
http://www.pengutronix.de/oselas/toolchain/download/OSELAS.Toolchain-1.99.3.1.tar.bz2There has been a build error on some distros and it might happen that you are seeing exactly this issue.
rsc