From: Jonathan Larmour <jifl@eCosCentric.com>
To: Evgeniy Dushistov <dushistov@mail.ru>
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:54:00 -0000 [thread overview]
Message-ID: <49777D7A.4040602@eCosCentric.com> (raw)
In-Reply-To: <20090121182051.GA12420@rain>
Evgeniy Dushistov wrote:
> On Thu, Jan 15, 2009 at 05:01:10PM +0000, Jonathan Larmour wrote:
>> 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.
Which is IMHO the wrong approach.
What I am proposing is that an ARM7-based AT91 target would have a target
record in ecos.db that included both CYGPKG_HAL_ARM_AT91 and
CYGPKG_HAL_ARM_ARM7. An ARM9-based AT91 target would have a target record
in ecos.db that contains both CYGPKG_HAL_ARM_AT91 and CYGPKG_HAL_ARM_ARM9.
> You suggest just make copy/paste from arm9 to at91 ?
Nope.
> Or there is cdl trick to use(include) in at91 header from arm9 directory?
No need.
> 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?
No indeed there are no current examples, which is why we need to do
something a bit more radical, i.e. creating a CYGPKG_HAL_ARM_ARM7 package
to break out the bits that are different from other cores.
>> 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?
That's not really relevant for what I'm talking about, since we need to be
concerned about the location of files like hal_cache.h, which can't depend
on configuration options.
Jifl
--
eCosCentric Limited http://www.eCosCentric.com/ The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------ Opinions==mine
prev parent reply other threads:[~2009-01-21 19:54 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
2009-01-21 19:54 ` Jonathan Larmour [this message]
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=49777D7A.4040602@eCosCentric.com \
--to=jifl@ecoscentric.com \
--cc=dushistov@mail.ru \
--cc=ecos-devel@ecos.sourceware.org \
--cc=ecos-discuss@ecos.sourceware.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 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).