[ECOS] Port to MIPS II, IDT-79RC32334

Tim Michals tim@cygnetinc.com
Tue Oct 10 06:09:00 GMT 2000


I have a MIPS gcc compiler from a "company" which supports the IDT part.  I
will do some research to see if they modified the compiler and associated

Thanks for the input on the BSP.  The "company" has a BSP already, so I was
going to move some parts to eCOS as necessary.

What do you think of the plan?  I have done a port to a MPC860, and
restructured the startup code to do more POST tests. For example, located
some of the code to dual port memory to allow RAM tests and printf to work

THANKS for your valuable input,


----- Original Message -----
From: "Bart Veer" <bartv@redhat.com>
To: <tim@cygnetinc.com>
Cc: <ecos-discuss@sourceware.cygnus.com>
Sent: Sunday, October 08, 2000 11:43 AM
Subject: Re: [ECOS] Port to MIPS II, IDT-79RC32334

> >>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes:
>     Tim> How long do you think it would take to port ecos1.3 for a
>     Tim> MIPS-II IDT-79RC32334? (Without network support?)
> The answer (which you may not find particularly useful) is anywhere
> between some weeks and some months.
> The first issue to consider is the toolchain. Do you already have a
> known working toolchain for this chip? You say it is a MIPS-II
> variant, so in theory you can take a standard toolchain release, build
> your code with -mips2, and everything should just work. In practice
> there may be problems: MIPS vendors have the annoying habit of adding
> little instructions of their own, or worse removing existing
> instructions. You may find that the compiled code tries to use an
> instruction that does not actually work on the target processor.
> Tracking down problems like that can be very time-consuming. If you do
> not already have a known working toolchain I suggest asking on both
> the gcc and the binutils mailing lists and finding out if anybody
> knows the status wrt the IDT part.
> Even if the code generated with -mips2 works fine, it may not be
> optimal for the specific part you are targetting: there may be subtle
> differences in e.g. the pipeline implementation which could cause gcc
> to generate sub-optimal code. If your cpu specification has allowed
> for plenty of spare cycles then this should not be an issue, but if
> you expect to run the cpu flat out then you may want to investigate
> tools specifically optimised for that cpu. Offhand I do not know
> whether or not there is any IDT-specific work in current versions of
> gcc.
> Assuming you have a working toolchain the next stage is to add a cpu
> variant port for the IDT part to the MIPS HAL hierarchy. I suspect
> starting with the TX39 port would be the best bet. The porting guide
> that Jesper is working on,
> http://sources.redhat.com/ecos/docs-latest/porting/index.html
> should prove very useful. The time this stage takes will depend a lot
> on your experience with the MIPS architecture generally and with the
> IDT part in particular. I have not looked at the chip specs in any
> detail so I do not know what strange things (if any) go on the
> CP0 implementation or anything like that.
> A cpu variant port is of limited use unless you also have a board
> port. The time that will take depends in large part on the complexity
> of the board, including how many different devices you need to
> support. What support is there for debugging? If it is a brand-new
> board rather than a heavily-used evaluation board then you may well
> run into hardware problems.
> Even if all the above proves straightforward, there is always the risk
> that you have to spend weeks tracking down some sporadic race
> condition.
> So as I said, anywhere from some weeks to some months. Without a lot
> more information (that is not an invitation) I cannot realy give any
> better estimates than that.
> Bart Veer // eCos net maintainer

More information about the Ecos-discuss mailing list