[ECOS] Re: eCos on IDT RC32364

[Bart Veer <bartv@cygnus.co.uk>]

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