RTEMS | bsps/microblaze: The BSP cannot raise a test interrupt and has no CPU counter (#5726)

[Sebastian Huber (@sebhub)]

Issue created by Sebastian Huber: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5726



`Cause_tm27_intr()` of the `microblaze_fpga` family raises the test interrupt
with the second counter of the AXI timer. The counter raises the interrupt some
counter ticks after the request. A validation test which needs the interrupt
inside the intend to block window of `_Thread_queue_Enqueue()` never receives it
there. `ts-validation-no-clock-0` reports 14707 failed steps and ends in
`INTERNAL_ERROR_THREAD_QUEUE_DEADLOCK`. The missed timeout leaves a MrsP
semaphore owned, the delete fails, and every later semaphore create returns
`RTEMS_TOO_MANY`, which accounts for 14004 of those steps.

The BSP also gives the test support one vector only.
`RtemsIntrReqEntryInstall` asks for a vector which it can raise, and
`bsp_interrupt_raise()` returns `RTEMS_UNSATISFIED` for every vector of this
BSP. The scan finds none, the test uses the vector count as a vector, and every
directive returns `RTEMS_INVALID_ID`. `ts-validation-intr` reports 7402 failed
steps from this cause alone.

A write to the interrupt status register of the AXI interrupt controller raises
an interrupt in software, but only while the hardware interrupt enable of the
master enable register is clear. That enable is write once on some
implementations, so a probe decides which mechanism the BSP uses.

The BSP also links the software CPU counter of `bsps/shared`.
`_CPU_Counter_read()` of that counter increments a static variable per call and
`_CPU_Counter_frequency()` returns 1000000000, so nothing in it measures time.
`rtems_counter_delay_nanoseconds()` therefore delays by a count of calls and
`getentropy()` takes no entropy from the time. The AXI timer has two counters
and the clock driver uses the first, so the second can be a free running up
counter of the full width.

`spcpucounter01` passed on this BSP only because the delay it measures and the
counter it measures with were the same fiction. With a real counter it fails on
Qemu. The counter is a register of the AXI timer, and Qemu takes the tick
interrupt later out of a loop which reads that register than out of the poll
loop the test synchronizes with. The test busy waits exactly one clock tick
period and asserts that a tick elapsed, so it has no margin for the difference.
Two defects of the Qemu AXI timer model were found and fixed while measuring
this, and neither is part of this issue.

Found while running the full test suite on eleven simulators. This description
was created with Claude Code assistance.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/work_items/5726
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/5-escj19wvyzcq8kqvq3ueye0e1-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260824/d299840a/attachment-0001.htm>