Opened on 02/09/23 at 14:54:34
Last modified on 02/13/23 at 08:24:00
#4846 assigned defect
Code for test software
Reported by: | Daniel Páscoa | Owned by: | Needs Funding |
---|---|---|---|
Priority: | normal | Milestone: | Indefinite |
Component: | arch/sparc | Version: | 6 |
Severity: | normal | Keywords: | qualification |
Cc: | Blocked By: | ||
Blocking: |
Description
Within function bsp_interrupt_raise ther is code active despite described as being dangerous and only to be used for test purposes.
It would be a good idea to insert a pragma in the code to present a warning when this is included/used. -> "#pragma GCC warning message"
Additional Notes:
To raise an IRQ# from 0-15 there is a proper register that permits that, but to raise IRQ# from 31-16 it is needed to write on top of the pending associated IRQ bit, which can override an already IRQ pending in that line. That is why that code may be dangerous and in the case of forcing IRQ# from 31-16 can only be used for testing.
This ticket was raised as an outcome of the Independent SW Verification and Validation (ISVV) for ESA-promoted RTEMS SMP Qualification Data Packs (https://rtems-qual.io.esa.int). Original ISVV reference for this issue is RTEMS-SMP-CODE-VER-044.
File list:
bsps\sparc\leon3\start\eirq.c (function bsp_interrupt_raise) (line 154-158)
Change History (3)
comment:1 Changed on 02/10/23 at 15:08:06 by Sebastian Huber
Component: | admin → arch/sparc |
---|---|
Milestone: | → 6.1 |
Resolution: | → wontfix |
Status: | new → closed |
comment:2 Changed on 02/13/23 at 08:23:31 by Sebastian Huber
Milestone: | 6.1 → Indefinite |
---|---|
Resolution: | wontfix |
Status: | closed → reopened |
One option is to remove the raise implementation for extended interrupts and test the extended interrupts through BSP-specific code.
comment:3 Changed on 02/13/23 at 08:24:00 by Sebastian Huber
Owner: | set to Needs Funding |
---|---|
Status: | reopened → assigned |
This warning is pretty useless since it is invisible to the user. The hardware limitations are documented in the hardware manuals. We could introduce some sort of a test mode which guards this feature. To keep it simple I tend to not fix it.