Sebastian Huber commented on a discussion on bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/230#note_112343 > (void) source; > (void) code; > > zynqmp_debug_console_flush(); > > + /* > + * This is a workaround for: > + * > + * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 > + */ > + __asm__ volatile (""); > + > while (true) { > - /* Wait */ > + /* Request a soft system reset */ > + *reset_ctrl |= UINT32_C(0x10); As I said, no matter which implementation we choose, there will be always applications for which this choice is wrong. In a complex system like the Zynq UltraScale+ you have to work out your own application-specific reset procedures. The default behaviour should be simple and targeted to RTEMS test suite runs. You can't expect that a BSP solves all your application issues. The APU issues right now also a system reset. Is this good if your safety functions run on the RPU? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/230#note_112343 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
