[Xenomai-core] Xenomai support for ARM926EJ

[Xenomai-core] Xenomai support for ARM926EJ

[Muruganandam Ganapathy]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Hello,

I am new to Xenomai and trying to understand whether it is suitable for our
need.
We have a board based on ARM926EJ. I would like to know


1. is there Xenomai support for ARM926
   I did google through and found that Xenomai is for the user application
   In our case, we have a kernel mode driver/application which is very time
   critical and we were unable to meet the timing requirement using the
regular kernel.

2. If support is available, what is the version to use. I am running 2.6.19
   on the board.

Looking forward for a response.

Thanks
G.Muruganandam

[-- Attachment #2: Type: text/html, Size: 883 bytes --]

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Gilles Chanteperdrix]

Muruganandam Ganapathy wrote:
 > Hello,
 > 
 > I am new to Xenomai and trying to understand whether it is suitable for our
 > need.
 > We have a board based on ARM926EJ. I would like to know
 > 
 > 
 > 1. is there Xenomai support for ARM926

Xenomai supports most ARM processor cores. For example, the ARM926 is
supported with the ARM integrator board. The real question is: does it
support the particular board you use ? If not, then all you have to do
is to adapt the I-pipe patch to the board you use.


 >    I did google through and found that Xenomai is for the user application
 >    In our case, we have a kernel mode driver/application which is very time
 >    critical and we were unable to meet the timing requirement using the
 > regular kernel.

No, Xenomai APIs exist both in kernel and user space and are symetrical
as much as possible. So, it is up to you to choose if you want to
program your application in kernel or user-space. Note however that for
future-proof designs, it is recommended to only write driver code in
kernel-space, using the RTDM API, and to write the rest of your
application in user-space.


 > 
 > 2. If support is available, what is the version to use. I am running 2.6.19
 >    on the board.

2.6.19 is only supported by the latest v2.3.x branch; since it has not
yet been released you will have to download the sources via svn, by
typing something like:

svn co http://svn.gna.org/svn/xenomai/branches/v2.3.x xenomai

Note that if the board you use is not supported, you will get undefined
symbols building the kernel, and this is where your work will start:
implementing the missing functions for the board you use. The missing
functions concern hardware timer management, tsc emulation using the
hardware timer, and interrupts demultiplexing. We can help you doing
this work if you tell us which board you use.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Muruganandam Ganapathy]

[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]

On 3/16/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>
> Muruganandam Ganapathy wrote:
> > Hello,
> >
> > I am new to Xenomai and trying to understand whether it is suitable for
> our
> > need.
> > We have a board based on ARM926EJ. I would like to know
> >
> >
> > 1. is there Xenomai support for ARM926
>
> Xenomai supports most ARM processor cores. For example, the ARM926 is
> supported with the ARM integrator board. The real question is: does it
> support the particular board you use ? If not, then all you have to do
> is to adapt the I-pipe patch to the board you use.
>
>
> >    I did google through and found that Xenomai is for the user
> application
> >    In our case, we have a kernel mode driver/application which is very
> time
> >    critical and we were unable to meet the timing requirement using the
> > regular kernel.
>
> No, Xenomai APIs exist both in kernel and user space and are symetrical
> as much as possible. So, it is up to you to choose if you want to
> program your application in kernel or user-space. Note however that for
> future-proof designs, it is recommended to only write driver code in
> kernel-space, using the RTDM API, and to write the rest of your
> application in user-space.
>
>
> >
> > 2. If support is available, what is the version to use. I am running
> 2.6.19
> >    on the board.
>
> 2.6.19 is only supported by the latest v2.3.x branch; since it has not
> yet been released you will have to download the sources via svn, by
> typing something like:
>
> svn co http://svn.gna.org/svn/xenomai/branches/v2.3.x xenomai
>
> Note that if the board you use is not supported, you will get undefined
> symbols building the kernel, and this is where your work will start:
> implementing the missing functions for the board you use. The missing
> functions concern hardware timer management, tsc emulation using the
> hardware timer, and interrupts demultiplexing. We can help you doing
> this work if you tell us which board you use.




The board is based on the Fujitsu SOC which has the ARM926EJ processor core.

This board has SPI, I2C and 10/100 ethernet interfaces and it can support
16/32MB SDRAM
and 4/8MB flash memory.


In addition, I would like to know the interrupt reponse  mesaured with
Xenomai in ARM9
processor based platforms, if any.
The interrupt response expected is around 40 -50 microseconds in our case.
The interrupt response I mean, it is the time between the generation of the
interrupt and the actual ISR invocation.


Whether use of Xenomai will enable us meet this timing reqirement.

Looking forward to hear from you.


Thanks
G.Muruganandam







--
>
>
>                                            Gilles Chanteperdrix.
>

[-- Attachment #2: Type: text/html, Size: 3992 bytes --]

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Gilles Chanteperdrix]

Muruganandam Ganapathy wrote:
 > The board is based on the Fujitsu SOC which has the ARM926EJ processor core.
 > 
 > This board has SPI, I2C and 10/100 ethernet interfaces and it can support
 > 16/32MB SDRAM
 > and 4/8MB flash memory.

You still do not tell us the name of the board, but it is probably not
supported.

 > 
 > 
 > In addition, I would like to know the interrupt reponse  mesaured with
 > Xenomai in ARM9
 > processor based platforms, if any.
 > The interrupt response expected is around 40 -50 microseconds in our case.
 > The interrupt response I mean, it is the time between the generation of the
 > interrupt and the actual ISR invocation.
 > 
 > 
 > Whether use of Xenomai will enable us meet this timing reqirement.

The latencies I have observed so far on ARM are usually larger than 150
microseconds, but these are userspace dispatch latencies.

So, you could improve situation if you stay in interrupt handlers.

Another way to improve the situation a bit more is to use ucLinux, if
your platform is supported.

Still, IMHO, 40-50 microseconds is too ambitious.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Dmitry Adamushko]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

On 20/03/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
> Muruganandam Ganapathy wrote:
>  > The board is based on the Fujitsu SOC which has the ARM926EJ processor
core.
>  >
>  > This board has SPI, I2C and 10/100 ethernet interfaces and it can
support
>  > 16/32MB SDRAM
>  > and 4/8MB flash memory.
>
> You still do not tell us the name of the board, but it is probably not
> supported.
>
>  >
>  >
>  > In addition, I would like to know the interrupt reponse  mesaured with
>  > Xenomai in ARM9
>  > processor based platforms, if any.
>  > The interrupt response expected is around 40 -50 microseconds in our
case.
>  > The interrupt response I mean, it is the time between the generation of
the
>  > interrupt and the actual ISR invocation.
>  >
>  >
>  > Whether use of Xenomai will enable us meet this timing reqirement.
>
> The latencies I have observed so far on ARM are usually larger than 150
> microseconds, but these are userspace dispatch latencies.
>
> So, you could improve situation if you stay in interrupt handlers.
>
> Another way to improve the situation a bit more is to use ucLinux, if
> your platform is supported.
>
> Still, IMHO, 40-50 microseconds is too ambitious.

Gilles, as I understood the question was about the interrupt latency, not
the scheduling one.

I guess, the vitually tagged cache is an additional component of high
scheduling latencies on ARM.

The interrupt latency should be ok though.

>
> --
>
>
>                                             Gilles Chanteperdrix.
>
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
>


-- 
Best regards,
Dmitry Adamushko

[-- Attachment #2: Type: text/html, Size: 2643 bytes --]

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Gilles Chanteperdrix]

Dmitry Adamushko wrote:
 > On 20/03/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
 > > Muruganandam Ganapathy wrote:
 > >  > The board is based on the Fujitsu SOC which has the ARM926EJ processor
 > core.
 > >  >
 > >  > This board has SPI, I2C and 10/100 ethernet interfaces and it can
 > support
 > >  > 16/32MB SDRAM
 > >  > and 4/8MB flash memory.
 > >
 > > You still do not tell us the name of the board, but it is probably not
 > > supported.
 > >
 > >  >
 > >  >
 > >  > In addition, I would like to know the interrupt reponse  mesaured with
 > >  > Xenomai in ARM9
 > >  > processor based platforms, if any.
 > >  > The interrupt response expected is around 40 -50 microseconds in our
 > case.
 > >  > The interrupt response I mean, it is the time between the generation of
 > the
 > >  > interrupt and the actual ISR invocation.
 > >  >
 > >  >
 > >  > Whether use of Xenomai will enable us meet this timing reqirement.
 > >
 > > The latencies I have observed so far on ARM are usually larger than 150
 > > microseconds, but these are userspace dispatch latencies.
 > >
 > > So, you could improve situation if you stay in interrupt handlers.
 > >
 > > Another way to improve the situation a bit more is to use ucLinux, if
 > > your platform is supported.
 > >
 > > Still, IMHO, 40-50 microseconds is too ambitious.
 > 
 > Gilles, as I understood the question was about the interrupt latency, not
 > the scheduling one.
 > 
 > I guess, the vitually tagged cache is an additional component of high
 > scheduling latencies on ARM.
 > 
 > The interrupt latency should be ok though.

Interrupt handler reside in cached memory as well. And a source of high
latencies on ARM is the fact that the TLB is flushed with interrupts
off. So, even if the interrupt handler was in TCM to avoid latencies
induced by the cache, interrupts off sections would still cause high
latencies. So, the only chance of success is to use uCLinux with the
interrupt handler in TCM.

-- 


					    Gilles Chanteperdrix.

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 2465 bytes --]

Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
>  > On 20/03/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>  > > Muruganandam Ganapathy wrote:
>  > >  > The board is based on the Fujitsu SOC which has the ARM926EJ processor
>  > core.
>  > >  >
>  > >  > This board has SPI, I2C and 10/100 ethernet interfaces and it can
>  > support
>  > >  > 16/32MB SDRAM
>  > >  > and 4/8MB flash memory.
>  > >
>  > > You still do not tell us the name of the board, but it is probably not
>  > > supported.
>  > >
>  > >  >
>  > >  >
>  > >  > In addition, I would like to know the interrupt reponse  mesaured with
>  > >  > Xenomai in ARM9
>  > >  > processor based platforms, if any.
>  > >  > The interrupt response expected is around 40 -50 microseconds in our
>  > case.
>  > >  > The interrupt response I mean, it is the time between the generation of
>  > the
>  > >  > interrupt and the actual ISR invocation.
>  > >  >
>  > >  >
>  > >  > Whether use of Xenomai will enable us meet this timing reqirement.
>  > >
>  > > The latencies I have observed so far on ARM are usually larger than 150
>  > > microseconds, but these are userspace dispatch latencies.
>  > >
>  > > So, you could improve situation if you stay in interrupt handlers.
>  > >
>  > > Another way to improve the situation a bit more is to use ucLinux, if
>  > > your platform is supported.
>  > >
>  > > Still, IMHO, 40-50 microseconds is too ambitious.
>  > 
>  > Gilles, as I understood the question was about the interrupt latency, not
>  > the scheduling one.
>  > 
>  > I guess, the vitually tagged cache is an additional component of high
>  > scheduling latencies on ARM.
>  > 
>  > The interrupt latency should be ok though.
> 
> Interrupt handler reside in cached memory as well. And a source of high
> latencies on ARM is the fact that the TLB is flushed with interrupts
> off. So, even if the interrupt handler was in TCM to avoid latencies
> induced by the cache, interrupts off sections would still cause high
> latencies. So, the only chance of success is to use uCLinux with the
> interrupt handler in TCM.

I think implementing coloured caches (with reservations for RT
processes) could be an option as well. Once RT context switches no
longer require full cache flushes, those for non-RT processes could be
made interruptible. But all this would require heavy Linux hacking, I'm
afraid.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Gilles Chanteperdrix]

Gilles Chanteperdrix wrote:
> Dmitry Adamushko wrote:
>  > On 20/03/07, Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org> wrote:
>  > > Muruganandam Ganapathy wrote:
>  > >  > The board is based on the Fujitsu SOC which has the ARM926EJ processor
>  > core.
>  > >  >
>  > >  > This board has SPI, I2C and 10/100 ethernet interfaces and it can
>  > support
>  > >  > 16/32MB SDRAM
>  > >  > and 4/8MB flash memory.
>  > >
>  > > You still do not tell us the name of the board, but it is probably not
>  > > supported.
>  > >
>  > >  >
>  > >  >
>  > >  > In addition, I would like to know the interrupt reponse  mesaured with
>  > >  > Xenomai in ARM9
>  > >  > processor based platforms, if any.
>  > >  > The interrupt response expected is around 40 -50 microseconds in our
>  > case.
>  > >  > The interrupt response I mean, it is the time between the generation of
>  > the
>  > >  > interrupt and the actual ISR invocation.
>  > >  >
>  > >  >
>  > >  > Whether use of Xenomai will enable us meet this timing reqirement.
>  > >
>  > > The latencies I have observed so far on ARM are usually larger than 150
>  > > microseconds, but these are userspace dispatch latencies.
>  > >
>  > > So, you could improve situation if you stay in interrupt handlers.
>  > >
>  > > Another way to improve the situation a bit more is to use ucLinux, if
>  > > your platform is supported.
>  > >
>  > > Still, IMHO, 40-50 microseconds is too ambitious.
>  > 
>  > Gilles, as I understood the question was about the interrupt latency, not
>  > the scheduling one.
>  > 
>  > I guess, the vitually tagged cache is an additional component of high
>  > scheduling latencies on ARM.
>  > 
>  > The interrupt latency should be ok though.
> 
> Interrupt handler reside in cached memory as well. And a source of high
> latencies on ARM is the fact that the TLB is flushed with interrupts
> off. So, even if the interrupt handler was in TCM to avoid latencies
> induced by the cache, interrupts off sections would still cause high
> latencies. So, the only chance of success is to use uCLinux with the
> interrupt handler in TCM.
> 

I checked latency -t 2 on an Intel Xscale with the cache calibrator
running, and I get latencies around 70 us.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> I think implementing coloured caches (with reservations for RT
> processes) could be an option as well. Once RT context switches no
> longer require full cache flushes, those for non-RT processes could be
> made interruptible. But all this would require heavy Linux hacking, I'm
> afraid.

Using TCM removes any cache effect and does not require Linux hacking.

-- 
                                                 Gilles Chanteperdrix

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> I think implementing coloured caches (with reservations for RT
>> processes) could be an option as well. Once RT context switches no
>> longer require full cache flushes, those for non-RT processes could be
>> made interruptible. But all this would require heavy Linux hacking, I'm
>> afraid.
> 
> Using TCM removes any cache effect and does not require Linux hacking.
> 

How is TCM managed? Can you push parts of I-pipe/Xenomai or even some
applications into it? Or does this only help here if you have a few ops
of an interrupt handler to be saved from the (RT-wise) lousy caching
architecture of ARM?

[I threw coloured caches into the ring also to trigger some discussion
on a long-term solution for MMU-based Xenomai on ARM.]

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Xenomai-core] Xenomai support for ARM926EJ

[Gilles Chanteperdrix]

Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
> 
>>Jan Kiszka wrote:
>>
>>>I think implementing coloured caches (with reservations for RT
>>>processes) could be an option as well. Once RT context switches no
>>>longer require full cache flushes, those for non-RT processes could be
>>>made interruptible. But all this would require heavy Linux hacking, I'm
>>>afraid.
>>
>>Using TCM removes any cache effect and does not require Linux hacking.
>>
> 
> 
> How is TCM managed? Can you push parts of I-pipe/Xenomai or even some
> applications into it? Or does this only help here if you have a few ops
> of an interrupt handler to be saved from the (RT-wise) lousy caching
> architecture of ARM?

TCM are 2 16K contiguous memory areas: one where data can be put, the
other where code can be put. They are mapped into the address space, and
once it is done, some data or code must be copied into them. Moving one
function to the TCM should be pretty straight-forward, allowing several
arbitrary functions to be in the TCM would probably require some more
work: a possible implementation would be to put the functions and data
in some specific sections that would be copied in the TCM at load time.

> 
> [I threw coloured caches into the ring also to trigger some discussion
> on a long-term solution for MMU-based Xenomai on ARM.]

Right, TCM do not exist on all ARM.

-- 
                                                 Gilles Chanteperdrix