[Adeos-main] porting adeos to MIPS architecture

[Adeos-main] porting adeos to MIPS architecture

[toon.diels]

[-- Attachment #1: Type: text/plain, Size: 941 bytes --]

Hi all,

I am porting adeos-1.0 to a MIPS processor. The most straight forward activities are porting the inline
assembly code for eg enabling/disabling interrupt, save/restoring registers etc.

However, porting the interrupt pipe (and domain switching) is not that trivial since it requires rewriting of the ipipe.
MIPS interrupt mechanisms are different then the x86 interrupt handling.

Before I start rewriting the interrupt (and exception) pipe mechanism to MIPS architecture, I would like to ask the
ADEOS originators what they expect to be reused when doing an architecture port: eg is it just reusing the API or
do you also want to reuse the sources (and which ones).

I have added some visio drawings with respect to the MIPS interrupt/exception handling to indicate how this takes
place on a MIPS.

(See attached file: viper_irq_pipeline.vsd)(See attached file: viper_irq.vsd)

thank you for the information and kind regards,

Toon

[-- Attachment #2: viper_irq_pipeline.vsd --]
[-- Type: application/octet-stream, Size: 43008 bytes --]

[-- Attachment #3: viper_irq.vsd --]
[-- Type: application/octet-stream, Size: 50176 bytes --]

[Adeos-main] Re: porting adeos to MIPS architecture

[Philippe Gerum]

Hi Toon,

toon.diels@domain.hid writes:
 > 
 > I am porting adeos-1.0 to a MIPS processor.

Bright and shinny day indeed ! :o)

 > Before I start rewriting the interrupt (and exception) pipe mechanism to MIPS architecture, I would like to ask the
 > ADEOS originators what they expect to be reused when doing an architecture port: eg is it just reusing the API or
 > do you also want to reuse the sources (and which ones).
 > 

The bottom line is of course keeping the API identical across
ports. Btw, please don't hesitate to suggest changes/extensions to
this API since everyone is welcome to participate in any part of this
project. The only thing that we must take care of is preventing Adeos
from bloating :o>

Now back to your question. The code layout for x86 was designed as
follows:

- kernel/adeos.c and include/linux/adeos.h contain
arch-independent stuff, so I guess that it should be possible to
port these files nearly as is, kernel header specifics kept apart.

- arch/i386/kernel/adeos.c, arch/i386/kernel/ipipe.c and
include/asm-i386/adeos.h are the arch-dependent parts of Adeos. If the
interrupt handling is that different on MIPS, I suspect that most of
ipipe.c has to be rewritten then, but this should be rather
straightforward since the code is (hopefully) simple.

Basically, the work done in ipipe.c comes down to:
	   - provide the interrupt and exception redirection/hooking
code (grabbing the IDT).
	   - implement the generic IRQ and exception handlers
	   - implement the IRQ and exception synchronization loop
called when the pipeline stage is unstalled.

arch/i386/kernel/adeos.c provides the domain switching code (rather
simple, just a lightweight stack switch) and a few other
arch-dependent implementations of services called from the generic part
in kernel/adeos.c. So I guess that this file is also candidate for
heavy changes across archs.

Other changes in the Linux tree are only aimed at trapping Linux
activity at the proper places to yield control to
Adeos when needed. include/asm-i386/system.h is pivotal since it
allows to control the interrupt pipeline. arch/i386/kernel/entry.S is
important too.

In any case, great care was taken to bracket _all_ the needed changes
to a vanilla Linux kernel between conditional blocks testing for the
CONFIG_ADEOS def/undef, just track them in C and assembly files. This
might not be very aesthetic, but this should be quite practical for
people doing ports.

 > I have added some visio drawings with respect to the MIPS interrupt/exception handling to indicate how this takes
 > place on a MIPS.
 > 
 > (See attached file: viper_irq_pipeline.vsd)(See attached file:
 > viper_irq.vsd)

I'll take a look at it since I'm an ignorant member of the peanut
gallery as far as the MIPS arch is concerned (along with a few
billions other things too ;o)

PS: I strongly suggest that you start working from Adeos milestone 2
(adeos-m2.tar.gz) which is now published on savannah. This milestone
is the stable one, M1 (1.0) was more like a proof-of-concept.
Incidentally, I've just finished the preliminary port of Adeos to
Linux/x86 2.5.25 in less than two days using this release, so I guess
it will be simpler for you too.

Cheers,

Philippe.

Re: [Adeos-main] porting adeos to MIPS architecture

[Karim Yaghmour]

Hello Toon,

This is great. I'm looking forward to more ports like this. I'd really
like to take a look at the drawings and give you some feedback, but
there's no Visio for Linux and I haven't been running that other OS
for a long time. Could you export those to PS or EPS?

Cheers,

Karim

toon.diels@domain.hid wrote:
> 
> Hi all,
> 
> I am porting adeos-1.0 to a MIPS processor. The most straight forward activities are porting the inline
> assembly code for eg enabling/disabling interrupt, save/restoring registers etc.
> 
> However, porting the interrupt pipe (and domain switching) is not that trivial since it requires rewriting of the ipipe.
> MIPS interrupt mechanisms are different then the x86 interrupt handling.
> 
> Before I start rewriting the interrupt (and exception) pipe mechanism to MIPS architecture, I would like to ask the
> ADEOS originators what they expect to be reused when doing an architecture port: eg is it just reusing the API or
> do you also want to reuse the sources (and which ones).
> 
> I have added some visio drawings with respect to the MIPS interrupt/exception handling to indicate how this takes
> place on a MIPS.
> 
> (See attached file: viper_irq_pipeline.vsd)(See attached file: viper_irq.vsd)
> 
> thank you for the information and kind regards,
> 
> Toon
> 
>   ------------------------------------------------------------------------------------------------------------------------------------------------------
>                              Name: viper_irq_pipeline.vsd
>    viper_irq_pipeline.vsd    Type: unspecified type (application/octet-stream)
>                          Encoding: base64
> 
>                     Name: viper_irq.vsd
>    viper_irq.vsd    Type: unspecified type (application/octet-stream)
>                 Encoding: base64

-- 
===================================================
                 Karim Yaghmour
               karim@domain.hid
      Embedded and Real-Time Linux Expert
===================================================

Re: [Adeos-main] porting adeos to MIPS architecture

[Herman Bruyninckx]

On Wed, 17 Jul 2002 toon.diels@domain.hid wrote:

[...]
> MIPS interrupt mechanisms are different then the x86 interrupt handling.

Do you have some URL with documentation about this difference?

Herman

-- 
K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://www.mech.kuleuven.ac.be/~bruyninc>  +32 16 322480