This is the mail archive of the
ecos-devel@sourceware.org
mailing list for the eCos project.
Re: at91sam9263ek
Evgeniy Dushistov wrote:
On Tue, Nov 18, 2008 at 04:37:33PM +0000, Jonathan Larmour wrote:
Andrew Lunn wrote:
On Thu, Nov 06, 2008 at 09:23:28PM +0300, Evgeniy Dushistov wrote:
Hi,
I want to see working ecos on at91sam9263ek board.
As far as I know, there is no freely available source code of ecos port on
this hardware, am I right? (I know about ecoscentric, but it is not
freely available).
May be anybody is working on such kind of port?
Right now I'm reading docs about cdl language, and stuck on which
variant to choose: create directory at91sam9 in
packages/hal/arm/arm9 and write hal package from scratch
or use packages/hal/arm/at91 stuff, at91sam9263ek is very similar
to at91sam7s,
I don't think it's that similar. At least, it seems similar at a
high-level, but differs in most of the details once you get into it. The
register layouts differ in many places between the SAM9 variants even. I
think you'd end up with huge amounts of ifdefs.
Can you, please, give, example of such defence?
Well I had flicked through our own SAM926x implementation to see the
variations, and there was differences for most of the base addresses as
you saw, the bus matrix, the EBI, pin mappings, peripheral assignments,
USB and PLLs.
Just to be clear, I was talking about cloning, rather than really starting
from scratch, but I'm sure that's what you were considering.
I recommend the former approach. If there is anything that can sensibly be
shared, perhaps it could be broken out into a separate package.
you mean split hal on several packages?
like package for work with gpio,
for reset cpu and so on?
I meant have a common package for the bits which are indeed common.
The reason is that I think it would be bad for the AT91 HAL to be a big
mess of #ifdefs for all the different variants all the way through. It's
getting that way already. eCos is meant to be modular, rather than having
large monolithic headers with the kitchen sink thrown in. It becomes
difficult to work out exactly what does apply where.
I guess alternatively, if it were in a single package, then it would be
better to break it into different files, and only the correct files are
used according to the configuration. A bit like the SH3 or SH4 HALs (I
suggest looking at those to see what I mean). Those had to deal with the
same sorts of problems - peripherals in various implementations combined
in different ways.
IMHO.
For example, consider the cache and MMU stuff. That really shouldn't
belong in the AT91 HAL. At least not the existing form of AT91 HAL. At the
very least you can't have hal_cache.h and var_io.h in both the ARM9 HAL
and the AT91 HAL, so _something_ will have to be majorly reorganised.
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.
------["The best things in life aren't things."]------ Opinions==mine