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

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.