Hi all,
are there IPIPE Patches for recent kernels (2.6.19) available for
Freescale's i.MX1/i.MXL and Atmel's AT91RM9200 cpus available.
Thanks a million,
Steven
___
Xenomai-core mailing list
Xenomai-core@gna.org
Gilles,
are there IPIPE Patches for recent kernels (2.6.19) available for
Freescale's i.MX1/i.MXL and Atmel's AT91RM9200 cpus available.
The IPIPE patches for ARM exist for linux 2.6.14 and 2.6.15. There is an
i.MX21 port for 2.6.14 and an AT91 port for 2.6.15...
Thanks very much.
Where
Gilles,
are there IPIPE Patches for recent kernels (2.6.19) available for
Freescale's i.MX1/i.MXL and Atmel's AT91RM9200 cpus available.
The IPIPE patches for ARM exist for linux 2.6.14 and 2.6.15. There is an
i.MX21 port for 2.6.14 and an AT91 port for 2.6.15...
Thanks very much.
Where
Philippe,
Since Philippe has done the x86 port of Adeos on 2.6.19, he will
probably be able to comment more on that.
Genirq definitely makes Adeos ports and maintenance easier. A mid-term
goal is to rebase all Adeos ports over 2.6.19 and later.
Ok. Are you working on ipipe for ARM based
Hi all,
we're doing the first steps with Xenomai and stumbled about some problems.
On our AT91RM9200 (adeos-ipipe-2.6.14-arm-1.5-04,
ipipe-2.6.14-at91-1.5-04.patch) a simple application (that just creates and
destroys two threads)
rt_task_create(task_1,task_1,0,50,0);
Hi all,
I wrote:
On our AT91RM9200 (adeos-ipipe-2.6.14-arm-1.5-04,
ipipe-2.6.14-at91-1.5-04.patch) a simple application (that just creates and
destroys two threads)
rt_task_create(task_1,task_1,0,50,0);
rt_task_create(task_2,task_2,0,51,0);
...
Hi Gilles,
I now tested Gille's brand new adeos-ipipe-2.6.19-arm-1.6-01.patch. The
above problems disapeared. I even do see a Xenomai: POSIX: destroyed
thread now.
So is this a known bug of ipipe-1.5 vs ipipe-1.6?
Or does anyone remember a bug like that?
I do not think there is such a
Gilles,
here comes the I-pipe patch for linux 2.6.19 on ARM. In addition to the
upgrade to linux 2.6.19, the AT91 port is improved:
Using vanilla 2.6.19, your new patch and xenomai from SVN as of yesterday
the test programm latency hangs randomly after a while ...
Did you test with latency?
Hi Gilles,
I am running xenomai (svn 22.02.2007) with adeos-ipipe-2.6.19-arm-1.6-02.patch
on our AT91RM9200 board. (# CONFIG_PREEMPT is not set)
When starting latency with 100µs period I get
~ # latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in
Gilles,
When starting latency with 100µs period I get
~ # latency
== Sampling period: 100 us
== Test mode: periodic user-mode task
== All results in microseconds
warming up...
BUG: soft lockup detected on CPU#0!
...
Ideas? How can I help with debugging this?
100us is too small, as I
Hi,
i pick up this issue again.
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat
Steven Scholz wrote:
Hi,
i pick up this issue again.
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period
Gilles,
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat min|-lat
Gilles,
Sure but I would still not expect the system to hang!
As I said missing a deadline is bad but ok.
But hanging the whole system is not quite ok.
I want this bug solved too, especially since I am not sure that we will
only see it with too short periods.
Makes us two! ;-)
I would
Philippe,
But I don't get the output of __backtrace()!
Before calling your backtrace helper, try adding:
ipipe_set_printk_sync(ipipe_current_domain);
And then use printk() instead of my_printk()?
Yes, switching this on is a brute force attempt to bypass any
bufferization and allow
Hi all,
I am running 2.6.19 + adeos-ipipe-2.6.19-arm-1.6-02.patch +
xenomai-svn-2007-02-22
on an AT91RM9200 (160MHz/80MHz).
When starting latency -p 200 it runs for a while printing
RTT| 00:05:37 (periodic user-mode task, 200 us period, priority 99)
RTH|-lat min|-lat
Hi Gilles,
Ok, found the bug (actually, Philippe did), as almost expected, the way
it is related to the latency program period is not really obvious. The
bug is that in the macro irq_handler in entry-armv.S, the return value
(in r0) of __ipipe_grab_irq is overriden by the subsequent call to
Hi all,
using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
interrupt handler for ethernet controller.
Now I wonder if this interrupt handler will be preempted by Xenomai if there
is a high priority, periodic real time task? Thus will the duration of the
ethernet
Philippe,
using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
interrupt handler for ethernet controller.
Now I wonder if this interrupt handler will be preempted by Xenomai if there
is a high priority, periodic real time task?
Hw interrupts are forcibly enabled
Philippe Gerum wrote:
On Thu, 2007-03-08 at 11:08 +0100, Steven Scholz wrote:
Philippe,
using an oscilloscope I found that the AT91RM9200 spends up to 300µs in the
interrupt handler for ethernet controller.
Now I wonder if this interrupt handler will be preempted by Xenomai
Philippe,
Thus will the duration of the
ethernet interrupt handler add the the worst case latency?
Not from Linux IRQ handlers; you may want to check this using the
tracer. If hw interrupts are masked there, then it's a blatant bug.
How could I check this using the tracer? Small hint
Hi all,
is there a ChangeLog for ADEOS IPIPE patches like
ksrc/arch/arm/patches/adeos-ipipe-2.6.19-arm-1.6-03.patch ?
Thanks.
--
Steven
___
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
Hi,
I just updated to the current xenomai svn.
After patching linux 2.6.19 for AT91RM9200 a
make ARCH=arm CROSS_COMPILE=arm-softfloat-linux-gnu- at91rm9200ek_defconfig
results in
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
HOSTCC scripts/kconfig/conf.o
HOSTCC
I wrote,
I just updated to the current xenomai svn.
After patching linux 2.6.19 for AT91RM9200 a
make ARCH=arm CROSS_COMPILE=arm-softfloat-linux-gnu- at91rm9200ek_defconfig
results in
...
file arch/arm/xenomai/Kconfig already scanned?
make[1]: *** [at91rm9200ek_defconfig] Error 1
Steven Scholz wrote:
I wrote,
I just updated to the current xenomai svn.
After patching linux 2.6.19 for AT91RM9200 a
make ARCH=arm CROSS_COMPILE=arm-softfloat-linux-gnu- at91rm9200ek_defconfig
results in
...
file arch/arm/xenomai/Kconfig already scanned?
make[1
25 matches
Mail list logo
