[ECOS] at91sam9263ek support ver. beta 1

Jonathan Larmour jifl@eCosCentric.com
Thu Jan 15 17:02:00 GMT 2009


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.

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.

> Common part for working with arm9 mmu, move it to common files, because
> of I see a lot of duplication in hal/arm/arm9: 
> http://sites.google.com/site/duhistov/Home/0004-move-common-for-arm9-code-for-work-with-mmu-into-com.patch?attredirects=0

Again ARM9 code in the architecture HAL is not appropriate. It should live
in the ARM9 processor variant HAL. With a new file, or via something
included from hal_mmu.h via a HAL-provided option.

As it stands this would break a lot of people's own ports outside of
anoncvs because of duplicated definitions (even once moved to the ARM9 HAL)
- this can be avoided in this case by changing the macro names, e.g. by
prefixing "CYGARC_HAL_".

> Some time ago(several weeks or  whole month), I sent request to fsf,
> about assigning copyrights, but have no reply, may be they just drop my
> email.

They have a backlog after the christmas break, but I would have thought
they should have got through it by now. If you are worried it may have been
lost, send a mail to assign [AT] fsf.org

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

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list