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
