Hello Phillipe,
I would like to thank you for your information on porting Adeos.
Now I registered my Custom domain, virtualizing Timer Interrupt with the
same resolution of Linux, during this time I made use of one of my 7
Segment display to make sure the interrupt handlers of TestDomain displays
Adeos, and I could achieve it too.

I have not tested __ipipe_tune_timer yet, I have one query about it,

Correct if I am wrong. So far my understandig is
1.  __ipipe_tune_timer, manged by the control domain to less resolution than
Linux is responsilbe to call __ipipe_propagate_irq to Linux at regular
interval of HZ.
2. During the course of tuning timer, the current tick count is saved in a
variable to make sure the get_timeoffset should not go wrong during the time
of getting date on Linux.

May I know if there is something more I should understand,also I could read
that in Xenomai, Aperiodic and Periodic Timer playing big role, so the
clarifications with you will help me to get out of few doubts and move on to
fine tuning of Adeos and also understanding in porting of xenomai and it
dependency.

Regards
Subbu

On 1/17/07, Philippe Gerum <[EMAIL PROTECTED]> wrote:

On Wed, 2007-01-17 at 20:30 +0530, Subramani Venkatesh wrote:
> Phillipe,
> I will surely look into this, so far local_irq_enable/disable i.e
> unstall and stall routines did not cause  problem in my assembly code.
> But I was facing this particular system call issue due to use of stack
> as arguments to the __ipipe_syscall_root  and also in my case the
> venilla kernel is using the same register for syscall number and
> return value, during this case when Iam  trying to save intial system
> call number on stack and once __ipipe_syscall_root is done I am
> reading it back, this may be corrupting stack, so I think I need to
> put more effort to resolve this and oragnize it.
> BTW  phillipe at this stage can I go testing timer interrupts using by
> other domain, which registers as priority domain than linux ?

If the interrupt exit path does not suffer from unexpected register
cloberring, yes.

>
> Regards
> Subbu
>
>
> On 1/17/07, Philippe Gerum <[EMAIL PROTECTED]> wrote:
>         On Wed, 2007-01-17 at 16:23 +0530, Subramani Venkatesh wrote:
>         > Hello Philippe,
>         > I would like to thank you once again for the HINT.
>         > Now I avoided changes to system call calling
>         __ipipe_syscall_root from
>         > my assembly code and tested the same, well it not giving any
>         errors as
>         > sent you yesterday, this concludes there is a problem in a
>         way of
>         > calling __ipipe_syscall_root, I guess my stack is getting
>         corrupted, i
>         > will make sure my stack is saved before calling
>         __ipipe_syscall_root
>         > and resolve the issues.
>
>         You should also check whether substituting inline code from
>         asmmacro.h
>         like local_irq_enable/disable with the I-pipe stall/unstall
>         calls had
>         any bad side-effect on the register set. Maybe t0 is not the
>         only
>         register affected by such operations anymore.
>
>         > I thank you once again.
>         >
>         > Cheers
>         > Subbu
>         >
>         > On 1/16/07, Philippe Gerum < [EMAIL PROTECTED]> wrote:
>         >         On Tue, 2007-01-16 at 15:49 +0530, Subramani
>         Venkatesh wrote:
>         >         > Hello All,
>         >         > I am currently porting Adeos-ipipe on one of my
>         MIPS
>         >         architecture. I
>         >         > am using I-Pipe 1.5-01, X86 as reference to my
>         porting. So
>         >         Far I did
>         >         > relevant changes in
>         >         > 1.Interrupts handlers
>         >         > 2. System calls
>         >         > 3. Pagefault Handler
>         >         > Except Exception handling, I mean critcial bug
>         events.
>         >         > With this changes I am able to Boot Linux kernel
>         and also
>         >         able to
>         >         > mount Ramdisk successfully.
>         >         >
>         >
>         >         [...]
>         >
>         >         > Opening console is successfull and
>         executing /sbin/init
>         >         > Algorithmics/MIPS FPU Emulator v1.5
>         >         > INIT: version 2.85 booting
>         >         > grep: error while loading shared libraries:
>         libc.so.6:
>         >         failed to map
>         >         > segment from shared object: Error 4090
>         >
>         >         There is likely something fishy in the syscall
>         interception
>         >         path from
>         >         arch/mips/kernel/entry.S; all the syscalls seem to
>         return
>         >         error values
>         >         mistakenly once the pipelining is in effect. You may
>         want to
>         >         check your
>         >         changes in this area.
>         >
>         >         Btw, it would be nice to work in an open manner and
>         post your
>         >         code on
>         >         this list if you want to ask for help about it
>         here.
>         >         Contribution has to
>         >         work both ways. TIA,
>         >
>         >         --
>         >         Philippe.
>         >
>         >
>         >
>         --
>         Philippe.
>
>
>
--
Philippe.



_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main

Reply via email to