<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en" style="--code-editor-font: var(--default-mono-font, "GitLab Mono"), JetBrains Mono, Menlo, DejaVu Sans Mono, Liberation Mono, Consolas, Ubuntu Mono, Courier New, andale mono, lucida console, monospace;">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title>
GitLab
</title>
<style data-premailer="ignore" type="text/css">
a { color: #1068bf; }
</style>
<style>img {
max-width: 100%; height: auto;
}
body {
font-size: .875rem;
}
body {
-webkit-text-shadow: rgba(255,255,255,.01) 0 0 1px;
}
body {
font-family: "GitLab Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Noto Sans",Ubuntu,Cantarell,"Helvetica Neue",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji"; font-size: inherit;
}
</style>
</head>
<body style="font-size: inherit; -webkit-text-shadow: rgba(255,255,255,.01) 0 0 1px; font-family: "GitLab Sans",-apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,"Noto Sans",Ubuntu,Cantarell,"Helvetica Neue",sans-serif,"Apple Color Emoji","Segoe UI Emoji","Segoe UI Symbol","Noto Color Emoji";">
<div class="content">
<p style="color: #777777;">
<a href="https://gitlab.rtems.org/chris">Chris Johns</a>
commented on a
<a href="https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143446">discussion</a>:
</p>
<div class="md" style="position: relative; z-index: 1; color: #3a383f; word-wrap: break-word;">
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">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.</p>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">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.</p>
<hr style="overflow: hidden; margin: 10px 0; border: 1px solid #dcdcde;">
<h3 id="user-content-dynamic-mmu-support-in-libbsd" dir="auto" style="margin-top: 1.5rem; margin-bottom: 1rem; font-weight: 600; font-size: 1.125rem; letter-spacing: inherit; line-height: 1.25; color: #18171d;" align="initial">Dynamic MMU Support in LibBSD<a href="#dynamic-mmu-support-in-libbsd" aria-label="Link to heading 'Dynamic MMU Support in LibBSD'" data-heading-content="Dynamic MMU Support in LibBSD" class="anchor" style="margin-top: 0;"></a>
</h3>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">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.</p>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">We considered adding a <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; margin-top: 0; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">SYSINIT</code> or similar type function to LibBSD in some new <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">rtemsbsd</code> 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.</p>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">We felt this added extra user configuration complexities into what can be viewed as already overly complicated areas.</p>
<h3 id="user-content-user-application-mmu" dir="auto" style="margin-top: 1.5rem; margin-bottom: 1rem; font-weight: 600; font-size: 1.125rem; letter-spacing: inherit; line-height: 1.25; color: #18171d;" align="initial">User Application MMU<a href="#user-application-mmu" aria-label="Link to heading 'User Application MMU'" data-heading-content="User Application MMU" class="anchor" style="margin-top: 0;"></a>
</h3>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">I want to try to bring all hard IP address space MMU support into the BSP and user controlled deployment <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; margin-top: 0; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">config.ini</code> 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.</p>
<h3 id="user-content-rtems-bsp-spec-file-option" dir="auto" style="margin-top: 1.5rem; margin-bottom: 1rem; font-weight: 600; font-size: 1.125rem; letter-spacing: inherit; line-height: 1.25; color: #18171d;" align="initial">RTEMS BSP Spec file Option<a href="#rtems-bsp-spec-file-option" aria-label="Link to heading 'RTEMS BSP Spec file Option'" data-heading-content="RTEMS BSP Spec file Option" class="anchor" style="margin-top: 0;"></a>
</h3>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">This approach adds a BSP option a user wanting to use PCIe adds to their BSP <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; margin-top: 0; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">config.ini</code> file. This is an understood workflow these days and user should be encouraged to have and to use a project or site specific <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">config.ini</code> file held in their deployment repos and used in their tooling workflows. The RTEMS Deployment repo is an example of such a workflow.</p>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">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) <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; margin-top: 0; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">aarch64</code>, <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">arm</code> and <code style="font-size: 90%; color: #18171d; word-wrap: break-word; background-color: #ececef; border-radius: .25rem; font-weight: inherit; overflow-wrap: break-word; white-space: break-spaces; font-family: "GitLab Mono", "JetBrains Mono", "Menlo", "DejaVu Sans Mono", "Liberation Mono", "Consolas", "Ubuntu Mono", "Courier New", "andale mono", "lucida console", monospace; font-variant-ligatures: none; word-break: keep-all; padding: 0.125rem 0.25rem;">riscv</code> 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.</p>
<h3 id="user-content-pl-mmu-mapping" dir="auto" style="margin-top: 1.5rem; margin-bottom: 1rem; font-weight: 600; font-size: 1.125rem; letter-spacing: inherit; line-height: 1.25; color: #18171d;" align="initial">PL MMU Mapping<a href="#pl-mmu-mapping" aria-label="Link to heading 'PL MMU Mapping'" data-heading-content="PL MMU Mapping" class="anchor" style="margin-top: 0;"></a>
</h3>
<p dir="auto" style="color: #3a383f; margin: 0 0 1rem;" align="initial">There is also a valid use case to add spec file options to map other UltraScale address spaces to MMU entries. The <a href="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" rel="nofollow noreferrer noopener" target="_blank" style="margin-top: 0;">TRM Address Space Figure 10-1</a> 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.</p>
<p dir="auto" style="color: #3a383f; margin: 0;" align="initial">It also provides an abstraction to our MMU support.</p>
</div>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #626168;">
—
<br>
<a href="https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143446">View it on GitLab</a>.
<br>
You're receiving this email because of your account on <a target="_blank" rel="noopener noreferrer" href="https://gitlab.rtems.org">gitlab.rtems.org</a>. <a href="https://gitlab.rtems.org/-/sent_notifications/2-3b4h80gckganfc610x665cvv3/unsubscribe" target="_blank" rel="noopener noreferrer">Unsubscribe</a> from this thread · <a href="https://gitlab.rtems.org/-/profile/notifications" target="_blank" rel="noopener noreferrer" class="mng-notif-link">Manage all notifications</a> · <a href="https://gitlab.rtems.org/help" target="_blank" rel="noopener noreferrer" class="help-link">Help</a>
<span style="color: transparent; font-size: 0; display: none; overflow: hidden; opacity: 0; width: 0; height: 0; max-width: 0; max-height: 0;">
Notification message regarding https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143446 at 1771978803
</span>
<script type="application/ld+json">{"@context":"http://schema.org","@type":"EmailMessage","action":{"@type":"ViewAction","name":"View Merge request","url":"https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1073#note_143446"}}</script>
</p>
</div>
</body>
</html>