Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143446 Good question and we circled around this topic until we converged on this solution. This approach is for hard IP logic in the UltraScale. See PL MMU Mappings below. Note, I have a task to update the MMU logic for the UltraScale to match the Versal to support DDR memory above 1G in size. --- ### Dynamic MMU Support in LibBSD We do not want to add RTEMS specific MMU support to any upstream code. It is out of context for the driver and there are complications and usability issues. We considered adding a `SYSINIT` or similar type function to LibBSD in some new `rtemsbsd` code to automatically run however that needs to have linkage references to pull in the runner and that creates reference type connections out into other places, eg BSP or nexus defines and hacks already in LibBSD. We felt this added extra user configuration complexities into what can be viewed as already overly complicated areas. ### User Application MMU I want to try to bring all hard IP address space MMU support into the BSP and user controlled deployment `config.ini` files and to remove the need for users stepping into the area of custom MMU tables in application code or specialized MMU calls for RTEMS provided components. Documentation is often messy and incomplete, building the code an be fragile and debugging is difficult if there is a mistake. ### RTEMS BSP Spec file Option This approach adds a BSP option a user wanting to use PCIe adds to their BSP `config.ini` file. This is an understood workflow these days and user should be encouraged to have and to use a project or site specific `config.ini` file held in their deployment repos and used in their tooling workflows. The RTEMS Deployment repo is an example of such a workflow. Enabling a PCIe MMU option is only part of the support process to have the PCIe driver work. The PCIe logic in LibBSD needs suitable flat device tree entries to configuration the new interrupt model we will be adding to LibBSD. FreeBSD has a new interrupt model for (I think) `aarch64`, `arm` and `riscv` that is configured by FDT entries. This is nice new feature of FreeBSD so well done the developers who have made this change. We welcome it. ### PL MMU Mapping There is also a valid use case to add spec file options to map other UltraScale address spaces to MMU entries. The [TRM Address Space Figure 10-1](https://docs.amd.com/api/khub/documents/xzMsp_c5sG9J6A3u7NkJYQ/content?Ft-Calling-App=ft%2Fturnkey-portal&Ft-Calling-App-Version=5.2.41#G12.398991) shows the AXI high performance full power and half power address spaces user map PL logic into. I feel it is better we provide options to handle these MMU entries so users can avoid providing custom MMU tables or calls n applications. We can then add documentation to the user manual to explain the option and what it does. It also provides an abstraction to our MMU support. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143446 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
