Re: [Xenomai-core] Xenomai support for ARM926EJ
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
Gilles Chanteperdrix wrote: > Dmitry Adamushko wrote: > > On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> 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 signature.asc Description: OpenPGP digital signature ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
Gilles Chanteperdrix wrote: > Dmitry Adamushko wrote: > > On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> 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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
Dmitry Adamushko wrote: > On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
On 20/03/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> 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@gna.org https://mail.gna.org/listinfo/xenomai-core -- Best regards, Dmitry Adamushko ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
On 3/16/07, Gilles Chanteperdrix <[EMAIL PROTECTED]> 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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
Re: [Xenomai-core] Xenomai support for ARM926EJ
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. ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
[Xenomai-core] Xenomai support for ARM926EJ
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 ___ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
