On 14/6/2024 10:42 pm, Peter Dufault wrote: > > >> On Jun 14, 2024, at 5:47 AM, Sebastian Huber >> <sebastian.hu...@embedded-brains.de> 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. >
I am not so sure it can be easily simplified. I know of a Zynq or ZynqMP application in a critical system (bare metal, no OS) with the caches disabled for a specific reason. I cannot go into or remember the specific detail. We cannot silently disable functionality. A call must do what it says or return or raise an error. If disabling the data cache is not implement there should be an error. The error would draw the user to the documentation. It is not yet clear we can disable the code in that function. If our kernel code uses atomics then the data cache cannot be disabled. However we should look into the use of atomics and if it is SMP specific and then handle the specific cases. A user can use atomics even if the kernel does not but leaving that to the user to figure out and deal is at best unhelpful and as an OS provider we should help users in these complex corner cases. At a minimum our documentation should cover this and we could update rtems-exeinfo to report a potential issue. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
