Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Kinsey Moore was added as a reviewer. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140688 These are auto set to false by a top level script. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140688 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price started a new discussion on
bsps/microblaze/microblaze_fpga/irq/irq.c:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140686
> }
>
> rtems_status_code bsp_interrupt_raise( rtems_vector_number vector )
> {
> - (void) vector;
> + if ( vector == microblaze_tm27_alt_vector() ) {
> +uint32_t mer;
> +
> +/*
> + * Generate a software interrupt by writing ISR while HIE is clear
> + * (Xilinx AXI INTC PG099).
> + */
> +mer = mblaze_intc->mer;
> +mblaze_intc->mer = mer & ~MICROBLAZE_INTC_MER_HIE;
> +mblaze_intc->isr = 1U << vector;
> +mblaze_intc->mer = mer;
Need to verify and add a comment from the xilinx guide.
--
View it on GitLab:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140686
You're receiving this email because of your account on gitlab.rtems.org.
___
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price started a new discussion on bsps/microblaze/microblaze_fpga/irq/irq.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140685 > #include > #include > #include > +#include > > #include > > static volatile Microblaze_INTC *mblaze_intc; > > +#define MICROBLAZE_INTC_SOFTWARE_VECTOR ( BSP_INTERRUPT_VECTOR_COUNT - 1 ) On microblaze this is set to 31 -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140685 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price pushed new commits to merge request !980 Merge request URL: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980 * f96a220d - microblaze: make intr validation raiseable and capture interrupted SP * cf2fe8ca - microblaze: re-enable interrupts for TM27 nesting -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140679 ``` - tm27.exe: PASS (END OF TEST printed) - rhilatency.exe: PASS - ts-validation-one-cpu-0.exe: PASS - ts-validation-no-clock-0.exe: PASS - ts-validation-intr.exe: PASS - ts-performance-no-clock-0.exe: PASS ``` -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140679 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Joel Sherrill commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140674 No. I am just saying that. It is OK to use a one-shot timer if it is not the one used for the timings in the tmtests. The timing tests just run without a clock driver under the assumption that there is only one counter/timer and that avoiding interrupts makes the execution times more consistent. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140674 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140672 Are you saying this wont work at using a one shot timer as a tm27 interrupt? My other options would be to create a second timer thats independent of the os clock. Or add software interrupt support to qemu -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140672 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price commented:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140671
Debugging the ts-validation-intr.exe test.
Several fields are not set, still debugging that one.
Fixing ts-validation-intr.exe might be a larger change to work on qemu.
```
rtems_interrupt_attributes *attributes
)
{
+ bool is_software_vector;
+
(void) vector;
+ is_software_vector = ( vector == microblaze_tm27_alt_vector() );
+
attributes->is_maskable = true;
+ attributes->can_enable = true;
attributes->maybe_enable = true;
+ attributes->can_disable = true;
attributes->maybe_disable = true;
- attributes->can_clear = true;
+ attributes->can_raise = is_software_vector;
+ attributes->can_raise_on = is_software_vector;
+ attributes->can_clear = is_software_vector;
attributes->cleared_by_acknowledge = true;
+ attributes->can_be_triggered_by_message = false;
+ attributes->trigger_signal = RTEMS_INTERRUPT_NO_SIGNAL;
```
--
View it on GitLab:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140671
You're receiving this email because of your account on gitlab.rtems.org.
___
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Joel Sherrill commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140669 The clock tick and benchmark timer are mutually exclusive. It is assumed that the hardware only supports one timer for the RTEMS tests. See [this](https://docs.rtems.org/docs/main/c-user/config/device-driver.html#configure-application-does-not-need-clock-driver) in the Classic API Guide. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140669 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140655 # Testing results ``` rtems/main (RTEMS 7.0.0.9deb5b8…) - tm27.exe: PASS - rhilatency.exe: PASS - ts-validation-one-cpu-0.exe: FAIL (tc-ratemon-timeout.c:597 1 == 0), then watchdog timeout - ts-validation-no-clock-0.exe: TIMEOUT (hangs at ScoreThreadValThread) - ts-validation-intr.exe: FAIL (many RTEMS_UNSATISFIED == RTEMS_SUCCESSFUL in tc-intr-is-pending.c:237), then watchdog timeout - ts-performance-no-clock-0.exe: TIMEOUT (progresses, no END OF TEST) tm27-mb-update (RTEMS 7.0.0.2c38cdf…) - tm27.exe: TIMEOUT (prints overhead lines, no END OF TEST) - rhilatency.exe: PASS - ts-validation-one-cpu-0.exe: PASS - ts-validation-no-clock-0.exe: PASS - ts-validation-intr.exe: FAIL + FATAL (unaligned data access exception), QEMU terminates - ts-performance-no-clock-0.exe: PASS ``` -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140655 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price started a new discussion on
bsps/microblaze/microblaze_fpga/include/tm27.h:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140649
> - } while (0)
> + /*
> + * Program timer1 in generate mode:
> + * - Write TLR1 with the one-shot interval.
> + * - Pulse LOAD to transfer TLR1 into the counter.
> + * - Set ENT to start the counter. The interrupt fires on rollover and the
> + * TINT bit is cleared by writing a 1 to it.
> + *
> + * Give the one-shot a chance to fire before returning. In QEMU, the
> Xilinx
> + * timer model schedules expiry on the virtual clock, so a tiny one-shot
> + * (TLR = 1) does not assert immediately on ENT; the guest must run long
> + * enough for at least one timer tick to elapse.
> + * Empirically, ~7000 nops was the last failing point; doubled to 14000
> + * to add margin.
> + */
> + for ( spin = 0; spin < 14000; ++spin ) {
Maybe we should pull a bit so (spin < 14000 || handler_serviced != 1)
--
View it on GitLab:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140649
You're receiving this email because of your account on gitlab.rtems.org.
___
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price commented: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140647 @joel I think this is causing issues with some tests and might not be a good option. I am trying to run the CPU tests for the cpu usage api. Part of the CPU use api is currently run under a test that needs the tm27 working properly for interrupts. Feel like i am fixing 1 issue but causing others. I could go in and patch qemu to allow for software driven interrupts and follow the spec outlined via xilinx. ``` *** BEGIN OF TEST RHILATENCY *** *** TEST VERSION: 7.0.0.9deb5b8323b71d80ff221105da4ad675e24ceb98-modified *** TEST STATE: EXPECTED_PASS *** TEST BUILD: RTEMS_POSIX_API *** TEST TOOLS: 12.4.1 20240905 (RTEMS 7, RSB no-repo, Newlib 038afec1) Rhealstone: Interrupt Latency - -6 *** END OF TEST RHILATENCY *** [ RTEMS shutdown ] RTEMS version: 7.0.0.9deb5b8323b71d80ff221105da4ad675e24ceb98-modified RTEMS tools: 12.4.1 20240905 (RTEMS 7, RSB no-repo, Newlib 038afec1) executing thread ID: 0x0a010002 executing thread name: TA1 qemu-system-microblazeel: terminating on signal 15 from pid 2600736 (python3) ``` -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140647 You're receiving this email because of your account on gitlab.rtems.org. ___ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
Re: RTEMS | Implement MicroBlaze TM27 via AXI timer (!980)
Sam Price started a new discussion on
bsps/microblaze/microblaze_fpga/include/tm27.h:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140637
> + timer->tlr1 = 1;
> + timer->tcsr1 = control | MICROBLAZE_TIMER_TCSR0_LOAD0;
> + timer->tcsr1 = control | MICROBLAZE_TIMER_TCSR0_ENT0;
>
> -#define Install_tm27_vector( handler ) \
> - do { \
> -(void) (handler); \
> - } while (0)
> + /*
> + * Give the one-shot a chance to fire before returning.
> + * Empirically, ~7000 nops was the last failing point; doubled to add
> margin.
> + */
> + for ( spin = 0; spin < 14000; ++spin ) {
> +__asm__ volatile( "nop" );
> + }
> +}
QEMU would not immediately fire the interrupt,
--
View it on GitLab:
https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/980#note_140637
You're receiving this email because of your account on gitlab.rtems.org.
___
bugs mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/bugs
