This is the mail archive of the ecos-discuss@sourceware.cygnus.com mailing list for the eCos project. See the eCos home page for more information.
>>>>> "mconner" == mconner <mconner@ziga.com> writes: mconner> I was wondering if anyone was working on getting eCos mconner> running on IDTs 32364 processor. They have an EVAL board mconner> called the 79s364. The 32364 has a MIP-II instruction set mconner> architecture with instruction enhancements and also a mconner> RiscCore 4000 MMU. I was also wondering if would be mconner> possible to use the TX89 tools/HAL and do a port from mconner> there? Any feel for the level of effort involved? As far as I am aware nobody has yet attempted this port, but I can provide some idea of the issues involved - based on information from a couple of sources within Cygnus. The first problem is to build a suitable toolchain. If you configure and build for the TX39 then the resulting tools will not be usable for the IDT 32364. Unfortunately there are many little MIPS variants and a toolchain suitable for one may not be immediately usable for the other. For example the TX39 has a 3-operand multiply, but the IDT part does not. There is no specific toolchain for the IDT part since nobody has contributed the necessary support. Instead it will be necessary to configure the toolchain for the more generic mips-elf target, at least initially, although this will not fully exploit the 32364's instruction set. The toolchain sources currently available on the sourceware site can be configured for mips-elf but there is a minor build problem in the simulator package. It should be relatively easy to work around this and produce a suitable patch. Also the toolchain sources have not been validated for mips-elf, so a "make check" would definitely be in order. I would not expect any major divergence from the TX39 results. Unfortunately configuring for mips-elf target will create a toolchain for the old MIPS ABI, not the current EABI. For most of eCos this should not be a problem, the tools will just do the right thing. There are a few bits of code that may be affected: startup, context switching, low-level interrupt handling, hardware exception handling, and possibly the linker scripts. Some of these will need attention anyway, for example I am not sure that interrupts work in exactly the same way on the TX39 and the IDT part, but you should be aware of the ABI issue. For the architectural side of the port it would be best to make a copy of the existing hal/mips directories into e.g. hal/idt32364, making appropriate additions to the top-level targets and packages files, and then work on this copy. In due course Cygnus will be generalizing the existing TX39 support into general MIPS support and some merging will be required, but for now a separate set of packages will make life easier. Apart from the ABI issues mentioned above most of the architectural HAL package should be reusable. There is no need to worry about floating point issues, 64 bit pointers, or mips16 support, any of which would complicate matters. The exact way in which interrupts and hardware exceptions work on the IDT chip will need to be examined, there may have to be some changes to the existing TX39 code in this area. In addition there is one important difference between the TX39 and the IDT part, namely the existence of an MMU. Initially this should be disabled completely, or if that is not possible it should be initialized during startup to give a flat address space with a one-one mapping of physical<->virtual memory and no attempt at protection. At some point in the future eCos may well start exploiting some of the MMU features, for example to prevent code from being accidentally overwritten, but that is an issue for later. The initial platform HAL port should be relatively straightforward since the board has a sensible amount of SRAM as well as DRAM. It will be necessary to implement suitable diag routines and a linker script. As far as I can tell the default EPROM has a sensible monitor on it, and a cursory inspection implies that gdb knows how to talk to it - at least "<IDT>" is a prompt that gdb is supposed to recognize. Right now I do not think we have suitable device drivers for the on-board peripherals such as the ethernet chip, so you would have to write your own for the devices you are interested in. As far as time estimates are concerned, you are probably looking at something of the order of two to four weeks to get a minimal system up and running, and a similar number of months for a fully tested system with support for all the on-board devices. Obviously a lot will depend on past experience with the architecture and with embedded systems generally, not to mention your exact requirements in terms of device support. Bart Veer // eCos net maintainer