public inbox for ecos-devel@sourceware.org
 help / color / mirror / Atom feed
From: Evgeniy Dushistov <dushistov@mail.ru>
To: Jonathan Larmour <jifl@eCosCentric.com>
Cc: ecos-discuss@ecos.sourceware.org, ecos-devel@ecos.sourceware.org
Subject: Re: [ECOS] at91sam9263ek support ver. beta 1
Date: Wed, 21 Jan 2009 19:20:00 -0000	[thread overview]
Message-ID: <20090121182051.GA12420@rain> (raw)
In-Reply-To: <496F6BD6.3040001@eCosCentric.com>

On Thu, Jan 15, 2009 at 05:01:10PM +0000, Jonathan Larmour wrote:
> Hi Evgeniy,
> 
> Thanks for working on this.
> 
> Evgeniy Dushistov wrote:
> > 
> > I need this changes, because of at91sam9 use the same code as arm9 to
> > work with caches: 
> > http://sites.google.com/site/duhistov/Home/0003-rename-all-hal_cache.h-to-var_cache.h-and-copy-creat.patch?attredirects=0
> 
> Urk. There are easier ways to do this. And in any case, putting
> ARM9-specific code in the architecture HAL is not right. Even with that
> addressed, it will break a lot of people's ports out there (not in
> anoncvs). That's something which should not be done lightly - I don't mean
> it can never be done, but it should be avoided and in this case can be. And
> in fact, should be because that's what the name "var_cache.h" signifies - a
> different processor variant, whereas in your patch it's used for platform
> ports too, most of which have the same variant.
> 
> I think the main problem is that we have separate processor HALs for ARM9,
> XScale, etc. But not for ARM7. There should be probably be an ARM7
> processor variant HAL to deal with bits which are specific to that. That's
> where hal_cache.h would live, along with anything else that isn't shared
> with other processor variants, but is shared with other ARM7's.
> 

But how this helps in our case, in at91 family there are arm7 and arm9
variants? That's why I move common with arm9 part to level higher -> arm.

You suggest just make copy/paste from arm9 to at91 ?
Or there is cdl trick to use(include) in at91 header from arm9 directory?

There are no other examples of such situation in eocs source code base,
when core of processor changed, but IP blocks are almost the same?

> This would also open up the possibility in future of breaking out some code
> in vectors.S which currently has to cater for the lowest-common-denominator
> instruction set of ARM architecture v4. It would be nice to be able to use
> better instructions in some places, and thumb in particular is simpler in
> later architecture versions.
> 
> Adding a new CYGPKG_HAL_ARM_ARM7 to the target definition in ecos.db is a
> much simpler change.
> 

There is CYGINT_HAL_ARM_ARCH_ARM7, may be it is possible to use it?

-- 
/Evgeniy

  reply	other threads:[~2009-01-21 19:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-15 15:17 Evgeniy Dushistov
2009-01-15 17:02 ` [ECOS] " Jonathan Larmour
2009-01-21 19:20   ` Evgeniy Dushistov [this message]
2009-01-21 19:54     ` Jonathan Larmour

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=20090121182051.GA12420@rain \
    --to=dushistov@mail.ru \
    --cc=ecos-devel@ecos.sourceware.org \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=jifl@eCosCentric.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).