RTEMS | bsps/stm32h7: make errata configurable (!184)

[Cedric Berger (@cedric)]

Cedric Berger commented on a discussion on spec/build/bsps/arm/stm32h7/errata.yml: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/184#note_111151

 > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 > +build-type: script
 > +copyrights:
 > +- Copyright (C) 2024 Karel Gardas
 > +do-build: null
 > +do-configure: |

Ok, so we're on the same page here, which means the PR goes to the wrong direction and is trying to fix the wrong thing:

1. The M7 has a cache, it is used by RTEMS, so 'fixing' the compiler does not help anybody here. Things are fine without any fix as far as regular code is concerned.
1. The M4 used in a few variants (like the stm32h747 we use) has no cache, so a toolchain fix could help there in theory, but nobody in their right mind would configure the M4 to use the FMC for data, these chips have dedicated memories for the M4 (SRAM 1/2/3)
1. What would be hugely useful though for RTEMS and would help us here a lot would be some way to put any memory that is touched by peripheral DMAs into another section. In this case here, if there was an easy way to say: "I want all my data in SDRAM, but please allocate Ethernet mbuf clusters from AXIS or SRAM2", then this would help a lot. the same goes of course for memory that is touched by the USB HOST stack. This is where we're stuck right now.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/184#note_111151
You're receiving this email because of your account on gitlab.rtems.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20240816/fc4000c8/attachment.htm>