From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4600F735.2030205@domain.hid> Date: Wed, 21 Mar 2007 10:13:25 +0100 From: Jan Kiszka MIME-Version: 1.0 Subject: Re: [Xenomai-core] Xenomai support for ARM926EJ References: <17914.63535.18893.207257@domain.hid> <17920.13832.789072.876398@domain.hid> <17920.60301.400005.135175@domain.hid> In-Reply-To: <17920.60301.400005.135175@domain.hid> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig1074D1108112635402E810FA" Sender: jan.kiszka@domain.hid List-Id: "Xenomai life and development \(bug reports, patches, discussions\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai@xenomai.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1074D1108112635402E810FA Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Gilles Chanteperdrix wrote: > Dmitry Adamushko wrote: > > On 20/03/07, Gilles Chanteperdrix = wrote: > > > Muruganandam Ganapathy wrote: > > > > The board is based on the Fujitsu SOC which has the ARM926EJ pr= ocessor > > core. > > > > > > > > This board has SPI, I2C and 10/100 ethernet interfaces and it c= an > > 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 mesaur= ed with > > > > Xenomai in ARM9 > > > > processor based platforms, if any. > > > > The interrupt response expected is around 40 -50 microseconds i= n our > > case. > > > > The interrupt response I mean, it is the time between the gener= ation of > > the > > > > interrupt and the actual ISR invocation. > > > > > > > > > > > > Whether use of Xenomai will enable us meet this timing reqireme= nt. > > > > > > The latencies I have observed so far on ARM are usually larger tha= n 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. > >=20 > > Gilles, as I understood the question was about the interrupt latency= , not > > the scheduling one. > >=20 > > I guess, the vitually tagged cache is an additional component of hig= h > > scheduling latencies on ARM. > >=20 > > The interrupt latency should be ok though. >=20 > 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 --------------enig1074D1108112635402E810FA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGAPc1niDOoMHTA+kRAhr8AJ9LAit/q/2av/Xze73/683X4oyddwCdG8Uu WEJN3lp2c5MDTaLx1jZuuZE= =FWzS -----END PGP SIGNATURE----- --------------enig1074D1108112635402E810FA--