Merge request https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1504 was reviewed by Christian Mauderer
-- Christian Mauderer commented on a discussion on spec/build/bsps/aarch64/ls1046a/linkercmds.yml: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1504#note_159881 > > + /* RAM1 is a maximum of 2GiB; RAM2 is a 30 GiB region. RAM3 is a 480 GiB > region. */ > + DRAM1_BASE = 0x80000000; Thanks for the suggestion. I checked the Versal. There is the additional BSP_XILINX_VERSAL_RAM_BASE and BSP_XILINX_VERSAL_RAM_LENGTH. It's basically the more complex calculation in the linker command file that I mentioned. But I still don't see much of an advantage. It just puts a different start address into the BSP using some options. A user of the options would still have to understand how the options are handled in the linker command file. So not much difference to telling a user to use his own linker command file if he wants to adapt the start address. The use case that I usually know for different start addresses are bootloaders. A bootloader that would sit at the beginning of the RAM and then wants to start an application that is loaded at an offset. The usual bootloaders (BL31 or U-Boot) don't have a problem with the application at the start of the RAM. If I write a custom multi-boot-concept with two RTEMS systems (for example the first one fetching an application via network and then booting it with an offset), I personally would prefer to use two linkercmds instead of using two BSP configurations. Another use case could be some partitioning to run Linux and RTEMS on the same system. That's a use case where a user has to know his system in a lot of details and most likely some additional adaptions are necessary. These users most likely have to touch the linkercmds anyway. What use case of a BSP configurable start address do I miss? -- Christian Mauderer commented on a discussion on bsps/aarch64/ls1046a/start/mmu-config.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1504#note_159882 > + .flags = AARCH64_MMU_DATA_RW_CACHED > + }, > + { /* DRAM3; if not used, base == end. In that case, the mmu > initialization ignores this */ Good point. At the moment it's not available yet except if the user adds it to the heap himself. I think we will have to fix that. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1504 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-btn65w9nklr1x17c8hsxvumht-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
