ROSSIER Daniel wrote:
Hi Philippe,
I perfectly got the point that the pipeline is already up and running when
calibrate_delay() is called. On our ARM board, the pipeline seems to work
perfectly. I however misunderstands something.
The ipipe configures the timer in one-shot mode when ipipe_init is called,
right? (also according to what it is mentioned in the Adeos-enhanced
configuration file of Linux). Tracing the kernel during the boot process showed
us one timer IRQ only; this is coherent.
Is it correct that right after ipipe_init(), there is no realtime scheduler
yet? The pipeline doesn't care about the schedule (it's the stuff of the
Xenomai pod), and therefore, the pipline doesn't reprogram the timer by itself,
right? - and it would be necessary to do that if the timer is in oneshot mode.
So, if calibrate_delay() -not used by Adeos/Xenomai, I agree - is doing a busy
loop to evaluate the CPU performance, waiting for the next incoming timer IRQ,
the system doesn't exit the loop and freezes. It actually works as long as the
timer is in periodic mode.
It's actually the behaviour we observed on the ARM board with the ARM patch.
I probably missed something, please correct me.
On platforms that do work natively in one shot mode instead of using a PIT, the
I-pipe reprograms itself the underlying hw timer, _except_ if it has been told
differently by some domain, in which case it delegates this to the said domain.
Have a look at linux/arch/arm/mach-integrator/core.c in the Integrator/CP patch:
integrator_timer_interrupt().
IOW, the I-pipe reprograms the timer until Xenomai grabs the hw timer. Your patch
likely lacks the corresponding code to handle that part in the platform-dependent
section applicable to your board.
Thanks again for your input.
Daniel
-----Original Message-----
From: Philippe Gerum [mailto:[EMAIL PROTECTED]
Sent: Tue 2/21/2006 12:57 PM
To: ROSSIER Daniel
Subject: Re: [Xenomai-core] Timer and calibration
ROSSIER Daniel wrote:
Hi Philippe,
Great! Thx a lot for these precisions, it will help us.
But regarding calibrate_delay(), it's still called in the normal boot process
of Linux even with the Adeos/Xenomai patch.
Sure it is. The interrupt pipeline is up and running at this point (ipipe_init),
so there is no issue getting IRQs there.
I've also seen that the boot process on a x86 architecture actually works since
the timer value is read directly from the
timer (calibrate_delay_direct() in init/calibrate.c) and this doesn't need to get
a timer IRQ. But without that,
and if calibrate_delay() is called instead of calibrate_delay_direct(), it
fails.
It actually works in both cases. You do have the IRQ sub-system already
virtualized at that point. ipipe_init has engaged the pipeline, local_irq_enable()
right before the calibration delay unstalls the root domain, so the timer ticks
can flow through the pipeline, and they actually do (well, otherwise, you would
not have a single Adeos-enabled x86 box working since 2002 :o)
You can convince yourself by commenting out the local_irq_enable() statement
before the calibration is started: then your x86 box would completely stall.
(Sorry for my previous mail; when I talked about timer calibration, it was
delay calibration)
Daniel
-----Message d'origine-----
De : Philippe Gerum [mailto:[EMAIL PROTECTED]
Envoyé : mardi, 21. février 2006 12:41
À : ROSSIER Daniel
Cc : xenomai-core@gna.org
Objet : Re: [Xenomai-core] Timer and calibration
ROSSIER Daniel wrote:
Hello,
We are currently porting Adeos/Xenomai with Linux 2.6.14 on a ARM9-based
Freescale i.mx21 (litekit) development board.
We started from the available patch for the ARM-based Integrator board.
We are now facing some interesting problems regarding clock/timer
frequencies with this board, but they are about to be solved J
However, we have a question of understanding; as far as we know, ipipe
starts with an aperiodic (one-shot) timer at the initialization time,
and that before
the calibrate function has been called. So, we get one interrupt only
since the xenomai scheduler has not been registered (we understand
that the xenomai scheduler should give the next timer shot, but since it
is not registered yet, no timer reprogramming is achieved).
So, how can the calibrate function can be invoked safely if no timer IRQ
is received since this kind of calibration comes before the xenomai
registration
(the calibrate function needs IRQ timers to calibrate the number of busy
loops between two jiffies) ?
Unlike Linux's calibrate_delay loop, Xenomai's timer calibration code does
not
measure the CPU performance level, but only the average cost of
programming the
underlying timer hw in oneshot mode (time-wise), so that the nucleus can
take this
unavoidable delay into account when programming the next shot.
Nowadays, this is basically an x86+8254 PIT only issue, since on this
platform,
one has to go through the ISA bus to (re)program the PIT for the next
timer shot,
and this is quite expensive (1.5 - 2.5 us for each outb, and you need two
of them
for programming the shot). Btw, this is the reason why using the APIC when
available on x86 is always a good idea, since it only costs ~100 ns to
program the
timer there through a memory mapped register.
IOW, the code does not wait for any timer IRQ, but only measures the
average time
for setting up the proper hw registers in order to program a timer shot.
How is it realized with a x86 architecture (another timer source?)
Look at ksrc/arch/*/hal.c, where all archs implement
rthal_timer_calibrate() their
own way.
Is there any documentation - or discussion threads - which gives some
information about the use of timers/RTC/TSC with Xenomai?
Maybe. Try browsing the archive.
Thanks so much for your help
Kind regards
Daniel Rossier
------------------------------------------------------------------------
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
--
Philippe.
--
Philippe.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
