Change Details

This page is a brief overview of the coding for initial v8-R64 support, and to help with code reviews . More specifically the goals are: - To briefly summarize the coding done, then - clarify the nature of the files of the three necessarily large patches into more-manageable review slices, and - to clarify some aspects of the patches that are not easy to see from the Gerrit reviews alone. The Gerrit reviews created for this new platform are, necessarily, large. It’s not really feasible to break them down into much-smaller patches, with each independently-compilable pieces. For example, we originally wanted to split https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10518 into one patch for No-EL3, and another for MPU. However, they had to be implemented simultaneously because: - We couldn't do the MPU changes before No-EL3, because no platform that has both EL3 and an MPU exists, and - we couldn't practically do the No-EL3 changes before MPU support, because many (perhaps most) of the EL3-system-register references are in the MMU-library code. We would have had to make many No-EL3 changes to the MMU-library code, only to abandon all of those changes when we switch over to MPU. //**Overview of Implementation and Gerrit Reviews**// The v8-R64 support was added in three distinct steps, each with its associated patch (Gerrit review). - Creating the firmware framework for the new FVP_R platform. - Changes to divert EL3-system-register accesses to corresponding EL2 registers, and creating `.../trusted-firmware-a/lib/xlat_mpu`, an MPU equivalent of the `.../trusted-firmware-a/lib/xlat_tables_v2` MMU library. - Loading System Validation OS as a mockup of the Partner/Customer runtime environment, then transfering control to it. //**Firmware Framework**// This initial patchset is the platform creation of `.../trusted-firmware-a/plat/arm/board/fvp_r`, which includes the framework files adapted from `.../trusted-firmware-a/plat/arm/board/fvp` with some references removed such at BL2, BL31, etc. and different features removed that are not applicable for `fvp_r`. Most of this patch is new files that create the patch, with a few memory map changes needed for R. Link to patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10512 //**No-EL3 and MPU**// This second patch primarily consists of creating alternative functions to those that access EL3 system registers. The alternative functions similarly access the corresponding EL2 system registers. In many cases, new alternative functions were added in new `.../trusted-firmware-a/plat/arm/board/fvp_r/` files. In some cases though, the `#define`d label `NO_EL3` was used to choose between EL3 and EL2 code pieces within an existing function. (This label may be changed to `BL1_AT_EL2`.) Sometimes we used macro parameterization to avoid duplicating too much code, such as with the `el3_common_macros.S` being changed to `el_max_common_macros.S` with a parameter to specify the max EL for the particular core. All references to that had to also change. This patch also involved creating an MPU alternative to the existing `.../trusted-firmware-a/lib/xlat_tables_v2` MMU library. Because MPUs are inherently much-more-limited than MMUs, this new `.../trusted-firmware-a/lib/xlat_mpu` library is considerably simpler than the MMU libraries. Nevertheless, they are still setup via two NULL-terminated (in essence - zero length) arrays of `mmap_region_t`, called `bl_regions` and `plat_regions`. Link to patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10518 //**Load and Hand-off to Customer/Partner Runtime System**// This patchset includes the changes required for loading and jumping to the customer/partner runtime system, in other words jumping from BL1 directly to BL33. In this case, BL33 is intended to be an test-OS binary which we are using to represent the customer/partner runtime system. - Creation of `bl1_load_bl33()` function, much like `bl1_load_bl2()` function in common code to specifically load BL33 that loads and authenticates the partner runtime image. - Addition of `disable_mpu_icache_el2()` and `disable_mpu_el2()` helper functions to disable the MPU before jumping to the next image. - Changes to `bl1_prepare_next_image()` function for preparing the context of the next BL33 image. - Addition of a `bl1_run_next_image()` function where the exception return takes place to jump to the runtime image. - General changes from hardcoded BL2 to BL33 as the next image for BL1. - Move of FIP from NOR Flash0 to DRAM due to the size of the FIP required for our testing purposes for SVOS. - Instantiation of the BL33 image based on SVOS. Note: This patch allows BL1 to jump to the test-OS image. Link to patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10519 //**Files to Review**// How to use this table: - Please see the first column below, "Review Types(s)," describing the high-level nature of – impetus for – that file's edits. It may make sense for a single person to review all of, say, the "MPU" changes. - Each of the three patches has a column – 10512, 10518, and 10519. (Note that number that text functions as a link to the Gerrit review.) - The entries in those three columns chronicle the history of the file for that particular row. For example, the eighth row, for file `.../trusted-firmware-a/plat/arm/board/fvp_r/fvp_r_common.c`... - Was created in the first patch, 10512, thus the "Created" in that column, then - was modifed in the second patch, 10518, thus the "Modified" in that column. - Each of the "Created" or "Modified" markings in these three columns are working links to the particular files in that particular Gerrit review. - Click on them to review that file's changes in that particular patch. - In the case of new files (see the New File? column), please also see the link in the Review Information. - As usual, the Gerrit review for new files shows that file "appearing out of thin air," so to speak. - As you would expect, these were not really created from scratch. - The links in the Review Information column take you to an `sdiff` of the final form of that file (prior to incorporating review comments) compared to the previously existing file from which it was originally made. - Please make review comments in the Gerrit reviews based upon these `sdiff` outputs in the Gerrit reviews as usual. We'll respond and/or make modifications as requested.

PlaceHolder...This page is a brief overview of the coding for initial v8-R64 support, and to help with code reviews . More specifically the goals are: - To briefly summarize the coding done, then - clarify the nature of the files of the three necessarily large patches into more-manageable review slices, and - to clarify some aspects of the patches that are not easy to see from the Gerrit reviews alone. The Gerrit reviews created for this new platform are, necessarily, large. It’s not really feasible to break them down into much-smaller patches, with each independently-compilable pieces. For example, we originally wanted to split https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10518 into one patch for No-EL3, and another for MPU. However, they had to be implemented simultaneously because: - We couldn't do the MPU changes before No-EL3, because no platform that has both EL3 and an MPU exists, and - we couldn't practically do the No-EL3 changes before MPU support, because many (perhaps most) of the EL3-system-register references are in the MMU-library code. We would have had to make many No-EL3 changes to the MMU-library code, only to abandon all of those changes when we switch over to MPU. //**Overview of Implementation and Gerrit Reviews**// The v8-R64 support was added in three distinct steps, each with its associated patch (Gerrit review). - Creating the firmware framework for the new FVP_R platform. - Changes to divert EL3-system-register accesses to corresponding EL2 registers, and creating `.../trusted-firmware-a/lib/xlat_mpu`, an MPU equivalent of the `.../trusted-firmware-a/lib/xlat_tables_v2` MMU library. - Loading System Validation OS as a mockup of the Partner/Customer runtime environment, then transfering control to it. //**Firmware Framework**// This initial patchset is the platform creation of `.../trusted-firmware-a/plat/arm/board/fvp_r`, which includes the framework files adapted from `.../trusted-firmware-a/plat/arm/board/fvp` with some references removed such at BL2, BL31, etc. and different features removed that are not applicable for `fvp_r`. Most of this patch is new files that create the patch, with a few memory map changes needed for R. Link to patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10512 //**No-EL3 and MPU**// This second patch primarily consists of creating alternative functions to those that access EL3 system registers. The alternative functions similarly access the corresponding EL2 system registers. In many cases, new alternative functions were added in new `.../trusted-firmware-a/plat/arm/board/fvp_r/` files. In some cases though, the `#define`d label `NO_EL3` was used to choose between EL3 and EL2 code pieces within an existing function. (This label may be changed to `BL1_AT_EL2`.) Sometimes we used macro parameterization to avoid duplicating too much code, such as with the `el3_common_macros.S` being changed to `el_max_common_macros.S` with a parameter to specify the max EL for the particular core. All references to that had to also change. This patch also involved creating an MPU alternative to the existing `.../trusted-firmware-a/lib/xlat_tables_v2` MMU library. Because MPUs are inherently much-more-limited than MMUs, this new `.../trusted-firmware-a/lib/xlat_mpu` library is considerably simpler than the MMU libraries. Nevertheless, they are still setup via two NULL-terminated (in essence - zero length) arrays of `mmap_region_t`, called `bl_regions` and `plat_regions`. Link to patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10518 //**Load and Hand-off to Customer/Partner Runtime System**// This patchset includes the changes required for loading and jumping to the customer/partner runtime system, in other words jumping from BL1 directly to BL33. In this case, BL33 is intended to be an test-OS binary which we are using to represent the customer/partner runtime system. - Creation of `bl1_load_bl33()` function, much like `bl1_load_bl2()` function in common code to specifically load BL33 that loads and authenticates the partner runtime image. - Addition of `disable_mpu_icache_el2()` and `disable_mpu_el2()` helper functions to disable the MPU before jumping to the next image. - Changes to `bl1_prepare_next_image()` function for preparing the context of the next BL33 image. - Addition of a `bl1_run_next_image()` function where the exception return takes place to jump to the runtime image. - General changes from hardcoded BL2 to BL33 as the next image for BL1. - Move of FIP from NOR Flash0 to DRAM due to the size of the FIP required for our testing purposes for SVOS. - Instantiation of the BL33 image based on SVOS. Note: This patch allows BL1 to jump to the test-OS image. Link to patch: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/10519 //**Files to Review**// How to use this table: - Please see the first column below, "Review Types(s)," describing the high-level nature of – impetus for – that file's edits. It may make sense for a single person to review all of, say, the "MPU" changes. - Each of the three patches has a column – 10512, 10518, and 10519. (Note that number that text functions as a link to the Gerrit review.) - The entries in those three columns chronicle the history of the file for that particular row. For example, the eighth row, for file `.../trusted-firmware-a/plat/arm/board/fvp_r/fvp_r_common.c`... - Was created in the first patch, 10512, thus the "Created" in that column, then - was modifed in the second patch, 10518, thus the "Modified" in that column. - Each of the "Created" or "Modified" markings in these three columns are working links to the particular files in that particular Gerrit review. - Click on them to review that file's changes in that particular patch. - In the case of new files (see the New File? column), please also see the link in the Review Information. - As usual, the Gerrit review for new files shows that file "appearing out of thin air," so to speak. - As you would expect, these were not really created from scratch. - The links in the Review Information column take you to an `sdiff` of the final form of that file (prior to incorporating review comments) compared to the previously existing file from which it was originally made. - Please make review comments in the Gerrit reviews based upon these `sdiff` outputs in the Gerrit reviews as usual. We'll respond and/or make modifications as requested.