public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Port to MIPS II, IDT-79RC32334
@ 2000-10-03 12:27 Tim Michals
  2000-10-08  9:43 ` Bart Veer
  0 siblings, 1 reply; 4+ messages in thread
From: Tim Michals @ 2000-10-03 12:27 UTC (permalink / raw)
  To: ecos-discuss

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]

All,
 
How long do you think it would take to port ecos1.3 
for a MIPS-II IDT-79RC32334? (Without network support?)
 
Tim

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Port to MIPS II, IDT-79RC32334
  2000-10-03 12:27 [ECOS] Port to MIPS II, IDT-79RC32334 Tim Michals
@ 2000-10-08  9:43 ` Bart Veer
  2000-10-10  6:09   ` Tim Michals
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Veer @ 2000-10-08  9:43 UTC (permalink / raw)
  To: tim; +Cc: ecos-discuss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Port to MIPS II, IDT-79RC32334
  2000-10-08  9:43 ` Bart Veer
@ 2000-10-10  6:09   ` Tim Michals
  2000-10-11  9:03     ` Bart Veer
  0 siblings, 1 reply; 4+ messages in thread
From: Tim Michals @ 2000-10-10  6:09 UTC (permalink / raw)
  To: bartv; +Cc: ecos-discuss

Bart,

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
tools.

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
properly.

THANKS for your valuable input,

Tim


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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Port to MIPS II, IDT-79RC32334
  2000-10-10  6:09   ` Tim Michals
@ 2000-10-11  9:03     ` Bart Veer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Veer @ 2000-10-11  9:03 UTC (permalink / raw)
  To: tim; +Cc: ecos-discuss

>>>>> "Tim" == Tim Michals <tim@cygnetinc.com> writes:

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

I would recommend also checking the vintage of that compiler and
linker. If it is based on sources prior to gcc 2.95.2 or binutils 2.10
it might lack features such as constructor priority ordering or
selective linking.

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

Existing working code is always a big help, especially because it
implies that the hardware actually works. There is one possible issue:
if you are thinking about contributing back some of your work and you
incorporate bits of that existing BSP, there could be copyright and/or
licensing problems. Just something to keep in mind.

Bart Veer // eCos net maintainer

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-10-11  9:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-10-03 12:27 [ECOS] Port to MIPS II, IDT-79RC32334 Tim Michals
2000-10-08  9:43 ` Bart Veer
2000-10-10  6:09   ` Tim Michals
2000-10-11  9:03     ` Bart Veer

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).