Valid interrupt vectors and the interrupt server
Joel Sherrill
joel at rtems.org
Sat Jun 17 18:16:00 UTC 2017
On Jun 17, 2017 11:17 AM, "Christian Mauderer" <
christian.mauderer at embedded-brains.de> wrote:
Hello,
I had a problem recently, that the interrupt server (for example used in
libbsd) caused some odd behaviour on an ARM Cortex BSP. That was solved by
the following patch:
https://git.rtems.org/rtems/commit/?id=ce3ac00c
Just today Sichen Zhao had a similar problem on the BBB:
https://lists.rtems.org/pipermail/devel/2017-June/018158.html
I took a look and it seems that there are a lot of BSPs which don't check
for the valid interrupt vector range in their
bsp_interrupt_vector_disable/enable
functions. Every one of them will most likely have a problems if someone
tries to use libbsd or the interrupt server.
It also seems that there is no test for the interrupt server. As far as I
know, not all targets are able to support the interrupt server depending on
the interrupt controller (I'm not exactly sure which ones have support and
which doesn't). So if a test for the server would be added, that test will
most likely fail on a lot of targets.
Has someone an idea how a test for the interrupt server could look like? We
would need an interrupt that can be used on every target.
Should we mass-change all BSPs to add the check for a valid interrupt? A
mass-change could be problematic because it is nearly impossible to test on
all targets and it's in a quite critical location.
Is there anyway a timer method could be used to fake out the interrupt
occurrence?
There is no single interrupt source or interface to get to one.
Kind regards
Christian Mauderer
--
--------------------------------------------
embedded brains GmbH
Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax: +49-89-18 94 741 - 08
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel at rtems.org
http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170617/d2c6b319/attachment-0002.html>
More information about the devel
mailing list