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.