* [Xenomai-help] Support for ARCH_MV88F6290
@ 2009-10-14 6:19 Didenko Sergey
2009-10-14 7:25 ` Gilles Chanteperdrix
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-10-14 6:19 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 2473 bytes --]
Dear Gilles
when I did change the HW Timer interrupt number (__ipipe_mach_timerint) from
0 to 1
Patched kernel is able to boot up...but I'm not sure whether Xenomai is
running or not even I can see the messages that it is started...
To verify whether it is running or not I want to do latency test ..for
that..I'm following the HOWTO which says that I have to
1) configure Xenomai
$ ./configure --build=i686-pc-linux-gnu --host=arm-linux
--enable-arm-mach=generic --enable-arm-tsc
2) make Install
When I do "make DESTDIR=/nfs install" where /nfs - is the NFS path to rootfs
mounted by board.
I have next situation...
===
[d.sergey@domain.hid xenomai-2.4.9.1]$ make DESTDIR=/nfs install
Making install in src
make[1]: Entering directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src'
Making install in include
make[2]: Entering directory
`/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
make[3]: Entering directory
`/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory
`/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
make[2]: Leaving directory
`/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
Making install in rtdk
make[2]: Entering directory
`/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4
-D__XENO__ -D__IN_XENO__ -Wstrict-prototypes -I../../include -MT
librtdk_la-init.lo -MD -MP -MF .deps/librtdk_la-init.Tpo -c -o
librtdk_la-init.lo `test -f 'init.c' || echo './'`init.c
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src/include -O2
-D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4 -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I../../include -MT librtdk_la-init.lo -MD -MP -MF
.deps/librtdk_la-init.Tpo -c init.c -fPIC -DPIC -o .libs/librtdk_la-init.o
init.c:1: error: bad value (armv4) for -march= switch
init.c:1: error: bad value (armv4) for -mtune= switch
make[2]: *** [librtdk_la-init.lo] Error 1
make[2]: Leaving directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src'
make: *** [install-recursive] Error 1
[d.sergey@domain.hid xenomai-2.4.9.1]$
====
What is wrong?
How can I patch the rootfs with Xenomai libraries correctly?
Sergey
[-- Attachment #2: Type: text/html, Size: 2711 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-14 6:19 [Xenomai-help] Support for ARCH_MV88F6290 Didenko Sergey
@ 2009-10-14 7:25 ` Gilles Chanteperdrix
2009-10-16 5:26 ` Didenko Sergey
0 siblings, 1 reply; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-10-14 7:25 UTC (permalink / raw)
To: Didenko Sergey; +Cc: xenomai
Didenko Sergey wrote:
> Dear Gilles
>
> when I did change the HW Timer interrupt number (__ipipe_mach_timerint) from
> 0 to 1
> Patched kernel is able to boot up...but I'm not sure whether Xenomai is
> running or not even I can see the messages that it is started...
> To verify whether it is running or not I want to do latency test ..for
> that..I'm following the HOWTO which says that I have to
> 1) configure Xenomai
> $ ./configure --build=i686-pc-linux-gnu --host=arm-linux
> --enable-arm-mach=generic --enable-arm-tsc
>
> 2) make Install
> When I do "make DESTDIR=/nfs install" where /nfs - is the NFS path to rootfs
> mounted by board.
> I have next situation...
>
> ===
>
> [d.sergey@domain.hid xenomai-2.4.9.1]$ make DESTDIR=/nfs install
> Making install in src
> make[1]: Entering directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src'
> Making install in include
> make[2]: Entering directory
> `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> make[3]: Entering directory
> `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> make[3]: Nothing to be done for `install-exec-am'.
> make[3]: Nothing to be done for `install-data-am'.
> make[3]: Leaving directory
> `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> make[2]: Leaving directory
> `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> Making install in rtdk
> make[2]: Entering directory
> `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk'
> /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4
> -D__XENO__ -D__IN_XENO__ -Wstrict-prototypes -I../../include -MT
> librtdk_la-init.lo -MD -MP -MF .deps/librtdk_la-init.Tpo -c -o
> librtdk_la-init.lo `test -f 'init.c' || echo './'`init.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src/include -O2
> -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4 -D__XENO__ -D__IN_XENO__
> -Wstrict-prototypes -I../../include -MT librtdk_la-init.lo -MD -MP -MF
> .deps/librtdk_la-init.Tpo -c init.c -fPIC -DPIC -o .libs/librtdk_la-init.o
> init.c:1: error: bad value (armv4) for -march= switch
> init.c:1: error: bad value (armv4) for -mtune= switch
> make[2]: *** [librtdk_la-init.lo] Error 1
> make[2]: Leaving directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk'
> make[1]: *** [install-recursive] Error 1
> make[1]: Leaving directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src'
> make: *** [install-recursive] Error 1
> [d.sergey@domain.hid xenomai-2.4.9.1]$
Your problem here is that you are trying to use gcc (that is probably an
x86 gcc) with options for an ARM gcc. It does not work. You have to
ensure that the build system uses your cross-compiler.
>
> ====
>
> What is wrong?
> How can I patch the rootfs with Xenomai libraries correctly?
I have no idea. But I can tell you that you do not need to patch
anything. It should work out of the box.
--
Gilles.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-14 7:25 ` Gilles Chanteperdrix
@ 2009-10-16 5:26 ` Didenko Sergey
2009-10-16 7:43 ` Gilles Chanteperdrix
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-10-16 5:26 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai, Jorge Ramirez, mohamad.sharifi
[-- Attachment #1: Type: text/plain, Size: 16795 bytes --]
In my case the paths are like:
# $linux_tree = /home/d.sergey/kernel/linux-2.6.29-v02.00.29
# $xenomai_root = /home/d.sergey/xemomai/xenomai-2.4.9.1
# $build_root = /home/d.sergey/build_root
# $staging_dir = /nfs/rootfs
CROSS_COMPILE - arm-none-linux-gnueabi
So, I do
1) $ $xenomai_root/scripts/prepare-kernel.sh --arch=arm --linux=$linux_tree
ENTER
I omitt --adeos parameter and the script suggests an appropriate one, ENTER
2) Apply patch from Jorge and fix some compilation errors
3) $ cd $linux_tree
4) $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
O=/home/d.sergey/build_root cosmos_mono_defconfig -j5
5) $ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
O=/home/d.sergey/build_root bzImage modules -j5
6) $ cd $build_root
7) $ /home/d.sergey/xemomai/xenomai-2.4.9.1/configure
--build=i686-pc-linux-gnu --host=arm-linux --enable-arm-mach=generic
--enable-arm-tsc
so far everything looks good
==== LOG
checking build system type... i686-pc-linux-gnu
checking host system type... arm-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking for arm-linux-gcc... no
checking for gcc... gcc
configure: WARNING: using cross tools not prefixed with host triplet
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking target system type... arm-unknown-linux-gnu
checking for arm-linux-gcc... no
checking for gcc... gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... no
checking for gcc option to accept ISO C89... (cached) none needed
checking how to run the C preprocessor... gcc -E
checking whether build environment is sane... yes
checking for arm-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether to enable maintainer-specific portions of Makefiles... no
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... no
checking for arm-linux-dumpbin... no
checking for arm-linux-link... no
checking for dumpbin... no
checking for link... link -dump -symbols
checking the name lister (link -dump -symbols) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 98304
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for arm-linux-ar... no
checking for ar... ar
checking for arm-linux-strip... strip
checking for arm-linux-ranlib... no
checking for ranlib... ranlib
checking command to parse link -dump -symbols output from gcc object...
failed
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries...
yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking dependency style of gcc... gcc3
checking for flex... flex
checking lex output file root... lex.yy
checking lex library... -lfl
checking whether yytext is a pointer... yes
checking for target architecture... arm
checking for debug symbols... no
checking for SMP support... no
checking for ARM machine... generic
checking for ARM architecture version... 4
checking for ARM SA1100 architecture... y
checking for TSC emulation in user-space.... not supported by this board
checking for ARM EABI interface... no
checking whether building Linux in Xenomai build tree... no
checking for Doxygen documentation... no
checking for doxygen... doxygen
checking for dot... NO
checking whether compiling Docbook XML documentation... no
checking for xmllint... xmllint
checking for xsltproc... xsltproc
checking for fop... no
checking whether Docbook XML documentation generation can use network.... no
checking for docbook-xml root dir... network
checking for docbook-xsl root dir... network
checking whether using LaTeX non-stop mode... no
checking mqueue.h usability... yes
checking mqueue.h presence... yes
checking for mqueue.h... yes
checking for sched_setaffinity... ok
checking for specific GCC switches... done
checking whether ld supports @file... yes
checking whether the POSIX skin library automatically calls mlockall... no
checking whether the pSOS skin library automatically calls mlockall... no
checking whether the uITRON skin library automatically calls mlockall... no
checking for shm_open... yes
checking for shm_unlink... yes
checking for mmap64... yes
checking for ftruncate64... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating config/Makefile
config.status: creating scripts/Makefile
config.status: creating scripts/xeno-config
config.status: creating scripts/xeno-load
config.status: creating scripts/xeno-test
config.status: creating src/Makefile
config.status: creating src/rtdk/Makefile
config.status: creating src/skins/Makefile
config.status: creating src/skins/posix/Makefile
config.status: creating src/skins/native/Makefile
config.status: creating src/skins/vxworks/Makefile
config.status: creating src/skins/psos+/Makefile
config.status: creating src/skins/vrtx/Makefile
config.status: creating src/skins/rtdm/Makefile
config.status: creating src/skins/rtai/Makefile
config.status: creating src/skins/uitron/Makefile
config.status: creating src/include/Makefile
config.status: creating src/testsuite/Makefile
config.status: creating src/testsuite/latency/Makefile
config.status: creating src/testsuite/switchbench/Makefile
config.status: creating src/testsuite/cyclic/Makefile
config.status: creating src/testsuite/switchtest/Makefile
config.status: creating src/testsuite/irqbench/Makefile
config.status: creating src/testsuite/clocktest/Makefile
config.status: creating src/testsuite/klatency/Makefile
config.status: creating src/utils/Makefile
config.status: creating src/utils/can/Makefile
config.status: creating include/Makefile
config.status: creating include/asm-generic/Makefile
config.status: creating include/asm-generic/bits/Makefile
config.status: creating include/asm-blackfin/Makefile
config.status: creating include/asm-blackfin/bits/Makefile
config.status: creating include/asm-x86/Makefile
config.status: creating include/asm-x86/bits/Makefile
config.status: creating include/asm-powerpc/Makefile
config.status: creating include/asm-powerpc/bits/Makefile
config.status: creating include/asm-ia64/Makefile
config.status: creating include/asm-ia64/bits/Makefile
config.status: creating include/asm-arm/Makefile
config.status: creating include/asm-arm/bits/Makefile
config.status: creating include/asm-sim/Makefile
config.status: creating include/asm-sim/bits/Makefile
config.status: creating include/native/Makefile
config.status: creating include/nucleus/Makefile
config.status: creating include/posix/Makefile
config.status: creating include/posix/sys/Makefile
config.status: creating include/psos+/Makefile
config.status: creating include/rtai/Makefile
config.status: creating include/rtdm/Makefile
config.status: creating include/uitron/Makefile
config.status: creating include/vrtx/Makefile
config.status: creating include/vxworks/Makefile
config.status: creating doc/Makefile
config.status: creating doc/txt/Makefile
config.status: creating doc/man/Makefile
config.status: creating doc/man/clocktest.man
config.status: creating doc/man/cyclictest.man
config.status: creating doc/man/irqbench.man
config.status: creating doc/man/irqloop.man
config.status: creating doc/man/klatency.man
config.status: creating doc/man/latency.man
config.status: creating doc/man/rtcanconfig.man
config.status: creating doc/man/rtcanrecv.man
config.status: creating doc/man/rtcansend.man
config.status: creating doc/man/switchbench.man
config.status: creating doc/man/switchtest.man
config.status: creating doc/man/runinfo.man
config.status: creating doc/man/xeno-config.man
config.status: creating doc/man/xeno-info.man
config.status: creating doc/man/xeno-load.man
config.status: creating doc/man/xeno-test.man
config.status: creating doc/doxygen/Makefile
config.status: creating doc/doxygen/Doxyfile-common
config.status: creating doc/doxygen/Doxyfile
config.status: creating doc/doxygen/Doxyfile-native
config.status: creating doc/doxygen/Doxyfile-nucleus
config.status: creating doc/doxygen/Doxyfile-posix
config.status: creating doc/doxygen/Doxyfile-rtdm
config.status: creating doc/docbook/Makefile
config.status: creating doc/docbook/catalog
config.status: creating doc/docbook/custom-stylesheets/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/common/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/fo/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/html/Makefile
config.status: creating doc/docbook/custom-stylesheets/xsl/html/chunk.xsl
config.status: creating doc/docbook/custom-stylesheets/xsl/html/onechunk.xsl
config.status: creating doc/docbook/xenomai/Makefile
config.status: creating src/include/xeno_config.h
config.status: linking
/home/d.sergey/xemomai/xenomai-2.4.9.1/include/asm-arm to
src/include/asm/xenomai
config.status: linking
/home/d.sergey/xemomai/xenomai-2.4.9.1/include/asm-generic to
src/include/asm-generic/xenomai
config.status: executing depfiles commands
config.status: executing libtool commands
====
But when I do
8) $ make DESTDIR=/nfs/rootfs install
I have next messages:
=== LOG
[d.sergey@domain.hid build_root]$ make DESTDIR=/nfs/rootfs install
Making install in src
make[1]: Entering directory `/home/d.sergey/build_root/src'
Making install in include
make[2]: Entering directory `/home/d.sergey/build_root/src/include'
make[3]: Entering directory `/home/d.sergey/build_root/src/include'
make[3]: Nothing to be done for `install-exec-am'.
make[3]: Nothing to be done for `install-data-am'.
make[3]: Leaving directory `/home/d.sergey/build_root/src/include'
make[2]: Leaving directory `/home/d.sergey/build_root/src/include'
Making install in rtdk
make[2]: Entering directory `/home/d.sergey/build_root/src/rtdk'
/bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
-I/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk -I../../src/include -O2
-D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4 -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I/home/d.sergey/xemomai/xenomai-2.4.9.1/include -MT
librtdk_la-init.lo -MD -MP -MF .deps/librtdk_la-init.Tpo -c -o
librtdk_la-init.lo `test -f 'init.c' || echo
'/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk/'`init.c
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk -I../../src/include -O2
-D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4 -D__XENO__ -D__IN_XENO__
-Wstrict-prototypes -I/home/d.sergey/xemomai/xenomai-2.4.9.1/include -MT
librtdk_la-init.lo -MD -MP -MF .deps/librtdk_la-init.Tpo -c
/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk/init.c -fPIC -DPIC -o
.libs/librtdk_la-init.o
/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk/init.c:1: error: bad value
(armv4) for -march= switch
/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk/init.c:1: error: bad value
(armv4) for -mtune= switch
make[2]: *** [librtdk_la-init.lo] Error 1
make[2]: Leaving directory `/home/d.sergey/build_root/src/rtdk'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/home/d.sergey/build_root/src'
make: *** [install-recursive] Error 1
===
Gilles said: "Your problem here is that you are trying to use gcc (that is
probably an
x86 gcc) with options for an ARM gcc. It does not work. You have to
ensure that the build system uses your cross-compiler."
Which step is wrong? I have only one compiler (located in
/home/d.sergey/compiler/armel-2007q3-51)
Also could you please provide me with the steps how to run the xenomai tests
on my board?
"you can run latency test" is really not enough for me...
Sergey
2009/10/14 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Didenko Sergey wrote:
> > Dear Gilles
> >
> > when I did change the HW Timer interrupt number (__ipipe_mach_timerint)
> from
> > 0 to 1
> > Patched kernel is able to boot up...but I'm not sure whether Xenomai is
> > running or not even I can see the messages that it is started...
> > To verify whether it is running or not I want to do latency test ..for
> > that..I'm following the HOWTO which says that I have to
> > 1) configure Xenomai
> > $ ./configure --build=i686-pc-linux-gnu --host=arm-linux
> > --enable-arm-mach=generic --enable-arm-tsc
> >
> > 2) make Install
> > When I do "make DESTDIR=/nfs install" where /nfs - is the NFS path to
> rootfs
> > mounted by board.
> > I have next situation...
> >
> > ===
> >
> > [d.sergey@domain.hid xenomai-2.4.9.1]$ make DESTDIR=/nfs install
> > Making install in src
> > make[1]: Entering directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src'
> > Making install in include
> > make[2]: Entering directory
> > `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> > make[3]: Entering directory
> > `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> > make[3]: Nothing to be done for `install-exec-am'.
> > make[3]: Nothing to be done for `install-data-am'.
> > make[3]: Leaving directory
> > `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> > make[2]: Leaving directory
> > `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/include'
> > Making install in rtdk
> > make[2]: Entering directory
> > `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk'
> > /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> > -I../../src/include -O2 -D_GNU_SOURCE -D_REENTRANT -Wall -pipe
> -march=armv4
> > -D__XENO__ -D__IN_XENO__ -Wstrict-prototypes -I../../include -MT
> > librtdk_la-init.lo -MD -MP -MF .deps/librtdk_la-init.Tpo -c -o
> > librtdk_la-init.lo `test -f 'init.c' || echo './'`init.c
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src/include -O2
> > -D_GNU_SOURCE -D_REENTRANT -Wall -pipe -march=armv4 -D__XENO__
> -D__IN_XENO__
> > -Wstrict-prototypes -I../../include -MT librtdk_la-init.lo -MD -MP -MF
> > .deps/librtdk_la-init.Tpo -c init.c -fPIC -DPIC -o
> .libs/librtdk_la-init.o
> > init.c:1: error: bad value (armv4) for -march= switch
> > init.c:1: error: bad value (armv4) for -mtune= switch
> > make[2]: *** [librtdk_la-init.lo] Error 1
> > make[2]: Leaving directory
> `/home/d.sergey/xemomai/xenomai-2.4.9.1/src/rtdk'
> > make[1]: *** [install-recursive] Error 1
> > make[1]: Leaving directory `/home/d.sergey/xemomai/xenomai-2.4.9.1/src'
> > make: *** [install-recursive] Error 1
> > [d.sergey@domain.hid xenomai-2.4.9.1]$
>
> Your problem here is that you are trying to use gcc (that is probably an
> x86 gcc) with options for an ARM gcc. It does not work. You have to
> ensure that the build system uses your cross-compiler.
>
> >
> > ====
> >
> > What is wrong?
> > How can I patch the rootfs with Xenomai libraries correctly?
>
> I have no idea. But I can tell you that you do not need to patch
> anything. It should work out of the box.
>
> --
> Gilles.
>
[-- Attachment #2: Type: text/html, Size: 18678 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-16 5:26 ` Didenko Sergey
@ 2009-10-16 7:43 ` Gilles Chanteperdrix
2009-10-16 8:30 ` Didenko Sergey
0 siblings, 1 reply; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-10-16 7:43 UTC (permalink / raw)
To: Didenko Sergey; +Cc: xenomai, Jorge Ramirez, mohamad.sharifi
Didenko Sergey wrote:
> CROSS_COMPILE - arm-none-linux-gnueabi
So, your compiler is named arm-none-linux-gnueabi-gcc
> checking build system type... i686-pc-linux-gnu
> checking host system type... arm-unknown-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking for arm-linux-gcc... no
> checking for gcc... gcc
> configure: WARNING: using cross tools not prefixed with host triplet
No need to go further. Here you know that something went wrong.
configure tells you that it will use gcc (the x86 compiler) as compiler
because it could not find a compiler named arm-linux-gcc. This will
definitely not work.
Your compiler is arm-none-linux-gnueabi-gcc, not arm-linux-gcc, so, you
should either configure passing --host=arm-none-linux-gnueabi, or define
the CC variable to be arm-none-linux-gnueabi-gcc.
This is explained in README.INSTALL.
--
Gilles.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-16 7:43 ` Gilles Chanteperdrix
@ 2009-10-16 8:30 ` Didenko Sergey
2009-10-16 8:46 ` Gilles Chanteperdrix
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-10-16 8:30 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai, mohamad.sharifi
[-- Attachment #1: Type: text/plain, Size: 1576 bytes --]
Thank you very much Gilles, now I have this done with no Warnings...good.
Two things are remained:
1) warning message like "remember to run `libtool --finish
/usr/xenomai/lib'" which are printed out when I do command
make DESTDIR=/nfs/rootfs install
How should I run it for the board's rootfs (located on /nfs/rootfs) ?
Is this "libtool --finish /nfs/rootfs/usr/xenomai/lib" correct?
Should I add this path to my board's environment variable?
2) I really need your help how to compile and run test-suit on my board.
Sergey
2009/10/16 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Didenko Sergey wrote:
> > CROSS_COMPILE - arm-none-linux-gnueabi
>
> So, your compiler is named arm-none-linux-gnueabi-gcc
>
> > checking build system type... i686-pc-linux-gnu
> > checking host system type... arm-unknown-linux-gnu
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking for arm-linux-gcc... no
> > checking for gcc... gcc
> > configure: WARNING: using cross tools not prefixed with host triplet
>
> No need to go further. Here you know that something went wrong.
> configure tells you that it will use gcc (the x86 compiler) as compiler
> because it could not find a compiler named arm-linux-gcc. This will
> definitely not work.
>
> Your compiler is arm-none-linux-gnueabi-gcc, not arm-linux-gcc, so, you
> should either configure passing --host=arm-none-linux-gnueabi, or define
> the CC variable to be arm-none-linux-gnueabi-gcc.
>
> This is explained in README.INSTALL.
>
> --
> Gilles.
>
[-- Attachment #2: Type: text/html, Size: 2123 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-16 8:30 ` Didenko Sergey
@ 2009-10-16 8:46 ` Gilles Chanteperdrix
2009-10-16 8:56 ` Didenko Sergey
0 siblings, 1 reply; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-10-16 8:46 UTC (permalink / raw)
To: Didenko Sergey; +Cc: xenomai, mohamad.sharifi
Didenko Sergey wrote:
> Thank you very much Gilles, now I have this done with no Warnings...good.
>
> Two things are remained:
>
> 1) warning message like "remember to run `libtool --finish
> /usr/xenomai/lib'" which are printed out when I do command
> make DESTDIR=/nfs/rootfs install
>
> How should I run it for the board's rootfs (located on /nfs/rootfs) ?
> Is this "libtool --finish /nfs/rootfs/usr/xenomai/lib" correct?
> Should I add this path to my board's environment variable?
You can safely ignore these messages.
>
> 2) I really need your help how to compile and run test-suit on my board.
If for instance you want to run latency on your board, then boot your
board, log on your board, then type:
cd /usr/xenomai/share/testsuite/latency
./run -- -p 1000
--
Gilles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-16 8:46 ` Gilles Chanteperdrix
@ 2009-10-16 8:56 ` Didenko Sergey
2009-10-16 9:30 ` Didenko Sergey
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-10-16 8:56 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai, mohamad.sharifi
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
Thank a lot Gilles, it is working!
2009/10/16 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Didenko Sergey wrote:
> > Thank you very much Gilles, now I have this done with no Warnings...good.
> >
> > Two things are remained:
> >
> > 1) warning message like "remember to run `libtool --finish
> > /usr/xenomai/lib'" which are printed out when I do command
> > make DESTDIR=/nfs/rootfs install
> >
> > How should I run it for the board's rootfs (located on /nfs/rootfs) ?
> > Is this "libtool --finish /nfs/rootfs/usr/xenomai/lib" correct?
> > Should I add this path to my board's environment variable?
>
> You can safely ignore these messages.
>
> >
> > 2) I really need your help how to compile and run test-suit on my board.
>
> If for instance you want to run latency on your board, then boot your
> board, log on your board, then type:
>
> cd /usr/xenomai/share/testsuite/latency
> ./run -- -p 1000
>
> --
> Gilles
>
>
[-- Attachment #2: Type: text/html, Size: 1507 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-16 8:56 ` Didenko Sergey
@ 2009-10-16 9:30 ` Didenko Sergey
0 siblings, 0 replies; 15+ messages in thread
From: Didenko Sergey @ 2009-10-16 9:30 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai, mohamad.sharifi
[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]
Do you have any guide how to run all tests?And what kind of results of each
test should I expect?
2009/10/16 Didenko Sergey <didenkos@domain.hid>
> Thank a lot Gilles, it is working!
>
> 2009/10/16 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
>
>> Didenko Sergey wrote:
>>
>> > Thank you very much Gilles, now I have this done with no
>> Warnings...good.
>> >
>> > Two things are remained:
>> >
>> > 1) warning message like "remember to run `libtool --finish
>> > /usr/xenomai/lib'" which are printed out when I do command
>> > make DESTDIR=/nfs/rootfs install
>> >
>> > How should I run it for the board's rootfs (located on /nfs/rootfs) ?
>> > Is this "libtool --finish /nfs/rootfs/usr/xenomai/lib" correct?
>> > Should I add this path to my board's environment variable?
>>
>> You can safely ignore these messages.
>>
>> >
>> > 2) I really need your help how to compile and run test-suit on my board.
>>
>> If for instance you want to run latency on your board, then boot your
>> board, log on your board, then type:
>>
>> cd /usr/xenomai/share/testsuite/latency
>> ./run -- -p 1000
>>
>> --
>> Gilles
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 2003 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-09 2:09 ` Didenko Sergey
@ 2009-10-09 9:12 ` Gilles Chanteperdrix
0 siblings, 0 replies; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-10-09 9:12 UTC (permalink / raw)
To: Didenko Sergey; +Cc: xenomai
Didenko Sergey wrote:
>
>
> 2009/10/8 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org
> <mailto:gilles.chanteperdrix@xenomai.org>>
>
> Didenko Sergey wrote:
> > Dear Xenomai Experts,
> >
> > So far I did not progress too much.
> >
> > What I have now is that patched Linux is starting to boot as original
> > kernel and it hangs right after line
> > [42949373.240000] ata1: SATA max UDMA/133 irq 27
> > As you can see after line
> >
> > [42949373.230000] ?^<6>Xenomai: real-time nucleus v2.4.9.1 (Big Bad
> > Moon) loaded.
> >
> > System does not go to timer_interrupt() function any more.
>
> That is expected. Once Xenomai runs, it takes over the timer interrupt.
>
> >
> > What I'm worring about is that the system has 2 timers, one is
> > free-running with disabled interrupts, second one is interrupt-driven
> > clockevent timer.
>
> No problem. Use the clockevent timer for hardware timer, use the
> free-running counter for tsc emulation.
>
> >
> > =========================== Code - Start
> > (...)
> > =========================== Code - End
> >
> > According to HOWTO Xenomai needs free-running counter, in my case
> it is
> > Timer 0, but all functions are configured to work with Timer 1,
> which is
> > not free running.
> >
> > What would you suggest to do?
>
> No, the howto does not say that you need a free-running counter. It
> shows the example of a free-running counter and tell you to look at the
> integrator or s3cxxxx code if you want to know how to implement the
> I-pipe support for a decrementer. The reason being that I wrote the
> howto, and I never had to work with a decrementer.
>
>
> If you never worked with decrementer, I do not want to use it if there
> is any other way...
> For example can I:
> - Enable interrupts for free-running Timer0?
> - Add one more timer with proper functionality for Xenomai (system has 2
> more timers which are not initialized) ?
I do not know the details of your architecture, only you know that. But
if your architecture only supports a decrementer, you will have to use
the decrementer. You will find this kind of details in the processor
datasheet, and then you will know if you have a choice.
Also note that what makes the implementation of the I-pipe support a bit
complicated on integrator and S3Cxxx is that the tsc emulation is based
on the decrementer. But if you have have a decrementer and a
free-running counter, you can use the free-running counter for the tsc
emulation, and the decrementer for the timer implementation. The omap3
I-pipe support works that way for instance.
>
> If you really want us to help you should show us the code that you
> added, not the code that we can already find in the linux kernel
> sources.
>
>
> Of course I really want...
>
> The code I added is under XENOMAI_SUPPORT_DSV definition
Bad idea. You should follow the howto and only use CONFIG_IPIPE. This
way, you can select the I-pipe support by enabling the option in the
kernel configuration. Besides, calling the XENOMAI_somehting is a bit of
a misnomer, since what you are implementing is the I-pipe support, not
xenomai support.
> /*
> * Program the hardware timer to trig an interrupt in 'delay' hardware
> timer ticks.
> */
> void __ipipe_mach_set_dec(unsigned long delay)
> {
> u32 u;
>
> XEN_PRINT("-")
>
> if (delay > MIN_OSCR_DELTA) {
Please use define names which are meaningful for your architecture, do
not reuse the PXA define names.
> unsigned long flags;
>
> local_irq_save(flags);
>
> // OSCR //OSMR0
> writel(delay + readl(TIMER1_VAL), TIMER1_RELOAD);
As discussed earlier, this looks wrong if your hardware timer is based
on a decrementer.
> static irqreturn_t orion_timer_interrupt(int irq, void *dev_id)
> {
> /*
> * ACK timer interrupt
> */
> writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
This is wrong. When I-pipe is enabled, this acknowledgement is done in
the ipipe_mach_acktimer function, and should no longer be done in the
timer interrupt. Look at pxa_timer_interrupt implementation in the howto.
> BTW, how can I know how much the MIN_OSCR_DELTA value should be for MV
> 88F6290 platfrom?
As I already told you MIN_OSCR_DELTA is called that way because on PXA,
the hardware timer is based on a register called OSCR. You should try
and find a name meaningful for your architecture. Anyway, this value
should be documented in the datasheet of your processor.
--
Gilles
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-08 8:41 ` Gilles Chanteperdrix
@ 2009-10-09 2:09 ` Didenko Sergey
2009-10-09 9:12 ` Gilles Chanteperdrix
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-10-09 2:09 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
[-- Attachment #1: Type: text/plain, Size: 11341 bytes --]
2009/10/8 Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
> Didenko Sergey wrote:
> > Dear Xenomai Experts,
> >
> > So far I did not progress too much.
> >
> > What I have now is that patched Linux is starting to boot as original
> > kernel and it hangs right after line
> > [42949373.240000] ata1: SATA max UDMA/133 irq 27
> > As you can see after line
> >
> > [42949373.230000] ?^<6>Xenomai: real-time nucleus v2.4.9.1 (Big Bad
> > Moon) loaded.
> >
> > System does not go to timer_interrupt() function any more.
>
> That is expected. Once Xenomai runs, it takes over the timer interrupt.
>
> >
> > What I'm worring about is that the system has 2 timers, one is
> > free-running with disabled interrupts, second one is interrupt-driven
> > clockevent timer.
>
> No problem. Use the clockevent timer for hardware timer, use the
> free-running counter for tsc emulation.
>
> >
> > =========================== Code - Start
> > (...)
> > =========================== Code - End
> >
> > According to HOWTO Xenomai needs free-running counter, in my case it is
> > Timer 0, but all functions are configured to work with Timer 1, which is
> > not free running.
> >
> > What would you suggest to do?
>
> No, the howto does not say that you need a free-running counter. It
> shows the example of a free-running counter and tell you to look at the
> integrator or s3cxxxx code if you want to know how to implement the
> I-pipe support for a decrementer. The reason being that I wrote the
> howto, and I never had to work with a decrementer.
>
>
If you never worked with decrementer, I do not want to use it if there is
any other way...
For example can I:
- Enable interrupts for free-running Timer0?
- Add one more timer with proper functionality for Xenomai (system has 2
more timers which are not initialized) ?
If you really want us to help you should show us the code that you
> added, not the code that we can already find in the linux kernel sources.
>
Of course I really want...
The code I added is under XENOMAI_SUPPORT_DSV definition
file time.c
=========================== Code - Start
#if XENOMAI_SUPPORT_DSV
#ifdef CONFIG_IPIPE
#ifdef CONFIG_NO_IDLE_HZ
#error "dynamic tick timer not yet supported with IPIPE"
#endif /* CONFIG_NO_IDLE_HZ */
#endif /* CONFIG_IPIPE */
#endif
/*
* Timer block registers.
*/
#define TIMER_CTRL (TIMER_VIRT_BASE + 0x0000)
#define TIMER0_EN 0x0001
#define TIMER0_RELOAD_EN 0x0002
#define TIMER1_EN 0x0004
#define TIMER1_RELOAD_EN 0x0008
#define TIMER0_RELOAD (TIMER_VIRT_BASE + 0x0010)
#define TIMER0_VAL (TIMER_VIRT_BASE + 0x0014)
#define TIMER1_RELOAD (TIMER_VIRT_BASE + 0x0018)
#define TIMER1_VAL (TIMER_VIRT_BASE + 0x001c)
#if XENOMAI_SUPPORT_DSV
#define XEN_PRINT(x) printk(x);
//#define XEN_PRINT(x)
/* Assume that 16 is Ok for MV 88F6290 platfrom - Need to be clarified */
#define MIN_OSCR_DELTA 16
/*Hardware timer IRQ number */
int __ipipe_mach_timerint = IRQ_MV88F6290_BRIDGE;
EXPORT_SYMBOL(__ipipe_mach_timerint);
/*Initialized to 0, it became non zero when the hardware timer is handled by
Xenomai. */
int __ipipe_mach_timerstolen = 0;
EXPORT_SYMBOL(__ipipe_mach_timerstolen);
/*
* Count of hardware timer ticks between two timer interrupts, same thing as
the LATCH constant.
*/
unsigned int __ipipe_mach_ticks_per_jiffy = LATCH;
static int orion_timer_initialized = 0;
union tsc_reg {
#ifdef __BIG_ENDIAN
struct {
unsigned long high;
unsigned long low;
};
#else /* __LITTLE_ENDIAN */
struct {
unsigned long low;
unsigned long high;
};
#endif /* __LITTLE_ENDIAN */
unsigned long long full;
};
#ifdef CONFIG_SMP
static union tsc_reg orion_tsc[NR_CPUS];
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
info->type = IPIPE_TSC_TYPE_NONE;
}
#else /* !CONFIG_SMP */
static union tsc_reg *orion_tsc;
// export the tsc to user-space
void __ipipe_mach_get_tscinfo(struct __ipipe_tscinfo *info)
{
XEN_PRINT( "\n===[Break point] __ipipe_mach_get_tscinfo - IN")
info->type = IPIPE_TSC_TYPE_FREERUNNING;
info->u.fr.counter = (unsigned *) TIMER1_VAL;
info->u.fr.mask = 0xffffffff;
info->u.fr.tsc = &orion_tsc->full;
}
#endif /* !CONFIG_SMP */
/*
* info->type indicates that the tsc is based on a free-running counter,
* info->u.fr.counter is set to the PHYSICAL address of the free-running
counter,
* info->u.fr.mask is a mask indicating which bits in the free-running
counter are valid.
* info->u.fr.tsc is a pointer to the shared tsc area
*/
/* Acknowledge the hardware timer interrupt at hardware timer level. */
void __ipipe_mach_acktimer(void)
{
/*
* ACK timer interrupt.
*/
XEN_PRINT("?")
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
}
// Emulates the tsc;
notrace unsigned long long __ipipe_mach_get_tsc(void)
{
XEN_PRINT("_")
if (likely(orion_timer_initialized)) {
union tsc_reg *local_tsc, result;
unsigned long stamp;
local_tsc = &orion_tsc[ipipe_processor_id()];
__asm__ ("ldmia %1, %M0\n":
"=r"(result.full): "r"(local_tsc), "m"(*local_tsc));
barrier();
stamp = readl(TIMER0_VAL);
if (unlikely(stamp < result.low))
/* 32 bit counter wrapped, increment high word. */
result.high++;
result.low = stamp;
return result.full;
}
return 0;
}
EXPORT_SYMBOL(__ipipe_mach_get_tsc);
/*
* Program the hardware timer to trig an interrupt in 'delay' hardware timer
ticks.
*/
void __ipipe_mach_set_dec(unsigned long delay)
{
u32 u;
XEN_PRINT("-")
if (delay > MIN_OSCR_DELTA) {
unsigned long flags;
local_irq_save(flags);
// OSCR //OSMR0
writel(delay + readl(TIMER1_VAL), TIMER1_RELOAD);
//OIER |= OIER_E0;
/*
* Clear and enable clockevent timer interrupt.
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
u = readl(BRIDGE_MASK);
u |= BRIDGE_INT_TIMER1;
writel(u, BRIDGE_MASK);
local_irq_restore(flags);
} else
ipipe_trigger_irq(IRQ_MV88F6290_BRIDGE);
}
EXPORT_SYMBOL(__ipipe_mach_set_dec);
#endif /* XENOMAI_SUPPORT_DSV */
/*
* Clocksource handling.
*/
static cycle_t orion_clksrc_read(void)
{
return 0xffffffff - readl(TIMER0_VAL);
}
static struct clocksource orion_clksrc = {
.name = "orion_clocksource",
.shift = 20,
.rating = 300,
.read = orion_clksrc_read,
.mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
/*
* Clockevent handling.
*/
static int
orion_clkevt_next_event(unsigned long delta, struct clock_event_device *dev)
{
unsigned long flags;
u32 u;
XEN_PRINT( "\n===[Break point] orion_clkevt_next_event - IN")
if (delta == 0)
return -ETIME;
local_irq_save(flags);
/*
* Clear and enable clockevent timer interrupt.
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
u = readl(BRIDGE_MASK);
u |= BRIDGE_INT_TIMER1;
writel(u, BRIDGE_MASK);
/*
* Setup new clockevent timer value.
*/
writel(delta, TIMER1_VAL);
/*
* Enable the timer.
*/
u = readl(TIMER_CTRL);
u = (u & ~TIMER1_RELOAD_EN) | TIMER1_EN;
writel(u, TIMER_CTRL);
local_irq_restore(flags);
return 0;
}
static void
orion_clkevt_mode(enum clock_event_mode mode, struct clock_event_device
*dev)
{
unsigned long flags;
u32 u;
XEN_PRINT( "\n===[Break point] orion_clkevt_mode - IN")
local_irq_save(flags);
if (mode == CLOCK_EVT_MODE_PERIODIC) {
/*
* Setup timer to fire at 1/HZ intervals.
*/
writel(__ipipe_mach_ticks_per_jiffy - 1, TIMER1_RELOAD);
writel(__ipipe_mach_ticks_per_jiffy - 1, TIMER1_VAL);
/*
* Enable timer interrupt.
*/
u = readl(BRIDGE_MASK);
writel(u | BRIDGE_INT_TIMER1, BRIDGE_MASK);
/*
* Enable timer.
*/
u = readl(TIMER_CTRL);
writel(u | TIMER1_EN | TIMER1_RELOAD_EN, TIMER_CTRL);
} else {
/*
* Disable timer.
*/
u = readl(TIMER_CTRL);
writel(u & ~TIMER1_EN, TIMER_CTRL);
/*
* Disable timer interrupt.
*/
u = readl(BRIDGE_MASK);
writel(u & ~BRIDGE_INT_TIMER1, BRIDGE_MASK);
/*
* ACK pending timer interrupt.
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
}
local_irq_restore(flags);
}
static struct clock_event_device orion_clkevt = {
.name = "orion_tick",
.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
.shift = 32,
.rating = 300,
.set_next_event = orion_clkevt_next_event,
.set_mode = orion_clkevt_mode,
};
static irqreturn_t orion_timer_interrupt(int irq, void *dev_id)
{
/*
* ACK timer interrupt
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
XEN_PRINT( "^")
/*
* Call event handler.
*/
orion_clkevt.event_handler(&orion_clkevt);
return IRQ_HANDLED;
}
static struct irqaction orion_timer_irq = {
.name = "orion_tick",
.flags = IRQF_DISABLED | IRQF_TIMER,
.handler = orion_timer_interrupt
};
void __init orion_time_init(unsigned int irq, unsigned int tclk)
{
u32 u;
__ipipe_mach_ticks_per_jiffy = (tclk + HZ/2) / HZ;
XEN_PRINT( "\n===[Break point] orion_time_init - IN")
/*
* Setup free-running clocksource timer (interrupts disabled)
*/
writel(0xffffffff, TIMER0_VAL);
writel(0xffffffff, TIMER0_RELOAD);
u = readl(BRIDGE_MASK);
writel(u & ~BRIDGE_INT_TIMER0, BRIDGE_MASK);
u = readl(TIMER_CTRL);
writel(u | TIMER0_EN | TIMER0_RELOAD_EN, TIMER_CTRL);
orion_clksrc.mult = clocksource_hz2mult(tclk, orion_clksrc.shift);
clocksource_register(&orion_clksrc);
/*
* Setup clockevent timer (interrupt-driven)
*/
setup_irq(irq, &orion_timer_irq);
orion_clkevt.mult = div_sc(tclk, NSEC_PER_SEC, orion_clkevt.shift);
orion_clkevt.max_delta_ns = clockevent_delta2ns(0xfffffffe,
&orion_clkevt);
orion_clkevt.min_delta_ns = clockevent_delta2ns(1, &orion_clkevt);
orion_clkevt.cpumask = cpumask_of(0);
clockevents_register_device(&orion_clkevt);
#if XENOMAI_SUPPORT_DSV
#ifdef CONFIG_IPIPE
#ifndef CONFIG_SMP
orion_tsc = (union tsc_reg *) __ipipe_tsc_area;
barrier();
#endif /* CONFIG_SMP */
orion_timer_initialized = 1;
#endif /* CONFIG_IPIPE */
#endif /* XENOMAI_SUPPORT_DSV */
}
#if XENOMAI_SUPPORT_DSV
#ifdef CONFIG_IPIPE
int __ipipe_check_tickdev(const char *devname)
{
return !strcmp(devname, orion_clkevt.name);
}
#endif /* CONFIG_IPIPE */
void __ipipe_mach_release_timer(void)
{
XEN_PRINT( "\n===[Break point] __ipipe_mach_release_timer - IN")
orion_clkevt_mode(orion_clkevt.mode, &orion_clkevt);
if (orion_clkevt.mode == CLOCK_EVT_MODE_ONESHOT)
orion_clkevt_next_event(LATCH, &orion_clkevt);
}
EXPORT_SYMBOL(__ipipe_mach_release_timer);
#endif
=========================== Code - End
BTW, how can I know how much the MIN_OSCR_DELTA value should be for MV
88F6290 platfrom?
[-- Attachment #2: Type: text/html, Size: 14613 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-10-08 8:27 Didenko Sergey
@ 2009-10-08 8:41 ` Gilles Chanteperdrix
2009-10-09 2:09 ` Didenko Sergey
0 siblings, 1 reply; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-10-08 8:41 UTC (permalink / raw)
To: Didenko Sergey; +Cc: xenomai
Didenko Sergey wrote:
> Dear Xenomai Experts,
>
> So far I did not progress too much.
>
> What I have now is that patched Linux is starting to boot as original
> kernel and it hangs right after line
> [42949373.240000] ata1: SATA max UDMA/133 irq 27
> As you can see after line
>
> [42949373.230000] ?^<6>Xenomai: real-time nucleus v2.4.9.1 (Big Bad
> Moon) loaded.
>
> System does not go to timer_interrupt() function any more.
That is expected. Once Xenomai runs, it takes over the timer interrupt.
>
> What I'm worring about is that the system has 2 timers, one is
> free-running with disabled interrupts, second one is interrupt-driven
> clockevent timer.
No problem. Use the clockevent timer for hardware timer, use the
free-running counter for tsc emulation.
>
> =========================== Code - Start
> (...)
> =========================== Code - End
>
> According to HOWTO Xenomai needs free-running counter, in my case it is
> Timer 0, but all functions are configured to work with Timer 1, which is
> not free running.
>
> What would you sugest to do?
No, the howto does not say that you need a free-running counter. It
shows the example of a free-running counter and tell you to look at the
integrator or s3cxxxx code if you want to know how to implement the
I-pipe support for a decrementer. The reason being that I wrote the
howto, and I never had to work with a decrementer.
If you really want us to help you should show us the code that you
added, not the code that we can already find in the linux kernel sources.
--
Gilles
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Xenomai-help] Support for ARCH_MV88F6290
@ 2009-10-08 8:27 Didenko Sergey
2009-10-08 8:41 ` Gilles Chanteperdrix
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-10-08 8:27 UTC (permalink / raw)
To: xenomai
[-- Attachment #1: Type: text/plain, Size: 10564 bytes --]
Dear Xenomai Experts,
So far I did not progress too much.
What I have now is that patched Linux is starting to boot as original kernel
and it hangs right after line
[42949373.240000] ata1: SATA max UDMA/133 irq 27
Next characters are printed out:
"?" - from __ipipe_mach_acktimer()
"^" - from orion_timer_interrupt()
"-" - from __ipipe_mach_set_dec()
"_" - from __ipipe_mach_get_tsc()
=========================== LOG - Start
Starting kernel ...
Uncompressing
Linux..........................................................................................................................................
[ 0.000000] Linux version 2.6.29_V02.00.29 (gcc version 4.2.1
(CodeSourcery Sourcery G++ Lite 2007q3-51)) #46 PREEMPT Thu Oct 8 15:059
[ 0.000000] CPU: Feroceon [41159260] revision 0 (ARMv5TE), cr=00053177
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: Marvell 88f6290 Board
[ 0.000000] Using u-boot passing parameters structure
[ 0.000000] uboot version: 33757680
[ 0.000000] board id: 240
[ 0.000000] usb host: 3
[ 0.000000] over ethernet address: 0x0
[ 0.000000] MAC address: 00:00:00:00:51:81
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total
pages: 130048
[ 0.000000] Kernel command line: root=/dev/nfs rw
nfsroot=10.88.198.79:/nfs/rootfs
ip=10.88.197.82:10.88.198.79:10.88.197.1:255.255.255.0::eth0:off conso8
[ 0.000000] PID hash table entries: 2048 (order: 11, 8192 bytes)
[ 0.000000]
[ 0.000000] ===[Break point] orion_time_init - IN
[ 0.000000] ===[Break point] orion_clkevt_mode - IN
[ 0.000000] ===[Break point] orion_clkevt_mode - IN<6>I-pipe 1.13-03:
pipeline enabled.
[42949372.960000] Console: colour dummy device 80x30
[42949372.960000] Dentry cache hash table entries: 65536 (order: 6, 262144
bytes)
[42949372.960000] Inode-cache hash table entries: 32768 (order: 5, 131072
bytes)
[42949372.960000] ?^?^<6>Memory: 256MB 256MB = 512MB total
[42949372.980000] Memory: 383744KB available (4188K code, 389K data, 116K
init)
[42949372.980000] SLUB: Genslabs=12, HWalign=32, Order=0-3, MinObjects=0,
CPUs=1, Nodes=1
[42949372.980000] Calibrating delay loop...
?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^?^797.90 BogoMIPS (lpj=3989504)
[42949373.190000] ?^Mount-cache hash table entries: 512
[42949373.200000] CPU: Testing write buffer coherency: ok
[42949373.200000]
[42949373.200000] ===[Break point] rest_init - IN<6>net_namespace: 884 bytes
[42949373.200000] NET: Registered protocol family 16
[42949373.200000] MV88F6290: MV88F6290-A0, TCLK=166666667.
[42949373.200000] GPIO-17 autorequested
[42949373.200000] MV88F6290 PCIe #0: <6>link up
[42949373.200000] MV88F6290 PCIe #1: <6>link down, ignoring
[42949373.200000] pci 0000:00:01.0: PME# supported from D0 D3hot D3cold
[42949373.200000] pci 0000:00:01.0: PME# disabled
[42949373.200000] PCI: bus0: Fast back to back transfers disabled
[42949373.200000] PCI: bus1: Fast back to back transfers enabled
[42949373.200000] pci 0000:00:01.0: PCI bridge, secondary bus 0000:01
[42949373.200000] pci 0000:00:01.0: IO window: disabled
[42949373.200000] pci 0000:00:01.0: MEM window: disabled
[42949373.200000] pci 0000:00:01.0: PREFETCH window: disabled
[42949373.200000] ?^?^bio: create slab <bio-0> at 0
[42949373.220000] SCSI subsystem initialized
[42949373.220000] usbcore: registered new interface driver usbfs
[42949373.220000] usbcore: registered new interface driver hub
[42949373.220000] usbcore: registered new device driver usb
[42949373.220000] ?^<6>NET: Registered protocol family 2
[42949373.230000] IP route cache hash table entries: 16384 (order: 4, 65536
bytes)
[42949373.230000] TCP established hash table entries: 65536 (order: 7,
524288 bytes)
[42949373.230000] TCP bind hash table entries: 65536 (order: 6, 262144
bytes)
[42949373.230000] TCP: Hash tables configured (established 65536 bind 65536)
[42949373.230000] TCP reno registered
[42949373.230000] NET: Registered protocol family 1
[42949373.230000]
[42949373.230000] ===[Break point] __ipipe_mach_get_tscinfo - IN
[42949373.230000] ===[Break point] __ipipe_mach_get_tscinfo - IN<6>I-pipe:
Domain Xenomai registered.
[42949373.230000] Xenomai: hal/arm started.
[42949373.230000] ?^<6>Xenomai: real-time nucleus v2.4.9.1 (Big Bad Moon)
loaded.
[42949373.240000] _-___-__<6>Xenomai: starting native API services.
[42949373.240000] Xenomai: starting POSIX services.
[42949373.240000] Xenomai: starting RTDM services.
[42949373.240000] ?___-__<6>bigphysarea: Allocated 32768 pages at
0xc08a8000.
[42949373.240000] ?___-__<6>NTFS driver 2.1.29 [Flags: R/O].
[42949373.240000] JFFS2 version 2.2. (NAND) .. 2001-2006 Red Hat, Inc.
[42949373.240000] msgmni has been set to 749
[42949373.240000] alg: No test for stdrng (krng)
[42949373.240000] io scheduler noop registered
[42949373.240000] io scheduler anticipatory registered
[42949373.240000] io scheduler deadline registered
[42949373.240000] io scheduler cfq registered (default)
[42949373.240000] ?___-__?___-__?___-__<6>Serial: 8250/16550 driver, 2
ports, IRQ sharing disabled
[42949373.240000] serial8250.0: ttyS0 at MMIO 0xf1012000 (irq = 3) is a
16550A
[42949373.240000] console [ttyS0] enabled
[42949373.240000]
??????????????????????????????????????????___-_____-_____-_____-_____-_____-_____-_____-_____-_____-_____-_____-_____-_____-_____-_____-__d
[42949373.240000] ?___-__<5>MV-643xx 10/100/1000 ethernet driver version 1.4
[42949373.240000] mv643xx_eth smi: probed
[42949373.240000] ?___-__?___-__<6>eth0 (mv643xx_eth_port): not using
net_device_ops yet
[42949373.240000] net eth0: port 0 with MAC address 00:00:00:00:51:81
[42949373.240000] ?___-__<6>usbcore: registered new interface driver
cdc_ether
[42949373.240000] ?___-__<6>usbcore: registered new interface driver
rndis_host
[42949373.240000] ?___-__<6>usbcore: registered new interface driver
cdc_subset
[42949373.240000] Driver 'sd' needs updating - please use bus_type methods
[42949373.240000] ?___-__<6>sata_mv sata_mv.0: version 1.25
[42949373.240000] ?___-__<6>sata_mv sata_mv.0: slots 32 ports 1
[42949373.240000] scsi0 : sata_mv
[42949373.240000] ?___-__<6>ata1: SATA max UDMA/133 irq 27
[42949373.240000] ?___-__?___-__?___-__?___-__?___-__?___-__?___-__?___-__
=========================== LOG - End
As you can see after line
[42949373.230000] ?^<6>Xenomai: real-time nucleus v2.4.9.1 (Big Bad Moon)
loaded.
System does not go to timer_interrupt() function any more.
What I'm worring about is that the system has 2 timers, one is free-running
with disabled interrupts, second one is interrupt-driven clockevent timer.
=========================== Code - Start
/*
* Clockevent handling.
*/
static int
orion_clkevt_next_event(unsigned long delta, struct clock_event_device *dev)
{
unsigned long flags;
u32 u;
XEN_PRINT("-ne-");
if (delta == 0)
return -ETIME;
local_irq_save(flags);
/*
* Clear and enable clockevent timer interrupt.
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
u = readl(BRIDGE_MASK);
u |= BRIDGE_INT_TIMER1;
writel(u, BRIDGE_MASK);
/*
* Setup new clockevent timer value.
*/
writel(delta, TIMER1_VAL);
/*
* Enable the timer.
*/
u = readl(TIMER_CTRL);
u = (u & ~TIMER1_RELOAD_EN) | TIMER1_EN;
writel(u, TIMER_CTRL);
local_irq_restore(flags);
return 0;
}
static void
orion_clkevt_mode(enum clock_event_mode mode, struct clock_event_device
*dev)
{
unsigned long flags;
u32 u;
local_irq_save(flags);
if (mode == CLOCK_EVT_MODE_PERIODIC) {
XEN_PRINT("-cm1-");
/*
* Setup timer to fire at 1/HZ intervals.
*/
writel(ticks_per_jiffy - 1, TIMER1_RELOAD);
writel(ticks_per_jiffy - 1, TIMER1_VAL);
/*
* Enable timer interrupt.
*/
u = readl(BRIDGE_MASK);
writel(u | BRIDGE_INT_TIMER1, BRIDGE_MASK);
/*
* Enable timer.
*/
u = readl(TIMER_CTRL);
writel(u | TIMER1_EN | TIMER1_RELOAD_EN, TIMER_CTRL);
} else {
XEN_PRINT("-cm2-");
/*
* Disable timer.
*/
u = readl(TIMER_CTRL);
writel(u & ~TIMER1_EN, TIMER_CTRL);
/*
* Disable timer interrupt.
*/
u = readl(BRIDGE_MASK);
writel(u & ~BRIDGE_INT_TIMER1, BRIDGE_MASK);
/*
* ACK pending timer interrupt.
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
}
local_irq_restore(flags);
}
static struct clock_event_device orion_clkevt = {
.name = "orion_tick",
.features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
.shift = 32,
.rating = 300,
.set_next_event = orion_clkevt_next_event,
.set_mode = orion_clkevt_mode,
};
static irqreturn_t orion_timer_interrupt(int irq, void *dev_id)
{
XEN_PRINT("^");
/*
* ACK timer interrupt and call event handler.
*/
writel(BRIDGE_INT_TIMER1_CLR, BRIDGE_CAUSE);
orion_clkevt.event_handler(&orion_clkevt);
return IRQ_HANDLED;
}
static struct irqaction orion_timer_irq = {
.name = "orion_tick",
.flags = IRQF_DISABLED | IRQF_TIMER,
.handler = orion_timer_interrupt
};
void __init orion_time_init(unsigned int irq, unsigned int tclk)
{
u32 u;
ticks_per_jiffy = (tclk + HZ/2) / HZ;
/*
* Setup free-running clocksource timer (interrupts
* disabled.)
*/
writel(0xffffffff, TIMER0_VAL);
writel(0xffffffff, TIMER0_RELOAD);
u = readl(BRIDGE_MASK);
writel(u & ~BRIDGE_INT_TIMER0, BRIDGE_MASK);
u = readl(TIMER_CTRL);
writel(u | TIMER0_EN | TIMER0_RELOAD_EN, TIMER_CTRL);
orion_clksrc.mult = clocksource_hz2mult(tclk, orion_clksrc.shift);
clocksource_register(&orion_clksrc);
/*
* Setup clockevent timer (interrupt-driven.)
*/
setup_irq(irq, &orion_timer_irq);
orion_clkevt.mult = div_sc(tclk, NSEC_PER_SEC, orion_clkevt.shift);
orion_clkevt.max_delta_ns = clockevent_delta2ns(0xfffffffe,
&orion_clkevt);
orion_clkevt.min_delta_ns = clockevent_delta2ns(1, &orion_clkevt);
orion_clkevt.cpumask = cpumask_of(0);
clockevents_register_device(&orion_clkevt);
}
=========================== Code - End
According to HOWTO Xenomai needs free-running counter, in my case it is
Timer 0, but all functions are configured to work with Timer 1, which is not
free running.
What would you sugest to do?
Sergey
[-- Attachment #2: Type: text/html, Size: 12315 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
[not found] ` <1f3e02580909280458ubf3f610he5e52aab1efa1cc6@domain.hid>
@ 2009-09-29 16:27 ` Gilles Chanteperdrix
0 siblings, 0 replies; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-09-29 16:27 UTC (permalink / raw)
To: Didenko Sergey; +Cc: jorge.ramirez, Xenomai help, mohamad.sharifi
Didenko Sergey wrote:
> Dear Gilles
>
>
>> Ok. You do not need to send me the sources, I found what I needed in the
>> .config you sent me. To add support the SOC quickly, you have to follow
>> this howto: http://www.xenomai.org/index.php/I-pipe:ArmPorting
>
>
> I'm coming through this guide...and so far I do not have a good progress
> having real hard time with configuring the timig related functions and
> definitions...
> meanwhile, could you please clarify one thing: If target ARCH is not
> supported by Xenomai, after I did patch the Kernel with Xenomai, what kind
> of configuration has been patched? What else should I do after doing all
> steps from to HOWTO?
Well, you need to follow the README.INSTALL guide to install Xenomai
using your modified kernel. You need to add some stuff to configure.in
if you want to use the TSC emulation in user-space, but it is not
important for a first step, so you should configure Xenomai with the
--enable-arm-mach=generic. Then run the latency test to see whether the
system is running.
P.S: please do not forget to CC the mailing list.
--
Gilles.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Xenomai-help] Support for ARCH_MV88F6290
2009-09-25 6:12 Didenko Sergey
@ 2009-09-25 8:37 ` Gilles Chanteperdrix
[not found] ` <1f3e02580909250400r7595efw769fedac12b71fce@domain.hid>
0 siblings, 1 reply; 15+ messages in thread
From: Gilles Chanteperdrix @ 2009-09-25 8:37 UTC (permalink / raw)
To: Didenko Sergey
Cc: xenomai, mohamad.sharifi, Me (Samsung Account), jorge.ramirez
Didenko Sergey wrote:
> Hello All
>
> I'm porting Xenomai 2.4.9 to the Linux Kernel 2.6.29.
>
> Target platform is MV 88F6290
I do not find this platform anywhere, neither in the kernel source, nor
on the internet.
> CPU: ARM926EJ-S
> Adeos patch: adeos-ipipe-2.6.29-arm-1.13-03.patch
>
> I do patch the kernel with xenomai and adeos:
> ./prepare-kernel.sh --arch=arm
> --linux=/.../kernel/linux-2.6.29-v02.00.29/
> --adeos=/.../xenomai-2.4.9/ksrc/arch/arm/patches/adeos-ipipe-2.6.29-arm-1.13-03.patch
>
> Then I compile the Linux kernel.
> At the time when I start to compile the kernel I have to answer for many
> questions regarding configuration, it is Ok!
> But finally I got the compile error like:
>
> ===
> arch/arm/kernel/ipipe.c: In function '__ipipe_grab_irq':
> arch/arm/kernel/ipipe.c:492: error: implicit declaration of function
> '__ipipe_mach_irq_mux_p'
> make[1]: *** [arch/arm/kernel/ipipe.o] Error 1
> make: *** [arch/arm/kernel] Error 2
> ===
>
> the reason of this error is that there is no definition of the macro
> "__ipipe_mach_irq_mux_p" for the target platform as well as there are no
> the others CPU dependent definitions.
>
> If I refer to the file "arch/arm/mach-at91/include/mach/irqs.h" all
> definitions like
> CONFIG_ARCH_AT91SAM9* are not defined
So, it is an AT91 something ?
>
> But, in the Xenomai's build questionnaire messages (build time) I found
> next lines:
>
> ===
>
> *
> * System Type
> *
> ARM system type
> 1. Agilent AAEC-2000 based (ARCH_AAEC2000)
> .
> .
> .
> 38. Nuvoton W90X900 CPU (ARCH_W90X900)
>> 39. Marvell MV88F6290 (ARCH_MV88F6290)
> choice[1-39]: 39
>
> ===
>
> Actually I did not select any system type anyhow. And it does not allow
> me to select it somehow, but the default choice is correct - system type
> is MV88F6290! I don't know why but it is a very nice that default system
> type is exactly what I need :) (please give some comments on it)
>
> The questions!
>
> 1) It looks like Xenomai do support the target SoC (MV88F6290), as well
> as do support processor type ARM926 it has.
There is no Xenomai code specific to a CPU core. What matters is what
SOC you are using, and from your description MV88F6290 is not a SOC, it
is a board. The SOC being an AT91 from what you told us. And yes, most
AT91 are supported.
> Then why I can not find the CPU dependent definitions in the patched
> kernel's source code?
> 2) What does it takes for you to support this system and CPU if it is
> not supported yet?
This question is an FAQ, the answer may be found here:
http://www.xenomai.org/index.php/I-pipe:ArmPorting
But from your description, if the SOC is really an AT91, what is missing
is probably just a #ifdef for its multiplexed GPIOS.
But if you tell me exactly what kernel sources you are using and send me
your .config, and I will be able to give you a definitive answer.
--
Gilles
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Xenomai-help] Support for ARCH_MV88F6290
@ 2009-09-25 6:12 Didenko Sergey
2009-09-25 8:37 ` Gilles Chanteperdrix
0 siblings, 1 reply; 15+ messages in thread
From: Didenko Sergey @ 2009-09-25 6:12 UTC (permalink / raw)
To: xenomai; +Cc: jorge.ramirez, Me (Samsung Account), mohamad.sharifi
[-- Attachment #1: Type: text/plain, Size: 2354 bytes --]
Hello All
I'm porting Xenomai 2.4.9 to the Linux Kernel 2.6.29.
Target platform is MV 88F6290
CPU: ARM926EJ-S
Adeos patch: adeos-ipipe-2.6.29-arm-1.13-03.patch
I do patch the kernel with xenomai and adeos:
./prepare-kernel.sh --arch=arm --linux=/.../kernel/linux-2.6.29-v02.00.29/
--adeos=/.../xenomai-2.4.9/ksrc/arch/arm/patches/adeos-ipipe-2.6.29-arm-1.13-03.patch
Then I compile the Linux kernel.
At the time when I start to compile the kernel I have to answer for many
questions regarding configuration, it is Ok!
But finally I got the compile error like:
===
arch/arm/kernel/ipipe.c: In function '__ipipe_grab_irq':
arch/arm/kernel/ipipe.c:492: error: implicit declaration of function
'__ipipe_mach_irq_mux_p'
make[1]: *** [arch/arm/kernel/ipipe.o] Error 1
make: *** [arch/arm/kernel] Error 2
===
the reason of this error is that there is no definition of the macro
"__ipipe_mach_irq_mux_p" for the target platform as well as there are no the
others CPU dependent definitions.
If I refer to the file "arch/arm/mach-at91/include/mach/irqs.h" all
definitions like
CONFIG_ARCH_AT91SAM9* are not defined
But, in the Xenomai's build questionnaire messages (build time) I found next
lines:
===
*
* System Type
*
ARM system type
1. Agilent AAEC-2000 based (ARCH_AAEC2000)
.
.
.
38. Nuvoton W90X900 CPU (ARCH_W90X900)
> 39. Marvell MV88F6290 (ARCH_MV88F6290)
choice[1-39]: 39
===
Actually I did not select any system type anyhow. And it does not allow me
to select it somehow, but the default choice is correct - system type is
MV88F6290! I don't know why but it is a very nice that default system type
is exactly what I need :) (please give some comments on it)
The questions!
1) It looks like Xenomai do support the target SoC (MV88F6290), as well as
do support processor type ARM926 it has.
Then why I can not find the CPU dependent definitions in the patched
kernel's source code?
2) What does it takes for you to support this system and CPU if it is not
supported yet?
IF you do support for this system for 2.6.29 version of kernel It would be
great because I can test it on my target board and give you all feed back
with the results, and finally you can include it to the next patches.
Looking forward to hearing from you any help regarding anything I can do to
run the patched kernel on my board successfully.
Sergey Didenko
[-- Attachment #2: Type: text/html, Size: 2621 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2009-10-16 9:30 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-14 6:19 [Xenomai-help] Support for ARCH_MV88F6290 Didenko Sergey
2009-10-14 7:25 ` Gilles Chanteperdrix
2009-10-16 5:26 ` Didenko Sergey
2009-10-16 7:43 ` Gilles Chanteperdrix
2009-10-16 8:30 ` Didenko Sergey
2009-10-16 8:46 ` Gilles Chanteperdrix
2009-10-16 8:56 ` Didenko Sergey
2009-10-16 9:30 ` Didenko Sergey
-- strict thread matches above, loose matches on Subject: below --
2009-10-08 8:27 Didenko Sergey
2009-10-08 8:41 ` Gilles Chanteperdrix
2009-10-09 2:09 ` Didenko Sergey
2009-10-09 9:12 ` Gilles Chanteperdrix
2009-09-25 6:12 Didenko Sergey
2009-09-25 8:37 ` Gilles Chanteperdrix
[not found] ` <1f3e02580909250400r7595efw769fedac12b71fce@domain.hid>
[not found] ` <4ABCA99D.1040206@domain.hid>
[not found] ` <1f3e02580909250526v52a0408ex455cc22191f3802@domain.hid>
[not found] ` <4ABCC977.6010500@domain.hid>
[not found] ` <1f3e02580909280458ubf3f610he5e52aab1efa1cc6@domain.hid>
2009-09-29 16:27 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.