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