Am 14.07.2015 um 00:39 schrieb Gilles Chanteperdrix:
You mean there is an issue with bus contention? Are there many
things occupying the bus when the problem happens?
Hi,
both cpu core can access our pci-card.
at this time we only have one pci-card with an fpga(with dpram) and a sram.
the fpga generate our system tick. And have a company internal bus system.
this bus system can configured with the dpram & fpga-config register.
we also must read witch irq come from the fpga, because internal he can have
more than one irq sources. and we must quit this irq. (with reading a
fpga register)
we see that if one core accessing the pci-bus, the other core have a
high latency.
core0 = importan & high prior accessing fpga and sram
core1 = linux & visu & some other low prior
if a low prior copy a memblock to/from the sram, the core0 have high
latency in
our irq handler at reading some data from fpga.
so we add a own pci-blocker task on core1. this task ist started about
50us before
next tick-irq is coming. now our irq handle can access the fpga without
waiting.
the old mainboard have pci on the southbridge.
but now we have a new mainboard. the new chipset have no pci bus.
on the mainboard there is now a pci-express to pci bridge chip.
we see that __ipipe_handle_irq is always called correct. but from this
function to our irq-handler, we have
a high latency and we see, that pci-locker task is not started 50us
before irq. sometime he started 100us or more
after the hardware irq.
i have orderd more documents about the bridge chip and wiring diagram
about bridge-chip and apic.
tomorrow i will measure the apic_eoi function time.
regards
Johann
PS: think we need a PCIexpress card, not a pci-card.
_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai
