Re: at91sam9263ek

[Jonathan Larmour <jifl@eCosCentric.com>]

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