This is the mail archive of the ecos-maintainers@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Assignment query & tree organization


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]