Re: [ECOS] at91sam9263ek support ver. beta 1

[Jonathan Larmour <jifl@eCosCentric.com>]

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