Hi Philippe,

On 05.11.2015 09:31, [email protected] wrote:
I just subscribe to the mailing list to ask you for a few insight on my
potential problem.

I'm having the same behaviour that Andreas Galauner observed on his board
and since there have been no news since April, I'm restarting this
thread...

I'm currently developping for a custom designed board based on a Zynq
7c020 and hoped to use Xenomai 3.0 on it.
Standard Linux (Xilinx version not Vanilla) is running fine on the board
but if I use the cobalt core, I'm having the same behaviour previously
described ie the system seems to hang for a random duration then becomes
responsive again as if nothing happened (several times).
It happens at each boot during:
- kernel decompression
- VFS/Rootfs mount
- console access
And after, it occurs randomly on command entered on console...

Also, it seems that network is not working with cobalt core enabled in
kernel (but with random freezes, I can't look at this issue for the
moment)

I'm suspecting some timer issue as Gilles supposed previously but I can't
find the beginning of a solution: I've followed the Guide "Porting Xenomai
dual kernel to a new ARM SoC" but as the arm core of the Zynq is a Cortex
A9, in theory, I've practically nothing to modify to have it working...

I've also enabled debug in I-Pipe and Xenoami and got no trace at all...

What I've seen so far is an enormous amount of interruptions on the twd
timer (and this is just after the boot!):

# cat /proc/interrupts
            CPU0       CPU1
  27:          0          0       GIC  27  gt
  29:   37426949   16329631       GIC  29  twd
  35:          0          0       GIC  35  f800c000.ocmc
  39:         43          0       GIC  39  f8007100.adc
  40:          0          0       GIC  40  f8007000.devcfg
  41:          0          0       GIC  41  f8005000.watchdog
  43:          0          0       GIC  43  ttc_clockevent
  45:          0          0       GIC  45  f8003000.dmac
  46:          0          0       GIC  46  f8003000.dmac
  47:          0          0       GIC  47  f8003000.dmac
  48:          0          0       GIC  48  f8003000.dmac
  49:          0          0       GIC  49  f8003000.dmac
  51:          0          0       GIC  51  e000d000.spi
  54:          0          0       GIC  54  eth0
  72:          0          0       GIC  72  f8003000.dmac
  73:          0          0       GIC  73  f8003000.dmac
  74:          0          0       GIC  74  f8003000.dmac
  75:          0          0       GIC  75  f8003000.dmac
  82:         49          0       GIC  82  xuartps
IPI1:          0          0  Timer broadcast interrupts
IPI2:        559        435  Rescheduling interrupts
IPI3:          0          0  Function call interrupts
IPI4:         25          8  Single function call interrupts
IPI5:          0          0  CPU stop interrupts
IPI6:          0          0  IRQ work interrupts
IPI7:          0          0  completion interrupts
Err:          0

To be more precise about my system, I'm using Linux 3.18.20 with the Adeos
I-Pipe patch for arm found in Xenomai 3.0 (Exact Zero) tarball on a
busybox-based rootfs.
I've taken a look at branch for-ipipe-3.18 in ipipe-gch.git but it seems
to be the same as  Xenomai 3.0's patch...

Does anyone have some idea where to look for a way to attack this issue?

Thanks in advance,

PS: If necessary I can post the kernel's config, but I did not want to put
too much data in this mail

Without looking too deep into your problem, I remember that
Zynq had similar problem with I-pipe enabled and the
frequency scaling kernel options enabled (I don't remember
the exact CONFIG_ name out of my head). So please make sure
to disable these config options.

Thanks,
Stefan


_______________________________________________
Xenomai mailing list
[email protected]
http://xenomai.org/mailman/listinfo/xenomai

Reply via email to