What to do with rtems_cache_disable_data()?
Sebastian Huber
sebastian.huber at embedded-brains.de
Fri Jun 14 09:47:59 UTC 2024
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.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.huber at embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
More information about the devel
mailing list