This is the mail archive of the ecos-discuss@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]

Re: 8260 porting.


>>>>> "Suresh" == Suresh N <nsuresh@cdotb.ernet.in> writes:

Suresh> hi everyone, We are trying to port eCos on MPC 8260 processor
Suresh> on ADS board.  I have got some doubts about the process. Any
Suresh> hints about this will be helpful.

Well, there's
http://sources.redhat.com/ecos/docs-latest/porting/index.html

But it doesn't contain any help for variant porting (yet). 

In short, what you want to do is to have a good look at the mpc8xx and
pp60x variant directories. Then clone the former into mpc82xx and
change it as necessary.

Note that for 82xx support there may have to be made architecture
changes as well - or rather, more code in the current architecture
HAL which should be moved to the variant HALs. For a start, make any
such changes to the architecture HAL using #ifdefs and I'll help you
clean it up later (or tell you how to clean it up ;)

Suresh> 	a) We have got a debugger working with the ADS board
Suresh> . So we don't have to implement the ecos stub for the
Suresh> board... is that right?

Yes and no. If you already have a working debugger, there's obviouosly
little incitement for you to do the work. On the other hand, many of
the eCos debugging features rely on GDB and features in the eCos stub
(thread debugging for instance).

Also, without a stub port, you're unlikely to find anyone else to help
you with problems you may run into later (seeing as others may not
have a properly working debugging environment as you seem to have).

Finally, after having the board initialization and serial code
working, you practically have a stub. It's just a special eCos
configuration. So you have little to gain from not doing this.


Suresh> 	b) The debugger would have already initialised the
Suresh> hardware.. so is hal_hardware_init is required?

Same arguments as above. See the exising hardware initialization as a
way of easing your writing of hal_hardware_init: you can read all the
register states and just stuff them into the registers again at
startup.

If you plan on using eCos in a final product it needs to be able to
initialize the board properly (unless you plan on shipping the product
with eCos running in RAM and _very_ large batteries included ;)

Suresh> 	c) What about RAM startup and ROM startup ?

Well, if you don't do the above work, you will never be able to use
ROM startup for the simple reason that the debug environment you have
now will not be available in ROM startup mode.


Suresh> 	d) Is there any porting under progress?

Not that I know of. Bart may know more.

Jesper

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