[Xenomai] xenomai , irq and pci

Jeroen Van den Keybus jeroen.vandenkeybus at gmail.com
Wed Mar 5 20:59:52 CET 2014

> >> task0 is one high prior in primary domain on core0.
> >> this task wait for event, that is fired by fpga irq.
> >> than this task will make some pci accesses to the fpga.

A while ago (11/02) you wrote to this list ('[Xenomai] Xenomai and pci
access') because you had issues with PCI transfers. Did you fix those ? How
large are your transfers ?

>> the other task (task1) is a shadow task, but running in secondary domain
> >> on core 1.
> >> This task make many big memcpy to sram.

I remember having asked for the complete PCI bus layout and to try out
other memory access methods besides memcpy. Did this do anything ?

Since you mention you have an FPGA, I would now suggest instrumenting it
(add some logging) as to find out when and how (regular intervals or with
interruptions) your FPGA is accessed by the PCI bus.


> >> in the ipipe_handler_irq we have a function callback.
> >> a small driver hooks to this callback add make some tracepoint into
> >> a shared memory.
> >>
> >> with the trace we see some time a very high jitter in the
> ipipe_handler_irq
> >> function (around 250 us).
> >> has anyone an explanation for this?
> >>
> >> and a 4 byte access from task0 to fpga need more than 300us,
> >>   while task1 is writing to sram.
> >
> > Maybe the problem is the size of the PCI burst when writing to the SRAM?
> > How large is it? If the sram is mapped with "write-combine", it will be
> > buffered and written in large bursts. Maybe you could try mapping the
> > sram area uncached?
> >
> Also, you do not tell us if your processor has two real cores, or if
> they are hyperthreaded?
> --
>                                                                 Gilles.
> _______________________________________________
> Xenomai mailing list
> Xenomai at xenomai.org
> http://www.xenomai.org/mailman/listinfo/xenomai

More information about the Xenomai mailing list