From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Sinisa Denic <sinisa.denic@domain.hid>
Cc: Xenomai help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] ARM cached,non-cached memory
Date: Tue, 02 Mar 2010 19:42:55 +0100 [thread overview]
Message-ID: <4B8D5C2F.6060005@domain.hid> (raw)
In-Reply-To: <201003021631.32165.sinisa.denic@domain.hid>
Sinisa Denic wrote:
> On Tuesday 02 March 2010 15:32:06 you wrote:
>> Sinisa Denic wrote:
>>> Hi, last year working with xenomai 2.4.2-3 we met problem (BUG) with
>>> memory caching on ARM AT91sam9260 arch.
>>> Then we were advised using non-cached memory and we've used it till
>>> now,but in our next application it has big performace slow down effect
>>> and I'm interested is this BUG solved in latest 2.4.10 - xenomai
>>> Regards,Sinisa
>> No, this is not a BUG in Xenomai. It is an architectural BUG^H^Hehaviour
>> of ARMv5, they have a VIVT cache, which is the cause of these issues.
>> Alternatively to using non-cached memory, you can use cached memory, and
>> flush cache when needed. Beware however defining "when needed", may be
>> complicated.
>>
>> A note: Xenomai 2.4.10 is not the latest, the latest is Xenomai 2.5.1
>> and it has a lot of performance improvements for ARM.
>
> Ok,sorry for my mistake I thought it is due to the xenomai.
> Of course we know new xeno 2.5.1 and all about ARM improvements,
> but we are afraid of switching to new kernel(current 2.6.21) and thus to new
> xenomai, because we have short time to deliver product and thus to well test
> all new components.
> Apart from memory caching 2.4 works well for us.
Ok. Understood.
> We work on critical relay protection device and new potential bug isn't
> desirable at all.
> I hope that xenomai 2.5.1 is heavily tested and stable for ARM arch,despite of
> some problems on the mailing list eg. native skin etc.
There is no such thing as bug-free software, as you probably know, but
we do our best to have the best stability possible. We have recently
fixed Xenomai for running on AT91SAM9263, and got good results over a
long testing period, the hardware support looks stable. The issue we
have such as with the native API are plain deterministic stupid bugs,
nothing which has any influence on stability.
> Al in all thank you very much we hope to see you in Belgrade soon.
> Sinisa
That could be arranged :-)
--
Gilles.
next prev parent reply other threads:[~2010-03-02 18:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-02 14:27 [Xenomai-help] ARM cached,non-cached memory Sinisa Denic
2010-03-02 14:32 ` Gilles Chanteperdrix
2010-03-02 15:31 ` Sinisa Denic
2010-03-02 18:42 ` Gilles Chanteperdrix [this message]
2010-03-06 10:42 ` Gilles Chanteperdrix
2010-03-08 7:58 ` Sinisa Denic
2010-03-08 13:52 ` Gilles Chanteperdrix
2010-03-08 14:59 ` Sinisa Denic
2010-03-08 15:13 ` Gilles Chanteperdrix
2010-03-08 15:34 ` Sinisa Denic
2010-07-11 11:32 ` Bosko Radivojevic
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B8D5C2F.6060005@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=sinisa.denic@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.