The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Gerte Hoogewerf]

Hi Xenomai team,

At LMI, we are in the machine vision industry, where some applications
require predictable and bounded ISR latency.   Although we are
gradually migrating our installations to Xilinx Zynq UltraScale+, most
field installations still run on the older Xilinx Zynq-7000 SoC.

We've been running Xenomai on our customized Zynq-7000 boards since
2021 or so.  Our products have been shipping with Xenomai 3, ipipe,
kernel 4.14 all this time.  Although it still runs and performs well,
the age of the stack is starting to affect security certification.

On multiple occasions, I've tried newer versions of Xenomai.   The
most recent version that still functions properly was kernel 5.4 (i.e.
the last version to support ipipe + Xenomai 3).  I was never able to
successfully boot anything newer than that version.

It typically hangs partway through boot, like this:

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.18.29-01121-g5d9e6ccea5cc
(ghoogewerf@NLKRLTF0FQR04) (arm-none-linux-gnueabihf-gcc (LMI3D G++
11.4.1-p1) 11.4.1 20240321, GNU ld (LMI3D G++ 11.4.1-p1) 2.40) #2 SMP
PREEMPT EVL Mon Jul 13 12:06:58 CEST 2026
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
[.....]
[    0.815404] io scheduler kyber registered
[    0.820358] zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
[    0.831589] dma-pl330 f8003000.dma-controller: Loaded driver for
PL330 DMAC-241330
[    0.839180] dma-pl330 f8003000.dma-controller:
DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
[    0.857446] brd: module loaded
[    0.865454] loop: module loaded
[    1.260102] Freeing initrd memory: 5620K
<======    HANG    ======>

The peculiar thing is that either "CONFIG_EVL=n" or "CONFIG_SMP=n"
works around this problem.  But that's not a good solution for obvious
reasons.

I am curious where Xenomai 4 stands regarding support for Zynq-7000
(or ARM32 in general).  Are you aware of problems with these older
boards?  Is there anything we can do ourselves to debug this further?
We are happy to share the full boot log, kernel config, and device
tree if that would help.  Any guidance or support you can offer would
be appreciated.

Thanks,

-- 
Gerte Hoogewerf
Senior Software Team Lead
LMI Technologies
Wiebachstraat 25b, Kerkrade 6466 NG, The Netherlands

-- 


This
email and any attachment(s) it may contain is confidential and is 
intended
solely for the use of the individual(s) to whom it is addressed. 
If you are not
the intended recipient of this email, you must not take 
action based on the
contents, nor distribute, nor expose any part of the 
content(s) to entities or
person(s) beyond the original distribution list. 
Please contact the sender and
delete the email if you have received it in 
error. Thank you.

Re: The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Philippe Gerum]

Gerte Hoogewerf <ghoogewerf@lmi3d.com> writes:

> Hi Xenomai team,
>
> At LMI, we are in the machine vision industry, where some applications
> require predictable and bounded ISR latency.   Although we are
> gradually migrating our installations to Xilinx Zynq UltraScale+, most
> field installations still run on the older Xilinx Zynq-7000 SoC.
>
> We've been running Xenomai on our customized Zynq-7000 boards since
> 2021 or so.  Our products have been shipping with Xenomai 3, ipipe,
> kernel 4.14 all this time.  Although it still runs and performs well,
> the age of the stack is starting to affect security certification.
>
> On multiple occasions, I've tried newer versions of Xenomai.   The
> most recent version that still functions properly was kernel 5.4 (i.e.
> the last version to support ipipe + Xenomai 3).  I was never able to
> successfully boot anything newer than that version.
>
> It typically hangs partway through boot, like this:
>
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 6.18.29-01121-g5d9e6ccea5cc
> (ghoogewerf@NLKRLTF0FQR04) (arm-none-linux-gnueabihf-gcc (LMI3D G++
> 11.4.1-p1) 11.4.1 20240321, GNU ld (LMI3D G++ 11.4.1-p1) 2.40) #2 SMP
> PREEMPT EVL Mon Jul 13 12:06:58 CEST 2026
> [    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
> [.....]
> [    0.815404] io scheduler kyber registered
> [    0.820358] zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
> [    0.831589] dma-pl330 f8003000.dma-controller: Loaded driver for
> PL330 DMAC-241330
> [    0.839180] dma-pl330 f8003000.dma-controller:
> DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
> [    0.857446] brd: module loaded
> [    0.865454] loop: module loaded
> [    1.260102] Freeing initrd memory: 5620K
> <======    HANG    ======>
>
> The peculiar thing is that either "CONFIG_EVL=n" or "CONFIG_SMP=n"
> works around this problem.  But that's not a good solution for obvious
> reasons.
>
> I am curious where Xenomai 4 stands regarding support for Zynq-7000
> (or ARM32 in general).  Are you aware of problems with these older
> boards?  Is there anything we can do ourselves to debug this further?
> We are happy to share the full boot log, kernel config, and device
> tree if that would help.  Any guidance or support you can offer would
> be appreciated.
>

To put it simply, every architecture Xenomai4 supports is considered
"tier 1", i.e. is actively maintained and must work
flawlessly. Therefore, although arm32 is aging, it is still fully
supported, not to speak of the fact that we do have quite a few projects
depending on it. However, we lost access to many platforms some time
ago, including Zynq hardware, so we can't test them routinely anymore.

Regarding the issue you are observing, it suspect this is
Dovetail-related. If so, xenomai 3.3 which is using Dovetail won't boot
on the Zynq either.

Such hang at boot is often the symptom of an issue with the proxy timer
Dovetail provides and xenomai relies on, i.e. the piece of code which
hands control over the system hardware timer to the real-time core.

To start debugging this, I would run the basic tests Dovetail provides
which cover the proxy tick management by configuring as follows:

CONFIG_DEBUG_IRQ_PIPELINE=y
CONFIG_IRQ_PIPELINE_TORTURE_TEST=y
CONFIG_DEBUG_DOVETAIL=y
CONFIG_EVL=n
CONFIG_SMP=y

These tests are executed during the boot sequence, a successful run
should look like this:

[    0.654959] Starting IRQ pipeline tests...
[    0.654981] IRQ pipeline: high-priority torture stage added.
[    0.654989] irq_pipeline-torture: CPU0 initiates stop_machine()
[    0.659603] irq_pipeline-torture: CPU3 responds to stop_machine()
[    0.659603] irq_pipeline-torture: CPU2 responds to stop_machine()
[    0.659603] irq_pipeline-torture: CPU1 responds to stop_machine()
[    0.659649] irq_pipeline-torture: CPU0 calls function on remote(s)
[    0.659666] irq_pipeline-torture: CPU1 handles remote function call
[    0.659677] irq_pipeline-torture: CPU2 handles remote function call
[    0.659689] irq_pipeline-torture: CPU3 handles remote function call
[    0.659856] CPU0: proxy tick device registered (396.00MHz)
[    0.659861] CPU2: proxy tick device registered (396.00MHz)
[    0.659867] CPU1: proxy tick device registered (396.00MHz)
[    0.666350] CPU3: proxy tick device registered (396.00MHz)
[    0.666440] irq_pipeline-torture: CPU0: irq_work handled
[    0.666451] irq_pipeline-torture: CPU0: in-band->in-band irq_work trigger works
[    0.666457] irq_pipeline-torture: CPU0: stage escalation request works
[    0.666465] irq_pipeline-torture: CPU0: irq_work handled
[    0.666475] irq_pipeline-torture: CPU0: oob->in-band irq_work trigger works
[    1.681508] CPU0: proxy tick device unregistered
[    1.681515] CPU2: proxy tick device unregistered
[    1.681521] CPU1: proxy tick device unregistered
[    1.688222] CPU3: proxy tick device unregistered
[    1.688345] IRQ pipeline: torture stage removed.
[    1.688354] IRQ pipeline tests OK.

Hopefully, some debug assertion this test suite enables is going to trip
instead.

-- 
Philippe.

Re: The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Gerte Hoogewerf]

Hi Philippe,

Thanks for the reply.

I built and ran the kernel with said options.  It's probably not
conclusive, since the tests passed.  With these options, the kernel
booted all the way into userland (because CONFIG_EVL=n).

See output below.

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 6.18.29-01153-g1e9f8ec43dcd
(ghoogewerf@NLKRLTF0FQR04) (arm-none-linux-gnueabihf-gcc (LMI3D G++
11.4.1-p1) 11.4.1 20240321, GNU ld (LMI3D G++ 11.4.1-p1) 2.40) #4 SMP
PREEMPT EVL Mon Aug 17 11:49:17 CEST 2026
[    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] OF: fdt: Machine model: Xilinx Zynq
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] cma: Reserved 750 MiB at 0x11000000
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
[    0.000000] OF: reserved mem: Reserved memory: No reserved-memory
node in the DT
[    0.000000] percpu: Embedded 12 pages/cpu s19468 r8192 d21492 u49152
[    0.000000] Kernel command line: console=ttyPS0,115200 cma=750M
l2x0_write_through=1
[    0.000000] Unknown kernel command line parameters
"l2x0_write_through=1", will be passed to user space.
[    0.000000] printk: log buffer data + meta data: 16384 + 51200 = 67584 bytes
[    0.000000] Dentry cache hash table entries: 32768 (order: 5,
131072 bytes, linear)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536
bytes, linear)
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 262144
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[    0.000000] rcu: Preemptible hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 100 jiffies.
[    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[    0.000000] slcr mapped to (ptrval)
[    0.000000] L2C: platform provided aux values match the hardware,
so have no effect.  Please remove them.
[    0.000000] L2C-310 erratum 769419 enabled
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[    0.000000] L2C-310 D prefetch enabled, offset 9 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x56760001
[    0.000000] IRQ pipeline enabled
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] zynq_clock_init: clkc starts at (ptrval)
[    0.000000] Zynq clock init
[    0.000000] ps_clk frequency not specified, using 33 MHz.
[    0.000001] sched_clock: 64 bits at 500MHz, resolution 2ns, wraps
every 4398046511103ns
[    0.000018] clocksource: arm_global_timer: freq: 499999995 Hz,
mask: 0xffffffffffffffff max_cycles: 0xe6a171a037, max_idle_ns:
881590485102 ns
[    0.000043] Switching to timer-based delay loop, resolution 2ns
[    0.000325] Console: colour dummy device 80x30
[    0.000351] Calibrating delay loop (skipped), value calculated
using timer frequency.. 999.99 BogoMIPS (lpj=499999)
[    0.000361] CPU: Testing write buffer coherency: ok
[    0.000390] CPU0: Spectre v2: using BPIALL workaround
[    0.000395] pid_max: default: 32768 minimum: 301
[    0.000541] Mount-cache hash table entries: 1024 (order: 0, 4096
bytes, linear)
[    0.000552] Mountpoint-cache hash table entries: 1024 (order: 0,
4096 bytes, linear)
[    0.001231] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.001262] cacheinfo: Unable to detect cache hierarchy for CPU 0
[    0.002306] Setting up static identity map for 0x100000 - 0x10003c
[    0.002473] rcu: Hierarchical SRCU implementation.
[    0.002478] rcu:     Max phase no-delay instances is 400.
[    0.002999] smp: Bringing up secondary CPUs ...
[    0.003680] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.003731] CPU1: Spectre v2: using BPIALL workaround
[    0.003844] smp: Brought up 1 node, 2 CPUs
[    0.003854] SMP: Total of 2 processors activated (1999.99 BogoMIPS).
[    0.003862] CPU: All CPU(s) started in SVC mode.
[    0.004053] Memory: 256456K/1048576K available (6144K kernel code,
224K rwdata, 1456K rodata, 1024K init, 84K bss, 20992K reserved,
770048K cma-reserved)
[    0.004557] devtmpfs: initialized
[    0.008386] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[    0.008531] clocksource: jiffies: freq: 0 Hz, mask: 0xffffffff
max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
[    0.008552] posixtimers hash table entries: 1024 (order: 1, 8192
bytes, linear)
[    0.008608] futex hash table entries: 512 (32768 bytes on 1 NUMA
nodes, total 32 KiB, linear).
[    0.019015] pinctrl core: initialized pinctrl subsystem
[    0.019919] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[    0.021704] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.022681] thermal_sys: Registered thermal governor 'step_wise'
[    0.024823] /axi/etb@f8801000: Fixed dependency cycle(s) with /replicator
[    0.024940] /axi/tpiu@f8803000: Fixed dependency cycle(s) with /replicator
[    0.024967] /axi/funnel@f8804000: Fixed dependency cycle(s) with
/axi/ptm@f889d000
[    0.024987] /axi/funnel@f8804000: Fixed dependency cycle(s) with
/axi/ptm@f889c000
[    0.025008] /axi/funnel@f8804000: Fixed dependency cycle(s) with /replicator
[    0.025047] /axi/ptm@f889c000: Fixed dependency cycle(s) with
/axi/funnel@f8804000
[    0.025079] /axi/ptm@f889d000: Fixed dependency cycle(s) with
/axi/funnel@f8804000
[    0.027727] /replicator: Fixed dependency cycle(s) with /axi/etb@f8801000
[    0.027820] /axi/etb@f8801000: Fixed dependency cycle(s) with /replicator
[    0.028053] /replicator: Fixed dependency cycle(s) with /axi/tpiu@f8803000
[    0.028162] /axi/tpiu@f8803000: Fixed dependency cycle(s) with /replicator
[    0.028391] /replicator: Fixed dependency cycle(s) with /axi/funnel@f8804000
[    0.028797] /axi/funnel@f8804000: Fixed dependency cycle(s) with
/axi/ptm@f889d000
[    0.028822] /axi/funnel@f8804000: Fixed dependency cycle(s) with
/axi/ptm@f889c000
[    0.028842] /axi/funnel@f8804000: Fixed dependency cycle(s) with /replicator
[    0.029084] /axi/funnel@f8804000: Fixed dependency cycle(s) with
/axi/ptm@f889c000
[    0.029196] /axi/ptm@f889c000: Fixed dependency cycle(s) with
/axi/funnel@f8804000
[    0.029422] /axi/funnel@f8804000: Fixed dependency cycle(s) with
/axi/ptm@f889d000
[    0.029509] /axi/ptm@f889d000: Fixed dependency cycle(s) with
/axi/funnel@f8804000
[    0.030334] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.030345] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.030980] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 27,
base_baud = 6249999) is a xuartps
[    0.031040] printk: legacy console [ttyPS0] enabled
[    0.656472] pps_core: LinuxPPS API ver. 1 registered
[    0.661475] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[    0.670642] PTP clock support registered
[    0.674730] FPGA manager framework
[    0.678947] vgaarb: loaded
[    0.681809] clocksource: Switched to clocksource arm_global_timer
[    0.696109] NET: Registered PF_INET protocol family
[    0.701211] IP idents hash table entries: 4096 (order: 3, 32768
bytes, linear)
[    0.709073] tcp_listen_portaddr_hash hash table entries: 512
(order: 0, 4096 bytes, linear)
[    0.717504] Table-perturb hash table entries: 65536 (order: 6,
262144 bytes, linear)
[    0.725305] TCP established hash table entries: 2048 (order: 1,
8192 bytes, linear)
[    0.733001] TCP bind hash table entries: 2048 (order: 3, 32768 bytes, linear)
[    0.740209] TCP: Hash tables configured (established 2048 bind 2048)
[    0.746644] UDP hash table entries: 256 (order: 2, 14336 bytes, linear)
[    0.753308] UDP-Lite hash table entries: 256 (order: 2, 14336 bytes, linear)
[    0.760525] NET: Registered PF_UNIX/PF_LOCAL protocol family
[    0.766234] PCI: CLS 0 bytes, default 64
[    0.770437] Trying to unpack rootfs image as initramfs...
[    0.773208] workingset: timestamp_bits=30 max_order=18 bucket_order=0
[    0.782489] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[    0.790608] Key type cifs.idmap registered
[    0.794984] io scheduler mq-deadline registered
[    0.799550] io scheduler kyber registered
[    0.804360] zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
[    0.815734] dma-pl330 f8003000.dma-controller: Loaded driver for
PL330 DMAC-241330
[    0.823414] dma-pl330 f8003000.dma-controller:
DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
[    0.823926] Freeing initrd memory: 868K
[    0.844386] brd: module loaded
[    0.852204] loop: module loaded
[    1.875058] hwmon hwmon0: temp1_input not attached to any thermal zone
[    1.891204] macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118
at 0xe000b000 irq 38 (88:20:12:f4:c1:e5)
[    1.901632] i2c_dev: i2c /dev entries driver
[    1.906095] cdns-i2c e0004000.i2c: can't get pinctrl, bus recovery
not supported
[    1.913947] cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 39
[    1.920565] clocksource: ttc_clocksource: freq: 81380 Hz, mask:
0xffff max_cycles: 0xffff, max_idle_ns: 358356783 ns
[    1.931176] timer #0 at (ptrval), irq=40
[    1.935478] armv7-pmu f8891000.pmu: hw perfevents: no
interrupt-affinity property, guessing.
[    1.944210] hw perfevents: enabled with armv7_cortex_a9 PMU driver,
7 (8000003f) counters available
[    1.954162] NET: Registered PF_INET6 protocol family
[    1.960216] Segment Routing with IPv6
[    1.963951] In-situ OAM (IOAM) with IPv6
[    1.967951] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    1.974456] NET: Registered PF_PACKET protocol family
[    1.979561] Key type dns_resolver registered
[    1.983957] Registering SWP/SWPB emulation handler
[    1.995551] Starting IRQ pipeline tests...
[    1.995564] IRQ pipeline: high-priority torture stage added.
[    2.005421] irq_pipeline-torture: CPU1 initiates stop_machine()
[    2.011360] irq_pipeline-torture: CPU0 responds to stop_machine()
[    2.011375] irq_pipeline-torture: CPU1 calls function on remote(s)
[    2.023753] irq_pipeline-torture: CPU0 handles remote function call
[    2.023879] CPU1: proxy tick device registered (499.99MHz)
[    2.030068] CPU0: proxy tick device registered (499.99MHz)
[    2.041026] irq_pipeline-torture: CPU1: irq_work handled
[    2.046338] irq_pipeline-torture: CPU1: in-band->in-band irq_work
trigger works
[    2.053645] irq_pipeline-torture: CPU1: stage escalation request works
[    2.053651] irq_pipeline-torture: CPU1: irq_work handled
[    2.065475] irq_pipeline-torture: CPU1: oob->in-band irq_work trigger works
[    3.121838] CPU1: proxy tick device unregistered
[    3.121841] CPU0: proxy tick device unregistered
[    3.131124] IRQ pipeline: torture stage removed.
[    3.135746] IRQ pipeline tests OK.
[    3.143513] clk: Disabling unused clocks
[    3.152057] Freeing unused kernel image (initmem) memory: 1024K
[    3.158189] Run /init as init process

---

/bin/sh: can't access tty; job control turned off
/ # uname -a
Linux (none) 6.18.29-01153-g1e9f8ec43dcd #4 SMP PREEMPT EVL Mon Aug 17
11:49:17 CEST 2026 armv7l armv7l armv7l GNU/Linux
/ # zcat /proc/config.gz 2>/dev/null | grep -E "^#? ?CONFIG_(DEBUG_IRQ_PIPELINE|
IRQ_PIPELINE_TORTURE_TEST|DEBUG_DOVETAIL|EVL|SMP)(=| is not set)"
CONFIG_SMP=y
# CONFIG_EVL is not set
CONFIG_DEBUG_IRQ_PIPELINE=y
CONFIG_IRQ_PIPELINE_TORTURE_TEST=y
CONFIG_DEBUG_DOVETAIL=y
/ #

---

On Mon, Aug 17, 2026 at 11:13 AM Philippe Gerum <rpm@xenomai.org> wrote:
> Regarding the issue you are observing, it suspect this is
> Dovetail-related. If so, xenomai 3.3 which is using Dovetail won't boot
> on the Zynq either.

I can actually confirm that.  We had been curious to try running the
Xenomai 3 stack on Dovetail by itself, and made the same observation:
it hangs during boot, and disabling CONFIG_SMP works around it.

I hope that helps.  Is there anything else you'd want me to try?
Regards,

-- 
Gerte Hoogewerf
Senior Software Team Lead
LMI Technologies
Wiebachstraat 25b, Kerkrade 6466 NG, The Netherlands

-- 


This
email and any attachment(s) it may contain is confidential and is 
intended
solely for the use of the individual(s) to whom it is addressed. 
If you are not
the intended recipient of this email, you must not take 
action based on the
contents, nor distribute, nor expose any part of the 
content(s) to entities or
person(s) beyond the original distribution list. 
Please contact the sender and
delete the email if you have received it in 
error. Thank you.

Re: The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Jan Kiszka]

On 17.08.26 12:11, Gerte Hoogewerf wrote:
> Hi Philippe,
> 
> Thanks for the reply.
> 
> I built and ran the kernel with said options.  It's probably not
> conclusive, since the tests passed.  With these options, the kernel
> booted all the way into userland (because CONFIG_EVL=n).
> 
> See output below.
> 
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 6.18.29-01153-g1e9f8ec43dcd
> (ghoogewerf@NLKRLTF0FQR04) (arm-none-linux-gnueabihf-gcc (LMI3D G++
> 11.4.1-p1) 11.4.1 20240321, GNU ld (LMI3D G++ 11.4.1-p1) 2.40) #4 SMP
> PREEMPT EVL Mon Aug 17 11:49:17 CEST 2026
> [    0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=18c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
> instruction cache
> [    0.000000] OF: fdt: Machine model: Xilinx Zynq
> [    0.000000] Memory policy: Data cache writealloc
> [    0.000000] cma: Reserved 750 MiB at 0x11000000
> [    0.000000] Zone ranges:
> [    0.000000]   Normal   [mem 0x0000000000000000-0x000000003fffffff]
> [    0.000000] Movable zone start for each node
> [    0.000000] Early memory node ranges
> [    0.000000]   node   0: [mem 0x0000000000000000-0x000000003fffffff]
> [    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000003fffffff]
> [    0.000000] OF: reserved mem: Reserved memory: No reserved-memory
> node in the DT
> [    0.000000] percpu: Embedded 12 pages/cpu s19468 r8192 d21492 u49152
> [    0.000000] Kernel command line: console=ttyPS0,115200 cma=750M
> l2x0_write_through=1
> [    0.000000] Unknown kernel command line parameters
> "l2x0_write_through=1", will be passed to user space.
> [    0.000000] printk: log buffer data + meta data: 16384 + 51200 = 67584 bytes
> [    0.000000] Dentry cache hash table entries: 32768 (order: 5,
> 131072 bytes, linear)
> [    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536
> bytes, linear)
> [    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 262144
> [    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
> [    0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
> [    0.000000] rcu: Preemptible hierarchical RCU implementation.
> [    0.000000] rcu:     RCU event tracing is enabled.
> [    0.000000] rcu: RCU calculated value of scheduler-enlistment delay
> is 100 jiffies.
> [    0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
> [    0.000000] slcr mapped to (ptrval)
> [    0.000000] L2C: platform provided aux values match the hardware,
> so have no effect.  Please remove them.
> [    0.000000] L2C-310 erratum 769419 enabled
> [    0.000000] L2C-310 enabling early BRESP for Cortex-A9
> [    0.000000] L2C-310 full line of zeros enabled for Cortex-A9
> [    0.000000] L2C-310 D prefetch enabled, offset 9 lines
> [    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
> [    0.000000] L2C-310 cache controller enabled, 8 ways, 512 kB
> [    0.000000] L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x56760001
> [    0.000000] IRQ pipeline enabled
> [    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
> [    0.000000] zynq_clock_init: clkc starts at (ptrval)
> [    0.000000] Zynq clock init
> [    0.000000] ps_clk frequency not specified, using 33 MHz.
> [    0.000001] sched_clock: 64 bits at 500MHz, resolution 2ns, wraps
> every 4398046511103ns
> [    0.000018] clocksource: arm_global_timer: freq: 499999995 Hz,
> mask: 0xffffffffffffffff max_cycles: 0xe6a171a037, max_idle_ns:
> 881590485102 ns
> [    0.000043] Switching to timer-based delay loop, resolution 2ns
> [    0.000325] Console: colour dummy device 80x30
> [    0.000351] Calibrating delay loop (skipped), value calculated
> using timer frequency.. 999.99 BogoMIPS (lpj=499999)
> [    0.000361] CPU: Testing write buffer coherency: ok
> [    0.000390] CPU0: Spectre v2: using BPIALL workaround
> [    0.000395] pid_max: default: 32768 minimum: 301
> [    0.000541] Mount-cache hash table entries: 1024 (order: 0, 4096
> bytes, linear)
> [    0.000552] Mountpoint-cache hash table entries: 1024 (order: 0,
> 4096 bytes, linear)
> [    0.001231] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
> [    0.001262] cacheinfo: Unable to detect cache hierarchy for CPU 0
> [    0.002306] Setting up static identity map for 0x100000 - 0x10003c
> [    0.002473] rcu: Hierarchical SRCU implementation.
> [    0.002478] rcu:     Max phase no-delay instances is 400.
> [    0.002999] smp: Bringing up secondary CPUs ...
> [    0.003680] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
> [    0.003731] CPU1: Spectre v2: using BPIALL workaround
> [    0.003844] smp: Brought up 1 node, 2 CPUs
> [    0.003854] SMP: Total of 2 processors activated (1999.99 BogoMIPS).
> [    0.003862] CPU: All CPU(s) started in SVC mode.
> [    0.004053] Memory: 256456K/1048576K available (6144K kernel code,
> 224K rwdata, 1456K rodata, 1024K init, 84K bss, 20992K reserved,
> 770048K cma-reserved)
> [    0.004557] devtmpfs: initialized
> [    0.008386] VFP support v0.3: implementor 41 architecture 3 part 30
> variant 9 rev 4
> [    0.008531] clocksource: jiffies: freq: 0 Hz, mask: 0xffffffff
> max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
> [    0.008552] posixtimers hash table entries: 1024 (order: 1, 8192
> bytes, linear)
> [    0.008608] futex hash table entries: 512 (32768 bytes on 1 NUMA
> nodes, total 32 KiB, linear).
> [    0.019015] pinctrl core: initialized pinctrl subsystem
> [    0.019919] NET: Registered PF_NETLINK/PF_ROUTE protocol family
> [    0.021704] DMA: preallocated 256 KiB pool for atomic coherent allocations
> [    0.022681] thermal_sys: Registered thermal governor 'step_wise'
> [    0.024823] /axi/etb@f8801000: Fixed dependency cycle(s) with /replicator
> [    0.024940] /axi/tpiu@f8803000: Fixed dependency cycle(s) with /replicator
> [    0.024967] /axi/funnel@f8804000: Fixed dependency cycle(s) with
> /axi/ptm@f889d000
> [    0.024987] /axi/funnel@f8804000: Fixed dependency cycle(s) with
> /axi/ptm@f889c000
> [    0.025008] /axi/funnel@f8804000: Fixed dependency cycle(s) with /replicator
> [    0.025047] /axi/ptm@f889c000: Fixed dependency cycle(s) with
> /axi/funnel@f8804000
> [    0.025079] /axi/ptm@f889d000: Fixed dependency cycle(s) with
> /axi/funnel@f8804000
> [    0.027727] /replicator: Fixed dependency cycle(s) with /axi/etb@f8801000
> [    0.027820] /axi/etb@f8801000: Fixed dependency cycle(s) with /replicator
> [    0.028053] /replicator: Fixed dependency cycle(s) with /axi/tpiu@f8803000
> [    0.028162] /axi/tpiu@f8803000: Fixed dependency cycle(s) with /replicator
> [    0.028391] /replicator: Fixed dependency cycle(s) with /axi/funnel@f8804000
> [    0.028797] /axi/funnel@f8804000: Fixed dependency cycle(s) with
> /axi/ptm@f889d000
> [    0.028822] /axi/funnel@f8804000: Fixed dependency cycle(s) with
> /axi/ptm@f889c000
> [    0.028842] /axi/funnel@f8804000: Fixed dependency cycle(s) with /replicator
> [    0.029084] /axi/funnel@f8804000: Fixed dependency cycle(s) with
> /axi/ptm@f889c000
> [    0.029196] /axi/ptm@f889c000: Fixed dependency cycle(s) with
> /axi/funnel@f8804000
> [    0.029422] /axi/funnel@f8804000: Fixed dependency cycle(s) with
> /axi/ptm@f889d000
> [    0.029509] /axi/ptm@f889d000: Fixed dependency cycle(s) with
> /axi/funnel@f8804000
> [    0.030334] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
> watchpoint registers.
> [    0.030345] hw-breakpoint: maximum watchpoint size is 4 bytes.
> [    0.030980] e0001000.serial: ttyPS0 at MMIO 0xe0001000 (irq = 27,
> base_baud = 6249999) is a xuartps
> [    0.031040] printk: legacy console [ttyPS0] enabled
> [    0.656472] pps_core: LinuxPPS API ver. 1 registered
> [    0.661475] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
> Rodolfo Giometti <giometti@linux.it>
> [    0.670642] PTP clock support registered
> [    0.674730] FPGA manager framework
> [    0.678947] vgaarb: loaded
> [    0.681809] clocksource: Switched to clocksource arm_global_timer
> [    0.696109] NET: Registered PF_INET protocol family
> [    0.701211] IP idents hash table entries: 4096 (order: 3, 32768
> bytes, linear)
> [    0.709073] tcp_listen_portaddr_hash hash table entries: 512
> (order: 0, 4096 bytes, linear)
> [    0.717504] Table-perturb hash table entries: 65536 (order: 6,
> 262144 bytes, linear)
> [    0.725305] TCP established hash table entries: 2048 (order: 1,
> 8192 bytes, linear)
> [    0.733001] TCP bind hash table entries: 2048 (order: 3, 32768 bytes, linear)
> [    0.740209] TCP: Hash tables configured (established 2048 bind 2048)
> [    0.746644] UDP hash table entries: 256 (order: 2, 14336 bytes, linear)
> [    0.753308] UDP-Lite hash table entries: 256 (order: 2, 14336 bytes, linear)
> [    0.760525] NET: Registered PF_UNIX/PF_LOCAL protocol family
> [    0.766234] PCI: CLS 0 bytes, default 64
> [    0.770437] Trying to unpack rootfs image as initramfs...
> [    0.773208] workingset: timestamp_bits=30 max_order=18 bucket_order=0
> [    0.782489] squashfs: version 4.0 (2009/01/31) Phillip Lougher
> [    0.790608] Key type cifs.idmap registered
> [    0.794984] io scheduler mq-deadline registered
> [    0.799550] io scheduler kyber registered
> [    0.804360] zynq-pinctrl 700.pinctrl: zynq pinctrl initialized
> [    0.815734] dma-pl330 f8003000.dma-controller: Loaded driver for
> PL330 DMAC-241330
> [    0.823414] dma-pl330 f8003000.dma-controller:
> DBUFF-128x8bytes Num_Chans-8 Num_Peri-4 Num_Events-16
> [    0.823926] Freeing initrd memory: 868K
> [    0.844386] brd: module loaded
> [    0.852204] loop: module loaded
> [    1.875058] hwmon hwmon0: temp1_input not attached to any thermal zone
> [    1.891204] macb e000b000.ethernet eth0: Cadence GEM rev 0x00020118
> at 0xe000b000 irq 38 (88:20:12:f4:c1:e5)
> [    1.901632] i2c_dev: i2c /dev entries driver
> [    1.906095] cdns-i2c e0004000.i2c: can't get pinctrl, bus recovery
> not supported
> [    1.913947] cdns-i2c e0004000.i2c: 400 kHz mmio e0004000 irq 39
> [    1.920565] clocksource: ttc_clocksource: freq: 81380 Hz, mask:
> 0xffff max_cycles: 0xffff, max_idle_ns: 358356783 ns
> [    1.931176] timer #0 at (ptrval), irq=40
> [    1.935478] armv7-pmu f8891000.pmu: hw perfevents: no
> interrupt-affinity property, guessing.
> [    1.944210] hw perfevents: enabled with armv7_cortex_a9 PMU driver,
> 7 (8000003f) counters available
> [    1.954162] NET: Registered PF_INET6 protocol family
> [    1.960216] Segment Routing with IPv6
> [    1.963951] In-situ OAM (IOAM) with IPv6
> [    1.967951] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> [    1.974456] NET: Registered PF_PACKET protocol family
> [    1.979561] Key type dns_resolver registered
> [    1.983957] Registering SWP/SWPB emulation handler
> [    1.995551] Starting IRQ pipeline tests...
> [    1.995564] IRQ pipeline: high-priority torture stage added.
> [    2.005421] irq_pipeline-torture: CPU1 initiates stop_machine()
> [    2.011360] irq_pipeline-torture: CPU0 responds to stop_machine()
> [    2.011375] irq_pipeline-torture: CPU1 calls function on remote(s)
> [    2.023753] irq_pipeline-torture: CPU0 handles remote function call
> [    2.023879] CPU1: proxy tick device registered (499.99MHz)
> [    2.030068] CPU0: proxy tick device registered (499.99MHz)
> [    2.041026] irq_pipeline-torture: CPU1: irq_work handled
> [    2.046338] irq_pipeline-torture: CPU1: in-band->in-band irq_work
> trigger works
> [    2.053645] irq_pipeline-torture: CPU1: stage escalation request works
> [    2.053651] irq_pipeline-torture: CPU1: irq_work handled
> [    2.065475] irq_pipeline-torture: CPU1: oob->in-band irq_work trigger works
> [    3.121838] CPU1: proxy tick device unregistered
> [    3.121841] CPU0: proxy tick device unregistered
> [    3.131124] IRQ pipeline: torture stage removed.
> [    3.135746] IRQ pipeline tests OK.
> [    3.143513] clk: Disabling unused clocks
> [    3.152057] Freeing unused kernel image (initmem) memory: 1024K
> [    3.158189] Run /init as init process
> 
> ---
> 
> /bin/sh: can't access tty; job control turned off
> / # uname -a
> Linux (none) 6.18.29-01153-g1e9f8ec43dcd #4 SMP PREEMPT EVL Mon Aug 17
> 11:49:17 CEST 2026 armv7l armv7l armv7l GNU/Linux
> / # zcat /proc/config.gz 2>/dev/null | grep -E "^#? ?CONFIG_(DEBUG_IRQ_PIPELINE|
> IRQ_PIPELINE_TORTURE_TEST|DEBUG_DOVETAIL|EVL|SMP)(=| is not set)"
> CONFIG_SMP=y
> # CONFIG_EVL is not set
> CONFIG_DEBUG_IRQ_PIPELINE=y
> CONFIG_IRQ_PIPELINE_TORTURE_TEST=y
> CONFIG_DEBUG_DOVETAIL=y
> / #
> 
> ---
> 
> On Mon, Aug 17, 2026 at 11:13 AM Philippe Gerum <rpm@xenomai.org> wrote:
>> Regarding the issue you are observing, it suspect this is
>> Dovetail-related. If so, xenomai 3.3 which is using Dovetail won't boot
>> on the Zynq either.
> 
> I can actually confirm that.  We had been curious to try running the
> Xenomai 3 stack on Dovetail by itself, and made the same observation:
> it hangs during boot, and disabling CONFIG_SMP works around it.
> 
> I hope that helps.  Is there anything else you'd want me to try?
> Regards,
> 

From what you described, it is most likely that some SoC-specific
adjustments are wrong or got lost on the transition from i-pipe to
dovetail. Already looked for Zynq-specific bits in the last 5.4-ipipe patch?

We never had any Zynq board enabled for the Xenomai lava lab, and all
the eval boards we had here got dumped while moving 2 years ago. But if
someone is willing to set up a lava working with a Zynq board, we can
include in future testing at least. Still, it would also need someone to
look into regressions, just like now...

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Gerte Hoogewerf]

Hey Jan/Philippe,

Thanks for pointing me in this direction.  I've done a bit of research
and I'm making good progress.

It actually booted as soon as I disabled the "scutimer" clock source
via the DTB.  This made the kernel fall back to "arm_global_timer" and
now it boots properly.

So, the original problem may be in Dovetail's "smp_twd" handoff under SMP.

> [..] if someone is willing to set up a lava working with a Zynq board [..].
> Still, it would also need someone to look into regressions, just like now...

I'm unaware of lava. Aside from Xenomai's patches, our boards need a
massive patchset to function fully (NAND flash, FPGA, etc.).  So, our
board is not the best testing vehicle. However, I am happy to help
test periodically, that's a small favor to return.

Let me know if you have any thoughts on where to look in smp_twd.c;
otherwise I'll keep digging on my end and report back.

Regards,

--
Gerte Hoogewerf
Senior Software Team Lead
LMI Technologies
Wiebachstraat 25b, Kerkrade 6466 NG, The Netherlands

-- 


This
email and any attachment(s) it may contain is confidential and is 
intended
solely for the use of the individual(s) to whom it is addressed. 
If you are not
the intended recipient of this email, you must not take 
action based on the
contents, nor distribute, nor expose any part of the 
content(s) to entities or
person(s) beyond the original distribution list. 
Please contact the sender and
delete the email if you have received it in 
error. Thank you.

Re: The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Jan Kiszka]

On 17.08.26 14:05, Gerte Hoogewerf wrote:
> Hey Jan/Philippe,
> 
> Thanks for pointing me in this direction.  I've done a bit of research
> and I'm making good progress.
> 
> It actually booted as soon as I disabled the "scutimer" clock source
> via the DTB.  This made the kernel fall back to "arm_global_timer" and
> now it boots properly.
> 
> So, the original problem may be in Dovetail's "smp_twd" handoff under SMP.
> 

Was that actively used with 5.4-ipipe or older? Not that it wasn't and
just happened to be pulled in by Linux > 5.4.

>> [..] if someone is willing to set up a lava working with a Zynq board [..].
>> Still, it would also need someone to look into regressions, just like now...
> 
> I'm unaware of lava. Aside from Xenomai's patches, our boards need a
> massive patchset to function fully (NAND flash, FPGA, etc.).  So, our
> board is not the best testing vehicle. However, I am happy to help
> test periodically, that's a small favor to return.
> 

That would indeed be welcome already.

> Let me know if you have any thoughts on where to look in smp_twd.c;
> otherwise I'll keep digging on my end and report back.
> 

Looking at smp_twd.c in 5.4-ipipe and 5.10-dovetail as well as
6.18-dovetail, the major differences are around

"Updates clockevent frequency when the cpu frequency changes.
 Called on the cpu that is changing frequency with interrupts disabled."

But that path is only taken if CONFIG_COMMON_CLK is not set for the
target - it should be ARCH_ZYNQ.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center

Re: The state of Xenomai 4 on Xilinx Zynq-7000 (or ARM32 in general)

[Philippe Gerum]

Gerte Hoogewerf <ghoogewerf@lmi3d.com> writes:

> Hey Jan/Philippe,
>
> Thanks for pointing me in this direction.  I've done a bit of research
> and I'm making good progress.
>
> It actually booted as soon as I disabled the "scutimer" clock source
> via the DTB.  This made the kernel fall back to "arm_global_timer" and
> now it boots properly.
>
> So, the original problem may be in Dovetail's "smp_twd" handoff under SMP.
>

Yes it is, good catch. At least, I could reproduce a crash on a socfpga
cyclone V. Enabling CONFIG_IRQ_PIPELINE is enough to crash the board
when entering user mode on this board:

[   14.199634] 8<--- cut here ---
[   14.199646] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[   14.199655] [00000000] *pgd=00000000
[   14.199666] Internal error: Oops: 5 [#1] SMP ARM
[   14.199673] Modules linked in:
[   14.199681] CPU: 0 UID: 0 PID: 31 Comm: kworker/u8:1 Not tainted 6.18.29-01154-gbeaef3a002b8 #8 NONE 
[   14.199695] Hardware name: Altera SOCFPGA
[   14.199699] IRQ stage: Linux
[   14.199704] Workqueue: xprtiod xs_stream_data_receive_workfn
[   14.199727] PC is at unwind_frame+0x3a8/0x6f8
[   14.199743] LR is at 0x0
[   14.199749] pc : [<c011b1b8>]    lr : [<00000000>]    psr: 60000113
[   14.199755] sp : f0801e10  ip : f0801e5c  fp : 00000000
[   14.199760] r10: 00000001  r9 : 00000003  r8 : 00000000
[   14.199765] r7 : f0801ea8  r6 : 00002000  r5 : 00000000  r4 : 00000000
[   14.199771] r3 : 00000001  r2 : c0c31b4c  r1 : 00000000  r0 : 0000000e
[   14.199776] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   14.199785] Control: 10c5387d  Table: 01d3004a  DAC: 00000051
[   14.199790] Register r0 information: non-paged memory
[   14.199800] Register r1 information: NULL pointer
[   14.199807] Register r2 information: non-slab/vmalloc memory
[   14.199814] Register r3 information: non-paged memory
[   14.199820] Register r4 information: NULL pointer
[   14.199825] Register r5 information: NULL pointer
[   14.199831] Register r6 information: non-paged memory
[   14.199836] Register r7 information: 2-page vmalloc region starting at 0xf0800000 allocated at start_kernel+0x4d0/0x678
[   14.199852] Register r8 information: NULL pointer
[   14.199859] Register r9 information: non-paged memory
[   14.199864] Register r10 information: non-paged memory
[   14.199870] Register r11 information: NULL pointer
[   14.199876] Register r12 information: 2-page vmalloc region starting at 0xf0800000 allocated at start_kernel+0x4d0/0x678
[   14.199889] Process kworker/u8:1 (pid: 31, stack limit = 0x(ptrval))
[   14.199897] Stack: (0xf0801e10 to 0xf0802000)
[   14.199907] 1e00:                                     00000000 c0b32ac0 00000000 ef7d00c0
[   14.199917] 1e20: c10d8b00 4e5cf840 00000001 00000003 c10d8b00 2ea79000 f0801ebc c015c718
[   14.199926] 1e40: 00000001 c10d8880 ef7d0080 ef7d0080 00000000 ef7d00c0 00000000 00000000
[   14.199936] 1e60: 00000000 c015fb44 ef7d0080 c0d57080 ef7d0080 c0147380 ef7d0080 01b9fb81
[   14.199945] 1e80: c0e03f34 ef7cc428 c0e02d40 00000003 4dca536e ef7cc428 00000003 ef7ce1c0
[   14.199955] 1ea0: 00000080 c0116524 00000000 00000000 00000000 c0951e04 4dca536e 01b9fb81
[   14.199964] 1ec0: 00000001 c01adb4c ef7ce1c0 c01c3fb0 00000001 00000022 00000002 ef7cde40
[   14.199973] 1ee0: ef7cde00 ef7cde00 c01c3f10 4dca4dce 00000003 c01b0fb0 ef7cfa00 ef7cde54
[   14.199982] 1f00: 00000000 4dca4dce 00000003 c0e3d316 c133ca6c ef7cde00 00000080 00000003
[   14.199992] 1f20: 4dca4dce ef7cde0c ef7cde88 ef7cdeb0 ef7cded8 c01b1d70 00000080 0000000f
[   14.200001] 1f40: c0e19148 4ce379c6 ef7cdf30 ef7cdf80 ef7cdf50 c0e48eb8 4dca4dce 00000003
[   14.200010] 1f60: c0d56980 00000001 c0a27f30 00000019 f0801fc0 c0e19148 00000001 00000000
[   14.200019] 1f80: 00000019 c011aa70 c1018300 c018f778 c0d56948 c1018300 00000000 f0801fc0
[   14.200029] 1fa0: c0e19148 c018820c c0d56948 c011d3e0 c0e19148 00000001 c10d8880 c0193b40
[   14.200038] 1fc0: c0e04214 c0d53410 c0d56948 c10d8880 ef7cc410 ffffffff f0911d24 c1475320
[   14.200047] 1fe0: c10d8880 00000000 f0911ce8 c0193ec4 c0951e04 60000113 ffffffff c091c95c
[   14.200052] Call trace: 
[   14.200058]  unwind_frame from profile_pc+0x60/0x9c
[   14.200076]  profile_pc from profile_tick+0x2c/0x54
[   14.200094]  profile_tick from tick_nohz_handler+0xa0/0x128
[   14.200113]  tick_nohz_handler from __hrtimer_run_queues+0x158/0x1f4
[   14.200134]  __hrtimer_run_queues from hrtimer_interrupt+0x140/0x2d8
[   14.200156]  hrtimer_interrupt from twd_handler+0x68/0x7c
[   14.200176]  twd_handler from handle_percpu_devid_irq+0xe8/0x1b8
[   14.200191]  handle_percpu_devid_irq from handle_irq_desc+0x5c/0x90
[   14.200209]  handle_irq_desc from arch_do_IRQ_pipelined+0x30/0x50
[   14.200227]  arch_do_IRQ_pipelined from sync_current_irq_stage+0x108/0x1a0
[   14.200248]  sync_current_irq_stage from handle_irq_pipelined_finish+0x64/0xd0
[   14.200266]  handle_irq_pipelined_finish from call_with_stack+0x18/0x20
[   14.200291]  call_with_stack from __irq_svc+0xa0/0xc8
[   14.200309] Exception stack(0xf0911cf0 to 0xf0911d38)
[   14.200317] 1ce0:                                     c1e38fa8 c1e38fb4 c1e38fb4 00000000
[   14.200328] 1d00: c1e38ec0 f0911eb0 0000000c f0911d58 c1475320 c19113c8 00000000 c10d8880
[   14.200336] 1d20: 00000001 f0911d48 c07ec654 c0951e04 60000113 ffffffff
[   14.200343]  __irq_svc from _raw_spin_unlock_bh+0x0/0x30
[   14.200365]  _raw_spin_unlock_bh from 0xf0911d58
[   14.200386] Code: 0afffff9 e35b0000 1a000043 e350000e (e594e000) 
[   14.200393] ---[ end trace 0000000000000000 ]---
[   14.200400] Kernel panic - not syncing: Fatal exception in interrupt

Intuitively, I'd say that trying to walk the interrupt stack frame of a
clock event which is likely to have been deferred due to pipelining is
unlikely to be a great idea, since that frame was already unwound prior
to the call to unwind_frame(). Why such issue wasn't hit earlier still
needs to be explained.

Anyway, the following patch allows the socfpga to boot, could you please
try it on the Zynq?

diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index df25c88b2c783..ad3b4256ebbff 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -107,7 +107,7 @@ static inline void instruction_pointer_set(struct pt_regs *regs,
 	instruction_pointer(regs) = val;
 }
 
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && !defined(CONFIG_IRQ_PIPELINE)
 extern unsigned long profile_pc(struct pt_regs *regs);
 #else
 #define profile_pc(regs) instruction_pointer(regs)
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
index b3836c94dc748..cd5d7576e5780 100644
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -40,7 +40,7 @@ EXPORT_SYMBOL(rtc_lock);
 /* change this if you have some constant time drift */
 #define USECS_PER_JIFFY	(1000000/HZ)
 
-#ifdef CONFIG_SMP
+#if defined(CONFIG_SMP) && !defined(CONFIG_IRQ_PIPELINE)
 unsigned long profile_pc(struct pt_regs *regs)
 {
 	struct stackframe frame;
        

The effect of such change on profiling in SMP still needs to be
assessed, but at any rate, we cannot keep unwinding stale stack frames,
so we need a fix in this area.

Please also note that I had to manually enable CONFIG_VDSO which
socfpga_config did not (for some reason to be determined too), so that
real-time applications can perform clock readouts in a syscall-less
fashion. Latency is fine on the socfpga after enabling it, that would
still work without at the expense of a couple of micro-seconds for each
readout though. You may want to check that VDSO is enabled by the Zynq
config as well.

You may also want to run "evl check" in a shell to make sure no adverse
kernel setting is in the way of minimal latency.

-- 
Philippe.