Assignment query & tree organization

Assignment query & tree organization

[andrea michelotti]

Hi,
I already sent a mail to devel mailing list asking how to insert a new
target into eCos source tree.
Gary Thomas answered me and I think there is no problem to sign a copyright
assignment if needed.
Now I would like to evaluate the effort to get the contribution accepted
into the tree.
Let me resume what I did for our new processor in this way you can estimate
the distance between what I did in the ecos tree and what you expect:
1) I created a new hal entry called diopsis/arch (part number:AT572D740)
this is essentially a copy of arm/arch with modifications in vector.S and
some vector routines for the DSP. Some other modifications are planned to
extend diopsis capabilities.
2) I created a new hal entry called diopsis/atjtst that contains the code
for two platforms that use diopsis. Most of code is derived from the
AT91(EB0) porting.
3) I added two entries into ecos.db containing these two new platforms.

thanks

--
Andrea Michelotti <amichelotti@atmel.com>
- Atmel Rome www.atmelroma.it

Re: Assignment query & tree organization

[Gary Thomas]

On Wed, 2004-06-02 at 08:17, andrea michelotti wrote:
> Hi,
> I already sent a mail to devel mailing list asking how to insert a new
> target into eCos source tree.
> Gary Thomas answered me and I think there is no problem to sign a copyright
> assignment if needed.
> Now I would like to evaluate the effort to get the contribution accepted
> into the tree.
> Let me resume what I did for our new processor in this way you can estimate
> the distance between what I did in the ecos tree and what you expect:
> 1) I created a new hal entry called diopsis/arch (part number:AT572D740)
> this is essentially a copy of arm/arch with modifications in vector.S and
> some vector routines for the DSP. Some other modifications are planned to
> extend diopsis capabilities.
> 2) I created a new hal entry called diopsis/atjtst that contains the code
> for two platforms that use diopsis. Most of code is derived from the
> AT91(EB0) porting.
> 3) I added two entries into ecos.db containing these two new platforms.

Why have you not just made the changes within the ARM tree?  I really 
don't like the idea of having two trees which cover ARM with slight 
differences.  The HAL is designed such that platform (or even family)
differences can be supported, but still within the architecture tree.

Could you send these changes (to this list) as a patch?  Then we can
comment further.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates

Re: Assignment query & tree organization

[Jonathan Larmour]

andrea michelotti wrote:
> Hi,
> I already sent a mail to devel mailing list asking how to insert a new
> target into eCos source tree.
> Gary Thomas answered me and I think there is no problem to sign a copyright
> assignment if needed.
> Now I would like to evaluate the effort to get the contribution accepted
> into the tree.
> Let me resume what I did for our new processor in this way you can estimate
> the distance between what I did in the ecos tree and what you expect:
> 1) I created a new hal entry called diopsis/arch (part number:AT572D740)
> this is essentially a copy of arm/arch with modifications in vector.S and
> some vector routines for the DSP. Some other modifications are planned to
> extend diopsis capabilities.

I don't know much about the Diopsis, but from what I see it contains an 
ARM7 with a DSP. If eCos is running on the DSP itself that would want its 
own HAL, but I would surmise that it's running on the ARM but prodding the 
DSP and providing access to it. It's not clear to me why this would require 
a separate architecture HAL, rather than providing a way for variant 
processor HALs to extend the architecture HAL in the way you would want.

The advantage is that the ARM HAL gets a lot more attention and so the 
Diopsis will get any improvements and fixes that come for the ARM HAL if it 
uses it. If the Diopsis has its own architecture tree, it would not get 
those benefits, and so would lose out on those improvements unless someone 
notices. So it would be beneficial to keep them together if it is sensible 
to do so.

> 2) I created a new hal entry called diopsis/atjtst that contains the code
> for two platforms that use diopsis. Most of code is derived from the
> AT91(EB0) porting.

Were you using eCos v2.0 or more recent CVS? The AT91 HALs had some 
substantial work and improvements done to them since eCos v2.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Assignment query & tree organization

[Jonathan Larmour]

Gary Thomas wrote:
> 
> Could you send these changes (to this list) as a patch?  Then we can
> comment further.

Just to pre-empt a possible mistake... Gary means the changes relative to 
the ARM architecture HAL, as generated by something like:
cd ecos/packages/hal
diff -urN arm/arch diopsis/arch > mypatch.txt

and preferably weeding out any unnecessary changes (such as whole files 
you've remove - the diff is just a text file which you can edit).

Rather than sending the entire set of files.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine

Re: Assignment query & tree organization

[Andrea Michelotti]

Jonathan Larmour wrote:

> I don't know much about the Diopsis, but from what I see it contains an
> ARM7 with a DSP. If eCos is running on the DSP itself that would want its
> own HAL, but I would surmise that it's running on the ARM but prodding the
> DSP and providing access to it. It's not clear to me why this would
require
> a separate architecture HAL, rather than providing a way for variant
> processor HALs to extend the architecture HAL in the way you would want.
>
> The advantage is that the ARM HAL gets a lot more attention and so the
> Diopsis will get any improvements and fixes that come for the ARM HAL if
it
> uses it. If the Diopsis has its own architecture tree, it would not get
> those benefits, and so would lose out on those improvements unless someone
> notices. So it would be beneficial to keep them together if it is sensible
> to do so.

Thank you very much for your interest.
As I said the modifications to arm architecture at the moment are restricted
to vectors.S to enhance interrupt handling (use of Advanced Interrupt
Controller to call interrupt handlers) and just an init procedure that
install two interrupt handlers for the DSP.
I don't like very much the duplication of code that I did at the moment. But
I would like to be free to optimize and specialize some piece of ARM7 code
without affecting other platforms. I'll have to modify also some part of the
stub to support debugging of diopsis (single step, stop during break...,
intercept particular addresses..). The idea will be to see diopsis not as an
ARM7 + a memory mapped DSP, but as a single processor.
Is there a clean way to modify interrupt handling and stub calls doing a
variant processor?
Do you think is acceptable a solution where I modify some arm/arch files via
#ifdef HAL_XX_DIOPSIS_YY?


> Were you using eCos v2.0 or more recent CVS? The AT91 HALs had some
> substantial work and improvements done to them since eCos v2.

I used the standard v2.0 distribution.
I'll check CVS version ASAP.  thank you.


Thank you
Andrea.

Re: Assignment query & tree organization

[Jonathan Larmour]

Andrea Michelotti wrote:
> Jonathan Larmour wrote:
> 
> 
>>I don't know much about the Diopsis, but from what I see it contains an
>>ARM7 with a DSP. If eCos is running on the DSP itself that would want its
>>own HAL, but I would surmise that it's running on the ARM but prodding the
>>DSP and providing access to it. It's not clear to me why this would
> 
> require
> 
>>a separate architecture HAL, rather than providing a way for variant
>>processor HALs to extend the architecture HAL in the way you would want.
>>
>>The advantage is that the ARM HAL gets a lot more attention and so the
>>Diopsis will get any improvements and fixes that come for the ARM HAL if
> 
> it
> 
>>uses it. If the Diopsis has its own architecture tree, it would not get
>>those benefits, and so would lose out on those improvements unless someone
>>notices. So it would be beneficial to keep them together if it is sensible
>>to do so.
> 
> 
> Thank you very much for your interest.
> As I said the modifications to arm architecture at the moment are restricted
> to vectors.S to enhance interrupt handling (use of Advanced Interrupt
> Controller to call interrupt handlers) and just an init procedure that
> install two interrupt handlers for the DSP.

Then it sounds like we should be able to do something to support this. As 
per Gary's other mail, the diff/patch of the arch hal changes would be good.

> I don't like very much the duplication of code that I did at the moment. But
> I would like to be free to optimize and specialize some piece of ARM7 code
> without affecting other platforms. I'll have to modify also some part of the
> stub to support debugging of diopsis (single step, stop during break...,
> intercept particular addresses..). The idea will be to see diopsis not as an
> ARM7 + a memory mapped DSP, but as a single processor.

I think you would have some significant hurdles with GDB to achieve that. 
Is it what developers would want anyway? Since they are entirely separate 
but parallel execution threads, running different code, it's difficult to 
perceive the benefit.

> Is there a clean way to modify interrupt handling and stub calls doing a
> variant processor?

Roughly how does the AIC work? It may be something we've already dealt with 
in a different way before. I had a quick search but only found 
http://www.atmel.com/dyn/resources/prod_documents/6075S.pdf which only says 
it optimises ISR branch and execution without saying how. If it means that 
it will return the address of the ISR to use then there's only a relatively 
small part of vectors.S that would need to be ifdeffed.

But if not, it can all be done, if nothing else by just ifdeffing entire 
functions, or even files, based on some CDL option that the 
variant/platform HAL defines.

> Do you think is acceptable a solution where I modify some arm/arch files via
> #ifdef HAL_XX_DIOPSIS_YY?

I think we want to keep generic code as generic. Instead the approach to 
take is to take a step back and figure out what it is you are wanting to 
allow being overridden and why. It's possible you might still have an 
ifdef, but on some generic capability like:

#ifdef CYGHWR_HAL_INTC_SUPPLIES_HANDLER

which would be a macro the platform HAL defines. So if other similar 
systems come along later, they would also make the same define.

Note that we haven't said that putting this in its own architecture tree is 
the wrong thing to do - it may be right, in which case that's what we'll 
do. But it is to be avoided if it can be.

>>Were you using eCos v2.0 or more recent CVS? The AT91 HALs had some
>>substantial work and improvements done to them since eCos v2.
> 
> 
> I used the standard v2.0 distribution.
> I'll check CVS version ASAP.  thank you.

Since obviously this contribution would be checked in to CVS, it would be a 
good idea to do that.

Thanks,

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine