at91sam9263ek support ver. beta 1

at91sam9263ek support ver. beta 1

[Evgeniy Dushistov]

Hi,

here is the fresh series of patches to support at91sam9263 ek board.

Now it passes near 100 tests from ecos's test suite, uses MMU, support my nor flash
(there is empty place to install nor flash, at least on at91sam9263ek rev. B).

It still requires at91bootstrap or jtag to run.

Here is links to patches, I suppose size too big to attach:

Support of 115200 baudrate (common baudrate to work with serial line for u-boot and linux):

http://sites.google.com/site/duhistov/Home/0001-change-default-delay-in-get-character-via-serial-lin.patch?attredirects=0


Move pio definitions to differents files to reduce size of common for at91 boards file,
and make it easy for editing:

http://sites.google.com/site/duhistov/Home/0002-This-patch-separate-board-s-pio-layout.patch?attredirects=0

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

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

at91sam9263 hal package:
http://sites.google.com/site/duhistov/Home/0005-hal-package-for-at91sam9263ek-and-at91sam9.patch?attredirects=0

My nor flash support:
http://sites.google.com/site/duhistov/Home/0006-support-of-norflash-for-at91sam9263ek.patch?attredirects=0

Work with pio interrupts like they are real one:
http://sites.google.com/site/duhistov/Home/0007-implement-support-pio-interrupts-in-the-way-as-ordin.patch?attredirects=0

the last two patches not require to make full working at91sam9263's hal.

Any comments?

PS

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.

Re: [ECOS] at91sam9263ek support ver. beta 1

[Jonathan Larmour]

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

Re: [ECOS] at91sam9263ek support ver. beta 1

[Evgeniy Dushistov]

On Thu, Jan 15, 2009 at 05:01:10PM +0000, Jonathan Larmour wrote:
> 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.
> 

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.

You suggest just make copy/paste from arm9 to at91 ?
Or there is cdl trick to use(include) in at91 header from arm9 directory?

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?

> 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?

-- 
/Evgeniy

Re: [ECOS] at91sam9263ek support ver. beta 1

[Jonathan Larmour]

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