* [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).