On 16.03.23 10:37, Karel Gardas wrote:
On 3/16/23 10:19, Sebastian Huber wrote:
On 16.03.23 10:14, Karel Gardas wrote:
This patch makes MPU setup more generic by adding capability to set
also control register. This way BSPs are allowed to enable MPU
also for hard faults by simply not setting PRIVDEFENA attribute
to control register. Compatibility with previous behavior and API
is preserved.
Is this really a BSP-specific choice or more a user option which
should be controlled by a BSP option (through config.ini)?
config.ini would be even more generic and probably more elegant too.
However for upstreaming I took a more conservative approach to have a
chance.
Let me ask what do you prefer and what will you support? I'm happy to
write that as long as it is reasonable simple and makes chance to
upstream higher.
My goal is simple:
I'm working on BSP for Precidata SL-3011 board. The board is using
STM32H747. Board firmware responsible for hardware management runs on
CM4 while RTEMS and app code will run on CM7 and will be using firmware
services by calling some API. For communication between both domains we
use SRAM4. To be able to print hard fault from RTEMS on CM7 I need either:
- keep cache disabled for SRAM4 region even for hard fault (hence MPU
change proposed)
or
- disable cache in print exception frame directly which involves quite a
bit of hacking around and looks to be more source code invasive than MPU
change.
I would add the ctrl parameter to _ARMV7M_MPU_Setup() and add a
ARMV7M_MPU_CTRL_DEFAULT (default value ARMV7M_MPU_CTRL_ENABLE |
ARMV7M_MPU_CTRL_PRIVDEFENA) BSP option for all Cortex-M BSPs.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@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/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
