> On Jun 14, 2024, at 5:47 AM, Sebastian Huber
> wrote:
>
> Hello,
>
> an user noticed that for example on the Xilinx Zynq 7000 BSP, the
> rtems_cache_disable_data() doesn't work.
>
> I had a look at this and managed to disable the L1 and L2 caches, however,
> afterwards I got not that far. On the Cortex-A cores it seems at least the L1
> data cache is required to provide support for atomic operations:
>
> https://stackoverflow.com/questions/76207164/disabled-dcache-will-prevent-atomic-flag-from-being-set
>
> I guess we have this situation on most modern chips with caches since the
> reservation granule is usually a cache line. How do we want to deal with
> rtems_cache_disable_data() in this case? From my point of view, this function
> as no real use case and adding it in the first place was a mistake.
>
> We have a couple of options:
>
> * Make the rtems_cache_disable_data() directive a no-operation. Afterwards
> the cache is still enabled, and an user may get confused.
>
> * Issue a fatal error if someone calls rtems_cache_disable_data().
>
> * Really disable the cache and let the user figure out that the atomic
> operations no longer work. Disabling the data cache can be a quite complex
> thing to do.
>
> * Add a return status code to rtems_cache_disable_data() and let it return
> RTEMS_UNSATISFIED for example.
Assuming "this function has no real use case and adding it in the first place
was a mistake" how about:
- In the active release continue to disable the data cache but add a warning
attribute 'warning ("Disabling data cache breaks atomic functionality")';
- In the next release change it to an error attribute and change the function
behavior to do nothing except return RTEMS_UNSATISFIED (in case someone somehow
still calls it), or better change it to call an RTEMS fatal function.
Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
