Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143510 I was only going to map the hard IP we have support for in our repos plus the HPM regions in the 32bit address space as they are mapped to PL logic and used by applications. I am fine to see the support organically grow and changes be back ported as new drivers are added. A lack of PL regions support forces users to manage local MMU tables and managing memory above 1G adds another layer of complexity it would be good to avoid and them having code to set the areas dynamically could clash with us adding anything, ie multiple entries in the MMU. I am not sure about mapping everything. For example CoreSight areas should be dynamic. I think this is the simplest place to manage MMU settings for LibBSD without dropping into a deep hole. As I stated above I want to avoid adding extra complexity to that repo. We have the cache coherent memory set by confdefs, there are BSP defined settings and much more now. If this works for other archs/bsp, sure by all means. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143510 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
