This is the mail archive of the
mailing list for the eCos project.
Re: [ECOS] at91sam9263ek support ver. beta 1
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:
>> 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 ?
> 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?
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.
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