- 03 Jul, 2018 3 commits
-
-
Antonio Nino Diaz authored
It is useful to have LOG_LEVEL_VERBOSE because it prints the memory map of each image, but that also means that the change_mem_attributes and get_mem_attributes functions have verbose prints, and generate a too long text output that hides other useful information. As they were mostly there for debug purposes, this patch removes them. Change-Id: I2986537377d1f78be2b79cc8a6cf230c380bdb55 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
The previous debug output for EL1&0 translation regimes was too verbose, which makes it hard to read and hides the intent behind the parameters assigned to each region. This patch simplifies this output and makes the outputs for EL3 and EL1&0 mostly the same. The difference is that in EL1&0 it is specified whether the region is exclusively accessible from EL1 (PRIV) or both EL0 and EL1 (USER). For example: MEM-RW(PRIV)-NOACCESS(USER)-XN(PRIV)-XN(USER)-S MEM-RO(PRIV)-NOACCESS(USER)-EXEC(PRIV)-EXEC(USER)-S After the change, it becomes this: MEM-RW-XN-PRIV-S MEM-RO-EXEC-PRIV-S Change-Id: I15f4b99058429d42107fbf89e15f4838a9b559a5 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
Instead of having one big file with all the code, it's better to have a few smaller files that are more manageable: - xlat_tables_core.c: Code related to the core functionality of the library (map and unmap regions, initialize xlat context). - xlat_tables_context.c: Instantiation of the active image context as well as APIs to manipulate it. - xlat_tables_utils.c: Helper code that isn't part of the core functionality (change attributes, debug print messages). Change-Id: I3ea956fc1afd7473c0bb5e7c6aab3b2e5d88c711 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 27 Jun, 2018 1 commit
-
-
Jeenu Viswambharan authored
At present, the function provided by the translation library to enable MMU constructs appropriate values for translation library, and programs them to the right registers. The construction of initial values, however, is only required once as both the primary and secondaries program the same values. Additionally, the MMU-enabling function is written in C, which means there's an active stack at the time of enabling MMU. On some systems, like Arm DynamIQ, having active stack while enabling MMU during warm boot might lead to coherency problems. This patch addresses both the above problems by: - Splitting the MMU-enabling function into two: one that sets up values to be programmed into the registers, and another one that takes the pre-computed values and writes to the appropriate registers. With this, the primary effectively calls both functions to have the MMU enabled, but secondaries only need to call the latter. - Rewriting the function that enables MMU in assembly so that it doesn't use stack. This patch fixes a bunch of MISRA issues on the way. Change-Id: I0faca97263a970ffe765f0e731a1417e43fbfc45 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 22 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The values defined in this type are used in logical operations, which goes against MISRA Rule 10.1: "Operands shall not be of an inappropriate essential type". Now, `unsigned int` is used instead. This also allows us to move the dynamic mapping bit from 30 to 31. It was an undefined behaviour in the past because an enum is signed by default, and bit 31 corresponds to the sign bit. It is undefined behaviour to modify the sign bit. Now, bit 31 is free to use as it was originally meant to be. mmap_attr_t is now defined as an `unsigned int` for backwards compatibility. Change-Id: I6b31218c14b9c7fdabebe432de7fae6e90a97f34 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 21 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The XN, PXN and UXN bits are part of the upper attributes, not the lower attributes. Change-Id: Ia5e83f06f2a8de88b551f55f1d36d694918ccbc0 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 14 Jun, 2018 1 commit
-
-
Yann Gautier authored
The issue can occur if end_va is equal to the max architecture address, and when mm_cursor point to the last entry of mmap_region_t table: {0}. The first line of the while will then be true, e.g. on AARCH32, we have: mm_cursor->base_va (=0) + mm_cursor->size (=0) - 1 == end_va (=0xFFFFFFFF) And the mm_cursor->size = 0 will be lesser than mm->size A check on mm_cursor->size != 0 should be done as in the previous while, to avoid such kind of infinite loop. fixes arm-software/tf-issues#594 Signed-off-by: Yann Gautier <yann.gautier@st.com>
-
- 13 Jun, 2018 1 commit
-
-
Antonio Nino Diaz authored
The function xlat_arch_is_granule_size_supported() can be used to check if a specific granule size is supported. In Armv8, AArch32 only supports 4 KiB pages. AArch64 supports 4 KiB, 16 KiB or 64 KiB depending on the implementation, which is detected at runtime. The function xlat_arch_get_max_supported_granule_size() returns the max granule size supported by the implementation. Even though right now they are only used by SPM, they may be useful in other places in the future. This patch moves the code currently in SPM to the xlat tables lib so that it can be reused. Change-Id: If54624a5ecf20b9b9b7f38861b56383a03bbc8a4 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 11 Jun, 2018 1 commit
-
-
John Tsichritzis authored
Rule 21.15: The pointer arguments to the Standard Library functions memcpy, memmove and memcmp shall be pointers to qualified or unqualified versions of compatible types. Basically that means that both pointer arguments must be of the same type. However, even if the pointers passed as arguments to the above functions are of the same type, Coverity still thinks it's a violation if we do pointer arithmetics directly at the function call. Thus the pointer arithmetic operations were moved outside of the function argument. First detected on the following configuration make PLAT=fvp LOG_LEVEL=50 Change-Id: I8b912ec1bfa6f2d60857cb1bd453981fd7001b94 Signed-off-by: John Tsichritzis <john.tsichritzis@arm.com>
-
- 09 May, 2018 1 commit
-
-
Roberto Vargas authored
Using variables as format strings can generate security problems when the user can control those strings. Some compilers generate warnings in that cases, even when the variables are constants and are not controlled by the user. Change-Id: I65dee1d1b66feab38cbf298290a86fa56e6cca40 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 02 May, 2018 1 commit
-
-
Antonio Nino Diaz authored
In AArch64, the field ID_AA64MMFR0_EL1.PARange has a different set of allowed values depending on the architecture version. Previously, we only compiled the Trusted Firmware with the values that were allowed by the architecture. However, given that this field is read-only, it is easier to compile the code with all values regardless of the target architecture. Change-Id: I57597ed103dd0189b1fb738a9ec5497391c10dd1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 26 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
According to the ARMv8 ARM issue C.a: AP[1] is valid only for stage 1 of a translation regime that can support two VA ranges. It is RES 1 when stage 1 translations can support only one VA range. This means that, even though this bit is ignored, it should be set to 1 in the EL3 and EL2 translation regimes. For translation regimes consisting on EL0 and a higher regime this bit selects between control at EL0 or at the higher Exception level. The regimes that support two VA ranges are EL1&0 and EL2&0 (the later one is only available since ARMv8.1). This fix has to be applied to both versions of the translation tables library. Change-Id: If19aaf588551bac7aeb6e9a686cf0c2068e7c181 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 17 Apr, 2018 1 commit
-
-
Antonio Nino Diaz authored
Change-Id: I989c1f4aef8e3cb20d5d19e6347575e6449bb60b Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 09 Apr, 2018 1 commit
-
-
Varun Wadekar authored
The last entry in the mapping table is not necessarily the same as the end of the table. This patch loops through the table to find the last entry marker, on every new mmap addition. The memove operation then has to only move the memory between current entry and the last entry. For platforms that arrange their MMIO map properly, this opearation turns out to be a NOP. The previous implementation added significant overhead per mmap addition as the memmove operation always moved the difference between the current mmap entry and the end of the table. Tested on Tegra platforms and this new approach improves the memory mapping time by ~75%, thus significantly reducing boot time on some platforms. Change-Id: Ie3478fa5942379282ef58bee2085da799137e2ca Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 28 Feb, 2018 2 commits
-
-
Roberto Vargas authored
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined Fixed for: make DEBUG=1 PLAT=fvp LOG_LEVEL=50 all Change-Id: I7c2ad3f5c015411c202605851240d5347e4cc8c7 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
Roberto Vargas authored
Rule 8.3: All declarations of an object or function shall use the same names and type qualifiers. Change-Id: Iff384187c74a598a4e73f350a1893b60e9d16cec Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 27 Feb, 2018 1 commit
-
-
David Cunado authored
MISRA C-2012 Rule 7.3 violation: lowercase l shall not be used as literal suffixes. This patch resolves this for the ULL() macro by using ULL suffix instead of the ull suffix. Change-Id: Ia8183c399e74677e676956e8653e82375d0e0a01 Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 10 Jan, 2018 1 commit
-
-
Antonio Nino Diaz authored
`mm_cursor` doesn't have the needed data because the `memmove()` that is called right before it overwrites that information. In order to get the information of the region that was being mapped, `mm` has to be used instead (like it is done to fill the fields of `unmap_mm`). If the incorrect information is read, this check isn't reliable and `xlat_tables_unmap_region` may be requested to unmap memory that isn't mapped at all, triggering assertions. Change-Id: I602d4ac83095d4e5dac9deb34aa5d00d00e6c289 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 17 Nov, 2017 1 commit
-
-
Antonio Nino Diaz authored
If an implementation of ARMv8.2 includes ARMv8.2-LPA, the value 0b0110 is permitted in ID_AA64MMFR0_EL1.PARange, which means that the Physical Address range supported is 52 bits (4 PiB). It is a reserved value otherwise. Change-Id: Ie0147218e9650aa09f0034a9ee03c1cca8db908a Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 08 Nov, 2017 2 commits
-
-
Antonio Nino Diaz authored
This function can be useful to setup TCR_ELx by callers that don't use the translation tables library to setup the system registers related to them. By making it common, it can be reused whenever it is needed without duplicating code. Change-Id: Ibfada9e846d2a6cd113b1925ac911bb27327d375 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Etienne Carriere authored
ARCH_SUPPORTS_LARGE_PAGE_ADDRESSING allows build environment to handle specific case when target ARMv7 core only supports 32bit MMU descriptor mode. If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_LARGE_PAGE_ADDRESSING to enable large page addressing support. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
- 17 Oct, 2017 2 commits
-
-
Sandrine Bailleux authored
This patch introduces a new API in the translation tables library (v2), that allows to change the memory attributes of a memory region. It may be used to change its execution permissions and data access permissions. As a prerequisite, the memory must be already mapped. Moreover, it must be mapped at the finest granularity (currently 4 KB). Change-Id: I242a8c6f0f3ef2b0a81a61e28706540462faca3c Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Sandrine Bailleux authored
This patch introduces a new API in the translation tables library (v2), that allows to query the memory attributes of a memory block or a memory page. Change-Id: I45a8b39a53da39e7617cbac4bff5658dc1b20a11 Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 05 Oct, 2017 4 commits
-
-
Antonio Nino Diaz authored
This patch introduces the ability of the xlat tables library to manage EL0 and EL1 mappings from a higher exception level. Attributes MT_USER and MT_PRIVILEGED have been added to allow the user specify the target EL in the translation regime EL1&0. REGISTER_XLAT_CONTEXT2 macro is introduced to allow creating a xlat_ctx_t that targets a given translation regime (EL1&0 or EL3). A new member is added to xlat_ctx_t to represent the translation regime the xlat_ctx_t manages. The execute_never mask member is removed as it is computed from existing information. Change-Id: I95e14abc3371d7a6d6a358cc54c688aa9975c110 Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Douglas Raillard authored
Introduce a variant of the TLB invalidation helper function that allows the targeted translation regime to be specified, rather than defaulting to the current one. This new function is useful in the context of EL3 software managing translation tables for the S-EL1&0 translation regime, as then it might need to invalidate S-EL1&0 TLB entries rather than EL3 ones. Define a new enumeration to be able to represent translation regimes in the xlat tables library. Change-Id: Ibe4438dbea2d7a6e7470bfb68ff805d8bf6b07e5 Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Sandrine Bailleux authored
TLB invalidation functions used to be conditionally compiled in. They were enabled only when using the dynamic mapping feature. because only then would we need to modify page tables on the fly. Actually there are other use cases where invalidating TLBs is required. When changing memory attributes in existing translation descriptors for example. These other use cases do not necessarily depend on the dynamic mapping feature. This patch removes this dependency and always compile TLB invalidation functions in. If they're not used, they will be removed from the binary at link-time anyway so there's no consequence on the memory footprint if these functions are not called. Change-Id: I1c33764ae900eb00073ee23b7d0d53d4efa4dd21 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
The current implementation of the memory mapping API favours mapping memory regions using the biggest possible block size in order to reduce the number of translation tables needed. In some cases, this behaviour might not be desirable. When translation tables are edited at run-time, coarse-grain mappings like that might need splitting into finer-grain tables. This operation has a performance cost. The MAP_REGION2() macro allows to specify the granularity of translation tables used for the initial mapping of a memory region. This might increase performance for memory regions that are likely to be edited in the future, at the expense of a potentially increased memory footprint. The Translation Tables Library Design Guide has been updated to explain the use case for this macro. Also added a few intermediate titles to make the guide easier to digest. Change-Id: I04de9302e0ee3d326b8877043a9f638766b81b7b Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 21 Sep, 2017 2 commits
-
-
Antonio Nino Diaz authored
In the S-EL1&0 translation regime we aren't using the higher VA range, whose translation table base address is held in TTBR1_EL1. The bit TCR_EL1.EPD1 can be used to disable translations using TTBR1_EL1, but the code wasn't setting it to 1. Additionally, other fields in TCR1_EL1 associated with the higher VA range (TBI1, TG1, SH1, ORGN1, IRGN1 and A1) weren't set correctly as they were left as 0. In particular, 0 is a reserved value for TG1. Also, TBBR1_EL1 was not explicitly set and its reset value is UNKNOWN. Therefore memory accesses to the higher VA range would result in unpredictable behaviour as a translation table walk would be attempted using an UNKNOWN value in TTBR1_EL1. On the FVP and Juno platforms accessing the higher VA range resulted in a translation fault, but this may not always be the case on all platforms. This patch sets the bit TCR_EL1.EPD1 to 1 so that any kind of unpredictable behaviour is prevented. This bug only affects the AArch64 version of the code, the AArch32 version sets this bit to 1 as expected. Change-Id: I481c000deda5bc33a475631301767b9e0474a303 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Douglas Raillard authored
Use a mmap_region_t as parameter instead of getting a parameter for each structure member. This reduces the scope of changes when adding members to mmap_region_t. Also align on the convention of using mm_cursor as a variable name for the currently inspected region when iterating on the region array. Change-Id: If40bc4351b56c64b214e60dda27276d11ce9dbb3 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 14 Sep, 2017 1 commit
-
-
Douglas Raillard authored
mmap_add_region_ctx and mmap_add_dynamic_region_ctx are clearing members that they are not aware of by copying each member one by one. Replace this by structure assignment. Change-Id: I7c70cb408c8a8eb551402a5d8d956c1fb7f32b55 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 11 Sep, 2017 1 commit
-
-
Douglas Raillard authored
Use the MAP_REGION to build the mmap_region_t argument in wrappers like mmap_add_region(). Evolution of the mmap_region_t might require adding new members with a non-zero default value. Users of MAP_REGION are protected against such evolution. This commit also protects users of mmap_add_region() and mmap_add_dynamic_region() functions against these evolutions. Also make the MAP_REGION macro implementation more explicit and make it a mmap_region_t compound literal to make it useable as a function parameter on its own and to prevent using it in initialization of variables of different type. Change-Id: I7bfc4689f6dd4dd23c895b65f628d8ee991fc161 Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
-
- 24 Aug, 2017 1 commit
-
-
Isla Mitchell authored
This patch enables the CnP (Common not Private) bit for secure page tables so that multiple PEs in the same Inner Shareable domain can use the same translation table entries for a given stage of translation in a particular translation regime. This only takes effect when ARM Trusted Firmware is built with ARM_ARCH_MINOR >= 2. ARM Trusted Firmware Design has been updated to include a description of this feature usage. Change-Id: I698305f047400119aa1900d34c65368022e410b8 Signed-off-by: Isla Mitchell <isla.mitchell@arm.com>
-
- 01 Aug, 2017 1 commit
-
-
Sandrine Bailleux authored
This patch changes the sign of the loop variable used in xlat_tables_print(). It needs to be unsigned because it is compared against another unsigned int. Change-Id: I2b3cee7990dd75e8ebd2701de3860ead7cad8dc8 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 26 Jul, 2017 5 commits
-
-
Sandrine Bailleux authored
Fix the type length and signedness of some of the constants and variables used in the translation table library. This patch supersedes Pull Request #1018: https://github.com/ARM-software/arm-trusted-firmware/pull/1018 Change-Id: Ibd45faf7a4fb428a0bf71c752551d35800212fb2 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
Previous patches have made it possible to specify the physical and virtual address spaces sizes for each translation context. However, there are still some places in the code where the physical (resp. virtual) address space size is assumed to be PLAT_PHY_ADDR_SPACE_SIZE (resp. PLAT_VIRT_ADDR_SPACE_SIZE). This patch removes them and reads the relevant address space size from the translation context itself instead. This information is now passed in argument to the enable_mmu_arch() function, which needs it to configure the TCR_ELx.T0SZ field (in AArch64) or the TTBCR.T0SZ field (in AArch32) appropriately. Change-Id: I20b0e68b03a143e998695d42911d9954328a06aa Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
This patch refactors both the AArch32 and AArch64 versions of the function enable_mmu_arch(). In both versions, the code now computes the VMSA-related system registers upfront then program them in one go (rather than interleaving the 2). In the AArch64 version, this allows to reduce the amount of code generated by the C preprocessor and limits it to the actual differences between EL1 and EL3. In the AArch32 version, this patch also removes the function enable_mmu_internal_secure() and moves its code directly inside enable_mmu_arch(), as it was its only caller. Change-Id: I35c09b6db4404916cbb2e2fd3fda2ad59f935954 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
In both the AArch32 and AArch64 versions, this function used to check the sanity of the PLAT_PHY_ADDR_SPACE_SIZE in regard to the architectural maximum value. Instead, export the xlat_arch_get_max_supported_pa() function and move the debug assertion in AArch-agnostic code. The AArch64 used to also precalculate the TCR.PS field value, based on the size of the physical address space. This is now done directly by enable_mmu_arch(), which now receives the physical address space size in argument. Change-Id: Ie77ea92eb06db586f28784fdb479c6e27dd1acc1 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
In a previous patch, the xlat_ctx_t type has been made public. This patch now makes the *_ctx() APIs public. Each API now has a *_ctx() variant. Most of them were already implemented and this patch just makes them public. However, some of them were missing so this patch introduces them. Now that all these APIs are public, there's no good reason for splitting them accross 2 files (xlat_tables_internal.c and xlat_tables_common.c). Therefore, this patch moves all code into xlat_tables_internal.c and removes xlat_tables_common.c. It removes it from the library's makefile as well. This last change introduces a compatibility break for platform ports that specifically include the xlat_tables_common.c file instead of including the library's Makefile. The UniPhier platform makefile has been updated to now omit this file from the list of source files. The prototype of mmap_add_region_ctx() has been slightly changed. The mmap_region_t passed in argument needs to be constant because it gets called from map_add(), which receives a constant region. The former implementation of mmap_add() used to cast the const qualifier away, which is not a good practice. Also remove init_xlation_table(), which was a sub-function of init_xlat_tables(). Now there's just init_xlat_tables() (and init_xlat_tables_ctx()). Both names were too similar, which was confusing. Besides, now that all the code is in a single file, it's no longer needed to have 2 functions for that. Change-Id: I4ed88c68e44561c3902fbebb89cb197279c5293b Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 25 Jul, 2017 2 commits
-
-
Sandrine Bailleux authored
At the moment, the translation context type (xlat_ctx_t) is a private type reserved for the internal usage of the translation table library. All exported APIs (implemented in xlat_tables_common.c) are wrappers over the internal implementations that use such a translation context. These wrappers unconditionally pass the current translation context representing the memory mappings of the executing BL image. This means that the caller has no control over which translation context the library functions act on. As a first step to make this code more flexible, this patch exports the 'xlat_ctx_t' type. Note that, although the declaration of this type is now public, its definition stays private. A macro is introduced to statically allocate and initialize such a translation context. The library now internally uses this macro to allocate the default translation context for the running BL image. Change-Id: Icece1cde4813fac19452c782b682c758142b1489 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
Sandrine Bailleux authored
Move the header files that provide translation tables architectural definitions from the library v2 source files to the library include directory. This allows to share these definitions between both versions (v1 and v2) of the library. Create a new header file that includes the AArch32 or AArch64 definitions based on the AARCH32 build flag, so that the library user doesn't have to worry about handling it on their side. Also repurpose some of the definitions the header files provide to concentrate on the things that differ between AArch32 and AArch64. As a result they now contain the following information: - the first table level that allows block descriptors; - the architectural limits of the virtual address space; - the initial lookup level to cover the entire address space. Additionally, move the XLAT_TABLE_LEVEL_MIN macro from xlat_tables_defs.h to the AArch32/AArch64 architectural definitions. This new organisation eliminates duplicated information in the AArch32 and AArch64 versions. It also decouples these architectural files from any platform-specific information. Previously, they were dependent on the address space size, which is platform-specific. Finally, for the v2 of the library, move the compatibility code for ADDR_SPACE_SIZE into a C file as it is not needed outside of this file. For v1, this code hasn't been changed and stays in a header file because it's needed by several files. Change-Id: If746c684acd80eebf918abd3ab6e8481d004ac68 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-