[Adeos-main] Porting Adeos-Ipipe on AVR32 (NGW 100), enable_pipeline.

[Adeos-main] Porting Adeos-Ipipe on AVR32 (NGW 100), enable_pipeline.

[A C]

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

Hello,
We are trying to implement the function enable_pipeline. 

For the NIOS2 architecture in this fonction there are calls to the functions __ipipe_init_hrclock(), __ipipe_init_hrtimer(). So we checked those functions and we understand what they do. But there are still two questions :
- Where can we find the physical adresses of the clock (timer 64 bits) (named "na_hrclock") and of the timer (timer 32 bits) (named "na_hrtimer) ? We don't find the declaration.

- Where is setting up the input clock frequency of the two timers (timer 64 bits and timer 32 bits)?

For the AVR32, we have at least  two 16-bit timers, we are thinking about to do the same functions (__ipipe_init_hrclock(), __ipipe_init_hrtimer()). We think we can also use the "ioremap_nocache" fonction. 

Regards

Adrien Chiron and Vincent Vanbesien



      

[-- Attachment #2: Type: text/html, Size: 1167 bytes --]

Re: [Adeos-main] Porting Adeos-Ipipe on AVR32 (NGW 100), enable_pipeline.

[Philippe Gerum]

On Tue, 2009-12-15 at 14:42 +0000, A C wrote:
> Hello,
> We are trying to implement the function enable_pipeline. 
> 
> For the NIOS2 architecture in this fonction there are calls to the
> functions __ipipe_init_hrclock(), __ipipe_init_hrtimer(). So we
> checked those functions and we understand what they do. But there are
> still two questions :
> - Where can we find the physical adresses of the clock (timer 64 bits)
> (named "na_hrclock") and of the timer (timer 32 bits) (named
> "na_hrtimer) ? We don't find the declaration.

You don't care about those declarations. Those are NIOS2 specific bits,
by definition. Besides, the NIOS2 is a  softcore, so those definitions
depend on the particular design that has been synthesized.

> 
> - Where is setting up the input clock frequency of the two timers
> (timer 64 bits and timer 32 bits)?
> 

In the NIOS2 case? Again, you don't care about this. What you do care
for is how you could get:

- a clock event source for the real-time domain
- a high precision monotonic clock to get precise timestamps

And you probably want to use what your board provides to this end, e.g.
using a freerunning timer to emulate the monotonic clock. It's possible
to use 16bit timers for that (some ARM platforms do), but that is
uselessly painful if you have better hw at hand.

How to set this up depends on your platform eventually, but you can't
copy/paste this from NIOS2 in any case.

> For the AVR32, we have at least  two 16-bit timers, we are thinking
> about to do the same functions (__ipipe_init_hrclock(),
> __ipipe_init_hrtimer()). We think we can also use the
> "ioremap_nocache" fonction. 

ioremap_nocache is just a helper to map a piece of memory having
side-effects in the kernel address space. You will have to resort to it
in case your platform provides MMIO to reach the (timer) devices. But
that is only a gory detail.

> 
> Regards
> 
> Adrien Chiron and Vincent Vanbesien
> 
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main


-- 
Philippe.

Re: [Adeos-main] Porting Adeos-Ipipe on AVR32 (NGW 100), enable_pipeline.

[Gilles Chanteperdrix]

Philippe Gerum wrote:
> (...) What you do care for is how you could get:
> 
> - a clock event source for the real-time domain
> - a high precision monotonic clock to get precise timestamps
> 
> And you probably want to use what your board provides to this end, e.g.
> using a freerunning timer to emulate the monotonic clock. It's possible
> to use 16bit timers for that (some ARM platforms do), but that is
> uselessly painful if you have better hw at hand.

Actually the ARM patch contains a few implementations of monotonic clock
emulations and clock event source based on all sort of kinds of hardware
counters. So, you may get some inspiration reading it. The usual scheme
is to use whatever Linux uses (except for AT91). We even try to document
this work, though you should take the advices with a grain of salt,
since they are intended to people writing support code for ARM, so, they
suppose that the whole generic I-pipe ARM support exists around.

http://www.xenomai.org/index.php/I-pipe:ArmPorting

-- 
                                          Gilles