What methods are available for altering an interrupt's priority in RTEMS? There's some mention of supporting up to 256 priorities, but no mention of how to adjust an interrupt's priority through the interrupt manager. It looks like I've got to use the interrupt controller's registers directly, and it isn't clear that RTEMS would respect the modification.
On Thu, Apr 4, 2019 at 7:24 AM Joel Sherrill <j...@rtems.org> wrote: > Thanks Andrei! I am glad you are past this but let's do a post-game analysis > of what > could be better next time so no one else suffers as much. These are random > ideas > and I am open to more. > > + Could this be detected at run-time during setup with a debug option? For machine-automated detection... is there *any* way to install an NMI handler via the Interrupt Manager? It looks like all of the user interrupt handlers go through a supercore-provided wrapper, even on v7-M. If NMI's are never installable via the interrupt manager, then RTEMS could have a DEBUG-guarded check of the priority level before handing off to the user's code. Combine that with some policy that if the user wants to install their own NMI handler, that they must do so themselves. On v7-M that's pretty easy thanks to the hardware's automatic register stacking. Then you have three categories of interrupts: - NMI's handled by RTEMS to detect fatal errors. Users can receive notification through the fatal notification hook in a user extension. The CPU Architecture Supplement enumerates them. - NMI's handled by user code. These must be installed by the user in a platform (or even processor)-specific way. User's should not attempt to replace NMI's owned by RTEMS for fatal errors. - Interrupts which may safely use the RTEMS services enumerated by the Interrupt Manager (the 8.3.2 list). These are installed and managed through the interrupt manager. > + Could this be written up in the BSP Guide so at least there is a place to > reference? > Perhaps in a generic section on dealing with interrupt controllers > > I don't think this is specifically an ARM issue. It is just easy to do on the > ARM. > I recall people doing similar things with high priority interrupts and NMI's > in the > past. > > Any other ideas? My goal is always to try to prevent people from suffering > over > and over from the same mistakes. > There's some room for improvement in the documentation. 8.2.3 in the interrupt manager manual discusses the risks involved with NMI's. The trouble is that NMI is overloaded to mean subtly different things on different processor architectures. 3.5 in the CPU Architecture Supplement isn't particularly clear about the differences between v4T/v7-A/R and the -M profile interrupt models. Some wishlist ideas for the CPU Architecture Supplement: - Describe exactly how an RTEMS NMI relates to the -M and the v4T models. - Call out the semantic difference between the -M profile NMI vector and an RTEMS NMI. - Make that 0x80 priority level available via a #define, maybe in score/armv7m.h - Describe how to map the RTEMS NMI priority level for the ARMv7-M port to an interrupt priority in CMSIS. - Describe how the 3.5.1 interrupt levels relate to NVIC and GIC interrupt priorities. IIUC, the level-1 interrupt is only supported on GICv2, only on the Cyclone-V BSP, and its chosen by directing the interrupt to the core's FIQ handler. So for example, a xilinx-zynq fabric FIQ request will end up just being treated as a fatal exception by RTEMS. - Call out which exception vectors are routed through the user extension point for fatal error detection. - Document that ARM uses the new interrupt handling model provided by the irq-extension.h header. Some ideas for the RTEMS Classic API manual: - Looking at the 23.2.12 fatal error extension, I'm a little confused about how to safely install my own fatal error hook in such a way that the BSP's fatal error hook still gets called. - Document the irq-extension.h interface. -- Jonathan Brandmeyer _______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
